IGARASHI Kazue

WordPress の検索機能に Algolia を利用する具体的な方法は各ドキュメントを参考に。Algolia にアカウントを作ってAPIキーを取得するAlgoliaWordPress プラグインをインストールして設定WP Search with Algoliaここまででデフォルトの検索ウィンドウや検索結果が置き換わるが、固定ページに検索結果ページを置いて、検索結果内で表示する投稿の各要素も調整したい場合は次のプラグインを入れてみよう。Search with Algolia Instantsearch BlocksAlgoliaの検索対象から特定の投稿（固定ページ、カスタム投稿タイプ）を除外したい本記事の主題。サイトトップを固定ページにしてるブログのアーカイブを固定ページに出しているなど、「表示もするし、XMLサイトマップや検索ロボットにインデックスさせたいけど、サイト内検索結果としては出したくない」ケースを想定しています。ドキュメントWP Search with Algolia プラグインの開発が Algolia からコミュニティ（WebDevStudios）に移管したので、プラグインのドキュメントはこちら。WordPress のデータを Algolia に自動同期させるタイミングでフィルターがあるので、条件・処理を加えることで Algolia に同期させない（検索の対象から除外）できる。仕様・設計投稿・固定ページにカスタムフィールドで「Algoliaの検索結果から除外」するフラグを作って保存するメタボックスを作るカスタムフィールドの保存（削除）「Algolia の検索結果から除外」するフラグがある投稿・固定ページは Algolia に自動同期させる時のフィルターで送信させないWordPress メタボックスとカスタムフィールドの保存ドキュメント通りに作っておけば良い。概ね下記のような設計になる。メタボックスを追加するどの投稿タイプにメタボックスを出すのか？が必要メタボックスの中身Nonce フィールド入れておこう。大事。カスタムフィールドの中身があったらメタボックスの要素にちゃんと反映させようカスタムフィールドの保存（削除）Nonce チェック大事。ものすごく大事。大事なことなので2回書きました。自動保存時は保存しないようにする。権限チェック大事。送信された値を確認して、上書きするのか削除するのか<?php// Register Meta boxfunction exclude_algolia_search_meta_boxes() {    // カスタム投稿タイプを含むpublicな投稿タイプすべてにメタボックスを表示（追加）    $args = array(        'public'   => true,    );    $my_screens = get_post_types( $args );    foreach ( $my_screens as $screen ) {        add_meta_box( 'exclude_algolia_search', 'Exclude Algolia search', 'exclude_algolia_search_cb', $screen, 'side' );    }}add_action( 'add_meta_boxes', 'exclude_algolia_search_meta_boxes', 10, 1 );// Meta callback functionfunction exclude_algolia_search_cb( $post ) {    // Add an nonce field so we can check for it later.    wp_nonce_field( 'exclude_algolia_search_box', 'exclude_algolia_search_box_nonce' );    // Use get_post_meta to retrieve an existing value from the database.    $value = get_post_meta( $post->ID, 'exclude_algolia_search_flag', true );    // Display the form, using the current value.    ?>    <p><label><input type="checkbox" name="exclude_algolia_search_flag" value="1" <?php checked( $value, 1 ); ?> >    Exclude Algolia search</label></p>    <?php}// Save meta value with save post hookfunction exclude_algolia_save_post( $post_id ) {    /*     * We need to verify this came from the our screen and with proper authorization,     * because save_post can be triggered at other times.     */    // Check if our nonce is set.    if ( ! isset( $_POST['exclude_algolia_search_box_nonce'] ) ) {        return $post_id;    }    // Verify that the nonce is valid.    $nonce = $_POST['exclude_algolia_search_box_nonce'];    if ( ! wp_verify_nonce( $nonce, 'exclude_algolia_search_box' ) ) {        return $post_id;    }    /*     * If this is an autosave, our form has not been submitted,     * so we don't want to do anything.     */    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {        return $post_id;    }    // Check the user's permissions.    if ( 'page' == $_POST['post_type'] ) {        if ( ! current_user_can( 'edit_page', $post_id ) ) {            return $post_id;        }    } else {        if ( ! current_user_can( 'edit_post', $post_id ) ) {            return $post_id;        }    }    /* OK, it's safe for us to save the data now. */    $value = isset($_POST['exclude_algolia_search_flag']) ? $_POST['exclude_algolia_search_flag'] : '';    if ( ! empty( $value ) ) {        update_post_meta( $post_id, 'exclude_algolia_search_flag', $value );    } else {        delete_post_meta( $post_id, 'exclude_algolia_search_flag' );    }}add_action( 'save_post', 'exclude_algolia_save_post', 10, 1 );「Algolia の検索結果から除外」するフラグがある投稿・固定ページは Algolia に自動同期させる時のフィルターで送信させないドキュメントにサンプルコードがあるので参考にして、 「Algolia の検索結果から除外」するフラグがあった場合の判定と処理を追加すれば良い。// Hook into Algolia to manipulate the post that should be indexed.function exclude_algolia_filter_post( $should_index, WP_Post $post ) {    if ( false === $should_index ) {        return false;    }    // カスタムフィールドを取得して除外する投稿の場合は false を返す    $exclude_algolia_search_flag = get_post_meta( $post->ID, 'exclude_algolia_search_flag', true );    if ( 1 == $exclude_algolia_search_flag ) {        return false;    }    return $should_index;}// Hook into Algolia to manipulate the post that should be indexed.add_filter( 'algolia_should_index_searchable_post', 'exclude_algolia_filter_post', 10, 2 );add_filter( 'algolia_should_index_post', 'exclude_algolia_filter_post', 10, 2 );完成形gist にアップしてるのでダウンロード後（必要な場合は加工の上）、プラグインとして追加し有効化すれば使えます。＊カスタム投稿タイプで動作しない場合は、すべてのインデックスをやり直して設定を送信すると、次から動きます。現場からは以上です。

WordPress ＋ Algoliaで、Algoliaの検索対象から特定の投稿（固定ページ、カスタム投稿タイプ）を除外する

弊社で今年は新卒採用があり、その中で necco さんの「アシスタントデザイナー新卒1年目の振り返り」の投稿が社内で回ってきまして、社内チャットで「皆様の1年目はどうでしたか？」と言うお題でメンバーがコメントしていく流れになりました。自分もさらっとコメントしたのですけど、年をとってくると経歴とかいろいろ聞かれる機会もあるので、めんどくさがりな自分はブログに書いておいてURL教えればいいかぁと思った次第です。1997年：大卒1年目はアルバイト就職氷河期で卒業までに就職先が決まらず、1月に学生部に呼び出される。求人票を元に地元の印刷会社を紹介されるが、技能的な要求レベルが今思い出しても大卒に求めるレベルじゃなくね？それ中途採用じゃね？と言う内容だったので申し込みはせず。（QuarkXPress 3.3J, Illustrator 5 が使える大学生ってよほどのリッチな学生か学校でそういう授業してない限り無理っしょ。知らない人はググろう）美術系学科に在籍していたため、卒業制作展のポスターを卒業制作でお世話になった某画材系商社の仙台営業所に持ち込んだところ、たまたまアルバイト募集していたのでその場で「応募していいですか？」「いいですよー。」の流れで面接、即採用。データの持ち込みをしていたので基礎スキルはあると思われていたようです。こうして卒業前の3月からアルバイトとはいえ社会人生活を開始。当時の所長さんから面接時に将来どういう仕事をしたいのかも聞かれ、「デザイナー、 DTPにすすみたい」と話したことから、アルバイトの合間にソフトウェアの勉強もさせてもらえました。営業所に併設された店舗兼出力センターでの採用だったので、当時の仕事はこんな感じ。MOで持ち込まれたDTPデータの出力業務（MOに時代を感じる）電話応対、店舗応対と言った社会人の基礎を教わる。ただし名刺交換の機会が無かったので未だにマナーはよく分からない。画材の販売と補充。カッティングマシーン、ラミネートもやった。モリサワのサーバー用フォントをインストール（教科書体がフロッピーで23枚は良い思い出、新ゴは5枚なのにね）。合間にPhotoshopとIllustratorとQuarkExpress覚える。夏ぐらいから販売代理をしているQuarkExpressのエクステンションやソフトウェアのデモをやるようになる（覚えるために本社への出張を組まれたり、お取引先や展示会でデモをやったり）就職してから1年後ぐらいに同社の営業サポートへの採用（と言っても正社員では無かったと思う）を打診されたけど、「DTPがやりたいです」といって取引先のデザイン会社を紹介されて転職しました。1998年2月〜2000年9月：デザイン会社デザイン会社で約2年半DTPオペレーター/デザイナーをしていました。アルバイト時代にソフトウェアの使い方は覚えていたので実践あるのみ。現場経験なしで入ったので、当時作ったキャラクターや筆で書いたロゴが採用されたときは嬉しかったなぁ。当時の仕事はこんな感じ基本DTPオペレーター、デザイナーさんのアシスタント、たまにデザインもやる（案をたくさん出すとき）手書きの原稿をひたすら文字入力レンタルポジのスキャンとPhotoshopでの調整（切り抜き祭り）当時は今で言うファンサイトをジオシティーズで作るのが流行っていて、自分でもやってみたくて某グループのファンサイト作っていたんですよね。めっちゃテーブルコーディング。Flashで簡単なアニメーションも作った。ちょうどデザイン会社も先細りしそうな気配がしたので、Webデザインの方に進みたくて転職を決意。2000年10月〜2013年10月：印刷株式会社のインターネット事業部でWebサイト制作求人情報誌から応募して1社目で面接→採用。実績は無いがファンサイトを作っていたので、履歴書とともにURLを送る。今思えばもうちょっとましなの作っておけよという自分史上最高の黒歴史。ちょうど新規事業立ち上げのタイミングだったこともあって採用されてそこから13年年務める。さすがに事例は出せないのけど、ざっくり書ける範囲だとこんな感じ。中小企業のサイト構築新着情報とかお問い合わせとかショッピングカート学校・行政系のサイト構築WordPressの多言語サイトでWPML使う。CMS使いたいけど静的なサイトでと言うオーダーでMovable Typeも頑張った。イベントサイトの構築HTMLのみのサイトの場合はDreamweaverやGolive使ってましたね。途中でマクロメディアがAdobeに買収されました。CMSについては環境が許すという条件付きでMovable Type, WordPressを採用していました。当時Movable Typeの有償化があってWordPressに乗り換えてそのあたりからWordPressコミュニティに関わるようになりました。2009年：WordPress2.9ぐらいから使い始める（それまではMovable Type）2010年：日本語フォーラムで回答を始める（〜2015年）2012年：WordCamp Tokyo 2012 登壇2013年：_s コントリビューターになる2013年：WordCamp Tokyo 2013 登壇このあたりの細かい話は以前のイベントでお話ししてるのでそちらもどうぞ。WordBench 秋田 vol.5 にて WordPress と自分の関わりを振り返ってみる2013年10月～現在：デジタルキューブでサイト開発者〜Webディレクター執筆時点で7年半務めてます。デジタルキューブに転職した話はブログに書いていたので、興味のある方はどうぞ。（書いておくものだなって思った）思ったよりも世界は近い東北IT物産展 in 秋田 に行ってしゃべってきました就職していわゆる「コミュニティ巻き込まれ事故」に遭遇して、あちこちのイベントに登壇したり、企画したり、サイト作ったりしたのもいい思い出です。2014年：WordCamp Kansai 2014 登壇書き出すのがつらくなったので、このブログの「イベント」アーカイブ参照仕事内容としては、WordPressのテーマ開発（主にフロント周り）で入って、今ではテクニカルディレクターとして、要件をまとめたり設計して開発チームに伝える仕事に変わってきています。四半世紀近く社会人してるので「思えば遠くに来たものだ」感があります。就職に関しては就職氷河期と言われる世代になるのですが、運に恵まれていたことも有り余り苦労したことは無く、むしろ就職してからが大変だった記憶しか無い。まぁ、きれいにまとめると就職してからも「日々是勉強」ですよ、と言うことで現場からは以上です。

皆様の1年目はどうでしたか？- 1997 年から2021年の仕事の話

