年に何度か忘れるのでメモ。
サイト内でFont Awesomeを利用していることが前提です。

Webアイコンフォント『Font Awesome』普通の使い方

サイト内でFont Awesomeを利用する場合、まず公式サイトで名前（クラス）を確認して

使いたい場所で[html]<i class="fa fa-○○"></i>[/html]のような感じで使います。
例えば「send」なら

[html]<i class="fa fa-send"></i>[/html]で表示されます。

※上記例はFont Awesome4.7で、現行バージョン5の場合はclass=”faの「fa」の部分がスタイルにより「fas」（Solid）、「far」（Regular）のように若干異なります。

Contact Form 7の送信ボタンで『Font Awesome』を使う

通常の方法でContact Form 7の送信ボタンにFont Awesomeを設定してみます。

確認すると、フォントアイコンは反映されず、テキストもデフォルトの「送信」になっています。

Chromeの「検証」で確認しても、入力したタグはきれいさっぱり消えています。

多分ContactForm7のsubmitフォームタグ内部ではタグの利用は排除されているのでしょう。

Font Awesomeの文字コードを使う

そこで、クラスでは無く通常のテキストと同じようにFont Awesomeを扱ってみます。
これは、IllustratorやパワポなどでFont Awesomeを使う場合と同じ方法です。
公式チートシートで文字コードを確認します。

該当のアイコンを見つけ、文字コードをコピーします。

submitフォームにペーストします。

次にCSSでフォントファミリーを指定します。

Font Awesomeのフォントファミリーを指定

[css].wpcf7-submit {
font-family: FontAwesome;
}[/css]
のような感じで該当箇所にフォントファミリーを指定します。

送信ボタンにFont Awesomeアイコンが表示されました！

投稿 Contact Form 7の送信ボタンにFont Awesomeアイコンを追加する は studioDoghands に最初に表示されました。

大量の記事のカスタムフィールドの内容を、新規で作成したカスタムタクソノミーに移動したい。
リニューアルや引き継ぎ案件でたまーに発生する作業です。

まず、サイトに掲載するデータをカスタムフィールドにするか、カスタムタクソノミーにするか、これは明確な場合もあれば、迷う場合もあります。
データが一意であればカスタムフィールドにしておけば良いのですが、サイトを長らく運用しているうちに「あれ？これ結構何回も使うぞ？カスタムタクソノミーにして選択式の方が良かったかも。」という状況が発生することもあります。

例えば、
毎回異なる調味料を紹介するサイト。カスタムフィールド「今日の調味料」を作成。
数年経つうちにレシピサイト寄りに路線変更。また、最初は単発の扱いであった「ハリッサ」のレシピが好評で、カスタムフィールド「今日の調味料」に「ハリッサ」が登録されている記事だけでも数十に。

こんな場合、明らかに「今日の調味料」はカスタム投稿タイプにしておいた方が運用が楽で、また「ハリッサを使ったレシピ一覧」の表示も簡単です。

弊社では「後々面倒にならない。運用が楽」であることを最も重視しているので、上記のようなことはめったに起こりませんが、既存のサイトではたまにみる設計です。

今回は、「カスタムフィールド」を利用して多くの記事を書いてしまったが、この「カスタムフィールド」に登録した単語を「カスタムタクソノミー」に移動、記事の他の部分には手を加えない。という作業をしてみます。

作業の順序

作業の順序はこのような感じになります。
1.カスタムフィールドを含んだ投稿をCSVでエクスポート
2.タクソノミー登録用にCSVを加工する。
3.タクソノミーを一気に登録する。
4.タクソノミーと関連付けた投稿CSVをインポートして投稿を上書き
5.カスタムフィールドの削除等の仕上げ

それでは実際に作業してみます。

1.カスタムフィールドを含んだ投稿をCSVでエクスポート

これはプラグインを利用します。
今回は「WP All Export」を使ってみましょう。

投稿タイプを選択してから、エクスポートするデータの項目の設定に進みます。

エクスポートするデータを選択します。
プラグイン「Advanced Custom Fields」（ACF）を利用したカスタムフィールドのラベルは「ACF」に表示されています。
該当のラベルを中央にドラッグします。

インポート時はIDで上書きする投稿を判別するので、「Title」や「Content」は枠外にドラッグしてクリアしても良いでしょう。

設定完了後、CSV形式でローカルに保存します。

2.タクソノミー登録用にCSVを加工する。

ローカルに保存したCSVは
・タクソノミー登録用
・投稿上書き用
の2種類に分けることになります。
まずは「タクソノミー登録用」にCSVを加工しましょう。

GoogleスプレッドシートにCSVをアップする

エクセルでもLibreOfficeでも何でも良いと思いますが、今回はGoogleスプレッドシートで加工してみます。
空のスプレッドシートを作成し、ローカルのCSVをインポートします。

「現在のシートを置換する」をチェックしてインポートします。

こんな感じでずらっと表が作成されます。

タクソノミー作成用の表を作るので、まずはシートをコピーして「タクソノミー抽出作業」のような名前を付けておきましょう。

Googleスプレッドシートで加工

加工に入ります。
この作業では、カスタムフィールド以外の情報は必要が無いので削除しておきます。
下の場合、「Id」と「Title」列は必要ありません。

下はカスタムフィールドのみ残した列のイメージです。
fruitsというフィールドに、みかんやいちご等の単語が並びます。
これらをタクソノミーとしてサイトに登録するために、まずは「重複」を消していきます。

