カテゴリー: WordPress
この記事は2024年3月16日に書かれたものです。情報が古い可能性がありますのでご注意ください。
イベント等の開催日を Advanced Custom Fields (ACF) の日付選択フィールドで作成し、この開催日をを使って年月別のアーカイブページを作りたい。そして更に、その月別リストを年単位で開閉表示させたいと考えました。
通常の月別アーカイブの月別リストを年単位で開閉表示させる方法は、「WordPressの月別アーカイブを年単位で開閉させる *Ateitexe」に書かれていましたので、これを参考にさせていただきました。
一方、カスタムフィールドの日付から月別アーカイブを作成する方法は、「カスタムフィールドに入力した日付で月別絞り込み&アーカイブページの整形 | oku-log」等で説明されていますが、今回は月別リストの開閉表示をしたかったので、オリジナルで実装してみることにしました。
“カスタムフィールドの日付フィールドで年毎に折りたたみ可能な月別リストとアーカイブページを作成” の続きを読む »
カテゴリー: WordPress
この記事は2023年9月12日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress のブロックエディタ Gutenberg の不要なブロックを非表示にする方法として以下のような手段がありますが、いろいろ試して PHP と JavaScript の併用して制御する方法に落ち着きました(半分妥協)。
- 「設定」の「表示ブロック」で制御する
- プラグイン「Disable Gutenberg Blocks – Block Manager」を使う
- PHP で制御する(ホワイトリスト形式)
- JavaScript で制御する(ホワイトリスト形式/ブラックリスト形式)
まず、「設定」の「表示ブロック」で制御する方法は、ユーザー毎に設定しなければならないこと、設定を知っている人なら誰でも変更できるので使おうと思えば使えてしまうことから却下。
プラグインを使う方法は、埋め込み系のブロックを個別に非表示にすることができないのと、多数のサイトを管理している場合に WordPress のアップデートでブロックが追加されるなどしたとき、それぞれのサイトにログインしてプラグインの設定画面を開いてを再設定するのが面倒。(PHP や JavaScript を編集するのも面倒ですが、コピペできるのでプラグインより多少は楽かと。)
PHP で制御する方法も埋め込み系のブロックを個別に非表示にすることができず、唯一、埋め込み系のブロックを個別に非表示にできて、不要なブロックを指定するブラックリスト形式にもできる JavaScript で制御する方法に決定!と思ったのですが…。
“Gutenberg の不要ブロックを非表示にする方法 … PHP と JavaScript の併用に落ち着く” の続きを読む »
カテゴリー: WordPress
この記事は2023年9月11日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress のブロックエディタ Guteberg で説明リスト(dl, dt, dd)を使用
するために、以前から WP-Yomigana プラグインを利用していましたが、このプラグインで dt や dd タグを追加するための操作が不可解になってきたので、Simple Definition List Blocks プラグインに入れ替えました。
元々 WP-Yomigana は、ブロックエディタが登場するずっと前から TinyMCE のプラグインとして利用していたもので、本来は ruby タグを挿入するボタンを追加することが目的のプラグインですが、付随機能として注釈(small)、引用(q)、引用元(cite)、そして定義リスト※1(dl, dt, dd)を入力するボタンも追加できるようになっており、この定義リストの機能のみを使っていたのでした。
“Gutenberg で説明リストを使うためのプラグインを WP-Yomigana から Simple Definition LIst Blocks に変更” の続きを読む »
カテゴリー: WordPress
この記事は2023年8月1日に書かれたものです。情報が古い可能性がありますのでご注意ください。
「PublishPress Future」は WordPress の記事に有効期限を設定して自動で非公開にしたり、カテゴリーを変更したりすることができるプラグインで、いくつかのサイトで利用しています。
元は「Post Expirator」という名前のプラグインでしたが、2021年12月に ver 2.7.0 へのアップデートに合わせて開発者が変更となり、名前も「PublishPress Future」に変更されました。
その後も何度かアップデートを重ね、2023年6月に ver 3.0.0 となったのですが、この時にいくつかの問題が発生しました。
ちなみに、私は WordPress 本体やプラグインをアップデートする際は、まずローカルサーバのテストサイトでアップデートしてみて、動作等問題がないかを確認してから運用中のサイトにアップデートを行なっています。なので、自動更新の設定は有効にしていません。
私がテストサイトで確認した問題は以下の4つです。
“PublishPress Future プラグインのアップデートによるバグと日本語化ファイル” の続きを読む »
カテゴリー: WordPress
この記事は2023年7月24日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress で予約システムを構築するプラグイン「Booking Package」ですが、全てのメニューや設定画面には管理者権限と編集者権限でアクセスできるものの、予約リストの CSV ダウンロードについては編集者には権限が与えられていません。
CSV ダウンロードが行えるのは「管理者」と「Booking Package Manager」、「Booking Package Editor」の権限のいずれかで、「Booking Package Manager」 と「Booking Package Editor」の権限設定は無料版では利用できないようです。
しかし、予約業務を行う担当者に WordPress の管理者の全ての権限を与えるわけにはいきませんので、他のプラグインを使って編集者権限でも CSV ダウンロードが出来るようにしてみました。
“Booking Package で編集者権限でも CSV ダウンロードが出来るようにする” の続きを読む »
カテゴリー: WordPress
この記事は2021年2月28日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress のショッピングサイト構築プラグイン Welcart で、定期購入プラグイン WCEX Auto Delivery を利用した場合、定期購入商品をカートに入れてお客様情報入力ページに遷移すると、ログインフォームのみが表示されます。そのため、新規の購入者は「新規会員登録はこちら」をクリックして別画面で会員登録をする必要があります。
定期購入は会員登録が必須となっているための仕様と思われますが、通常購入の場合はお客様情報入力ページで購入者情報の入力と同時に任意で会員登録ができるので、これと同じように定期購入の場合でも、お客様情報入力ページでそのまま会員登録ができた方がフローが統一され、分かりやすいのではないかと思います。
そこで検索すると、Welcart のテクニカルノートに「【Auto Delivery】定期購入時のカート遷移中に会員登録フォームの表示カスタマイズ」というドンピシャな記事があったのですが、これは Welcart Basic のテーマを使用した場合のもので、Welcart Basic 独自の関数が使われているため、WCEX Auto Delivery 同梱の wc_customer_page.php を使用したオリジナルテーマには当てはまりません。
また、「次へ」ボタンの非表示だけでなく、パスワード欄の表記なども変更した方がよいので、そのカスタマイズを考えてみました。
“Welcart の定期購入のカート遷移中にお客様情報入力ページで購入者情報入力フォームを表示して会員登録を必須にする” の続きを読む »
カテゴリー: WordPress
この記事は2020年8月9日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress の投稿を自動で Facebook ページに投稿したい案件があり、当初、自動投稿に特化し機能も豊富な NextScripts: Social Networks Auto-Poster (SNAP) というプラグインを使用しようと設定を進めていましたが、“Invalid Scopes: manage_pages, publish_pages.
” という警告が出て、どうにも連携することができず。
どうも、テストアプリを作成したり、レビュー申請ビデオを作成して Facebook の審査を受けなければならないなど、いろいろ面倒っぽいので、SNAP の利用は諦め、API が不要な Jetpack プラグインを利用することにしました。Jetpack はアクセス解析やセキュリティ対策など、30種類以上もの機能がパックになっているプラグインですが、この中にある Facebook や Twitter などの SNS と連携できる「パブリサイズ共有」の機能を使用します。
ただ、自動投稿に特化したプラグインではないので、デフォルトではカスタム投稿タイプに対応していません。また、今回カスタム投稿タイプの投稿全てと、標準の投稿の内、特定のカテゴリの投稿のみを Facebook に自動投稿せる必要があるのですが、カテゴリを選択できる機能もないので、カスタマイズしてみました。
“Jetpack のパブリサイズ共有をカスタム投稿タイプと特定のカテゴリの投稿のみに適用する” の続きを読む »
カテゴリー: WordPress
この記事は2020年7月11日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress からカスタム投稿タイプの投稿データとそれに関連するデータを CSV で出力したい案件があり、テーマの中のテンプレートを使って実現してみました。
投稿データを CSV で出力できるプラグインはあるようですが、今回一定の条件で絞り込んだり、Advanced Custom Fields の「投稿オブジェクト」カスタムフィールドで紐付けた、別のカスタム投稿タイプの投稿データを一緒に出力する必要があったため、特定のページのテンプレートを作成する要領で実現できないかと考えました。
7年くらい前まで Movable Type を使っていましたが、Movable Type のテンプレートは静的ファイルを書き出すので、書き出すファイル名と拡張子を指定すれば、CSV などのテキストファイルを書き出すことも、CSS や JavaScript のファイルに MT タグを使って、セレクタや値を代入したり変数をループで処理したりすることができました。
一方、WordPress のテンプレートは動的に Web ページを表示するものなので、Movable Type のように簡単には行きません。
でも、以前 WordPress に FullCalendar を組み込んだ際、カレンダーに投稿データを読み込むための JSON 形式のファイルをテンプレートを使って作成したり、同じように Google Map に投稿データからマーカーを生成するための XML 形式のファイルをテンプレートを使って作成した経験がありましたので、まずは同様の方法で CSV 形式のファイルを作成してみました。
“WordPress からテーマのテンプレートを使って CSV を書き出す” の続きを読む »
カテゴリー: WordPress
この記事は2020年7月7日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress でメールフォームから送信されたデータを元に、自動で投稿を作成したい案件があり、調べてみたら Contact Form 7 を使うと実装できることがわかりました。
ContactForm7のフォーム送信時に自動でブログ記事を作成する方法
Contact Form 7 で用意されているフック「wpcf7_mail_sent」を利用して投稿を作成できるというもので、カスタムフィールドの値も登録することができ、まさに実現したい仕様でしたが、今回、Advanced Custom Fields (ACF) プラグインのグループフィールドのサブフィールドにもデータを登録する必要がありました。
そこで、次の記事を参考にして、上記の方法と組み合わせることで実現することができました。
【WordPress】PHPプログラムからAdvanced Custom Fieldsの繰り返しフィールドに値を保存する方法 – 上尾市のWEBプログラマーによるブログ
更に、Contact Form 7 Serial Numbers プラグインによる連番も取得してカスタムフィールドに反映してみました。
“Contact Form 7 の送信データから自動で投稿を作成し、ACF のグループフィールドに反映させる” の続きを読む »
カテゴリー: WordPress
この記事は2020年6月3日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress のバージョンを 5.2 から 5.4 にアップグレードしました。昨年11月に 5.3 がリリースされていましたがアップグレードを保留していたので、1世代超えてのメジャーバージョンアップとなりました。
するとあるサイトで、Advanced Custom Fields (ACF) プラグインのデイトピッカーで設定した日付が、1日前の日付で表示されるというトラブルが発生しました。時刻を設定してないので確認できませんが、正確には UTC との時差である9時間前なのかもしれません。
調べてみると、WordPress 5.3 で日付と時刻の処理が大きく変更(改善)されたようで、“PHPのタイムゾーンを date_default_timezone_set() で変更しないでください”ということのようです。
当該サイトは date_default_timezone_set('Asia/Tokyo'); として、date() で現在の日時を取得していたため、今回のバージョンアップで誤作動を起こしたようです。
そもそも、当初から date_default_timezone_set() を使わず、date() ではなく WordPress 独自の date_i18n() を使えばよかったんですね。
さらに、date_i18n() についても WordPress 5.3 からこの代わりとなる wp_date() という関数が新たに追加されたようです。