やりたいこと投稿に作成者とは別に「監修者」のカスタムフィールドを用意してWordPressのユーザーを紐付けておく作成者別アーカイブで該当ユーザーの作成した投稿（デフォルト）以外に監修者に設定されてる投稿も混ぜて表示する監修者カスタムフィールドコードではなくカスタムフィールド系プラグインでさっと作成作成者アーカイブWordPressの作成者アーカイブは癖が強いです。pre_get_postsフックあるいはサブクエリで作成者アーカイブのクエリを改変（その作成者の投稿と、監修者カスタムフィールドにその作成者が付与されている投稿を混ぜる）すれば一見正しいコードに見えます。ただし、元々のクエリの作成者情報に引きづられてページ送りなどがすごく影響を受けます。やってみて影響を受けたもの投稿と監修者の投稿と合わせたとき、本来のユーザーの投稿数より 多い と、ページ送りはできる（生成される）けど、最後の方のページが404と判定され投稿が表示されない。pre_get_posts フックで作成者アーカイブの時にクエリ改変する。このとき author_name があると1の影響あったため、削除する。ページ送りできるようになるが、ユーザー情報を使う部分で不具合（titleタグなど）が出る。ということはpre_get_postsの後に実行されるアクションフック（今回は wp）で、削除したauthor_name, author をセットし直したらいいんじゃね？となります。実際のコード作成者アーカイブでのプログラムの流れはこんな感じユーザーが作成者の投稿IDを配列で取得しておくユーザーが監修者カスタムフィールドで紐付けられているの投稿IDを配列で取得しておくpre_get_posts フックにおいて、作成者アーカイブの場合、author_nameを空白にセット、1, 2の投稿のみをセットしたクエリにするwp フックで作成者アーカイブの場合、3で削除（空白をセット）されたauthor_name, authorを戻す<?php// ユーザーが作成者の投稿IDを取得function get_author_post_id( $user_id ) {    if ( empty( $user_id ) ) {        return;    }    $post_id = array();    $posts_array = get_posts( array(        'posts_per_page' => -1,        'author' => $user_id,        'fields' => 'ids',    ) );    if ( ! empty( $posts_array ) ) {        $post_id = $posts_array;    }    return $post_id;}// ユーザーが監修者の投稿IDを取得function get_supervisor_post_id( $user_id ) {    if ( empty( $user_id ) ) {        return;    }    $post_id = array();    $posts_array = get_posts( array(        'posts_per_page' => -1,        'meta_key' => 'post_supervisor', // 監修者カスタムフィールドのキー        'meta_value' => $user_id,        'fields' => 'ids',    ) );    if ( ! empty( $posts_array ) ) {        $post_id = $posts_array;    }    return $post_id;}function mod_pre_get_posts( $query ) {    if ( is_admin() || ! $query->is_main_query() ){        return;    }    if ( $query->is_author() ) { // 作成者アーカイブの場合        //クエリ改変        $userdata = get_user_by( 'slug', get_query_var( 'author_name' ) );        $userid   = $userdata->ID;        $user_main_post_id = (array) get_author_post_id( $userid );        $user_sub_post_id  = (array) get_supervisor_post_id( $userid );        $user_posts_ids = array_merge( $user_main_post_id, $user_sub_post_id );        $user_posts_ids = array_unique( $user_posts_ids );        $user_posts_ids = array_values( $user_posts_ids );        $query->set( 'author_name', '' ); // これをセットしないとページ送りができなくなる        $query->set( 'post__in', $user_posts_ids );    }}add_action( 'pre_get_posts', 'mod_pre_get_posts' );// wp のアクションフックで削除した author_name, author をセットし直す。これを実施しないとクエリを参照にして実行される関数に影響が出るfunction mod_wp_author() {    if ( is_author() ) { // 作成者アーカイブの場合        global $wp_query;        $username = $wp_query->query[ 'author_name' ];        $userdata = get_user_by( 'slug', $username );        $userid   = $userdata->ID;        set_query_var( 'author_name', $username );        set_query_var( 'author', $userid );    }}add_action( 'wp', 'mod_wp_author' );こういったクエリの改変のコードを書いたときに便利なプラグインが「Query Monitor」になります。https://ja.wordpress.org/plugins/query-monitor/実際に呼ばれてるクエリやどんなフックで何が実行されているかを確認できます。現場からは以上です。

[WordPress] 投稿に作成者と別に監修者を設定して、作成者別アーカイブで合わせて表示

2020年12月に参加した「WordPressのカスタマイズ、子テーマ？プラグイン？カスタマイザー？ WP ZoomUP #54」で子テーマやカスタマイザーの話が上がったので、翌日WordPress 2.9 から 5.6 までのカスタマイズに関して覚えてる部分をつらつらツイートしてました。ブログにまとめるのは迷っていたのですが、ツイートへの後藤さんのレスもあったので、この投稿でまとめつつ5.6以降の方向性も記載したいと思います。「ブログにも書いた」の展開を希望します（笑）— よつばデザイン後藤 あんこ好き (@428design) December 11, 2020WordPress 2.9 以前のテーマカスタマイズまだブログとしての利用がメインの時代。プラグインは実装されていたが、テーマ（見た目）をカスタマイズしようと思ったら、テーマファイルのPHPやCSSを直接変更するしか方法がなかった。メニュー的なものもカテゴリーウィジェットなどを使うしかなく当時は本当に辛かった。WordPress 3.0：カスタマイズのためのAPIWordPress 3.0 の機能2010年6月にリリースされたこのバージョンでは2.9以前から大幅な機能追加がされた。有名どころはカスタム投稿タイプ、カスタム分類。詳しくは上記のリンク先を参考にして欲しいが、サイトの見た目に関わりそうなカスタマイズに関する機能は以下の通り。カスタムメニューダッシュボードから任意の固定ページを含めて自由にメニューの構成を変更できるようになった。カスタムヘッダー、カスタムバックグラウンドAPIが実装されダッシュボードからテーマのヘッダー画像と背景を変更できるようになった。3.0のデフォルトテーマ Twenty Ten で実装されている。テーマ：Twenty Ten子テーマTheme Handbook：Child Themesすでにあるテーマの一部分だけを変更したい場合は「子テーマ」を作成し元になるテーマのコードを毀損することなくカスタマイズが可能になった。例えば Twenty Ten テーマのバージョンアップを行っても子テーマで作成したコードは影響を受けない。逆に直接コードを変更したテーマをアップデートした場合はその変更は無視される。10年経った現時点でも言われる「WordPress のカスタマイズを行いない場合は子テーマ」という文脈はここから。この頃から WordPress をブログではなく CMS として利用する需要が増えてきた（加えて他の CMS からの移行を含めてユーザーが増加した）こともあり、見た目・機能ともにカスタマイズの需要が高まってきた。子テーマを利用したカスタマイズは、CSSの変更程度であれば簡易だが、HTML構造や機能面の変更をしたい場合はPHPファイルを変更する必要があり、プログラミングが苦手なライトユーザーには敷居が高くなりがちだった。そこで登場したのが「多機能テーマ」。ダッシュボードの専用のオプションページを用意し、ノンコードで画像や要素の配色などが細かく設定できた。反面、マニュアルがないと見本の通りの見た目にできなかったり、多言語化されていないテーマの場合はドキュメントもわかりづらい場合が多かった。テーマ開発者が3.0以降で自作のテーマを作る手法は主に４つ。現在でもこの流れは変わっていないと思われる。スクラッチ開発子テーマテーマフレームワークスターター・テーマそれぞれについては 2012年に @naokomc さんが「WordPress テーマ開発4つのアプローチ」というブログを書かれてるので参考に見て欲しい。WordPress テーマ開発4つのアプローチ #wacja2012前述の「多機能テーマ」の開発でもっとも難しい部分がオプションページの作成や設定した内容をデータベースに保存するAPI部分。これらのAPIはドキュメントはあってもプラグイン開発者向けということもありテーマ開発がメインのユーザーには敷居が高かった。このようなテーマ開発者向けに作られたテーマフレームワークとして2011年に「Options Framework Theme」が登場した。Options Framework Theme | WP Themingこのフレームワークを利用するとオプションページの作成やデータベースへの保存の他にもカラーピッカーやメディアのアップローダーもコードのコピー＆ペーストで実装できたため、当時はかなり画期的だった。WordPress 3.4：テーマカスタマイザーAPIこのバージョンでテーマカスタマイザーAPIが登場。これ以降、ダッシュボードでプレビューしながらテーマのヘッダー画像や背景を変更・保存できるようになる。WordPress 3.4 の機能これ以降テーマカスタマイザーは徐々に強化されていきます。推測になりますがテーマオプションを採用したテーマの乱立（各テーマで独自の手法）があり、コアの機能として統一していきたかったのかと思います。WordPress 3.9テーマカスタマイザーの中でウィジェットの設定とプレビュー、ヘッダー画像アップロード時のトリミング（切り抜き）とプレビューができるようになる。WordPress 3.9 の機能WordPress 4.3テーマカスタマイザーの中でカスタムメニューのプレビュー、サイトアイコン（favicon）の設定ができるようになる。WordPress 4.3 の機能WordPress 4.5カスタムロゴ（ヘッダーロゴ）とテーマカスタマイザーでタブレット、スマートフォン端末でのプレビューができるライブレスポンシブプレビューが実装される。WordPress4.5 の機能実はライブレスポンシブプレビューが実装前の4.3ぐらいの時に同僚の @Webnist さんが同じ機能をプラグイン「Customizer Theme Resizer」としてリリースしてそれが WordPress Tavern に取り上げられました。Customizer Theme Resizer Plugin Offers Live Previews of Your Site on Mobile Devices – WordPress TavernWordPress 4.7：スターターコンテンツ4.6まではまだテーマを有効化しただけでは見本と同じレイアウト・セクション構成にならない問題は残っていましたが、4.7で実装されたスターターコンテンツで解消されます。この機能で、テーマ作者の意図したウィジェットやTOPページに掲載するコンテンツ、固定ページなどを設定・表示できるようになりました。Starter content for themes in 4.74.7のデフォルトテーマ Twenty Seventeen で実装されています。Twenty Seventeen: Merge Proposal for 4.7また、このバージョンではヘッダー画像に動画（アップロードまたはYoutube）を設定できるようになりました。出力時には動画再生やフォールバックの処理をするjsも追加されています。WordPress 4.9：テーマカスタマイザーの下書き・予約投稿これまで保存したら即反映されていたテーマカスタマイザーの内容ですが、このバージョンから下書き保存と予約公開ができるようになりました。WordPress 4.9 の機能WordPress 5.0：ブロックエディタ（Gutenberg）の登場このバージョンからコアの機能のうちテーマおよびカスタマイズに関わるものはブロックエディタ（Gutenberg）、アクセシビリティの強化となっていきます。WordPress 5.0 の機能今後の WordPress の（主に見た目）のカスタマイズGutenberg のロードマップのフェーズ4に「ブロックベースのテーマ」があります。これは現在ウィジェットやヘッダー画像など別々のAPIで実装してるカスタマイズ機能をブロクエディタを「Full Site Editing」としてサイト全体のカスタマイズに利用するようになります。ロードマップFull Site Editing 完全編集可能テーマの草案が公開 – ニュース – Capital P – WordPressメディアWhat Is Full Site Editing and What Does It Mean for the Future of WordPress? – WordPress TavernFull site editing – Make WordPress DesignFull Site Editing が次のバージョン（WordPress 4.7）ですぐ実装されるわけではないと思いますが、ロードマップにもあることからよほどのことがない限り近い将来実装されるでしょう。テーマカスタマイズの歴史をまとめると、ユーザーがノーコード、ダッシュボードからGUIで多様なデザイン・レイアウトを設定できるように進化する歴史といえます。大きなブレイクスルーがあるたびにテーマ開発者は覚えることも増えていく苦難の道ともいえますが。。。現場からは以上です。

WordPressのテーマカスタマイズの歴史

