WordPressのJetPackプラグインを入れ、連携承認しようとしたところ「cURL error 60: SSL certificate problem」で承認できない。
っちょっと調べてみたところ
SSL証明書にあるみたい
っていうことがわかった。
SSL SERVER TESTで証明書をチェックしてみたところ…
中間証明書のところで「USERTrust RSA Certification Authority」が「 期限切れ」ってなっていた。
証明書発行元に確認したところ変更があったらしく、中間証明書を新しくダウンロードして導入してくださいということなので
早速行ったところ無事jetpackの承認ができ、動作できるようになりました。
もうちっとエラーメッセージほしいところだよな。
WordPressのカスタム投稿プラグイン（Advanced Custom Fields：略ACF）を利用したサイトを構築したときにWP REST APIで値を更新する方法をメモしておきます。
※ACFはインストール済みとします。あと、WP REST APIの認証部分も省略します。
function.phpに下記の2行を入れてREST APIの時の設定を表示させます。
// Enable the option show in rest add_filter( 'acf/rest_api/field_settings/show_in_rest', '__return_true' ); // Enable the option edit in rest add_filter( 'acf/rest_api/field_settings/edit_in_rest', '__return_true' );
そうするとカスタムフィールド設定に下記の２つの設定ボタンを表示されます。見ての通りなので、両方とも「はい」にします。
まず、このページを読まないと進みません。
エンドポイントとして
投稿の場合は下記のようなものが用意されています。
/wp-json/acf/v3/posts/{id}
/wp-json/acf/v3/posts/{id}/{field-name}
更新するにあたっては「fields[‘カスタムフィールドで指定した名前’]」にすれば更新できます。
え？更新？更新しかないようで、新規に値を入れることはできないようです。
API流れとして、
・ページ（記事）を作成する
・カスタムフィールドの値を更新する
となります。
じゃあ、リピートフィールドは？ACFの中で便利な機能です。
下記のような形で更新できます。
"fields[repeattext]":[
{
"itemname":"1234",
},
{
"itemname":"あいうえお",
}
],
えーそうなんですよ、更新なので記述が無いものは削除されます。
なんか履歴を追加していきたい！！って思った場合は全件取得して全件ぶっこむようになるのでしょう。。。
今回は、商品に対して、価格の履歴をACFのリピートフィールドで入れたいなって思っていたのでどうしようかな…
2021/12/29追記
公式サイトの記事（https://www.advancedcustomfields.com/resources/wp-rest-api-integration/）によると「Advanced Custom Fields Pro」のversion5.11以降ならこのプラグインだけで値の登録等ができるとのこと。
さっそくやってみた。「ACF toREST API」は無効化。代わりに「Advanced Custom Fields Pro」を有効化。
今回やりたかったのがユーザーにカスタムフィールドを追加してそこに値を入れたかったのでそのようなものを作ってみた
カスタムフィールドを作り、設定欄のアクティブとShow in REST APIをはいにする
「Show in REST API」を「はい」にしないとその項目は登録できないみたいなので注意が必要。
項目の指定方法は
"acf": {
"bikou": "テスト",
}
ACFの配下にフィールド名と値を記述する
これでAPIで項目の格納が可能になった。
ホームページの表示速度を早くしたい！っていう相談が多々きますのでちょっとざっくりとホームページの表示速度ってなんなのかまとめていきたいと思います。
・サーバーの性能
・コンテンツのデータ転送量
が主な要因になります。
基本的にはハードウェア回りのCPU、メモリ、HDD or SSD、ネットワーク回線が主に影響します。
最近のパソコン選びと同じでCPUはそこそこ、メモリは８GB以上、SSDは必須、バックボーンのネットワークは高速が良いです。
さらに、サーバーの性能に含まれてしまう？ケースが多いのが
・WEBサーバーの種類（Apacheやnginx）。現状は、一般的にはngixの方が速いです。
・WordPressを利用しているとPHP5とPHP7の違い
あたりが一般的ななのかもしれません。
これ以外にも単なるOSの環境が単なるLAMP環境よりも高速にチューニングされたkusanagiを利用したほうが断然速いです。
ここでいう速いは、Apache BENCHを利用した結果に影響する部分になります。
この部分がちょっと厄介ですね。日々更新してデータが増えていくので絶対というのは無いですが工夫しないといけないです。
・画像サイズ調整、圧縮
・ScriptやCSS系の圧縮の利用
このあたりは、「Google PageSpeed Insights」や「GTmetrix」でチェックしていけばよいかと思います。そうすると対処する箇所を指摘してくれるので。
これらを総合してのホームページ表示測度となります。
例えば1秒台でホームページを表示したい！って思たら、「サーバーだけ強化すればよい」っていうことはありません。
サーバーとコンテンツの両方を調整して、1秒台になります。また、サーバーに関しては同時アクセスや月間PVがどのくらいなのかによってもスペック調整が必要です。
ちょっと、空いていたサーバーにkusanagiをインストールして速度を図ってみました。
VPSサーバー：メモリ2GB、CPU３コア
GTmetrixだとページ表示までに1.5秒とのこと。まあ、スペックからしてまあよいではないかと思います。（WordPressの初期テンプレ）
じゃあ、サーバーとしての処理能力をは？
apache BENCHで
ab -n 1000 -c 100 http://対象ドメイン/
とした場合
・1秒で処理できるリクエスト
Requests per second: 113.53 [#/sec] (mean) PHP７
1秒なので1か月を秒数（2,592,000秒）に直して計算すると 292,896,000 PV/月。
えーと、２億いくんですか…初期のWordPressってなんもないからな…大したクエリもないので…
・bcacheをオンにした場合
Requests per second: 1412.66 [#/sec] (mean)
はあ。。。も、いっか。
初期テンプレでやっていると現実的じゃないな…
実際のサイトで試したところ、結構なばらつき。（WordPressサイト）
・エックスサーバーで運用しているサイト（なんか、ばらつき大きいな。PHP５と７の違いも大きい）
Requests per second: 5.61 [#/sec] (mean) PHP５
Requests per second: 22.70 [#/sec] (mean) PHP７
Requests per second: 63.22 [#/sec] (mean) PHP７
・お名前.comで2019年のリリースされたサーバー（PHP7で動作）
Requests per second: 86.29 [#/sec] (mean) PHP７
・過去のwpxのサーバー（今は後継がある）
Requests per second: 74.87 [#/sec] (mean) PHP７
すべて、ばらばらなコンテンツが載っているので正確なものではないです。また、共用なので負荷かけるのはまずいので回数等減らしているのであいまいな数字です。
サーバが速くても掲載するコンテンツや作りによって上記のように処理できる量が変わります。
高速だったのに、あれもこれも表示してって追加していったら、処理能力が1/3に落ちたとか結構あります。
あっちからこっちからデータをぐりぐりして持ってくるようなホームページに仕上がったら処理能力が落ちてると思ったほうが良いですね。
キャッシュ系は、処理能力をアップする上で便利ですが、キャッシュなのでドツボにハマるときもあります。
kusanagiの「キャッシュ除外URL」がなぜか反応しないケースが…
httpsをプラグインを入れてやっているので除外URLに
http://～とhttps://～を記述してみた。
http://～/passwordreset/[\w!?/\+\-_~=;.,*&@#$%\(\)\’\[\]]+
とか？簡単そうでなんだかな…
キャッシュ除外URLに空行入れていたら、キャッシュ全て有効になってなかった
正規表現を利用して「/?」が入っているページのキャッシュが除外できないような。
POSTとGETどっちも除外になるのかな？
⇒結局kusanagiのキャッシュは、良いのだが、いうこと聞かないケースが多いので外してみることにした
セキュリティだけじゃなくて、処理能力の面からみてもPHP5は、早くやめてPHP７に変えたほうが良いって結果になりました。
WordPressの「WP OAuth Server」を使ってみました。
よくわからないのでちょっとずつ情報をアップしていこうと思います。
WP OAuth Serverって何？認証に使います。OAuth2が利用できます。
Once the plugin is installed, go to OAuth Server -> Settings to access the global settings. There are two tabs for settings.
The global settings are set to a default state which works for most installs out of the box. Go to the General Settings tab and ensure that “OAuth Server Enabled” is checked.
えーと、管理画面に「OAuth Server」→「Setting」があるから一般とアドバンスの設定をしろよと。
「OAuth Server Enabled」にチェックが入っていると使えるとのこと。
で、アドバンスを見ると
マニュアルはこちら
https://wp-oauth.com/docs/general/grant-types/
無料版だと「Authorization Code」だけ利用できるみたいです。
さてどうするの？
「client」からアプリを登録します。
ここでは、同じドメイン配下で別フォルダにクライアントアプリを用意しました。
で、認証とかどーするの？
やり方はこのページを読めと「https://wp-oauth.com/docs/general/grant-types/」
で無料版で使えるのが「Authorization Code」。
OAuth2をやっている人はどうってことないのかな？
Auth Codeをとるために、「/oauth/authorize」にアクセスする。
次にAccess Tokenをゲットするのじゃ。
あとは、晴れてリクエストをなげよう！！！
なんのこっちゃいっていう人は「https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be」を参照してください。
/oauth/authorize/
/oauth/token/
/oauth/me/
/oauth/destroy/
/.well-known/keys/
/oauth/introspection/
/.well-known/openid-configuration/
があるそうです。
function.phpに下記のフィルターを追加する
add_filter( 'wo_use_grant_request', '__return_true' );
まあ、慣れるまでちょっと時間がかかりそうだ
WordPressで「メディア」＞「任意の画像」＞「画像を編集」をクリックしていったときに添付ファイルの詳細で画像が表示されいことがありましたので対処方法をメモしておきます。
今回は、function.phpを「?>」で閉じてた。💦
なんでしょう。どうしたことでしょうか…閉じておりました(ノД`)・゜・。
他にもこのような事象があったときは、function.phpを見直してみましょう。
今までコンタクトフォーム7を利用していましたが、今一つ、あのプラグインを導入するとこっちのプラグインが動かない等ちょっと面倒くさいことが多かったので「MW WP Form」を使ってみることにした。
・無料
プラグイン本体（https://ja.wordpress.org/plugins/mw-wp-form/）
・有料
フォームジェネレーター
⇒追加スタイルあり
MW WP Form CAPTCHA
プラグイン販売（https://plugins.2inc.org/mw-wp-form/add-on/）
フォームジェネレーターは、簡単に作れるが、自由度は減る。でも、大抵は問題ないのでは？？
ゴリゴリやってもいいんだけど変更も多いからGUIでちゃちゃっと変更したいから導入した
⇒スタイルはビジネスタイプがよかったので追加した。
※XXXは、ルール名
「mwform_validation_rules」でフィルターを追加して独自の値チェックルールを作ることができた。
add_filter( 'mwform_validation_rules', 'mwform_validation_rule_XXX' );
「public function rule( $key, array $options = array() )」で$optionsに設定値を引き渡すのが最初よくわからなかった。
nameのところで最後に[XXX]で指定すればいいらしい。
name="<?php echo MWF_Config::NAME; ?>[validation][<?php echo $key; ?>][<?php echo esc_attr( $this->getName() ); ?>][XXX]"
ログイン情報は「https://plugins.2inc.org/mw-wp-form/manual/」を参照すれば利用可能。
あとは、filterで自分で作れるのでACFで定義した値も取得することが可能
add_filter( 'mwform_value_mw-wp-form-フォームID', 'my_mwform_value', 10, 2 );
用意されている。
用意されている。
これで作りたかったフォームができるかな・・・？
重複禁止！っていうフォームを用意したいと思ったのでちょっと実現できるのか調べてみました。
基本的にはデータは「post」「postmeta」で構成されているようなのでカスタム投稿と投稿者、フォームIDで抽出可能。
あとは「get_post_meta」で「tracking_number」を取得すれば、問い合わせ番号がわかる。
※ログインユーザー限定。
完了画面URLだけ指定していたら、確認画面等でこのメッセージが表示されるようになった。
対処としては、全ての画面のURLを入れればよいようだ。
例：reportというページでフォームを作っていて、完了ページをthanksとした場合は下記のような感じ
「mwform_choices_mw-wp-form-xxx」フィルターフックすれば可能「xxx」はフォームID
表示される毎に並び順が変わります。クイズや選択肢の位置を固定したくない場合に利用可能
あれ、確認画面で表示が異なることがある・・・なんだろうか..
function func_choices_random( $children, $atts ) {
if ( $atts['name'] == 'フォームのネームの値' ) {
shuffle($children);
}
return $children;
}
add_filter( 'mwform_choices_mw-wp-form-xxx', 'func_choices_random', 10, 2 );
→これだと呼び出される毎にランダムになってしまう。そのため、確認画面でもずれてしまう。
POSTしたときに送っている値は自動的に出力されてる「0,1,2…」の値である。
単純にシャッフルしただけだとフォームの戻り値が0,1,2…ってなってしまう。
っていうことでいっそのこと、VALUEと表示値を指定して返すことにしてみた。
フォームのVALUEの値が指定した値になり、ランダムが実現したよ～。
function func_choices_random( $children, $atts ) {
if ( $atts['name'] == 'フォームのネームの値' ) {
$shuffle = $children;
shuffle($shuffle);
$children = array();
foreach ($shuffle as $value)
{
$children += array($value => $value );
}
}
return $children;
}
add_filter( 'mwform_choices_mw-wp-form-xxx', 'func_choices_random', 10, 2 );
完了画面へのコンテンツ渡しのフィルターですが2回通るようです。
wp_insert_userを利用すると完了画面が一瞬表示されるが最初のフォーム状態に戻される
MW WP Form version 4.4.2で試した。
今後のためにもメモとして残しておくがどうなんだろうか・・・。
「mwform_complete_content_mw-wp-form-xxx」を利用したいと思うが「wp_insert_user」を利用すると完了画面が一瞬しか表示されないし、2回何故か通っていた？？なんだかわからない。
っていうことでちょっと創意工夫してみたもんだ。
「mwform_after_send_mw-wp-form」というアクションフックがある。メール送信後の追加処理らしい。
このアクションフックで「wp_insert_user」を実施してみた。
その後、入力画面へリダイレクトさせる。
ざっくりと下記のようなイメージ。
なぜか、「registration」はフォームの入力画面。やってみた結果ベースさ。
※一度、結果を表示しないと次に「registration」アクセスしたときに結果が表示されたので矯正リダイレクトしてみた。
これだと完了画面にエラー内容を表示できないという問題はあるけどそれは諦めです。
add_action( 'mwform_after_send_mw-wp-form-xxx', 'my_mwform_complete_useradd' );
function my_mwform_complete_useradd( $Data ){
//ユーザー追加
$userdata = array(
'user_login' => $user_id,//ユーザ名
'user_pass' => $password,//パスワード
'last_name' => $last_name,//ユーザー姓
'first_name' => $first_name,//ユーザー名
'user_email' => $email,//email
);
$user_id = wp_insert_user($userdata);
wp_redirect( '/registration/' );
exit();
}
ときにはシステムのルールなんてっていう事象が多いのが現状！！
PDF Embedderは無料で簡単にPDFをWordPress内に埋め込みできるプラグインです。今回はその先にあるセキュアなことに意識て有料のプラグイン「PDF Embedder Secure」を試してみました。
価格的には3,500円程度。（１サイト版）
・無料版と有料版では別プラグインとして認識するみたいですが、どちらか１つしか有効にできません。
※ショートコードは無料版のまま利用できます。
・メイン設定
連続ページにチェックが最初入っているので外すと無料版と同じ感じ
ツールバーの表示がマウスオーバーになっているので「ツールバーを常に表示」にする
・安全です
英語メニューです。
Secure PDFs ： メディアにアップするとPDFがsecurepdfsというフォルダに入るとのこと
Disable Righlt Click：右クリック禁止
Cache Encrypted PFDs:安全なPDF（暗号化）でサーバーのキャッシュを利用するとのこと（ダウンロード速度アップ）
Text to display on secure PDFs: PDFに表示するテキスト
ここに記述したテキストがスライド上に表示されます。fullname, username, emailが利用できるとのこと。
セキュアのところにアップしたものだけ対象らしい。
そうするとダウンロードだけのリンクも作れないとちょっと物足らない…っていうことで調べてみた。
下記のようにすることでダウンロードリンクができる。
/?pdfemb-serveurl={urlencode(PDFのURL)}&pdfemb-nonce={nonceの値}
え？nonceの値はコードを見てみたら…
wp_create_nonce('pdfemb-secure-download-' . {URL});
ってな感じ。
いやいや、ショートコードでダウンロードするためのリンク作成が用意されていたよ。解説には書いてなかったような。。。
[pdf-direct-link url="PDFのURLを記述する"]ダウンロードはこちら[/pdf-direct-link]
これでダウンロードへのリンクが記述される。
WP USERFRONTENDからPDFファイルをアップロードしてもセキュアに入りました。
下記のような設定を追加するとのこと。元情報はこちら
location ~ ^/(wp-content/uploads/securepdfs) {
allow 127.0.0.1;
deny all;
}
kusanagiに不慣れなので反映しないで苦戦してたら、上位の方に記述したら反映した。何が影響しているのかな…
「読み込み中…」となり、表示されません。
WordPressの記事を「WP All Import」でざくざくインポートしよう！！っておもって試してみました。
確かに、CSVやEXCELから記事、ACF、タームの利用が可能！！
・Excelから改行含んだ複数行テキストをインポートしたときに改行あたりに予期しない文字が入る
⇒CSVならOK
・タームのスラッグを指定しているがなぜか、新しくtermが作られる
⇒毎回同じ行なので、データに問題？？
・インポートしたユーザーデータがSKIPされた
→何件スキップしたのかって出る割には、どのデータがスキップしたのかわかりにくい。
その場合は「WARNING Sorry, 」として記述されている文面をログから探すと良い。
メールアドレスが重複している場合は「WARNING Sorry, that email address」と記述されている。
ユーザーの場合は、ユーザー一覧をエクスポートしてユーザー登録日で判別するのもありかもしれないが、どちらにしろ大変
WordPressのアップロードしたファイルは通常メディアに格納され
ファイル格納先のフォルダはhtaccessで閲覧できないようになっている。「wp-content/uploads/download-manager-files」
RewriteEngine On <Files *> Deny from all </Files>
こちらもアクセス禁止となっている。「wp-content/uploads/wpfd」
deny from all
・良いところ
フロントからファイルアップロードができる
IMGやPDFは、権限が許可されていれば、File direct linkにかかれているURLで「IMG SRC＝」や「[pdf-embedder url=””]」で開くことが可能
ファイルは全体で管理者が管理するタイプ
直リンクでファイルが見れない
・気になる点
ディレクトリの階層ができない？？
権限設定はグループのみ
もう少し細かく設定したい
えーと、有料版も入れてみました。
・よいところ
個人のフォルダができ、そこにファイルをアップロードできる。
フロントからも投稿。むしろフロントがメイン？
・わるいところ
直リンクでファイルにアクセスできる！？？(ノД`)・゜・。
⇒むしろ直リンクで画像表示を管理画面でも利用しているようんだ…htaccessでアクセスできないようにしてみたらだめだった…あー、失敗,,,,
これは指定しないとuploadsフォルダ配下にファイルを見たいだ。FTPにもつながるようだ
https://wordpress.org/plugins/frontend-uploader/
このプラグインは、フロントからメディアへアップロードするプラグイン
https://ja.wordpress.org/plugins/memphis-documents-library/
member投稿が可能且つプライベートと共有ができるみたい
管理者が行うのであれば「wp file download」が良いかな
個人がファイルをアップロードして…ってなるとどれもこれも微妙…
ＷＥＢサーバーの性能測定を行いたいと思い、ひさびさにＡＢコマンドを使ってみることにしました。
久しぶりに使うとなんだったか忘れてしまいますね。
基本的には下記の記述になります。
ab -n ＜総リクエスト数＞ -c ＜同時リクエスト数＞ ＜URL＞
例えば、100ユーザがhttp://exampleに10リクエストを発行した場合を想定。
ab -n 1000 -c 100 http://example/
・結果
Server Software: nginx ： WEBサーバーのソフト名
Server Hostname: <ホスト名> ：サーバーホスト名
Server Port: 80：サーバーのポート番号
Document Path: / ： ドキュメントパス
Document Length: 27411 bytes ： ドキュメント容量
Concurrency Level: 100
Time taken for tests: 8.418 seconds
Complete requests: 1000 ：リクエストの成功回数
Failed requests: 0 ： リクエストの失敗回数
Total transferred: 27771000 bytes
HTML transferred: 27411000 bytes
Requests per second: 118.79 [#/sec] (mean) ： 1秒間で処理されたリクエスト数
Time per request: 841.816 [ms] (mean)
Time per request: 8.418 [ms] (mean, across all concurrent requests)
Transfer rate: 3221.62 [Kbytes/sec] received：1秒間で受信したデータ数
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 8.2 0 65
Processing: 104 811 124.2 824 1084
Waiting: 39 810 124.6 824 1084
Total: 113 812 124.2 824 1107 ： 合計でどれくらいかかったかの時間
Percentage of the requests served within a certain time (ms)
50% 824 ： 50%リクエストが0.824秒以内に返ってくる
66% 847
75% 860
80% 869
90% 901
95% 964
98% 1013
99% 1034
100% 1107 (longest request)
で、何がいいんだか悪いんだか分らん…いろいろと見比べながら…
試験にかかった時間。数値が低いのが良い
処理に失敗したリクエストの数。数値がひくのが良い。基本０で考えるのかな
1秒で処理できるリクエスト数。数値が高い方が良い
1リクエストにつき処理に要した時間。数値が低い方が良い
1秒間で受け取ったデータの大きさ。数値が高い方が良い
数値が低いほうが良い
リクエストを完了するにかかっている時間なので数値が低いほうが良い。
ってな感じです。わかったようなわからないような…