単語の重複を排除する

重複の削除は簡単です。

列を選択して、上部の「データ」から「重複を削除」をクリックして完了です。

重複が削除されました。

基本的な加工は一旦ここまでにして、「3.タクソノミーを一気に登録する。」に進みます。

3.タクソノミーを一気に登録する。

まずは移行対象となるタクソノミーをサイトに登録しておきます。
例えば、カスタムフィールドの項目「Fruits」をタクソノミーに移動したい場合は「Fruits」や任意の名前でタクソノミーを作成します。
「Custom Post Type UI」等のプラグインを利用しても良いでしょう。

このタクソノミーに個々の単語（ターム）を一括で登録する為、プラグインを利用してみます。

今回は「WP Taxonomy Import」を使います。
※長らく更新されていない為、管理画面からのプラグイン検索結果には表示されず、ダウンロードしてインストールする必要があります。

プラグインを有効可して、「設定」→「Taxonomy Import」から設定画面を開きます。

プルダウンから登録しておいたタクソノミーを選択し、フォームにタームを記入していきます。
タームの入力方法は下記の通りです。
・デリミタで区切るとタームとスラッグを同時で登録可能（デフォルトのデリミタ: $ ）
例:りんご$ringo
・タームの親子関係は->で指定可能
例
Toyota->rav4
Toyota->ch-r

スラッグも登録しておく

ということなので、先程作成した表にスラッグも追加してみます。
コツは間に一列を追加し、セルにデリミタ（$）を入れておくことです。

こうしておけば、表をコピーして

エディタ（ATOMやSublime Text、VS Code等何でも良いです）にペースト

余計な空白を置換して削除すれば、「Taxonomy Import」に使えるテキストが完成します。

※画像では一列目（fruits$スラッグ）までコピーしてしまっていますが、ここは必要ありません。

「Taxonomy Import」にテキストをペーストして、タクソノミーをインポートします。

ここまでで、カスタムフィールドに登録されていた単語を特定のタクソノミーのタームとして登録することができました。

4.タクソノミーと関連付けた投稿CSVをインポートして投稿を上書き

後は投稿とタクソノミー（のターム）を紐付けて、既存の投稿を上書きします。

「1.カスタムフィールドを含んだ投稿をCSVでエクスポート」で作成し、スプレッドシートにアップした表を利用します。

投稿の一括登録（上書き）には、プラグイン「Really Simple CSV Importer」を利用してみます。

このプラグインも長らく更新が無く、ダウンロードしてインストールが必要になります。

「Really Simple CSV Importer」の基本的な使い方

基本的な使い方は、プラグイン製作者様のこちらの記事が一番わかり易いです。

CSVの各項目のタイトルをルールに沿ってリネームし、WordPress管理画面「ツール」→「インポート」→「CSV」からインポートを実行します。

「Really Simple CSV Importer」用に表を加工する

今回は既存の記事に、新規設定したタクソノミーを登録するだけなので、表はシンプルです。
必要なのは記事IDとタームのみです。後は、投稿タイプの指定も推奨されているので追加しておきます。

元の表。実際はTitleの列も必要ありません。
エクスポートしたカスタムフィールドの項目名を、今回登録したタクソノミー名に変更します。

「Really Simple CSV Importer」ではタクソノミーを登録する際、下記のルールがあります。
・列名は「tax_タクソノミー名」。例えばfruitsならtax_fruits
・タクソノミーとタームは登録済である必要がある※この為、「3.タクソノミーを一気に登録する。」の作業をしておく必要があります。

今回の作業で最低限必要なのは、このようなイメージの表です。※ポストタイプは必須ではありませんが、指定が推奨。

加工した表をCSVとしてローカルに保存

表の加工が完了したら、「ファイル」→「ダウンロード」からCSV形式でローカルに保存します。

WordPress管理画面からインポート画面（「ツール」→「インポート」→「CSV」）から先程のCSVを選択して、インポートを実行して完了です。

5.カスタムフィールドの削除等の仕上げ

後は、利用しないフィールドの削除、管理画面で該当するカスタムタクソノミーの表示、サイト側の表示コードの修正、等の仕上げを行います。

カスタムフィールドのデータを削除「Delete Custom Fields」

「Advanced Custom Field」から項目を削除しても、以前に入力し、記事に紐付けられているデータは残ったままなので、データベースから削除、またはプラグインを利用します。

これまた長らく更新されていないプラグインなので、下記ページからダウンロードしてインストールが必要です。
利用時には念の為サイトのバックアップを取っておきましょう。
Delete Custom Fields

「ツール」→「Delete Custom Fields」から、データを削除するカスタムフィールドを選択し、実行します。

記事に紐付けられていたカスタムフィールドのデータが削除されます。

最初の設計が肝心

如何でしたでしょうか？
ホームページの設計時に、カスタムフィールドとカスタムタクソノミーの特性を理解しておけば、このような作業は必要ありません。
・後でまとめて表示したいかも
・何回も使うかも
と思うような項目は、カスタムタクソノミーの利用を考えましょう。

引き継いだサイトの中には、繰り返されるセミナーの開催地や、採用ページの勤務地がカスタムフィールドとして設計されているサイトもありました。
つまり、管理画面から毎回毎回同じような住所を記入しなければならないのです。
このような場合は、カスタムタクソノミーで地名を選択式にしておき、連動する要素（住所、アクセス、地図）を自動で出し分ける方が運用が楽でしょう。
カスタムフィールドで選択式にしておく方法もあると思いますが、この場合「同じ会場で開催されているセミナー一覧」「同じ勤務地で募集している採用一覧」などの表示が面倒です。