この投稿は Shifter Advent Calendar 2020 と Snow Monkey Advent Calendar 2020 の12月15日の投稿です。このブログは Shifter を使っていますが、社内チャットでとある方から「Snow Monkey で LP（サイト）つくって、Shifter デプロイを10分で！」とのお題を頂いたので、弊社サービスの「用心棒」のサイトを Snow Monkey ＋ Shifter で作成し Generate（デプロイ＝公開）まで行ってみました。Shifter でサイトを作って公開まで「10分で」というお題をもらいタイムアタックさがならでやってみましたが、結論から言うと以下の条件で、Shifter へのログインから公開まで13分程度でした。シナリオとしては「サイトのテーマを Snow Monkey に切り替えてウィジェットなどを設定、ランディングページ（TOP）を Snow Monkey Blocks で設定」となります。Shifter へログインサイトを選んで WordPress を起動Shifter の WordPress に投稿や固定ページをすでに作ってあるメディア（画像）類もアップロード済みテーマを Snow Monkey に切り替えてウィジェットや見た目を調整ランディングページ（TOP）を Snow Monkey Blocks を使って作成完成したら WordPress を終了して Shifter で Generate（デプロイ）完了後サイトが公開されるShifter と Snow Monkey でログインからデータのインポート、サイトの作成と公開までの動画を戸田さんがいい感じに編集してくれましたのでこちらもどうぞ！動画はタイムアタックさながらにテキストなどはコピー＆ペーストしていますが、Shifter の場合、WordPress 上で設定や公開などを行ってもすぐに公開されるわけではない（Shifter で Generate するまで公開されてるサイトは置き換わらない）ので製作途中のサイトが一般公開されるわけではありません。安心してサイトを作りましょう！サイトのスコアを取ってみようShifter の特徴の一つとして「サイトの表示が速い」があります。また Snow Monkey もテーマ単体で速く表示されるように工夫がされています。今回デモとして用いた用心棒サイトを例に「現行サイト」「Snow Monkey ＋ Shifter のサイト」「Snow Monkey ＋ レンタルサーバーのサイト」の3つを Lighthouse のスコアで比較してみました。現行サイトhttps://yojinbo.digitalcube.jp/U.S. Web Design System (USWDS) を使った HTML + CSS フレームワークNetlifyGoogle アナリティクス（タグマネージャー）なしSnow Monkey ＋ Shifterhttps://mystifying-blackburn2226.on.getshifter.io/インストールプラグイン：Snow Monkey Blocks, Snow Monkey EditorGoogle アナリティクス（タグマネージャー）ありSnow Monkey ＋ レンタルサーバーのサイトhttps://www.purpledingo1.sakura.ne.jp/yojinbo/そのうち削除します。Basic 認証は shifter / DemoShifterと同じぐらいのランニングコストということで「さくらのレンタルサーバープレミアムプラン」にホスティングインストールプラグイン：Snow Monkey Blocks, Snow Monkey EditorGoogle アナリティクス（タグマネージャー）あり比較して現行サイトは HTML＋CSS フレームワークのいわゆる静的サイトですが、Netlify が日本にエッジロケーションを持っていないためアクセスに時間がかかってるようです。また Web フォント周りがボトルネックになっています。一方、同じテーマ・プラグインでも Shifter と一般的なレンタルサーバーではスコアに差が出ますので、次の段で詳しく説明したいと思います。Shifter が速い理由一般的なサーバーで URL にアクセスしてから WordPress でページが表示されるまでURL から HTML ファイル（実際にファイルやディレクトリがある）か WordPress で作ったページなのかを判定ファイルやディレクトリがない場合、WordPress が起動URL の構造から表示したいページの種別を判定（アーカイブなのか、投稿なのか固定ページなのか）データベースから情報を取得する設定してるテーマから当該 URL のテンプレートを選んで HTML を組み立てる（ここにプラグインの処理も入ってきます）HTML からリンクされている CSS, JS, 画像などが読み込まれる表示となります。WordPress で作られたサイトの高速化テクニックとして「キャッシュ」があげられるのは、2-5の処理でできあがった HTML（や付随するソース）をキャッシュとして保持しておくことでサーバーで行われる処理を減らして表示されるまでの時間を短縮することを意味します。Shifter ではどのようになっているかというと、Generate というプロセスで WordPress で作ったページを全て HTML と付随する CSS, JS, 画像に変換しています。出来上がったファイル類はホームページビルダーや Dreamweaver でサイトを作るのと同じでサイトにアクセスしても2-5の処理が行われないため表示が速くなります。また、サイトを設置してるサーバーですが、Shifter の場合は CDN を介して全世界に配信されます。日本のサーバーに設定したサイトを日本から見る場合は実感は少ないかもしれませんが、もしサイトの訪問者がヨーロッパからアクセスしていた場合は CDN のエッジロケーションがヨーロッパにあるので日本のサーバーにアクセスするより早く表示されます。今回のサイトではあまり写真を多用していませんが、Shifter の有料プランでは WordPress の画像類を WebP 形式に変換して配信する「Media CDN」があります。写真を多用するようなサイトで表示速度が気になる場合は利用しましょう。Shifter がメンテナンスフリーでセキュアな理由Shifter は WordPress を使いたい時だけ、WordPress のインストールしたサーバーが起動し、使わない時はサーバーそのものが停止しています。また、WordPress 本体に関しては Shifter の中の人が検証後、一律でアップデートを行うため常に最新版が提供されます。（テーマとプラグインについてはユーザーがアップデートする必要があります）例えばブルートフォースアタックを含めた不正アクセス・ログインの心配公開後のサイトにログイン URL はないので心配不要。アップデートしたらサイトが壊れたShifter で Generate してデプロイしない限り公開されたサイトの中身は書き換わらないので、壊れたとしても閲覧に問題はありません。一旦終了してセーフモードで起動するか落ち着いて右下のチャットからお問い合わせをしましょう。まとめ：Snow Monkey ＋ Shifter のいいところSnow Monkey と Shifter の組み合わせは WordPress を利用してサイト構築する人にありがちな「セキュリティの心配」「アップデートが面倒」「サイト更新以外の部分に時間が取られる」「開発難しそう」が解消されると思います。私個人はオリジナルテーマの開発とサーバーは AMIMOTO を用意してもらうことがほとんどですが、久々にレンタルサーバー契約してサイト作って「時間がかかる」「面倒」と思った部分が解消されました。Web サイトを運用する人のメリットHTML タグが分からなくてもブラウザの操作だけでお洒落で素敵な見た目のサイトが作れるWordPress の機能を利用することで記事を書くことに集中できるうっかりミスしても（Generate しなければ）サイトを壊す心配がないWeb サイト開発者のメリットSnow Monkey を使うことで幅広いレイアウト・デザインパターンのサイトを短時間で制作できるいろいろなプラグインを追加しなくても必要なことができる（SEO やアクセス解析のタグの挿入）Shifter にサインアップ後、サイトを申し込むとすぐ WordPress が使える（データベースは自動で作成）セキュリティやアップデートに悩む時間がなくなるPHP・データベースのバージョンなどサーバー周りの面倒ごとを気にしなくて良いうっかりミスしても（Generate しなければ）サイトを壊す心配がない困ったら右下のチャットでお問い合わせ他にもあるかと思いますが、Snow Monkey と Shifter とが相互のパートナーシップを結んだことでより一層ユーザーフレンドリーなサービスを提供していけると思います（ちょっと宣伝）Snow Monkey ホスティングパートナーhttps://snow-monkey.2inc.org/snow-monkey-hosting-partner/Shifterパートナーネットワークhttps://spn.getshifter.io/partner/snow-monkey/現場からは以上です。

Snow Monkey ＋ Shifter で手軽に安全なサイトを作ろう #JP_GetShifter, #wpsnowmonkey

RSSフィードからSNSに配信する場合は以下の記事参照WordPressでプラグインを使わずIFTTTを使ってRSSフィードからSNSに配信するhttps://qiita.com/gatespace/items/ebd43d1ba6ef18365415RSSフィードにある要素であればその組み合わせでSNSに配信できるのだけど、「投稿タグを自動でハッシュタグに変換してSNSに投稿したい」となると、ちょっと面倒です。WordPressのデフォルトフィードでの投稿タグの扱い下記の部分https://core.trac.wordpress.org/browser/tags/5.5.1/src/wp-includes/feed-rss2.php#L97the_category_rss( 'rss2' )  で処理してます。the_category_rss()https://developer.wordpress.org/reference/functions/the_category_rss/get_the_category_rss()　を echo してるだけget_the_category_rss()https://developer.wordpress.org/reference/functions/get_the_category_rss/大まかに説明すると1. 投稿のカテゴリーとタグを全て取得2. 取得したカテゴリー名とタグ名を配列にする3. カテゴリー名とタグ名の配列をループ処理で1つずつ <category> に出力となります投稿タグだけ何とかしたいget_the_category_rss() にフィルターもあるんですけど、、「投稿タグを自動でハッシュタグに変換してSNSに投稿したい」なので、投稿タグだけを処理するのがしんどそうなので、「投稿タグだけのタグ」を追加するのが良さそう。こう言う時はアクションフックの rss2_item で追加できるのです。https://developer.wordpress.org/reference/hooks/rss2_item/「投稿タグだけのタグ」を追加するコード良いネームスペースが思いつかなかったのでフィードバリデーターではエラー出ますので注意。雑なサンプルなので、微調整は必要ですよ。add_my_rss_node.php<?phpadd_action( 'rss2_item', 'add_my_rss_node', 10, 1 );function add_my_rss_node() {    $post_tags = get_the_tags();    $separator = ', ';    $output = '';    if ( $post_tags && ! is_wp_error( $post_tags ) ) {        foreach ( $post_tags as $tag ) {            // とりあえず空白は削除、他にもハッシュタグに使えない文字の変換必要かもしれない            $tagname = str_replace([' ','　'], '', $tag->name );            $output .= '#' . esc_html( $tagname ) . $separator;      }        $output = trim($output, $separator);    }    // ネームスペースいいのないかな    echo '<tags><![CDATA[' . $output . ']]></tags>' . "\n";}フィードはこうなる<item> の最後の方にハッシュタグ付きになった投稿タグがカンマ区切りで入っていれば成功<tags><![CDATA[#Shifter, #ShifterAdventCalendar2019, #ShifterGithubPlugin/ThemeInstaller]]></tags>確認してみようZapierやIFTTTでフィードを取り込んで <tags> が使えたら成功現場からは以上です。

[WorPress] RSSフィードからSNS配信するときにタグをハッシュタグで追加したい

