WordPressでAdvanced Custom Fields（ACF）を利用するケースはあるかと思いますが今回は、ACFの値を投稿以外のページで値として利用したと思って調べてみました。

POST_TYPE

acf-fieldがフィールド

acf-field-groupがフィールドをまとめたグループ

post_name

acf-field⇒「field_」

acf-field-group⇒「group_」

という名称で保存されます。

これがKEYになります。

post_excerpt

ここに格納されているのがカスタムフィールドとして設定したフィールド名が入っています。

通常投稿から利用する場合

get_filed(‘フィールド名’)やget_field_object(‘フィールド名’)で値を取得することが可能

※これにはPOST_IDが必要。

投稿以外のページからACFのフィールドの情報を取得するには？

Key名って？いうとACFはフィールドを増やす毎にユーザーが指定したフィールド名以外にキーとなる名称を付けています。

ということで、「get_field_object(‘Key名’)」で取得できるようです。

じゃあ、フィールド名⇒KEYに変換できるのか？というとfunctionを作ればできる？

※post_excerpt⇒post_nameを取得する

「$wpdb->get_results」を利用してクエリを書いてみた。

function getCustomfieldToFieldKey($column)
{
    if(empty($column))
        return false;

    global $wpdb;
    $query = "
    SELECT post_excerpt, post_name
    FROM $wpdb->posts AS p
    WHERE p.post_type = 'acf-field'
    AND p.post_status = 'publish'
    AND p.post_excerpt = '{$column}'
  ";

    $results = $wpdb->get_results( $query );

    if(!empty($results[0]->post_name))
    {
        return $results[0]->post_name;
    }
    return false;

}

これでpost_name（KEY）が取り出せる。

もちろん重複している場合はNGなのでカスタムフィールドを設計する際には気を付けないといけない。

あとは「get_field_object」にKEYを入れて内容を取り出す。

チェックボックスは検索向きじゃないのでタクソノミーで代用

リピートフィールドをプログラムでデータを追記する

あんまり使うこと無いかもしれないけど、リピートフィールドをPHPプログラムでデータを追記する場合

ACFのドキュメントに記述された方法だと失敗したのでメモとして残しておく。

・参考記事
https://www.kevinleary.net/update-an-acf-repeater-field-programmatically/

$existing = get_field( '１．リピートフィールド名' ,$post_id);
if ( ! is_array($existing) ) $existing = [];

$additions = [
    [
        '１．リピートフィールド名のリピートで設定しているフィールド名A' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名B' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名C' => '追加の値',
    ],
    [
        '１．リピートフィールド名のリピートで設定しているフィールド名A' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名B' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名C' => '追加の値',
    ],
    [
        '１．リピートフィールド名のリピートで設定しているフィールド名A' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名B' => '追加の値',
        '１．リピートフィールド名のリピートで設定しているフィールド名C' => '追加の値',
    ],

];

$updated = array_merge ($existing , $additions);//過去のデータと新しいデータを結合
update_field( '１．リピートフィールド名', $updated,$post_id );//そんでもって更新

これでなんとか。

WordPressの検索機能をカスタマイズしてみました。

検索プラグインがいくつかあるのですが、「fe-advanced-search」は、アドバンスカスタムフィールドプラグインに対応しておらず、なんだかんだといって、自作することにしました。

WordPressカスタムフィールドを検索させるのにちょっとハマったりしましたので基本的なところからメモを残していきたいと思います。

カスタムフィールドを検索できるようにするための下準備

まずは、wp_postsだけがSQLの対象となっているのでJOINでpostmetaを結合する関数を追加します。

function posts_join_custom_fields( $join, $query ) {
    if ( $query->is_search() && $query->is_main_query() && ! is_admin() ) {
        global $wpdb;
        $join ="INNER JOIN $wpdb->postmeta ON ($wpdb->posts.ID = $wpdb->postmeta.post_id)";
    }
    return $join;
}
add_filter( 'posts_join', 'posts_join_custom_fields', 10, 2 );

※管理画面以外、接続するようにしています。INNERで結合しているのでpostmetaに値があることが前提です。利用するカスタム投稿等によっては、上記の記述だと問題があると思いますので、どの画面で対象にするのか条件分を記述したほうが良いです。

次にカスタムフィールド（テキスト）を検索対象にしてみます。

「$search」の最初に「AND」でWHEREの追加をします。

その後、「meta_key＝カスタムフィールド」、「meta_value=検索値」で絞り込んでいます。