これからサイトを作る場合は後々運用が面倒にならないように、慎重に設計しましょう。

投稿 カスタムフィールドで登録した情報をやっぱりカスタムタクソノミーに移行してみる は studioDoghands に最初に表示されました。

PHP開発IDE「PhpStorm」には、ファイルを変更すると自動でFTP接続と該当ファイルのアップロードを行う機能があります。
リモートサーバだけでは無く、ローカルフォルダも対象にすることができます。

まず、
Preferences→Build, Execution, Deployment→Deployment
で接続対象とアカウント、ディレクトリ等を入力（このあたりは通常のFTPソフトと同じです）します。

その後、
Preferences→Build, Execution, Deployment→Deployment→Options
の「Upload changed files automatically to the default server」を「Never」から「Always」か「On explicit save action」に変更します。

アップロード対象除外ファイルの設定

この自動アップロード機能では、任意のファイルを対象から外すことができます。
※Filezilla等、多くのFTPソフトでも同様の機能があります。
例えばメモやGit関連、Gulp関連、最終的なCSS以外のSASSファイル等です。

設定はFTPアカウント管理画面の「Excluded Paths」から行います。
例えば私が良く利用するBootstrap4のスターターテーマ「UnderStrap」の子テーマでは下の画像のようになります。

さて、この「Excluded Paths」ですが、設定が面倒な割に「複製」や「設定の書き出し」が見当たりません。
実はこれらの情報はプロジェクトフォルダに作成される「.idea」ディレクトリの「deployment.xml」ファイルに記載されています。
※参考:公式サイト「プロジェクトの作成と管理」

「.idea」フォルダの確認

「.idea」ファイルは見ての通り「.（ドット）」から始まるファイルで、多くのMacの設定では「.htaccess」同様、不可視ファイルとして扱われるため、Finderでも表示されません。
不可視フォルダを表示するMacのショートカットキーは「command（⌘）」 + 「shift」 + 「.」です。
これで「.idea」フォルダが表示されます。

deployment.xmlの確認

「deployment.xml」をクリックして開きます。

paths→serverdata→excludedPathsノードに除外ファイルの情報が保存されています。

これを他のプロジェクトのdeployment.xmlにコピーして利用することが可能です。

投稿 PhpStormの自動アップロード機能、除外ファイル設定をコピーして利用する は studioDoghands に最初に表示されました。

サイトの多言語化プラグインの定番「WPML」で、お問合せフォームプラグインの定番「コンタクトフォーム7」の各項目の翻訳をしてみましょう。

考えられる翻訳方法

コンタクトフォームの翻訳は次の方法が考えられます。
A:言語ごとにコンタクトフォームを作成し、各言語の固定ページにそれぞれのショートコードを反映。
B:専用のプラグイン、「Contact Form 7 Multilingual add-on」を利用して、ひとつのショートコードから生成されるフォームを言語で分岐。
今回はBの方法を試してみます。

必要な環境、プラグインなど

WPMLの初期設定は終了している前提です。
また、日本語でのコンタクトフォーム7の作成も完了しておきます。
その他必要なプラグインは下記の通りです。WPMLにログイン後、ダウンロードページからダウンロード、アップロード後有効化しておきましょう。
「String Translation」
「Translation Management add-on」
「Contact Form 7 Multilingual add-on」

コンタクトフォーム7の翻訳

それではフォームを翻訳していきましょう。

WPML→翻訳管理から、コンタクトフォームを絞り込み検索します。

今回は「base」と名前を付けたコンタクトフォームを多言語化してみます。
該当のフォームを選択して言語を選び、「翻訳バスケットに選択したコンテンツを追加」をクリックします。

翻訳バスケットに移動し、トランスレーターを選び（もちろん自分で構いません）、「全てのアイテムを翻訳に送信する」をクリックします。

WPML→翻訳をクリックします。

「翻訳する」をクリックします。

とりあえず今回は青の「自分で翻訳する」を選択してみます。

各項目を選択し、翻訳していきます。

雷マークは自動翻訳なので、使ってみましょう。

返信メールも同様に修正します。

編集が完了したら、「Finish」を押して完了します。

これで、ひとつのお問合せフォームショートコードで複数の言語への対応が可能になりました。

フォームは、「お問合せ」からも多言語編集することができます。
項目をがっちりと変更（フリガナを削除したり、郵便番号からの自動住所反映コードを変更したり、等）する場合はここから修正した方が早いかもしれません。

後は微調整

後は設計による誤差の微調整を行います。このフォームの場合、「必須」テキストがCSS（SCSS）の疑似要素で設定されている様子で、英語版でも「必須」のままです。

修正にはいろいろな方法（英語フォームでは読み込むCSSを変更したり、英語フォームにIDを付けてCSSを分岐等）がありそうですが、今回は「:lang擬似クラス」を使ってみます。
使い方は「要素名:lang(言語コード) {プロパティ名:値;}」で、言語コードはこちらを参照してください。ja（日本語）、en（英語）、es（スペイン語）、fr（フランス語）、zh（中国語）のような感じです。

CSS(SCSS)に追加してみます。

修正されました！

投稿 WPMLでコンタクトフォーム7の翻訳をしてみよう は studioDoghands に最初に表示されました。