Auth0https://auth0.com/jp/WordPressとの連携はプラグインがある。https://ja.wordpress.org/plugins/auth0/Auth0は無料プランから開始できるけど、ここは覚えておいたほうがいいよというポイントのメモ。最初にざっくりまとめるとAuth0ではカスタムドメイン設定しておいた方が面倒は少ない：Auth0 の有料プラン必要カスタムメールプロバイダ：配信されるメールを日本語にしたり文面をカスタマイズにしたければメールサーバーの設定が必須ですユニバーサルログインログイン（認証）ページをAuth0のユニバーサルログインページにリダイレクトさせる場合は問題ありません。ただし、ログイン（認証）のフォームをアプリケーション（Webサイト側に）埋め込みたい時はテナントでカスタムドメインの設定が必要（Auth0でのカスタムドメインの利用は有償です）。「Cross-Origin Authentication」の設定もありますが、ここに手間や時間をかけるくらいならカスタムドメインの設定をした方が良いです。SNSアカウントでのログインSNS側でアプリの作成が必要Google AuthThis connection is using Auth0 development keys. Auth0 development keys are intended for testing and are not recommended for Production environments. This connection should be configured with your own keys to enable SSO, federated logout, and other features. More information about Social Connection developer keys.すぐに使えるけど開発用のキーだから本番環境では自分で諸々取得してね。と言う説明。https://auth0.com/docs/connections/social/devkeysちょっと罠っぽいのがGoogle Authの赤い枠の部分。FacebooやTwitterの場合はアプリケーション名になるのに、Googleは認証情報で設定したリダイレクト先のURLのドメインになる。利用者に対してドメイン違うことで惑わせたくない場合はAuth0でのカスタムドメイン設定しておきましょうと言う話。Facebook アプリメールアドレス・名前の取得になるので、アプリにプライバシーポリシーやWebサイトのURLを設定する必要あり。アプリをライブモードにしておかないとAuth0からエラーが返されますTwitter アプリTwitterアカウントでTwitterのデベロッパーの申請1のアカウントのメールアドレスに申請の確認のメールが配信されるので認証（申請の完了）Twitterがアプリを承認するのを待つ3の承認がされたらアプリとAuth0との連携Twitter アプリの作り方は以下を参照https://dev.classmethod.jp/articles/auth0-twitter/Twitterからメールアドレスを取得したい場合Auth0のドキュメントhttps://auth0.com/rules/get-twitter-emailTwitterアプリで Privacy Policy URL と Terms of Service URL を埋めてからPermissionsでメールアドレス取得にチェックを入れるAuth0のRulesで「Get email address from Twitter」を作成し、メールアドレスを取得するルールを追加。この時TwitterのコンシューマーキーとコンシューマーシークレットをRulesに変数で設定しておくところがプリセットされているGet email address from Twitterのルールではメールアドレスが取得できないという罠がある。なので、を少し書き換えてapp_metadataというフィールドを追加して格納するよう変更する必要あり。具体的なコードはうちのチームのエンジニアが書いてくれるはず。。。もしかしたらAuth0側でこのRulesのプリセットのコードが改修されている可能性があるので、最新ドキュメントは必ず読んでテストしてください。メールのカスタマイズWarning! You are using the Auth0 Email Provider which is only intended for development/trial use. Any customizations made to this email template will NOT take effect until a Custom Email Provider is configured. All emails sent will use the default Auth0 templates, even if customized. Please enable a Custom Email Provider for production use of custom templates.デフォルトでもメールは配信されるけど、本番環境ではCustom Email Providerの設定をしてね。と言う説明。またメールのサブジェクトや文面をカスタマイズしたい場合もCustom Email Providerの事前設定が必要。https://auth0.com/docs/auth0-email-services/configure-external-smtp-email-providers[番外] Webサイト側でCloudFrontなどCDNを通す場合WebサイトとAuth0間の認証はCookieでやりとりします。CDNや強固なキャッシュ対策を行っている場合はWebサイト側でコールバックURLはキャッシュしないようにしておく 例：/auth0-callback* をキャッシュしないキーが auth0_*のCookieをホワイトリストを追加としておく必要があります。無料からスタートできるのはあくまで開発までなので、本運用にあたってはちゃんと課金しましょうってことで現場からは以上です。

Auth0 + Webサイトで設定しておいたほうがいいこと

小学生（執筆当時）の子供のロボットの作品をブログで公開しています。https://blue7010.comブログを作った動機は一旦置いておいて、Shifterで作ったブログを親子で運用する方法を書きたいと思います。小学生がブログを書くための役割分担ロボットブログは元は子供がメモ帳などで文章を作成し、親（私）がShifterでブログを書いていました。なかなかに時間がとられていたのですが、そもそも子供もパソコンで文章が書ける（打てる）ようになってきたので「もう直接ブログ書いちゃいなよ！」と子供用のアカウントを作成しました。Shifter（WordPress）に限りませんが、記事の作成と公開は子供が自由に行えるけどお金に関する部分、ドメイン管理や料金の支払いなど大元の管理は親がするようにします。これを実施するためShifterのTeamsを使いました。役割分担のためにShifterでやったことShifterのTeams機能を使います。https://www.getshifter.io/features/teams-members/1. 子供用のShifterアカウントを作る子供用のメールアドレスが必要となります。うちの場合はiCloudのファミリー共有で子供用のアカウント（メールアドレス）を管理しています。Googleにも同様のアカウント管理機能があるので13歳未満でもメールアドレスが作れます。ファミリー共有とお子様用の Apple IDお子様の Google アカウントの作成と管理メールアドレスを作ったらShifterへのサインアップとアクティベーションを忘れずに。2. ShifterでTeamを作ってメンバーを招待する手順はこちらhttps://support.getshifter.io/en/articles/2161018-setting-up-shifter-teamsメンバーの役割はこちらhttps://www.getshifter.io/ja/blog/shifter-static-team-site-managerうちの場合は子供にデプロイ（公開）までさせたかったので、子供のアカウントは「Member」にしてあります。gatespace：親　blue7010：子供Shifterの利用料金の支払い・ドメイン管理：Ower 親 記事作成・ShifterのGenerate（ブログの公開）：Member 子供実際にやってみるもともとパソコン上で文章を書くことはできていたので、ShifterへのログインからWordPressの起動とログイン記事の書き方（ブロックエディタの使い方）写真の加工とアップロードとギャラリーの設定カテゴリー、タグの設定アイキャッチ画像の設定プレビューの確認記事の保存からShifterでのGenerate＝記事の公開を教えました。初回は使い方を教えたのですが、2回目からは「かんたん」と豪語しています。ブロックエディタはこれまでのエディタを知らなかった分使いやすかったみたいです。一応公開前に親のチェックは入りますが作文レベルの指摘のみです。ShifterのWordPressにログイン記事を書いてみよう写真の加工ギャラリーの作成まとめあくまでうちの場合のやり方で親子でブログを運用する方法を書きました。「中の人」にも言われたのですが、Shifterの場合、WordPress上で何かやらかしても表側には影響が出ないことと公開されてるサイトの巻き戻しが簡易なので子供が初めてブログを書いてみたり自由に触らせる場合にはお勧めかと思います。今後ですが子供が自分で全て管理したいとなったときはWordPressなので移行はやりやすいかなと思います。なお、執筆時点でShifterのOwnerの権限移行（移譲）はできませんのでご留意ください。

Shifterで子供のブログを作って親子で運用

検索結果の並び順の根拠をたまに聞かれるので。（追記）ロジックに関して追記しました。https://twitter.com/tekapo/status/1266621537324371969デフォルトは関連順デフォルトの検索ウィンドウでサイト内検索した場合の記事の並び順。3.7から関連順になってる。検索の改善より関連性のある検索結果となるよう改善検索結果を表示するときの SQLORDER BY wp_posts.post_title LIKE '%検索してるテキスト%' DESC, wp_posts.post_date DESC順序のロジックはこちらhttps://core.trac.wordpress.org/changeset/25632The ordering logic is as follows:- Full sentence matches in post titles.- All search terms in post titles.- Any search terms in post titles.- Full sentence matches in post content.Each section and any remaining posts are then sorted by date.投稿のタイトル＞投稿本文の順で検索して行って同じ関連度なら日付でソート。検索結果の並び順を変えたいときpre_get_posts ではなく posts_search_orderby フックで変更。SQLのORDER BY句をそのまま記述する形で返す。https://developer.wordpress.org/reference/hooks/posts_search_orderby/例：日付順にする場合/** * 検索結果は日付順にする */add_filter( 'posts_search_orderby', 'my_posts_search_orderby', 10, 2 );function my_posts_search_orderby( $search_orderby, $wp_query ) {    return 'post_date desc';}現場からは以上です。

[WordPress] 検索結果の並び順

やりたいことお問い合わせやアンケートのフォームをサイトに設置したいでもメール配信されて内容を管理するのはNGCRMツールを使った壮大な顧客管理システムまでは不要からのGoogleフォームでフォーム使って裏ではGoogleスプレッドシートでデータ取りまとめできるよね。でもサイトにGoogleフォームを埋め込んだときの見た目が気に入らないのでなんとかしたいという要件。CMS（WordPress）のデータベースにデータを溜めたくない時にもおすすめ。（個人的にそんな設計は避けたい）Formfacade 使いましょうhttps://formfacade.com/1フォームで100レスポンス/月までは無料で始められます。フォームや送信数が増えるのなら有料プランへ。（といってもよほどのリクエストがない限り$8/月で始められます）https://formfacade.com/website/pricing.htmlやり方基本的にGoogleフォームにアドオンを入れるだけ。https://formfacade.com/website/how-to-embed-google-forms-in-wordpress.html1. Googleフォームを作るよしなに作っておきましょう（スクリーンショットは元々あるサンプルのフォーム）。フォームそのものへのアクセス権も設定しておき、サイトに埋め込む前にブラウザのシークレットモードなどGoogleにログインしていない状態でフォームにアクセスできるかテストしておくと良し。2. GoogleフォームでFormfacadeのアドオンを入れる送信の右側のメニューからアドオンを選んでFormfacadeで検索して出てきたら追加3. 埋め込み用のコードを取得アドオンからFormfacadeを選んで「Embed in a webpage」を選択埋め込むWebサイトの種類を選ぶ（今回はWordPress）。コードが提供されるのでよしなにサイトに設置埋め込みできたらYesを押しましょ。出来上がりGoogleフォームの残念な感じがなくなります。スクリーンショットはWordPressデフォルトテーマのCSSそのままなので、適宜カスタマイズは可能。Ajaxで送信されるので、ページ遷移なしで完了する。無料プランはFormfacadeのブランディングがあるが、有料プランでは削除される。送信されたデータはGoogleフォームやスプレッドシートで確認できます。もちろんGoogleフォームでメール配信を設定していれば配信もされます。この辺りはGoogleフォームの機能そのままです。現場からは以上です。

サイトの見た目に合わせてGoogleフォームを埋め込むサービス Formfacade

Shifter Advent Calendar 2019 2日目です。この記事では2019年9月にリリースされた Shifter Github Plugin/Theme Installer プラグインを使った自作のWordPressテーマ・プラグインの更新を紹介します。Shifter Github Plugin/Theme Installer プラグイン  とはShifterではユーザーに対しサーバーへのアクセス権を提供していません。このため一般的なサーバーとは異なり、自作のテーマやプラグインをShifter上のWordPressにインストールしようと思った場合、zipファイルのアップロードが必要でした。またこの方法は初回のみであれば手間ではないのですが、アップロード済みのテーマ・プラグインのファイルを差し替え（更新）する場合はいちいちテーマやプラグインを削除してzipファイルをアップロードする必要があり、テーマ・プラグイン開発者からすると大変面倒です。この「面倒」を解消するためにリリースされたのが「Shifter Github Plugin/Theme Installer」ですShifter Github Plugin/Theme Installer プラグインを公開しましたShifter Github Plugin/Theme Installer を使ってGitHubのリポジトリにある自作のテーマやプラグインを登録るすと、ShifterのWordPressでも手軽にインストール・アップデートできます。登録自体はGitHubのリポジトリのURLを入力するだけです。後述しますが、リリース用パッケージを作ることでWordPressダッシュボードからテーマ・プラグインを更新することもできます。自作のテーマ・プラグインを更新したい時Shifter Github Plugin/Theme Installer を使って登録した自作のテーマ・プラグインを更新したい場合はGitHubリポジトリでリリースパッケージが作られていて、かつWordPressにインストールされてるテーマ・プラグインよりも新しいバージョンナンバーである必要があります。＊インストールのみであればリリースパッケージがあればいいですが、ダッシュボードから更新する場合はバージョン番号も新しくなってる必要があります。CodeタブのReleasesをクリックすると出ますリリースパッケージですが、tagを作って自分でzipを用意すればGitHubのページ上でマニュアルで作成することもできます。ただし、都度zipファイルを用意するのは大変面倒ですので、Shifter Github Plugin/Theme Installer で紹介されてるようにGitHub Actionsを使って自動でリリースパッケージを作ってみましょう。GitHub Actions を使ったリリースパッケージの作成GitHub Actionsは2019年11月に正式リリースされてるので、どのユーザーでも使えるようになっていると思います。自分のリポジトリで「Actions」タブが出ているか確認しましょう。サンプルワークフローをテーマ・プラグインのリポジトリに含めるShifterですでにプラグインとテーマのサンプルを用意しています。プラグインのサンプルhttps://github.com/getshifter/shifter-github-hosting-plugin-sampleテーマのサンプルhttps://github.com/getshifter/shifter-github-hosting-theme-sampleそれぞれのリポジトリにある .github/workflows/release.yml を自分のテーマ・プラグインのリポジトリにコピーしておきましょう。release.yml の書き換えコピーした release.yml の中身を自分のテーマ・テーマプラグインに合わせて書き換えます。同時にテーマの style.css プラグインファイルなどバージョン番号が記載されてる部分の書き換えも必要となります。ここではテーマを例に説明します。composer と npm の設定リリースパッケージのビルドに composer や npm を使う場合は    # - name: composer install    #   run: composer install    # - name: npm clean install    #   run: npm ciこれらのコメントアウトを外しましょうバージョン番号の自動付与GitHubアクションで style.css のバージョン番号をgitのタグ名に置き換えします。style.css のバージョン部分は Version: {release version} としておきましょう。PACKAGE_NAME の変更PACKAGE_NAME: "shifter-github-hosting-theme-sample" が2箇所あるので shifter-github-hosting-theme-sample を自分のテーマ（プラグイン）のリポジトリ名にしましょうFILES_TO_ARCIVE は適宜変更FILES_TO_ARCIVE の部分はリポジトリ内にあるどのファイル（ディレクトリ）をリリースパッケージに含めるか、という設定です。サンプル以外のディレクトリやファイルを追加（削除）したい場合は適宜変更しましょう。FILES_TO_ARCIVE: "*.php *.md *.css *.txt *.png LICENSE phpcs.xml.dist inc/ js/ languages/ layouts/ template-parts/"ここまでで自分用のrelease.ymlの編集は終わりです。タグ＝リリースバージョンとしてpushしようここまで準備できて、コミットもOKとなったら$ git tag 1.1.0$ git push origin 1.1.0で、タグ＝リリースバージョンとしてpushしましょう。GitHubのリポジトリにタグがpushされると GitHub Actions が動作します。成功・失敗・ログもリポジトリのActionsから閲覧できます。WordPressでテーマ・プラグインの更新リリースパッケージが作成されたらダッシュボード＞更新にアクセスしましょう（Shifterは再起動しなくでも良い）gitのタグ＝バージョン番号を新しく（大きく）しておけば更新があることが表示されます。アイキャッチ画像は作成してないテーマなので空欄（バグではない）あとは通常のテーマやプラグインと同じく更新することが可能です。なお、テーマの場合は子テーマでも問題なく動作します（子テーマの場合最低限style.cssがあれば良い）この記事を書くにあたって作成したTwenty Fifteen の子テーマのサンプルリポジトリはこちらになります。https://github.com/gatespace/twentyfifteen-childそれでは良きShifterライフを！現場からは以上です。