function custom_search($orig_search, $query) {
    if ( $query->is_search() && $query->is_main_query() && ! is_admin() ) {
        global $wpdb;

        $search =' AND ';
        $search .="($wpdb->postmeta.meta_value  LIKE '%日本橋%' and $wpdb->postmeta.meta_key = 'カスタムフィールド名')";
        return $search;
    }
    return $orig_search;
}
add_filter('posts_search','custom_search', 10, 2);

このあたりを基本系としてあとは、発展していった内容を記述していけばよいかと思います。

WordPressの翻訳を修正するときにある程度の知識があると便利なのでまとめてみました。

まずは、どんな翻訳システムをWordPressでは利用しているのか？

WordPressのユーザーインターフェース翻訳はGUNのgettext翻訳システムを採用している。

このGUNのgettext翻訳システムは複数タイプのファイル（POT、PO、MO）がある。languageファイルを覗くと「PO」「MO」のファイルが入っているかと思います。

POT

テキストファイル。基本言語（英語）の文言が入っているが翻訳は空白。

PO

テキストファイル。１つの言語に１つのPOファイルが作成される。

MO

バイナリファイル。POファイルからコンパイルして生成されたファイル

これらのファイルを操作するにはPoeditが必要。

作成手順

PoeditでPOTを元に新しいカタログを作成します。

カタログの設定でjaに設定します。

あとは、翻訳を作り、保存し、「wp-content/languages/plugins/」にアップロードすれば反映されます。

作成するあたって保存するファイル名は重要です。

例えば「<?php _e( ‘ソーステキスト’, ‘ドメイン’ ); ?>」とプログラム本体に記述されています。

この場合にファイル名は「ドメイン-ja」にしないと作成した翻訳ファイルを認識して翻訳してもらえません。

もし、翻訳が適用されないと思ったときにはチェックしてみるとよいかと思います。

ホームページ作成しているときに翻訳調整することがあると思いますので知っていると便利です。

WordPressのユーザー情報を変更したときに自動的にメール送信されるのを止めたい！

そんなときは、FUNCTION.PHPに「Filter」を掛けると対応できる。

// 「ユーザー登録時」に「管理メールアドレス宛」のメール送信停止する
add_filter( 'wp_new_user_notification_email_admin', '__return_false' );

// 「ユーザー登録時」に「登録ユーザー宛」にメール送信停止する
add_filter( 'wp_new_user_notification_email', '__return_false' );

// 「メールアドレス変更時」にメール送信停止する
add_filter( 'send_email_change_email', '__return_false' );

// 「パスワード変更時」のメール送信停止する
add_filter( 'send_password_change_email', '__return_false' );

// 「パスワードリセット時」のメール送信停止する
add_filter( 'wp_password_change_notification_email', '__return_false' );

とりあえず、function.phpにfilterを記述して動作するか確認しましょう。

WordPressでがりごりがごり、コーディングしてできた～～！っていったら速度がおそ～い。っていうときにちょっと調べた内容をメモ程度に残しておきます。

速度測定サイトでもブラウザでも何でもよいのですが検証「F12」を押したときに出てくる「DevTools」の「ネットワーク」を利用します。

下記のような読み込み速度が見れるかと思います。スタイル、画像、スクリプトが遅いのかはこれでさくっとわかるかと思います。

下記のだと「/」の反応がすでに遅いです。

WordPressを分解してみたところ、「index.php」「single.php」「page.php」に入る前の状態が一番上の行に表示されています。

このあたりでは何をしているのかというとプラグイン系を読み込んでいると考えてよいです。

っていうことで遅そうなプラグインを停止したところ、「3.54s」→「1.77s」まで改善されました。

最終的には停止したプラグインのアップデートしたところ、速度の原因をプラグインの開発者の方で修正したみたいです。

気を付けるプラグイン

・Acunetix WP Security

設定で「Enable Live Traffic tool.」とすると遅い。そりゃそうだ。

・プラグインのバージョン

まれにプラグインのバージョンで遅いものがある。チェックしてから本番に反映しよう。

WordPressのAJAXを利用していて「wp-admin/admin-ajax.php 500 (Internal Server Error)」って表示されたときにレスポンスの値が何もないのでどーしようかと思いました。

ディスプレイにエラーが表示が出ていないようなのでエラーが表示されるPHPの部分に下記のように1行追加しました。

その後再度アクセスし、エラーを表示させました。

 ini_set('display_errors',1);

Fatal error: Uncaught Error: Cannot use object of type WP_Error as array in.......以下省略

これだとobject typeがNGなんだとか。。。まあ、あとで中身はチェックです。