先日、当サイトで全てのタクソノミーの表示が消えました。
エラーでは無く、カテゴリーやカスタムタクソノミーのタームが全く登録されていないのと同じ状況です。

例えば、下のようなデフォルト投稿タイプのカテゴリー表示コードが全く動作しない状態です。

[php]
<?php if ( get_post_type() === ‘post’ ): //デフォルト投稿タイプ ?>
<?php
$category = get_the_category(); //カテゴリーは配列で取得
if ( isset( $category[0] ) ) { //カテゴリーの最初のひとつだけ表示
$category_link = get_category_link( $category[0]->term_id );
$category_name = $category[0]->cat_name;
$category_slag = $category[0]->category_nicename;

$link = ‘<a href="’ . $category_link . ‘" class="cat ‘ . $category_slag . ‘">’ . $category_name . ‘</a>’;
esc_html( $link );
}
?>
<?php endif; ?>
[/php]

こういったカテゴリーの表示も消えました。

まず一通り確認

get_the_category()やget_the_terms()を使ったコードが全て表示されず、エラーも吐き出さない状態。
コードは全て
[php]if ( isset( $category[0] ) ) {[/php]
のように、該当するタームがある場合のみ表示する条件なので、ターム自体が認識されていない状況です。

この場合考えられるのは
・PHPアップデートによる関数の制限またはバグ
・タクソノミーまたはタームが消えた
・WordPressアップデートによるエラー
・プラグインの干渉
諸々です。
サイト内の一部の不具合なので、サーバメンテナンス等の可能性はとりあえず除外して良いでしょう。

管理画面では、カテゴリーやカスタムタクソノミーのタームは問題無く存在していた為、次に
カスタム投稿タイプ操作プラグイン「Custom Post Type UI」を一旦停止して様子を見てみましたが、状況は変わらず。
そもそもデフォルトのタクソノミーである「カテゴリー」も「タグ」も取得できないので、カスタム投稿タイプやカスタムタクソノミーを操作する上記プラグインは関係無さそうです。

プラグインを疑う

簡易的なテストコードを作成し、タクソノミーの中身が入っているかどうかだけの判別をしても、「タームは無し」の状態なので、これは根本的に、WordPressがタクソノミーまたはタームを参照している場所が間違っている感じです。
つまり、get_the_category()を実行しても「カテゴリーとか全然無かったよ！」と、WordPress的にはきちんと答えを返している状況です。

なんとなく、タクソノミーの順番入れ替えプラグインが怪しいです。

『Simple Custom Post Order』というそのものズバリのプラグインを停止してみたところ、不具合が直りました。

普段は『Intuitive Custom Post Order』という同様のプラグインを利用していたのですが、テストで入れ替えていました。

さっそくサポートを確認したところ、似たような状況の質問がりました。
https://wordpress.org/support/topic/last-update-cause-dissapear-custom-taxonomies/

前回のアップデート後にタクソノミーの表示が消えたとのことです。
他に似たような報告は無さそうなので、複数の要因が重なった可能性があります。

対応方法

『Simple Custom Post Order』を削除して、再度インストールすることで問題が解決しました。

まとめ

・カスタム含めたタクソノミーのタームが存在しているのに
・get_the_category()もget_the_terms()も値を返さない時は
・記事やタームの順番入れ替え系のプラグインを確認

投稿 get_the_category()やget_the_terms()が効かない！そんな時はタームの順番入れ替えプラグインが原因かも は studioDoghands に最初に表示されました。

特殊な例なので参考になる人は少ないと思いますがメモ。
管理画面のカスタム投稿タイプ一覧に「Advanced Custom Fields」プラグインで作成したカスタムフィールド（日付:デイトピッカー）を表示。
更にその日付順で並べる、という作業を行いました。
問題無く反映されたと思いきや、サイト更新時に不具合が発生したので解決方法の記録です。

カスタムフィールドの項目を管理画面のカスタム投稿タイプの一覧に表示

※下記プロジェクトは簡易化したサンプルです。実際は複数のカスタムフィールドの列を追加しています。

カスタム投稿タイプ「イベント(event)」の一覧に、カスタムフィールド「年月日(event_date)」の列を表示する必要がありました。

まずは列を追加して
[php]
//『event』カスタム投稿にカスタムフィールド『event_date』の項目を追加
function add_column_to_event ( $columns ) {
$columns[‘event_date’] = "年月日";
return $columns;
}
add_filter( ‘manage_event_posts_columns’, ‘add_column_to_event’ );
</code>
[/php]

追加した項目に値（日付データ）を入れます。
[php]
//追加したカスタムフィールドの項目に値を表示
function add_column_value_to_event ($column, $post_id) {
switch ( $column ) {
case ‘event_date’ :
echo get_post_meta( $post_id , ‘event_date’ , true );
break;
}
}
add_filter( ‘manage_event_posts_custom_column’, ‘add_column_value_to_event’, 10, 2 );
[/php]

そして、カスタムフィールドで追加した日付順（降順）で並べます。下のような感じのコードになります。
[php]
//カスタム投稿『event』一覧を、カスタムフィールド『event_date』の降順で並べ替え
function set_post_types_admin_order_to_event ( $wp_query ) {
if (is_admin()) {
$post_type = $wp_query->query[‘post_type’];
if ( $post_type == ‘event’ ) {
$wp_query->set(‘meta_key’, ‘event_date’);
$wp_query->set(‘orderby’, ‘meta_value’);
$wp_query->set(‘order’, ‘DSC’);
}
}
}
add_filter( ‘pre_get_posts’, ‘set_post_types_admin_order_to_event’ );
[/php]

問題無く表示されました。

更新すると問題発生。日付形式が強制的に上書きされる

しかし、過去のデータを編集し、保存しなおしたところ問題が発生しました。

例えばカスタムフィールドで登録した日付「2018/09/01」の記事を修正、保存すると、日付は変更していないのにも関わらず、一覧では「20180901」と表示され、順番が狂ってしまうのです。

つまり、保存時に日付のフォーマットが強制的に書き換えられているということです。

原因。プラグインのアップデートによる仕様変更によるもの

そこで、Advanced Custom Fields公式ドキュメントの「Date Picker」を確認してみます。
https://www.advancedcustomfields.com/resources/date-picker/
冒頭から理由が記載されていました。
要約すると次のような感じです。

ACF(アドバンスドカスタムフィールド)の以前のバージョンには「保存形式（Save Format）」という設定が含まれていました。
この設定により、開発者はDBに保存されている形式を変更できました。
保存形式の指定は便利ではありますが、多くの問題を引き起こす為、新バージョンでは削除されました。
現在は「YYYYMMDD」を唯一の保存フォーマットとしています。
公式サイトより一部意訳

つまり、データベースには「2018/09/01」のフォーマットで保存されていても、新バージョンでは「20180901」で保存されるということです。

データベースをチェックしてみる

念の為phpMyAdminでデータベースを確認してみます。
カスタムフィールドのキーと値はpost_metaテーブルに入っています。

該当のカスタムフィールドで検索してみます。

有りました。更新済の記事のみ基本フォーマットで保存されています。一覧表示での順序の崩れの原因が確定しました。

旧バージョン（5以前）を確認

試しにプラグインダウンロードページで、旧バージョンのACFをダウンロード、確認してみます。適当にバージョン4.3.8をインストールしてみます。

なるほど、「フォーマットを保存する」の項目があります。覚えていませんが、恐らく以前ここでフォーマットを指定していたと思われます。

ちなみに最新バージョンは下記のような画面です。
※「Translation preferences」はマルチ言語プラグイン「WPML」によるもので、今回は無関係です。

修正する

「じゃあ全部新しい形式にする為に記事を保存し直せばよいか」と言いたいところですが、このカスタム投稿タイプには1500程度の記事が登録されていました。
元々、これらの記事はCSVから「Really Simple CSV Importer」を使って一気に読み込んだものです。

CSVを確認したところ、確かに「2018/09/01」形式（Y/m/d）で日付を記入しています。ソフトはLibreOfficeを使っています。

何らかの方法で記事をCSVに書き出し、日付を一気に修正、読み込み直す、という方法は記事IDの保持が面倒そうなので、データベースを書き換えることにしました。

データベースで日付を置換

phpMyAdminにログイン後、SQLタブを開きます。
「wp_postmeta」というテーブルの「event_date」キーにあるデータから、「/」を取り除きたい。つまり「2018/09/01」を「20180901」にしたい、というSQLクエリは下のように書きます。
[sql][/sql]update wp_postmeta set meta_value=REPLACE(`meta_value`,’/’,”) where meta_key = ‘event_date’;[sql][/sql]

無事に全て置換されました。

管理画面でもカスタムフィールドで指定した日付の降順で並んでいます。

日付の表示を修正

管理画面とはいえ、この日付フォーマットは少々味気ないのでY/m/d形式で表示することにします。

値を表示するコードを下記のように修正します。
[php]
//追加したカスタムフィールドの項目に値を表示。日付フォーマットも変更。
function add_column_value_to_event ($column, $post_id) {
switch ( $column ) {
case ‘event_date’ :
$date = get_post_meta( $post_id , ‘event_date’ , true );
$date = new DateTime($date);
echo $date->format(‘Y/m/d’);
break;
}
}
add_filter( ‘manage_event_posts_custom_column’, ‘add_column_value_to_event’, 10, 2 );
[/php]

表示形式が修正されました。

投稿 管理画面の一覧にカスタムフィールドのデイトピッカーを表示すると更新時に問題発生(解決済) は studioDoghands に最初に表示されました。

ワードプレス最新バージョン「WordPress 5.2 “Jaco”」がリリースされました。
“Jaco”は70年代中期〜80年代前半に活躍したアメリカのジャズベーシスト「ジャコ・パストリアス」由来の命名との事。
※彼は、ジョジョの奇妙な冒険第六部（ストーンオーシャン）でお馴染み「ウェザー・リポート」に所属していた時期もあります。

さて、今回のバージョンアップでは、
・「サイトヘルスチェック」に関する管理画面ページの追加
・PHP エラープロテクション（画面真っ白状態の回避）
の大きなアップデートの他
・アクセシビリティの向上
・プラグイン互換性チェック
・新しいダッシュボードアイコン
などが改善項目として記載されています。

今回は、「サイトヘルスチェック」を確認してみます。

WordPressの新機能「サイトヘルスチェック」を使ってみる

前回のリリース(5.1)では「サイトヘルス」機能が追加されていました。
これは、古いバージョンのPHPを使っている場合にアラートを表示したり、PHPのバージョンの違いによりプラグインがトラブルを引き起こすと予測できる場合は、プラグインのインストールを許可しない、という機能です。

5.2では、上記に加えてより視覚的にホームページの状況を確認できるようになりました。

「サイトヘルスチェック」ページの確認

WordPress管理画面から「ツール」→「サイトヘルス」をクリックします。

「サイトヘルスステータス」（ステータスタブ）が表示されました。
セキュリティ系のプラグインを入れている方にはおなじみの項目かもしれません。

上部の「Critical issues」がすぐに対応した方が良い項目。

次の「Recommended improvement」がおすすめの改善項目。

最後の「テスト通過」ボタンを押すと、「サイトヘルスチェック」の確認を通過した項目が並びます。

「サイトヘルスチェック」に従って環境を改善してみる

とりあえず、「Recommended improvement」の「PHPの更新をおすすめします」の項目を改善してみます。

エックスサーバの管理画面から、PHPを最新バージョンに変更します。

しかし、戻ってもステータスに変化が無いので、「パフォーマンス」をクリックして詳細を確認。
「PHP の更新についてさらに詳しく」のリンク先に飛んでみます。

PHP7.3でしたか！

エックスサーバで現在利用できるPHPのバージョンは現在（2019年5月9日時点）でPHP7.2xなので、もう少し待ちですね。
エックスサーバ公式:PHPのバージョンについて

古いデータベースサーバー

もうひとつ表示されていた改善項目「古いデータベースサーバー」については数年前から自覚（今度やろう、今度やろうと早数年）しているので、これを機に修正しました。
修正前。MariaDB5.5(MySQL5.0)

修正後。MariaDB5.5(MySQL5.7)

データベースのバージョンアップに少し詰まったので、こちらはまた解説します。

追記、データベースバージョンアップを行いました。
エックスサーバ「MySQL移行ツール」でMySQL5.0からMySQL5.7へバージョン移行してみた

投稿 WordPressの新機能「サイトヘルスチェック」でトラブルを未然に防ごう は studioDoghands に最初に表示されました。

ワードプレスにアップロードした画像が特定の閲覧環境、例えばスマホなどで横向きになってしまうことがあります。
この原因は多くの場合、JPEG画像に含まれるExif情報が関連しています。
Exif情報には、撮影日時、場所、デジカメの機種や各種設定が含まれていて、このなかに「カメラを横に構えているか、縦に構えているか等、カメラの向き（Orientation属性）」※の情報も保存されています。
※Orientation属性は8種類に分かれていて、少し分かりづらいのですが、「写真が横向きになってしまう」ことの解決方法として理解する必要は無いので割愛します。

要は、WordPressにアップする画像から「Exif情報」を削除してしまえば画像の向きが勝手に変更される問題は無くなります。

方法その１、ローカルでExif情報を削除

社内、または自分で画像加工する際にExif情報を削除しておきましょう。
利用しているアプリ名と「Exif」「削除」でググれば大体出てくると思います。
例えばPhotoshopであれば、「WEB用に書き出し」を行うと同時にExif情報も削除されます。

多くの画像一括処理ソフトはデフォルトでExif情報は削除されます。
例えば私が愛用しているMacの画像サイズ一括変更アプリ「Th-MakerX」でも、Exif情報の保持にチェックを入れない限りは削除されます。

方法その2、プラグインでExif情報を削除

EWWW Image Optimizerプラグインが定番です。本来は画像のサイズ（容量）を圧縮するプラグインですが、Exif情報削除のみの目的でも利用できます。
プラグイン→新規追加で「EWWW Image Optimizer」を検索、インストールします。

設定→EWWW Image Optimizerを開き、「Basic」タブの「Remove Metadata」にチェックを入れます。
これで、今後WordPressにアップロードする画像からはExif情報が削除されます。

今までアップロードした画像も処理する場合は、
メディア→一括最適化から、「最適化されていてない画像をスキャンする」をクリックし、処理を進めます。

ローカルで処理するのが確実ですが、スタッフが複数に渡る場合は「最後の関所」で例外を省くこの方法が有効でしょう。

オンラインでExif情報を削除

数枚の画像から手っ取り早くExif情報を消したい場合はオンラインサービスを使う選択肢もあります。
「remove Exif online」あたりで検索すると複数のサービスが見つかります。
例:VIEW AND REMOVE EXIF ONLINE
当然「他人のサービスに画像をアップロードして処理する」リスクはありますが、WEBに掲載する目的の画像であればリスクは若干さがります。

まとめ。プロジェクトで自分が提出しているファイルで無駄なワークフローを生み出していないか確認しよう。

個人のサイトで「画像が稀にに横になってしまう」程度であれば問題はありませんが、複数のスタッフからなるプロジェクトで、「この人からの画像ファイルは気をつけないと横になる」というのは非常に大きなムダを生みます。「珠にある事柄」のためにチェック項目が増えてしまうからです。

これは、チーム内の１人のみがWindowsで「シフトJIS/JIS」でファイルを編集、しかも①②③などの機種依存文字を多様、Macで受け取ったメンバーが毎回「㈰㈪㈫」の謎文字を探し、修正する、というあるあるにも似ています。

プロジェクトで自分が提出するファイルが無駄なワークフローを生み出していないか常にチェックしてみましょう。

投稿 ワードプレスにアップした画像が横向きになる時は「Exif情報」を削除で解決 は studioDoghands に最初に表示されました。

WordPressに限らず、サイトは突然落ちます。
真っ白になったり、PHPのエラーコードが吐き出されたりと様々です。
その中で、少なくとも弊社が経験したクライアントサイトの「403 Forbidden」エラーで一番多い原因を紹介します。

そもそも「403 Forbidden」エラーとは？

HTTP 403、またはエラーメッセージ Forbidden（「閲覧禁止」「禁止されています」の意）は、HTTPステータスコードの一つ。ページが存在するものの、特定のアクセス者にページを表示する権限が付与されず、アクセスが拒否されたことを示すもの。また、サイトの制作者側の設計ミスによる障害やサイトが非常に混雑している時、URLが間違っている場合にも表示される事がある。

出典: フリー百科事典『ウィキペディア（Wikipedia）』

つまり、有名な「404エラー」（ページが存在しない）と違い、「ページはあるけどあなたは見ることが出来ません」というエラーメッセージです。

「昨日まで問題なかったサイト」が突然「403 Forbidden」エラーで見えなくなったら

「403 Forbidden」の原因は主に
・サーバのWAF（ウェブアプリケーションファイアウォール）設定によるセキュリティで弾かれている※最近はあまりありません
・「.htaccess」ファイルの誤設定
・各種ファイルのパーミッションを書き換えてしまった
・新規ドメインやサーバ移動などで諸々の設定が反映されていない
等があります。

但し、これらはホームページ制作者であれば触ることもあるかもしれませんが、お客様サイトで、何も触っていないのに「403 Forbidden」エラーが出た場合の原因は、殆どが
サーバの更新手続きや支払いを行っておらず、サービスが停止された
が原因です。
意外と大きな会社に多く、「サーバの取得は別の部署」「サーバアカウントの連絡先の社員が退社」「クレジットカードの利用が禁止されており、銀行振り込み。督促メールも未確認。」「取り急ぎクレジットカードは社長のものを使ったが、カード番号更新の際にサーバ側が決済できず（いわゆる「洗い替え」を行なっていない）、社長も当然の如くサーバ会社からの未決済メールは未確認。」などの事情が重なり、サービス停止に至ります。

WordPressサイトで突然の「403 Forbidden」エラー、まとめ

すぐにサーバの管理画面にログイン、支払い状況を確認しましょう。
ほとんどのサーバは支払い後復旧可能です。
その後、アカウントの連絡先アドレスを確認、特定の個人スタッフの場合は、会社のメインメール（info@・・・等）に変更しておきましょう。
また、同時に「ドメイン管理サービス」の支払い状況もチェックしておきましょう。（ドメインのほうが停止された場合深刻です）

投稿 WordPressサイトで「403 Forbidden」エラーが表示された場合の意外な原因No1はこれ は studioDoghands に最初に表示されました。

WordPressで大量の記事を一気に消したい事がたまにあります。
例えばテスト環境で、今あるCSVデータを反映して表示部分を調整したい、でも元データはクライアントがアップデートしているので、随時テスト環境はクリアにして最新データを反映したい、等です。
そんな時に便利なプラグインを紹介します。

大量の記事データを一気に削除する

方法その１「ページごとに表示する項目数」を増やして、一気に削除

結論。大量の場合はお勧めしません。
数年前、大量の記事を「一括操作」で編集しようとして、何の気なしに「ページごとに表示する項目数」を500（多分上限は999だったと思います）にしたところ、ブラウザが全く反応しなくなりました。
WordPressを扱う人間の大半が経験する「5分前まではあんなに普通の日常だったのに」というやつです。

そのときの対処方法は「ページごとに表示する項目数」を増やし過ぎてブラウザが固まった時はに書いています。
簡単に説明すると、管理画面のすべてが固まったと思いきや「記事の検索」だけは動作していたので、そこで意図的に数件しかヒットしない単語（等サイトでは「犬」等）を入れ、検索結果画面に移動。
そこでおもむろに表示オプションの「ページごとに表示する項目数」を減らす（そのときはもう500で固まったことが恐ろしくて、デフォルトの「20」も怖く、「6」としました。）です。
※現在はまた油断して「100」くらいにしている投稿タイプもあります。

一応説明します。
投稿一覧の上部、「表示オプション」をクリックします。

「ページ毎に表示する項目数」を増やします。
消したい記事の数だけ増やしたいところですが、ブラウザが固まる恐れがあるので100〜200くらいが妥当だと思います。

全選択をしてから

一括編集→ゴミ箱へ移動、をクリックします。

※「全選択」はあくまで「そのページに表示されている記事を全選択」なので、1000を超える場合でも1ページの表示数は200程度に抑え、ページ遷移して地道に消しましょう。私のように「ページごとに表示する項目数」を増やすと痛い思いをします。

方法その2「プラグインを使う」

これがベストだと思います。解説します。

WP Bulk Deleteで大量の記事を一発で全削除

WP Bulk Deleteのインストール

プラグイン→新規追加からWP Bulk Deleteを検索してインストールします。
※またはこちらからダウンロードしてインストール。

WP Bulk Deleteの使い方

プラグインを有効化すると、管理画面サイドバーに「WP Bulk Delete」が表示されるのでクリックします。

最初のタブは「Clean up」で、リビジョンやゴミ箱を消去してくれます。今回は記事を削除したいので、隣の「By Posttype」をクリックします。

全削除したい投稿タイプを選択します。

「Delete Posts」をクリックして完了です。

その他

SQL(WordPressの国内環境の場合はほぼMySQL)でコントロールするのがベストだとは思います。
DELETE FROM wp_posts WHERE 〜のように指定したら1分もかからないじゃないか、という意見もあるでしょう。
ただし、
・私自身、過去25年に渡りSQL直接いじってやらかした経験は大量
・やっと慣れてきて、スタッフにお勧めしたところ、懐かしいくらい私のミスを踏襲
・SQLでぱぱっとできる人はこの記事を必要としない
ことから、SQL直接いじりは省きます。

投稿 大量の記事をまとめて一気に削除！便利プラグイン【WP Bulk Delete】 は studioDoghands に最初に表示されました。

WordPressのプラグインアップデート中に、稀にサイト、管理画面共エラー画面で停止してしまうことがあります。
エラーメッセージは「Briefly unavailable for scheduled maintenance. Check back in a minute.」です。

復旧方法

FTPソフトでWordPressのインストールディレクトリ※を開き、「.maintenance」というファイルを削除して完了です。

「.maintenance」が見当たらない

FTPソフトの設定を確認しましょう。「.」始まるファイル（.htaccessなど）を非表示にしているかもしれません。
Filezillaであれば、フィルターをオフにして確認しましょう。

エラーの原因

プラグインのアップデート中はメンテナンスモードに入っています。通常は数秒なので意識しませんが、この間にアップデート中のプラグインを開いたり記事の更新を行おうとすると、メンテナンスモードから回復できなくなることがあります。
これが「Briefly unavailable for scheduled maintenance. Check back in a minute.」エラーの原因です。

時間が経つと回復することも

最近は2回ほどこのエラーを誘発してしまいましたが、「.maintenance」ファイルを探しているうちに回復していました。
見た目的に動きが無いので不安になりますが、3分程度待ってみるのも良いでしょう。

投稿 【復旧は簡単】エラー「Briefly unavailable for scheduled maintenance. Check back in a minute.」が表示されたときは は studioDoghands に最初に表示されました。

カスタムフィールドを追加/管理する定番WordPressプラグイン「Advanced Custom Fields」。
テキストや画像、投稿オブジェクトなど、様々なフィールドが使えます。
その中で「Wysiwyg エディター」の利用時の注意点について解説します。

カスタムフィールドの登録

このような感じでWysiwygエディターのフィールドを追加してみます。
フィールドタイプは「Wysiwygエディター」を選択します。

投稿画面で適当にテキストを入力します。

カスタムフィールドの表示

投稿表示用のテンプレート（通常はsingle.php）の[code]&lt;?php the_content(); ?&gt;[/code]
の下に、フィールド表示用のコードを追加します。
pタグで囲み、太字・赤文字で出力してみます。
[code]
&lt;?
$wysiwyg = get_field( ‘wysiwyg_test’ );//wysiwyg_testはフィールド名
if ( $wysiwyg ) {
echo ‘&lt;p class="font-weight-bold text-danger"&gt;’ . $wysiwyg . ‘&lt;/p&gt;’;//pタグで囲みクラスを追加
}
?&gt;
[/code]
結果を確認します。
テキストは表示されていますが、意図した装飾が反映されていません。

コードを確認すると、クラスを付与したpタグが閉じられ、新しくpタグが追加されてしまっています。

意図しないpタグの原因

カスタムフィールドを取得する関数「get_field」（表示はthe_field）には3つの引数があり、そのうちの1つが自動整形を担当し、デフォルトでは有効になっています。
これが意図しないpタグのクローズと追加の原因です。

「get_field」関数の引数

[code]get_field($selector, [$post_id], [$format_value]);[/code]
$selectorはフィールド名です。必須の引数です。
$post_idは投稿IDです。デフォルトでは現在の記事を取得するので、空白またはfalseで問題ありません。
投稿ID123の「text_field」を取得する場合は下記のように書きます。
[code]$value = get_field( "text_field", 123 );[/code]
$format_valueがコードの整形に関する引数で、デフォルトではtrueになっています。これが整形の原因です。

参考:公式ドキュメント

それでは上記を踏まえ、引数の2番目と3番目を「false」にしてコードを修正してみます。
[code]
&lt;?
$wysiwyg = get_field( ‘wysiwyg_test’,false,false );//wysiwyg_testはフィールド名
if ( $wysiwyg ) {
echo ‘&lt;p class="font-weight-bold text-danger"&gt;’ . $wysiwyg . ‘&lt;/p&gt;’;//pタグで囲みクラスを追加
}
?&gt;
[/code]

結果を確認します。
意図したとおり、クラスを付与したpタグで囲まれ、文字も装飾されました。
しかし、整形機能をオフにしたことで、今度は改行が無視されてしまいました。

改行を反映させる

改行を反映させるには、PHPの関数「nl2br」を使います。
参考:公式ドキュメント
この関数は、テキストの改行文字(\r\n、 \n\r、\n および \r) の前に
を付与して文字列を返します。
基本的は使い方は下記の通りです。
[code]echo nl2br(‘改行入りの文字列’);[/code]

「nl2br」を利用してコードを修正してみます。
[code]
&lt;?
$wysiwyg = get_field( ‘wysiwyg_test’,false,false );//wysiwyg_testはフィールド名
if ( $wysiwyg ) {
echo nl2br(‘&lt;p class="font-weight-bold text-danger"&gt;’ . $wysiwyg . ‘&lt;/p&gt;’) ;//pタグで囲みクラスを追加
}
?&gt;
[/code]

確認します。
無事改行が反映されました。

投稿 Advanced Custom Fieldsの「Wysiwyg エディター」の出力で挿入されるpタグを除去する は studioDoghands に最初に表示されました。