Shifter Github Plugin/Theme Installer を使って自作テーマ・プラグインをアップデートしよう #JP_Getshifter

MDNに全部載っているんですけどねっていう。https://developer.mozilla.org/ja/docs/Web/HTML/Element/Inputとはいえ type 属性でページ分かれてるのでHTML5で追加になった type属性を中心にデモを作成。デモPCの主要ブラウザのほかスマートフォンでもUIが変わるのでぜひスマホでもみてください。コードtype="color"<input type="color" value="#ff0000">type="date"<input id="date" type="date">type="month"<input type="month">type="month"<input type="number">type="range"<input type="range">type="time"<input type="time">type="week"<input type="week">現場からは以上です。

input 要素 はブラウザ（スマートフォン含む）によってUIが変わる

Shifterへのブログ移行時にSNS周りのプラグインを変えました。WordPressとSNSの連動は主に2つサイト（投稿）のシェアボタン記事公開時にSNSに自動で配信する2についてShifterではWordPressのプラグインを利用できないので注意です。サイト（投稿）のシェアボタンShifter環境（でなくノーマルなWordPress）で投稿ページにSNSのシェアボタンを掲載する方法は2つ。各SNSの公式ボタンのコード、もしくはAPIを利用した自作のコードをテーマに埋め込むプラグインを使ういずれかになります。ただし各SNSの公式ボタンではなく自作のアイコンを使いたい自作ボタンでSNSのシェア数を出したいTwitterやFacebookだけではなくLINEやはてなブックマークも使いたいとなってくると、非常に手間がかかってきます（詳細は割愛しますが、主要なSNSでもAPIの仕様が変わると自作コードの場合はその都度仕様変更を追いかけることになります。しんどい）。しんどいことはしたくないので、WordPressのプラグインを使いましょう。AddToAny Share Buttonshttps://ja.wordpress.org/plugins/add-to-any/対応してるSNSの数が多い（LINEもはてなブックマークもある）SNS側が対応していればシェア数も出してくれるこのプラグイン入れておけば（よほどデザインにこだわりがない限り）十分だと思います。メリット挙げればきりがないのでぜひサービスのサイトも参考にしてください。AddToAnyhttps://www.addtoany.com/記事公開時にSNSに自動で配信するShifterでは記事公開時にSNSに自動で配信するプラグインは利用できません。RSSフィードの生成はできるので、RSSフィードからIFTTTやZapierといったサービスを使って自動配信することは可能で、この方法はノーマルなWordPressでも有用です。ShifterでのRSSフィードの生成はダッシュボードのShifter＞Settingsで「Skip feeds」のチェックを外しておいてください。IFTTTでの設定はQiitaに投稿してありますので参照してください。現在このブログからのSNS（Twitter）への自動配信はZapierを利用していますが概ね設定方法は同じです。（余裕ができたらZapierについてもQiitaに投稿するかもしれません）IFTTThttps://ifttt.comZapierhttps://zapier.comWordPressでプラグインを使わずIFTTTを使ってRSSフィードからSNSに配信するhttps://qiita.com/gatespace/items/ebd43d1ba6ef18365415IFTTTやZapierがRSSフィードを巡回するタイミングを調整できないので記事公開からSNS投稿までのタイムラグが発生しますがおおよそ15〜30分程度で配信されます。まとめAddToAny Share Buttons は便利SNSへの自動配信はRSSフィードと別のサービスを使おう

ShifterとSNSの連動 #JP_Getshifter

あります！事前確認や注意点などあればぜひ〜— JP_Getshifter (@JP_Getshifter) September 11, 2019中の人（同僚ですが）にも事前確認や注意点などあればと言われたので、ノーマルなWordPressサイトをShifterに移行する時に留意すべきポイントを書いておきたいと思います。Shifterでのサイトの作り方やドメインの割り当てなどは割愛しますのでご了承ください。その1　移行に利用するプラグインAll-in-One WP Migrationhttps://ja.wordpress.org/plugins/all-in-one-wp-migration/移行元のWordPressに上位のプラグインをインストールして中身（投稿やユーザー、メディア、テーマ、プラグインなど全て）をエクスポートします。エクスポートしたファイルをShifter側でインポートします。移行（マイグレーション）にかかる手順はこれだけなのですが、移行元であらかじめ確認・設定しておいたほうが良いポイントがあります。その2　ShifterのアカウントとWordPressユーザーShifterでアカウントを作成するとそのメールアドレスで WordPressユーザーも管理者として作成されます。移行元とShifterとでユーザーのメールアドレスが同じ場合はWordPressユーザーも同じになるのですが、移行元での権限グループが管理者以外の場合、マイグレーション後ShifterのWordPress環境で操作ができなくなる可能性があります。私の場合、移行元が投稿者だったためShifter移行後テーマやプラグインの設定ができなくなりました。（こういった場合、Shifterでは管理者権限を付与したエマージェンシーユーザーを一時的に作成して起動ログインする方法があります）移行元で管理者以外の権限グループだった場合は管理者に変更しておきましょう。その3　Shifterで使えないプラグインがあるShifterでは静的HTMLに変換されるため、よくあるメールフォームやコメントフォーム、検索フォームが使えないのはもちろんなのですが、それ以外にもShifterで使えないプラグインがあります。https://support.getshifter.io/en/articles/1648764-force-disabled-pluginsWordPressのプラグインは非常に多いのでShifterで全てのプラグインの動作を確認しているわけではありません。あらかじめ移行元で全てのプラグインを停止しておいたほうが良いでしょう。プラグイン停止時に設定を削除するプラグインでなければマイグレーション後、プラグインを有効化した時に設定も復活します。なお、このブログをマイグレーションした時は Crayon Syntax Highlighter が有効化されてると <pre> タグのあるコンテンツで書き出しが停止されました（つまりShifterでは利用できない）。まとめShifterで登録したメールアドレスが移行元のWordPressユーザーで管理者以外の権限グループだった場合は管理者に変更しておく。移行元で全てのプラグインを停止してからマイグレーション用のデータを書き出すShifter Meetup ではマイグレーションのワークショップもあるようです。[9/12 神戸開催] Shifter Meetup West #2 これからのShifter 実践マイグレーション！https://eventregist.com/e/hCQMtsajUHnA[10/2 東京開催] Shiftup! Vol6 Shifter 実践マイグレーション！https://eventregist.com/e/tncYf1FuvSj9中の人やすでにShifterでサイトを運用されてる方も参加されるようにですので、この記事以外のマイグレーションのコツなど聞くことができるかもしれません。この機会にぜひご参加ください。

WordPressサイトをShifterに移行する時のポイント #JP_Getshifter

ShifterはWordPressを静的HTMLに変換するので動作しないプラグインがあります。このブログのShifter移行に伴って、ブログの機能の棚卸も行いました。今回はWebサイトに必須とも言えるGoogleタグマネージャー（アナリティクス）とGoogleアドセンス、AMPについて書きます。なお内容についてはノーマルなWordPressでも適用できるものです。ShifterのWordPressShifterのWordPressは都度起動とシャットダウンが行われるので、レンタルサーバーやVPSのようにSFTPやgitを使ったファイルのアップロードができません。※全くできないわけではなくそういった用途のプラグインを利用すればできます。https://www.digitalcube.jp/shifter/10479/この辺りの「めんどくささ」を考えると自作プラグインやテーマのカスタマイズでPHPコードを書くよりはプラグインを使ってダッシュボードでの操作のみで完結したいので、プラグインを使って設定をしていきます。Googleタグマネージャー（アナリティクス）要件としては <head> タグ内部と <body> 開始タグ直後（もしくは</body> タグ直前にソースコードを入れられるプラグインであればOK。後述しますがAMPに対応してAMP用のアドセンスも入れるのであればなお良し。Insert Headers and Footershttps://ja.wordpress.org/plugins/insert-headers-and-footers/<head> タグ内部と </body> タグ直前にソースコードを入れられるプラグイン。シンプル。Scripts n Styleshttps://ja.wordpress.org/plugins/scripts-n-styles/Insert Headers and Footersより高機能。サイト共通のscript、CSSの設定と投稿ごとに入力もできる。Head, Footer and Post Injectionshttps://ja.wordpress.org/plugins/header-footer/さらに高機能。AMPプラグイン対応。<body> 開始タグ直後にも入れられる。このブログでは Head, Footer and Post Injections を利用してタグマネージャーの設置をしました（タグマネージャーにGoogleアナリティクスのトラッキングも含まれる）探せばタグマネージャーのコンテナIDを入れるだけのプラグインもありますが、多機能すぎたのでまずはこのプラグインのみで運用中です。AMPAMPhttps://ja.wordpress.org/plugins/amp/AMPプラグインも多種ありますが、対応するなら上記プラグインでOK。プラグイン単体でAMP用アナリティクスにも対応してます。現行バージョンではStandard：設定してるテーマをAMPに変換し、AMP優先で表示（URLがAMPと共用）Transitional：設定してるテーマをAMPに変換し、AMPは末尾に ?amp が付与されたURLになるReader：AMPプラグインで用意してるテーマで表示。AMPは末尾に /amp/ が付与されたURLになる。とAMPに変換する場合の設定を選べます。ノーマルなWordPressの場合、プラグインやテーマがAMPプラグインに対応してる（*1）のであればどれでも動作しますが、Shifterの場合は Transitional に対応していないので注意しましょう。*1 AMP-ready plugins and themeshttps://amp-wp.org/ecosystem/Googleアドセンス以前は広告の設置箇所や個数など悩んだのですが、先にも書いた通りShifterの場合、カスタマイズしたテーマテンプレートのアップロードがしんどいので、この機会にアドセンスは全て自動広告にしました。自動広告の場合<head> タグ内部にコードを設置するだけAMP自動広告は上記にプラスしてコンテンツ本文にコード設置広告が表示される位置は閲覧者のデバイスやコンテンツのマークアップに合わせてよしなに表示。既存の広告ユニットがあれば広告ユニットが優先。広告の種別はアドセンス側で指定できるというお手軽さなので個人ブログにはオススメです。なおAMPプラグインを利用してる場合、コンテンツ内にAMP用の広告が入っているとプラグイン側で自動で <head> タグ内部に設置するコードを出力してくれますので、実質コンテンツ本文に入れるコードの設置のみでOKです。このブログでは前述のHead, Footer and Post Injectionsでコードを設置しました。まとめ最低限2つのプラグインがあれば、タグマネージャー、AMP、アドセンスの3つに対応できます。今回紹介したプラグインはShifterだけではなくノーマルなWordPressでももちろん利用できます。ブログを書くのを優先したい場合やテーマのカスタマイズに手間をかけたくない場合はオススメです。なお、SEO関連については別記事の予定です。

ブログをShifterに移行した話 Googleタグマネージャー、AMP、アドセンス編 #JP_Getshifter

遅まきながらこのブログを Shifter に移行しました。某カスタマーサクセスの人にブログ書いてと言われたのですが、Shifterでのサイトの作り方や移行、Tipsについて書かれているブログもあるのですが、コスト面についてあまり書かれてるブログが少なかったようなので書いてみようと思います。（プラグインや設定のコツなどは別記事にします。）なお、金額を記載する部分がありますが執筆時点（2019年9月4日）でのプランになりますのでご了承ください。AMIMOTO セルフホスティングでのコスト金額AWS のAMIイメージ（AMIMOTOセルフホスティング）の利用フィーとAWS EC2インスタンス（t2.micro）が主となります。EC2インスタンスは以前はリザーブドインスタンスを使って多少安くしていたのですが、更新手続きを忘れたのでオンデマンドインスタンスでの利用賞金で支払いをしてます。そのため以前書いた記事よりも若干値上がりして、約$18/月となります。料金以外のコストWordPress（コア・プラグイン・テーマ）のアップデートとそのためのバックアップ（スナップショット）SSLの証明書（Let’s Encrypt）の設定と自動更新管理画面への特定IPアドレス以外でのアクセス禁止CloudWatchを使ってCPUの監視（落とさないための監視）セルフホスティングなのでサーバーOS、ミドルウェアのアップデート（慣れないと辛い）WordPressのアップデートは管理画面からでもできるのですが、それ以外のSSLやセキュリティ対策、OSやミドルウェアのアップデートはフロントエンドエンジニア上がりのディレクターには作業にかかる時間的なコストが高かったです（慣れない、失敗したらどうしよう、手順が不安　など）また、バーチャルホストで同じEC2インスタンスに複数のWordPressをインストールしてる場合もWordPressのアップデートなどの複数回作業しないといけなくなります。Shifterでのコスト金額ドメインを割り当てるの前提であればPersonal以上で。私は2サイト運用したかったこと、ずっと使い続ける前提があったのでPersonalを年間契約したので、$15/月です。料金以外のコスト既存のWordPressサイトの移行であれば初回のマイグレーションとプラグインやテーマの再検討が必要です。新規・移行ともにカスタムドメインの割り当てが若干大変かなと思いますが、これも初回のみ。AMIMOTOでやらなければならなかったアップデートやメンテナンス部分はShifterではやる必要がなくなったので、そこのコストは無くなりました。まとめ金額的にはShifterの方が若干安くなりました。ただ、サーバーやWordPressのメンテナンスを考えると金額以上のお得感があります。Shifterに移行することで、今までできていたこと（テーマやプラグインの機能）ができなかったりといった制限も出てきますが、機能の棚卸の機会にもなりました。今のところ更新頻度の少ないコーポレートサイトなどが事例として取り上げられますが、個人ブログでも十分要件を満たすと思いますので、「WordPressのアップデート大変」を思ってる方もぜひShifterを検討して欲しいです。

ブログをShifterに移行した話 コスト編 #JP_Getshifter

要件とか公開日時と更新日時を併記したいけど、軽微な修正程度では更新日時を変更したくない。手動で掲載用の更新日時の指定をしたい記事を更新したら一覧系（HOMEやアーカイブ）の並び順も更新日順にしたい。更新しない記事もあるのでその場合は公開日時も並び順の条件に加えるという要件で 手動で更新日時を変更するなら「公開日時」を変更すればOK となるが、公開日時と更新日時を併記する都合上、記事を 初めて公開した日時をカスタムフィールドに保存しておくようにする。（カスタムフィールドで掲載したい更新日時を保存する方法の場合、並び順のクエリが複雑になるのがよろしくないという事情もある）なお、過去に投稿された記事にも対応。保存のロジック初回の公開日時は1回だけ保存されればいい隠しのカスタムフィールドにすることで投稿編集画面から変更できないようにしておく。なのでsave_post 実行時に公開済み、予約投稿、非公開の投稿のみ隠しのカスタムフィールド（_publish_date） がなかった場合公開日時を保存add_action( 'save_post', 'my_save_post' );function my_save_post( $post_id ) {    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {        return;    }    if ( wp_doing_cron() ) {        return;    }    if ( get_post_status ( $post_id ) == 'publish' || get_post_status ( $post_id ) == 'future' || get_post_status ( $post_id ) == 'private' ) {        if ( empty( get_post_meta( $post_id, '_publish_date', true ) ) ) {            $publish_date_u = get_the_date( 'U', $post_id );            update_post_meta( $post_id, '_publish_date', $publish_date_u );        }    }}※過去の投稿は管理画面の投稿一覧の一括編集で投稿を選択して、何も変更せず保存すればOK。表示カスタムフィールド _publish_date をよしなに出力。上の例ではUNIXタイムで保存してるので日時フォーマットは適宜設定。管理画面の投稿一覧初回掲載日時を出しておきたい場合参照：WordPress 管理画面の投稿一覧にカラムを追加してカスタムフィールドの値を出すadd_filter( 'manage_posts_columns' , 'add_publish_date_columns' );function add_publish_date_columns( $columns ) {    $new_columns = array();    foreach ( $columns as $column_name => $column_display_name ) {        if ( $column_name == 'date' ) {            $new_columns['publish_date'] = '記事公開日時';        }        $new_columns[ $column_name ] = $column_display_name;    }       return $new_columns;}add_action( 'manage_posts_custom_column' , 'custom_publish_date_column', 10, 2 );function custom_publish_date_column( $column, $post_id ) {    switch ( $column ) {        case 'publish_date' :            if ( ! empty( get_post_meta( $post_id, '_publish_date', true ) ) ) {                echo date_i18n( get_option('date_format') . get_option('time_format'), get_post_meta( $post_id, '_publish_date', true ) );             }            break;    }}現場からは以上です。

[WordPress] 初回の記事公開日をカスタムフィールドに残す

やりたいこと（見本はダサいが）カスタムブロックを追加してHTMLを触らずとも画像や複数のDOMが組み合わさったパーツを本文内に入れたい。 簡単に。※自作テーマなどで自作のカスタムブロックを使いたい人向け。すでに出来上がっているカスタムブロックを追加したい人は別のプラグインを探しましょう。プラグインを使おうBlock Lab管理画面からカスタムブロックの設定と内部のフィールドを設定テーマにカスタムブロックのテンプレートを作っておくプラグインがよしなにカスタムブロックの追加をしてくれるサイト：https://getblocklab.com/ドキュメント：https://github.com/getblocklab/block-lab/wiki管理画面からカスタムブロックの設定と内部のフィールドを設定タイトル：カスタムブロックの名前Slug：自動で入る。ユニークな名前にしておくIcon：お好みでCategory：ブロックエディタで挿入する時のカテゴリーField Label：カスタムブロック内のフィールドの名前Field Name：自動で入る。カスタムブロックのテンプレートで使うのでユニークな名前にしておくFiled Type：画像、テキスト、テキストエリアなど。詳しくはドキュメントを見ようFiled Location：ブロックエディタ内で編集するか、サイドバーで編集するか他はお好みで保存すると、テーマ内のどこにどのような名前でカスタムブロックのテンプレートファイルを保存すれば良いか表示されますテーマにカスタムブロックのテンプレートを作っておくルールは使用するテーマフォルダ内に blocks フォルダを作成して、そこにテンプレートファイル（PHP）を保存します。/my-theme/　└ /blocks/　　　　　　　├ block-{block name}.php // 表示用　　　　　　　└ preview-{block name}.php // エディタで編集してる時用中身はこんな感じblock-author-info.php<div class="author-info"><?php    $image = block_field( 'author-image', false ); // 要素の有無の判定できる    if ( ! empty( $image ) ) {        echo '<img src="' . $image . '" alt="' . block_field( 'author-name', false ) . '" />' . "\n";    }?><h3><?php block_field( 'author-name' ); ?></h3><p><?php    $author_information = block_value( 'author-information' );    echo nl2br($author_information); // textarea は自動で改行されない?></p></div>エディタで編集してる時にCSSも合わせたいときは style-editor.css を作ってよしなにCSS書いてください。プラグインがよしなにカスタムブロックの追加をしてくれるブロック挿入時挿入された後現場からは以上です。

[WordPress] Gutenberg（ブロックエディタ）にカスタムブロックを追加（Block Lab利用）

答えは _s のソースコードにあるので、おおよそ公式ディレクトリ掲載のテーマは対応してますが、ポイントは以下。公開日時は get_the_date() https://developer.wordpress.org/reference/functions/get_the_date/更新日時は get_the_modified_date() https://developer.wordpress.org/reference/functions/get_the_modified_date/予約投稿をした場合、公開日時よりも更新日時が 過去 になる日時の比較をするときはUNIXタイムで。答えは以下。https://github.com/Automattic/_s/blob/master/inc/template-tags.php#L10-L36_s では 公開日時と更新日時が 一致しない 場合に両方表示するようにしていますが、予約投稿で公開日時よりも更新日時が過去になるのが気になる場合は if の所を変えればOK。if ( get_the_time( 'U' ) < get_the_modified_time( 'U' ) ) {余談DATE_W3C という定数とはなんぞやと思った人は以下http://php.net/manual/ja/class.datetime.phpPHP 5.2.0 とPHP7で使えるDateTime クラスの定数

[WordPress] 公開日時と更新日時を表示しつつ予約投稿で公開日よりも更新日時が過去になるのを避ける

2018年12月20日(木) に東京は渋谷（原宿）というハイカラな場所で行われたShifter の日本のコミュニティのキックオフイベント Shiftup! JP_Getshifter キックオフイベント Shifterコミュニティがついに日本上陸！ に参加して来ました。宣言通り軽い気持ちで撮影班するつもりだったのですが、主催の偉い人たちから「スマホではなくカメラで撮って」と言われ真剣に撮影班してたので内容がうろ覚えなのはご勘弁ください。おかん 今日も働き者 #JP_Getshifter石田 知也さんの投稿 2018年12月20日木曜日会場とか参加者会場は原宿にあるStripeさんのオフィスをお借りしました。最寄駅出たところでイルミネーションあるわ人が多いわで「これがリア充が訪れる街か。。。」と思ったのはここだけの話です。オフィスからは東京タワーもスカイツリーも見えるとのことでおしゃれな感じにクラクラします。今回はキックオフということもあってビールやピザを楽しみながらの会となりました。参加者もAWS（JAWS-UGの歴代の代表）界隈のいわゆるインフラ側の方からWordPress界隈（テーマやプラグインを開発してる層からブログとして使ってる層）といった、あまり混じったことのない両者が集まっているなぁというのが印象的でした。セッションの内容雰囲気は Togetter にまとめやイベントレポートがあるのでそちらをどうぞ。私は写真撮るのに忙しかったので！2018/12/20 Shiftup! JP_Getshifter キックオフイベント Shifterコミュニティがついに日本上陸！日本Shifterユーザー初のイベント「Shiftup!」を開催しました！Serverless Static Site Generator 「Shifter」の紹介と10のよくある質問静的サイトジェネレーターからShifterに移った話Shifterを使ってみて感じた108の良かったこと/悪かったことShifterのダメなところLT：Let’s Change to Shifter    20181220_Lets_Change_toShifter  from Hisayuki Mori 撮影班したよ！「子供の学校行事の写真が取れればいい」ぐらいのアマチュアレベルもいいところな上、機材もEOS Kiss X8i＋EF-S18-135 IS USM レンズというママさん向けデジイチエントリーモデルだったわけですが、超頑張った。写真どこにあげようか悩んだ挙句Googleに置いてるのでよかったらどうぞ。https://photos.app.goo.gl/aaFxXyD78egMWLvVA次回の開催2/6にまたStripeさんでやりますのでTwitterの @JP_Getshifter を是非フォローお願いします。Shiftup! JP_Getshifter Vol1！また「Shifterに移行しました！」なネタも大募集なので、SNSに投稿する際はぜひ #JP_Getshifter のハッシュタグをつけて投稿してみてくださいね。

Shiftup! #JP_Getshifter キックオフイベントに行って来ましたよ

やりたいことSimple GA Ranking で特定の投稿（URL）を除外したいSimple GA Ranking は WordPress で Google Analytics のデータを利用してランキングを表示させるプラグインです。ランキングデータを外部（Google Analytics）に持たせるため、WordPressを設置してるサーバーの負荷が軽いのが利点。プラグイン自体に投稿タイプを除外したり、特定のカテゴリー（ターム）に絞ったり除外したりもできますが、特定の投稿を除外できないのが難点だったりします。特定の投稿（URL）を除外＝フィルターパラメータを使うSimple GA Ranking は Core Reporting API のフィルターパラメータを指定することができます。Query Explorer を使いながら検証するのが便利。例としてノーマルで取得できる上記のデータから /2013/03/05/aws-s3-static-site/ を除外したい時は filters で ga:pagePath!@aws-s3-static-site とすると除外されます。正規表現が使えるので Core Reporting API 見ながらよしなに変更してください。これを Simple GA Ranking の filter に渡します。PHPの場合<?php$args = array(    'filter' => 'ga:pagePath!@aws-s3-static-site');$ranking_data = sga_ranking_get_date( $args );?>ショートコードの場合[sga_ranking filter="ga:pagePath!@aws-s3-static-site"]現場からは以上です。

[WordPress] Simple GA Ranking で特定の投稿を除外したい

前提としてAdvanced Custom Fields で Google Map の設定などができてるGoogle Maps のAPIが有料なのは知ってる有料化に伴いAPIもあれこれ変わったらしく、以前から利用していたサイトで「APIが有効化されてない」と表示されたので、覚書。APIキーをとるとき※有料化に関してなんやかんや登録しないといけないことは割愛1 Google Maps Platform から「使ってるみる」をクリック2 Enable Google Maps Platform で Maps を選択して CONTINUE3 Select a project と Set up your billing は割愛4 WP側にAPIキーを反映させるコードも割愛ここから重要ACF使わないでGoogle Mapを埋め込むだけなら上記で有効化されるAPIでOKなのですが、管理画面で Google Map を住所で検索する場合、追加で Places API for Web が必要になります。（ちょっと気づかないよねこれ）1 Maps API のコンソール を開いて、設定したいプロジェクトか確認します。2 API メニューの「未使用の API」から「Places API for Web」をクリックして有効にします。Google Maps Platform からの手順を書いてますが、通常のAPIコンソールから Places API for Web を有効化してもOK。この手順で有効化されるAPIMaps Embed API：iframe で埋め込むとき必要Maps JavaScript API：JavaScriptで埋め込むときに必要Maps SDK for AndroidMaps SDK for iOSMaps Static APIPlaces API for WebStreet View API「ACFのGoogle Mapを使うときは Maps のセットの他に Places API for Web も必要」 ということで現場からは以上です。

[WordPress] Advanced Custom Fields で Google Map を使うときに取得しておくAPI

2021年5月18日 追記今はこんな面倒なことをしなくても Google Tag Manager で設定できるので、この記事のことは忘れて Google Tag Manager の使い方を覚えましょう。https://tagmanager.google.com/ダメなパターン$( 'a.event_tracking' ).on( 'click', function( e ) {    gtag( 'event', 'click', {        'event_category': 'イベントカテゴリ',        'event_label'   : 'イベントラベル'    });  });これだと、次のページの読み込みが始まるとjavascriptの実行が停止してイベントトラッキングが完了しないことがある。（よく考えれば当たり前だよね。。。）成功パターン一旦止めてコールバックで実行すればいい。https://developers.google.com/analytics/devguides/collection/gtagjs/sending-data?hl=ja$( 'a.event_tracking' ).on( 'click', function( e ) {    if ( typeof gtag === 'function' ) { // gtag.js が読まれてる時だけ実行        e.preventDefault(); // 一旦止める        var linkUrl = $(this).attr('href'); // そのaタグのリンク先を取得しておく        gtag( 'event', 'click', {            'event_category': 'イベントカテゴリ',            'event_label'   : 'イベントラベル',            'event_callback': function() { // イベントトラッキングが送信されたら呼び出される                location.href = linkUrl;            }        });    }});セレクタとかはよしなに変更してください。現場からは以上です。

Google アナリティクス（gtag.js）でリンクをイベントトラッキングする

WP Post Branches公開された記事に対して「ブランチ」を作って指定日時（公開予定日時）で元の投稿を上書きするプラグイン上書きされるまで元の投稿はそのまま公開しておける使い方はぐぐってください元記事の公開日時も更新されてしまう問題早い話プラグインの仕様な訳ですが、アーカイブなどで記事の順序が入れ替わるのでそれをやめたいわけです。元記事の更新日時をブランチ記事の公開日時にする元記事の公開日時は変更しないフィルターフックがあるのでよしなに改変すればOK。https://github.com/horike37/WP-Post-Branches/blob/master/wp-post-branches.php#L179my_wpbs_draft_to_publish_update_post.phpadd_filter( 'wpbs_draft_to_publish_update_post', 'my_wpbs_draft_to_publish_update_post', 10, 1 );function my_wpbs_draft_to_publish_update_post( $new ) {    // 元記事の更新日時をブランチ記事の公開日時にする    $new['post_modified']      = $new['post_date'];    $new['post_modified_gmt']  = $new['post_date_gmt'];    // 元記事の公開日時は変更しない    $old_id   = $new['ID'];    $old_post = get_post( $old_id );    $new['post_date']     = $old_post->post_date;    $new['post_date_gmt'] = $old_post->post_date_gmt;    return $new;}現場からは以上です。

[WordPress] WP Post Branches で更新された元記事の公開日時を変更しない

WP Simple Related Postsカテゴリやタグをベースとした関連記事を出すプラグイン。投稿編集時に任意の記事に置き換えることもできる。自動で本文の最後に表示される（表示項目は記事のタイトルとリンク）かつアイキャッチ画像や抜粋をよしなに表示したい場合のカスタマイズ関連記事のID取得GitHubに説明ある通り。パラメーターはよしなに。<?php$ids = sirp_get_related_posts_id();戻り値が連想配列なので注意array(3) {    [0]=> array(1) {        ["ID"]=> string(4) "7763"    }    [1]=> array(1) {        ["ID"]=> string(4) "7757"    }    [2]=> array(1) {        ["ID"]=> string(4) "7753"    }}アイキャッチ画像や抜粋の表示アイキャッチ画像は投稿IDを渡して取得できるが、抜粋（ the_excerpt(), get_the_excerpt() ）はループ外で使えない＝投稿IDを渡してもグローバル変数の　$post　を参考にしてしまうので、関連記事のIDで forearch するのではなく、WP Queryクラス（または get_posts() ） で処理しましょう。htmlタグとかはよしなに変更してください。my_simple_related_posts.php<?phpfunction my_simple_related_posts() {    // プラグインが有効化されてなかったら関数がないってことなので終了    if ( ! function_exists( 'sirp_get_related_posts_id' ) )        return;    $related_posts_ids = sirp_get_related_posts_id();    // 関連記事IDがなかったら終了    if ( empty ( $related_posts_ids ) )        return;    // WP_Query クラスに渡す為にsirp_get_related_posts_id()の戻り値をよしなに変更    $ids = array();    foreach ( $related_posts_ids as $related_posts_id ) {        $ids[] = $related_posts_id['ID'];    }    if ( empty ( $ids ) )        return;    // 配列を整形した投稿IDを元に投稿を取得    $related_posts = new WP_Query( array(        'posts_per_page' => -1,        'post__in'       => $ids,        'order'          => 'ASC',        'orderby'        => 'post__in'    ) );    if ( $related_posts->have_posts() ) {        echo '<h3>関連記事</h3>';        echo '<ul>';        // ループ開始        while ( $related_posts->have_posts() ) {            $related_posts->the_post();            echo '<li>';            echo '<a href="' . get_the_permalink() . '">';            if ( has_post_thumbnail() ) {                the_post_thumbnail( 'thumbnail' );            }            the_title( '<h4>', '</h4>' );            echo '<div class="excerpt">';            the_excerpt();            echo '</div>';            echo '</li>';        } // ループ終わり        echo '</ul>';    }    wp_reset_postdata();}現場からは以上です。

[WordPress] WP Simple Related Posts で関連記事にアイキャッチ画像や抜粋をつけたい

お手軽にAMP対応したいプラグイン「AMP for WordPress」を入れましょう。https://ja.wordpress.org/plugins/amp/AMP for WordPress の標準機能AMPページの作成通常ページで <link rel="amphtml" href="http://example.com/xxxx/amp/"> の追加投稿作成時にAMPでのプレビューボタン追加投稿ごとにAMPにするかどうかを選択できる外観＞カスタマイズでのAMPでのプレビュー機能テーマカスタマイザーでAMPページのヘッダーテキスト色、ヘッダー背景色とリンク、メイン部分の背景色とテキスト色の変更GoogleアナリティクスなどAMP対応のアナリティクスコードの管理と出力以下、機能やカスタマイズの説明。固定ページやカスタム投稿タイプもAMPにしたいダッシュボードのAMP＞Generalで「Post Type Support」にチェック入れるだけ。（ver 0.6〜）PHPコード不要となりました。ヘッダーやメイン部分の色を変えたい外観＞カスタマイズ＞AMPである程度は変更可能ヘッダーのテキスト色ヘッダーの背景色とテキストリンク色（ただしこれはセット）メイン部分の背景色とテキスト色（白背景＋黒文字 or 黒背景＋白文字の二択）なお、WordPressコア機能の「サイトアイコン」を設定して入れば右上に出ますアナリティクス入れたいダッシュボードのAMP＞Analyticsから設定可能。AMPに対応してるアナリティクスのTypeとJSONコードだけでOK。Googleアナリティクスの管理画面からトラッキングコードのように自動で発行されるわけではないので、Googleアナリティクスの場合は以下のドキュメントを参考にJSONコードを作りましょう。https://developers.google.com/analytics/devguides/collection/amp-analytics/以上、ここまではプラグインのインストールのみで対応できる部分。自前のテンプレートにしたい。以前書いた「[ざっくり翻訳] WordPress AMP プラグイン カスタマイズなどの説明」 は多少情報が古くなってるので Wikiを頑張って読みましょうプラグイン付属のテンプレートを「ちょっと変えたい」レベルであればアクションフックやフィルターフックで対応できます。HTML構造からもろもろフルカスタマイズしたい場合はカスタムテンプレートを作りましょう。筆者のオススメはプラグイン形式でカスタムテンプレートを作る方法です。これだとテーマの切り替えに依存しないし、プラグインの有効化・停止で切り替えできるので。現場からは以上です

[WordPress] AMP 対応するときのプラグインやカスタマイズ

「[WordPress] ターム（カテゴリー・タグ）アーカイブで記事が指定件数以下なら404扱いにしたい」https://qiita.com/gatespace/items/a29b0814a308fa2d77d7上記でアーカイブページを404にしたのだけど、投稿ページ（single.php）カテゴリーやタグの一覧や、ウィジェットのカテゴリーやタグクラウドなど、とにかくリンク自体も出したくない場合。投稿に関する場合the_category(), the_tags(), the_terms() など最終的には get_the_terms() で呼び出してるので大元のフィルターフックで改変。https://developer.wordpress.org/reference/functions/get_the_terms/my_get_the_terms.php<?php// get_the_terms でタグに所属する投稿が指定した件数より少なかったら表示しないadd_filter( 'get_the_terms', 'my_get_the_terms', 10, 3 );function my_get_the_terms( $terms, $post_id, $taxonomy ) {    if ( is_admin() ) { // 管理画面だったら何もしない        return $terms;    }    if ( $taxonomy != 'post_tag') { // 条件分岐はよしなに        return $terms;    }    $new_terms = array();    foreach ( $terms as $term ) {        if ( $term->count >= 6 ) {            $new_terms[] = $term;        }    }    return $new_terms;}投稿に関係ないタームの一覧の場合ウィジェットの「カテゴリー」や「タグクラウド」などなど、タームに関するものはget_terms() で呼び出してるので大元のフィルターフックで改変。https://developer.wordpress.org/reference/functions/get_terms/なお、4.5.0以降は get_terms() のパラメーターでタクソノミーの渡し方が変わってるので注意。my_get_terms.php<?php// get_terms でタグに所属する投稿が指定した件数より少なかったら表示しないadd_filter( 'get_terms', 'my_get_terms', 10, 4 );function my_get_terms( $terms, $taxonomies, $args, $term_query ) {    if ( is_admin() ) { // 管理画面だったら何もしない        return $terms;    }    if ( $taxonomies[0] != 'post_tag' ) { // 条件分岐はよしなに        return $terms;    }    $new_terms = array();    foreach ( $terms as $term ) {        if ( $term->count >= 6 ) {            $new_terms[] = $term;        }    }    return $new_terms;}Advanced Custom Fields のタクソノミーフィールドの場合https://www.advancedcustomfields.com/resources/taxonomy/Objectsにしていた場合は $term->count で記事数が取れるのでよしなに条件分岐で弾いてください。（IDの場合はしちめんどくさいので）現場からは以上です。

[WordPress] ターム（カテゴリー・タグ）の記事が指定件数以下なら一覧などに出力しない

タイトルそのまま。template_redirect アクションフック使うだけ。タームにはカテゴリー、タグも含まれるので条件分岐はよしなに。via. https://increment-log.com/access-redirect-404/コードtag_archive_template_redirect.php<?phpadd_action( 'template_redirect', 'tag_archive_template_redirect' );function tag_archive_template_redirect() {    if ( ! is_tag() ) { // タグアーカイブ以外は何もしない        return;    }    $queried = get_queried_object();    if ( $queried->count < 6 ) { // 総記事数が5件以下なら        global $wp_query;        $wp_query->set_404();        status_header( 404 );    }}template_redirect : https://developer.wordpress.org/reference/hooks/template_redirect/get_queried_object() : https://developer.wordpress.org/reference/functions/get_queried_object/WP_Query::set_404() : https://developer.wordpress.org/reference/classes/wp_query/set_404/status_header() : https://developer.wordpress.org/reference/functions/status_header/現場からは以上です。

[WordPress] ターム（カテゴリー・タグ）アーカイブで記事が指定件数以下なら404扱いにしたい

やりたいことタグ（カテゴリー、ターム）一覧を表示したい数が多くなったらページ送りしたい。WordPressは自動でタグ（カテゴリー、ターム）一覧のページを生成しないのでよしなにやる必要があります。コード単純にWordPress上にあるタグ全ての情報を得るだけなら　get_terms() でいいけど、ページ送りしようと思うとちょっと面倒よね、という話で。固定ページに埋め込む想定。page-{slug}.php など作って他に影響出ないようにしましょう。<?php    $terms = get_terms( 'post_tag', array(        'orderby' => 'count',     ));    if ( ! empty( $terms ) ) {        $html           = '';        $posts_per_page = 5; // 1ページあたりのタームの表示数        $count = 1;        foreach ( $terms as $term ) {            $html .= '<div><a href="' . get_term_link( $term ) . '">' . esc_html( $term->name ) . '</a></div>';            if ( $count === $posts_per_page ) {                $html .= '';                $count = 1;            } else {                $count++;            }        }        $html = rtrim( $html, '' );        $post->post_content = rtrim( $html, '' );        setup_postdata( $post );    }    the_content();    wp_link_pages( array(        'before' => '<div class="page-links">' . esc_html__( 'Pages:', 'iemoto' ),        'after'  => '</div>',    ) );    wp_reset_postdata();?>現場からは以上です。

[WordPress] 固定ページでタグ（カテゴリー、ターム）一覧を出してかつページ送りも実装

やりたいことタグのスラッグ使わないで　http://example.com/tag/{$term_ID}/ の形にする。デフォルトだと意識してタグのスラッグを編集しない限りタグの名前が自動でスラッグになるので、2バイトだと /tag/%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB%E3%83%89/ となってちょっと、、、という場合に。投稿タグのフィードやページ送りもバッチリOK。なお、カテゴリーアーカイブのパーマリンクをカテゴリーIDにしたい場合は以下の記事参照。カテゴリーのパーマリンクをカテゴリーIDにするよソースコードはいどーん。<?phpfunction numeric_term_link( $url, $term, $taxonomy ) {    global $wp_rewrite;    // post_tag only    if ( $taxonomy == 'post_tag' ) {        if ( $wp_rewrite->using_permalinks() ) {            $permastruct = $wp_rewrite->get_extra_permastruct( 'post_tag' );            $permastruct = str_replace( '%post_tag%', $term->term_id, $permastruct );            $url = home_url( user_trailingslashit( $permastruct, 'tag' ) );        }    }    return $url;}add_filter( 'term_link', 'numeric_term_link', 10, 3 );function add_tag_id_to_qvar( $vars ) {    $vars[] = 'tag_id';    return $vars;}add_filter( 'query_vars', 'add_tag_id_to_qvar' );function numeric_tag_rewrite_rules( $rules ) {    $custom_rules = array();    foreach ( $rules as $regex => $rewrite ) {        $regex = str_replace( '/(.+?)/', '/([0-9]{1,})/', $regex );        $rewrite = str_replace( '?tag=', '?tag_id=', $rewrite );        $custom_rules[$regex] = $rewrite;    }    return $custom_rules;}add_filter( 'post_tag_rewrite_rules', 'numeric_tag_rewrite_rules' );term_link のフィルターフックで numeric_term_link() を実行し、投稿タグアーカイブへのリンクをスラッグらタグIDになるよう変更。なおこれはURLのみを変更するのでこれだけでは片手落ち。リライトルールでタグIDを使えるように query_vars のフィルターフックで tag_idを追加しておく。リライトルールにフックは色々あるけど、post_tag_rewrite_rules で投稿タグのリライトルールに限定して改変。最後に管理画面の「パーマリンク設定」を変更せずに更新すること現場からは以上です。

IGARASHI Kazue

WordPress ＋ Algoliaで、Algoliaの検索対象から特定の投稿（固定ページ、カスタム投稿タイプ）を除外する

皆様の1年目はどうでしたか？- 1997 年から2021年の仕事の話

[WordPress] 投稿に作成者と別に監修者を設定して、作成者別アーカイブで合わせて表示

WordPressのテーマカスタマイズの歴史

Snow Monkey ＋ Shifter で手軽に安全なサイトを作ろう #JP_GetShifter, #wpsnowmonkey

[WorPress] RSSフィードからSNS配信するときにタグをハッシュタグで追加したい

Auth0 + Webサイトで設定しておいたほうがいいこと

Shifterで子供のブログを作って親子で運用

[WordPress] 検索結果の並び順

サイトの見た目に合わせてGoogleフォームを埋め込むサービス Formfacade

Shifter Github Plugin/Theme Installer を使って自作テーマ・プラグインをアップデートしよう #JP_Getshifter

input 要素はブラウザ（スマートフォン含む）によってUIが変わる

ShifterとSNSの連動 #JP_Getshifter

WordPressサイトをShifterに移行する時のポイント #JP_Getshifter

ブログをShifterに移行した話 Googleタグマネージャー、AMP、アドセンス編 #JP_Getshifter

ブログをShifterに移行した話コスト編 #JP_Getshifter

[WordPress] 初回の記事公開日をカスタムフィールドに残す

[WordPress] Gutenberg（ブロックエディタ）にカスタムブロックを追加（Block Lab利用）

[WordPress] 公開日時と更新日時を表示しつつ予約投稿で公開日よりも更新日時が過去になるのを避ける

Shiftup! #JP_Getshifter キックオフイベントに行って来ましたよ

[WordPress] Simple GA Ranking で特定の投稿を除外したい

[WordPress] Advanced Custom Fields で Google Map を使うときに取得しておくAPI

Google アナリティクス（gtag.js）でリンクをイベントトラッキングする

[WordPress] WP Post Branches で更新された元記事の公開日時を変更しない

[WordPress] WP Simple Related Posts で関連記事にアイキャッチ画像や抜粋をつけたい

[WordPress] AMP 対応するときのプラグインやカスタマイズ

[WordPress] ターム（カテゴリー・タグ）の記事が指定件数以下なら一覧などに出力しない

[WordPress] ターム（カテゴリー・タグ）アーカイブで記事が指定件数以下なら404扱いにしたい

[WordPress] 固定ページでタグ（カテゴリー、ターム）一覧を出してかつページ送りも実装

[WordPress] タグアーカイブのパーマリンクをタグIDにする

WordPress ＋ Algoliaで、Algoliaの検索対象から特定の投稿（固定ページ、カスタム投稿タイプ）を除外する

皆様の1年目はどうでしたか？- 1997 年から2021年の仕事の話

[WordPress] 投稿に作成者と別に監修者を設定して、作成者別アーカイブで合わせて表示

WordPressのテーマカスタマイズの歴史

Snow Monkey ＋ Shifter で手軽に安全なサイトを作ろう #JP_GetShifter, #wpsnowmonkey

[WorPress] RSSフィードからSNS配信するときにタグをハッシュタグで追加したい

Auth0 + Webサイトで設定しておいたほうがいいこと

Shifterで子供のブログを作って親子で運用

[WordPress] 検索結果の並び順

サイトの見た目に合わせてGoogleフォームを埋め込むサービス Formfacade

Shifter Github Plugin/Theme Installer を使って自作テーマ・プラグインをアップデートしよう #JP_Getshifter

input 要素 はブラウザ（スマートフォン含む）によってUIが変わる

ShifterとSNSの連動 #JP_Getshifter

WordPressサイトをShifterに移行する時のポイント #JP_Getshifter

ブログをShifterに移行した話 Googleタグマネージャー、AMP、アドセンス編 #JP_Getshifter

ブログをShifterに移行した話 コスト編 #JP_Getshifter

[WordPress] 初回の記事公開日をカスタムフィールドに残す

[WordPress] Gutenberg（ブロックエディタ）にカスタムブロックを追加（Block Lab利用）

[WordPress] 公開日時と更新日時を表示しつつ予約投稿で公開日よりも更新日時が過去になるのを避ける

Shiftup! #JP_Getshifter キックオフイベントに行って来ましたよ

[WordPress] Simple GA Ranking で特定の投稿を除外したい

[WordPress] Advanced Custom Fields で Google Map を使うときに取得しておくAPI

Google アナリティクス（gtag.js）でリンクをイベントトラッキングする

[WordPress] WP Post Branches で更新された元記事の公開日時を変更しない

[WordPress] WP Simple Related Posts で関連記事にアイキャッチ画像や抜粋をつけたい

[WordPress] AMP 対応するときのプラグインやカスタマイズ

[WordPress] ターム（カテゴリー・タグ）の記事が指定件数以下なら一覧などに出力しない

[WordPress] ターム（カテゴリー・タグ）アーカイブで記事が指定件数以下なら404扱いにしたい

[WordPress] 固定ページでタグ（カテゴリー、ターム）一覧を出してかつページ送りも実装

[WordPress] タグアーカイブのパーマリンクをタグIDにする

input 要素はブラウザ（スマートフォン含む）によってUIが変わる

ブログをShifterに移行した話コスト編 #JP_Getshifter