カテゴリー: WordPress

  • [WordPress : 検証終了] – Simple WordPress Membership – メンバーシップ プラグインをAMPに搭載できるか!? – メンバーのレベルに応じた閲覧制限をページに設ける [2021/05/15]

    [WordPress : 検証終了] – Simple WordPress Membership – メンバーシップ プラグインをAMPに搭載できるか!? – メンバーのレベルに応じた閲覧制限をページに設ける [2021/05/15]

    ID22131

    Simple WordPress Membership

    Simple WordPress Membershipプラグインは、Ultimate Memberプラグインのように、メンバーシップを構築できるプラグインです。いずれは有料のPro版ができるかも知れませんが、2021/2現在、オールフリーのプラグインになっています。

    基本機能のみで使用は可能ですが、その他追加の機能は、マニュアルでダウンロードして、そのファイルをインストールする形式になっています。

    AMP対応のベージに、Ultimate Memberプラグインを使用すると、ページのワーニングが少し多く出るので、完全移行(現在はAMP対応でない通常の一部のページのみにUltimate Memberプラグインを適応させてます)には躊躇していました。これに代わるメンバーシップのページを作ることができるプラグインとして、「Simple WordPress Membership」(SWPM)を検討しました。

    SWPMの機能は、Ultimate Memberよりも多いので、全部を検証することはなかなか難しいですが、ある程度でUltimate Memerより優位な機能やAMP対応について優しいと判断できればUltimate Memberから、このSimple WordPress Membershipに移行したいと考えています。

    どんなプラグインでも少なからず、jquery.jpなどのJAVAを使用しているので、AMPに優しくない部分は必ず存在しています。これらは、どこまで許容できるかですが(AMPプラグインからCCS Usageの使用率(%) が80%を超えると赤色)、主観的、あるいは、システム構成に依存する部分なので、完全移行の基準は今の所は、よくわからず、厳密には決めていません。ポストの中には、下の例のように80%を超えている記事もあります。それが、どのような具体的な影響があるかは把握できていません。

    Error in AMP validation

    2つのメンバーシップ・プラグインは、下表に示したようにJavaScriptが使用されていので、AMPプラグインではエラーが出ます。

    PluginError in AMP
    Simple WordPress Membershipjquery.js
    Membership & Content Restriction – Paid Member Subscriptions1.front-end.js
    2.Invalid inline script
    3.jquery.js

    アドオン

    現在、Simple WordPress Membershipには、27のアドオンが用意されており、管理者メニューの「WP Membership」→ 「アドオン」から確認できます。

    1. After Login Redirection
    2. MailChimp Integration
    3. Form Shortcode
    4. Member Directory Listing
    5. Form Builder
    6. Custom Messages
    7. WooCommerce payments
    8. Affiliates Manager
    9. iDevAffiliate
    10. Affiliate Platform
    11. bbPress Integration
    12. Google reCAPTCHA
    13. Full Page Protection
    14. Protect Older Posts
    15. Custom Post Protection
    16. Partial Protection
    17. Member Data Exporter
    18. Bulk Member Importer
    19. Display Member Paymetns
    20. AWeber Integration
    21. WP User Import
    22. ConvertKit Integration
    23. Google First Click Free
    24. Miscellaneous Shortcodes
    25. Show Member Info
    26. Expiry Email Notification
    27. 2 Factor Authentication

    Partial Proteiction

    部分的な閲覧制限機能について、Ultimate Memberプラグインでは、標準で機能ONになっているのですが、Simple WordPress Membershipプラグインでは、提供されているアドイン・プラグインが必要になります。マニュアルでアップロードして、ショートコードで、目的の領域を囲む方法です。Ultimate Memberでは,ブロック単位で設定スイッチがあるので, それをONにするだけで設定が可能になっているので、それと比べれば面倒であるとも思えましたが、エディタ上では、挟んでいることが明確にわかるため、この方が編集しやすいかもしれません。

    apply-partial-section-protection

    結論です

    2021/05/14、Ultimate MemberプラグインからSimple WordPress Membershipプラグインに移行するにことにしました。Ultimate Memberの使用状況は、以下の通りで発展性がないことが理由です。その他の機能の追加や、その他の機能があるプラグインとの連携が弱いためです。

    • Ultimate Memberは、そのプラグインの機能として以下を備えている
      • 登録者が、フォームからメールアドレスとその他情報を入力して送信すると、確認メールを自動で返信し、その返信メールのリンクを、登録者がクリックしないと、登録が完了しない
      • 登録者のユーザークラスは、自動的に、例えば、「購読者」に登録される。
      • 購読者でないと、読めないページや、ページ中のあるプロックを指定できる
      • 以上の機能により、メンバーシップ環境が、このプラグイン1つで完結する
    • Ultimate Memberプラグインは、AMP対応に優しくなく、AMP対応にするために、ある一定以下でのJava Scriptやcssコードを許容するが、他のAMP対応プラグインと比較して、そのリソースを比較的多く使ってしまうため、必要なプラグインを外さなければならない場合も起こったことがある
      • そのため、現状では、Ultimate Memberは、AMP対応にしたページには、その機能を使用していない

    Simple WordPress Membership (SWPM)は、ページ中の指定した領域に、ショートコードで挟めば、指定したユーザーのレベルでしか表示できないように簡単にできる。ただし、そのためのAddonをサイトからダウンロードして、マニュアルでインストールする必要がるが、検証の結果、Ultimate Memberと同様に機能することを確認できた。また、AMP対応のページに設定したとしても、AMP対応のためのリソースは、Ultimate Memberより少なく済むことがわかった。また、SWPMは、MailChimpプラグインに対応していたり、ネット支払いにも対応していたりと、今後の発展性があることから、現状のUltimate Memberの使用は停止し、SWPMに移行することとした。

    SWPMに移行する作業

    プラグインの「Search Regex」で”um_”を検索し、Ultimate Memberプラグインのコードが挿入されているページを探します。そのコードの代わりにSWPMのPartial Protectionコードで置き換えていきます。まずは、この作業を進めます。

    今は、新しいメンバー登録は停止していますが、SWPMでのメンバー登録ができるようになったら、また、テストを行いたいと思います。

    • Search Regexプラグイン
      • “um_”のあるページを探す
    • 探したページの編集
      • SWPMのPartial Protectionコードに置き換える
      • 全てのUltimate Memberコードがあるページを処理する
    • Ultimate Memberプラグインを無効化、および削除する
    • AMPプラグイン
      • 全てのページを更新する (この作業は、殆どの種類のプラグインを更新すると、ページが古くなったとの警告が出るので、必要な作業です)
      • 余談ですが、AMPプラグインが最近(2021/05/15現在)、更新されてからは、このAMPページの更新作業(サーバーでの処理時間)が早くなったため、以前より、退屈な時間は少なくなりました。

    編集履歴

    2021/02/28 Mr.Harikiri
    2021/05/15 追記 (SWPMに移行する)
  • [Synology] DS920+のblog server – 15時間のアクセス普通について、今回の原因とは、そしてその対応 [2021/02/22]

    [Synology] DS920+のblog server – 15時間のアクセス普通について、今回の原因とは、そしてその対応 [2021/02/22]

    はじめに

    なぜか、RT2600acのポート転送にWeb Serverへの設定が消えていたことで、HARIKIRI-INSIGHTのBlogへのアクセスができず普通になっていた。そのサーバーダウンの期間は、2/22 AM3ごろからPM3の12時間です。Google Search Consoleからアクセス数を見ていて、「おや、今日は休日の間にある平日だから、8人しかアクセスがないのかな。いつもは50人程度の訪問者がいるのに」と、思いました。いやいや、そんなことは無いと思い直して調査を開始。

    ブラウザからBlogページにアクセス出来なし、DSMへのリモートアクセスもできません。そうです、全く、DS920+にアクセスすることができなかったのでした。

    SynologyのツールのDS FindでDS920+を探して、これを使ってようやく、DS920+のDSMにログインできました。あとは、以下のように調査と対策を行いました。

    対応した作業

    RT2600acのポート転送が消えていることに気づくまでには、Web Server/WordPressをの載せているDS920+のEZ-Internetで再設定したりして、盲目的に解決を試みましたが、アクセスができずにいました。

    ポート転送を確認してみると、EZ-Internetで再設定したはずなのに、RT2600acの設定には、Web Server/WordPressのDS920+の設定が一切ありませんでした。どうやら、RT2600acでのポート設定も消えたし、PnP設定も機能していないようです。RT2600acが怪しそうです。

    とりあえず、DS920+のポート設定をPnPではなく、手動で設定して、確かに設定されていることを確認し、プラウザーからアクセスして接続できることを確認して、この問題の解決に至りました。

    RT2600acの再起動が必要かもしれませんが、このように、NASのEZ-InternetのPnP設定によるルーターRT2600acへのリモート設定がちゃんと働かないことが以前にも多くありました。

    原理を理解しているなら、手動による設定が最も良い対策になることを今回の不具合で理解しました。

    みなさまもお気をつけ下さい。原理は知っておく必要性を強く感じました.

    編集履歴

    2021/02/22 MR.HARIKIRI
  • [WordPress] CLS; Cumulative Layout Shift – 2021/03からGoogle検索評価のスコアに加わる –  [2020/12/23]

    [WordPress] CLS; Cumulative Layout Shift – 2021/03からGoogle検索評価のスコアに加わる – [2020/12/23]

    はじめに

    当サイトを立ち上げた頃には、もっぱらpluginの追加をすることで、サイトの機能向上に重きを置いたサイト構築を進めていました。ところが、いつもお世話になっている「ホームネットワーク研究所」のプロガーである観音寺さんから、当サイトの読み込み速度が低いことのご指摘を頂きました。それまでノーマークでした。

    その後、サイト速度を測定するツールやWebサイトを調べて、測定したところ(PageSpeed Insights by Google)、MobileとPCでそれぞれ、一桁と20~30 (%表示される)でした。自分以外のサイトも指定できるので、比較として測定してみると、レンタル・サーバーでは当然ですが、100%近い値を見ることができました。この結果と受けた衝撃から、当サイトにおけるレスポンス改善活動が始まっています。この話題は、他の記事をご覧ください。

    Cumulative Layout Shift

    CLSは、遅延表示などで、表示されているところに後から別のエレメント(element)が挿入されたりすることで、最初にあったelementがシフト(shift)する現象を表しています。この現象が多いページは、ユーザーエクスペリエンスが不良とされます。Gooleは、検索スコアとして、2021/03以降から追加すると発表しています。すでに、PageSpeed Insightの測定結果には、「CLS」という項目の測定値を見ることができます。

    確かに、一度表示された画面が、次の瞬間からめくりめくようにして、あるelementが挿入されて既存elementが邪魔にされるように、下く繰り下げられる様子は、閲覧者としては、気持ちの良いものではありません。

    当サイトでは、WordPressの広告プラグインとして、「Advanced Ads Pro」をインストールしています。このプラグイン・サイトに英語ですが、CLSに関して解説があります。

    CLSに関する情報

    1)

    Cumulative Layout Shift (CLS) and Ads – Advanced Ads プラグイン –

    https://wpadvancedads.us10.list-manage.com/track/click?u=d761f7e9c05eb20567b500ddb&id=558703c702&e=615e72e98f

    2)

    Cumulative Layout Shift (CLS) – web dev –

    https://web.dev/cls/

    ページのレスポンスを測定するツールサイト

    解説には、Googleの「PageSpeed Insights」や「Google Search Console」、Chromeブラウザのプラグインである、「Lighthouse」の紹介があります。当サイトでは、blogメンテ用の端末としてiPadを使用しているため、フル機能のChromeを使用できないので、iPadからWeb siteの「PageSpeed Insights」を多用しています。その他、当サイトで評価したことのある測定サイトも含め以下にまとめました。

    • PageSpeed Insights
    • Google Search Console
    • Lighthouse
    • GTmetrix.com
    • EZOIC

    以下には、その他、ページ・レスポンスを計測できるサイトを紹介している記事ですが、そちらもご参考にしてください。

    編集履歴

    2020/12/23 Mr.HARIKIRI
    2021/03/13 追記(CLSについての情報)

    関連記事

  • [WordPress] Widget Logic プラグイン [2020/12/17]

    [WordPress] Widget Logic プラグイン [2020/12/17]

    Widget Logicプラグイン

    2020/12現在、updateがされておらず、WordPress の最新Version ではテストされていますせんが、おそらく、複雑なコードになっていないと思われるので、最新のWordPressでも使用できると思います。DeveloperはWPChefさんです。

    例えば、ページが、mobileに表示しているのか、PCに表示しているのかで条件を設定してやることで、あるWidgetの表示/非表示をコントロールしてくれるプラグインです。詳細は、リンクをご参照ください。

    条件の例

    • is_front_page()
    • wp_is_mobile()
    • etc.
    https://wordpress.org/plugins/widget-logic

    ウィジェットの表示・非表示を制御できるプラグイン Widget Logic の使い方 – vektor,Inc

    https://www.vektor-inc.co.jp/post/widget-logic/

    編集履歴

    2020/12/17, はりきり(Mr)

  • [WordPress] AMP対応化で、使用しているその他のプラグインによるエラーが出ないようにするために – プラグイン別 [2020/11/16]

    [WordPress] AMP対応化で、使用しているその他のプラグインによるエラーが出ないようにするために – プラグイン別 [2020/11/16]

    はじめに

    AMPプラグインをインストールしている場合、投稿/ページを公開/更新した際に、AMPの検証/再検証が行われます。サイト毎に使用されているプラグインがAMPに沿ったコードを作るわけでは無いため、AMPの仕様に沿わない場合があります。その結果として、「makeupエラー」や「スクリプトエラー」などがアラートされる訳です。これらのエラーは、AMPにおいてなるべく出なくすることが良いと考えます。そのエラーとなったコードを削除した場合にどうなるのかは、表示させたりしてその結果を確認しないと分かりません。

    • AMP (Accelerated Mobile Pages)はGoogleが提唱する高速化の仕様であり、以下のような制約が設定されている
    • JavaScript は使用禁止
    • CSS は head セクション内にインラインで 75,000 バイト(約 75KB) 以下
    • img タグは amp-img に置換
    • frameタグはamp-fameに置換
    • フォームや video、audio タグを利用するには専用のライブラリをロードしSSL 環境行う
    • すべての仕様に準拠する必要がある
    • AMP の詳しい仕組み

    以下の情報は、AMPプラグインを使用している前提で、その他のブラグインの使用として、エラーが出ないように工夫してきた、知識情報です。

    あるプラグインを使用する場合、使用していもエラーが出ないもの、使用すると前述のようなエラーが出るものなど、基本的にやってみないと分からないものばかりです。

    機能を充実したり、見栄えを良くしたりするために、色々なプラグインを使用することは、速度の制約となるという、トレードオフの関係にあります。その規律(ルール)となっているのが、AMPプラグインです。AMPプラグインは、速度の制約となるものをエラーとして知らせます。エラーとならない使い方、すなわち、機能の有効化/無効化が、AMPプラグインで設定が可能です。

    AMPエラーが出たとしても、そのプラグインを使用したい場合は、AMPページでの、そのプラグインの使用を無効化することで、AMPに非対応にできます。この最終手段により、そのプラグインを使用できます。

    以下は、そのプラグインを使用して、且つ、AMP対応にしたい使い方について、プラグイン別に示しました。

    基本的な設定方法

    • 使用したいプラグインを有効にして、目的のページに使用し、AMPページを更新する
    • AMPの検証済みURLを表示
      • 当該ページが赤フラグ(エラー)となっていれば、そのAMPページを表示させる
      • エラー(削除提案が出ている)について、削除のチェックをつけ、更新ボタンを押す
      • ページを表示して、表示状況を確認する
      • 問題があれば、削除提案のチェックは外す
      • 問題なければ、その後の操作は必要ない。その更新内容を受け入れることになる
    • エラーになった機能の削除を受けてれた場合は、そのプラグイでエラーとなっていた機能を削除したその操作は、今後のその他のAMPページでも自動的に採用されるので、同様のエラーとはならず、デフォルトで削除チェックが付いた状態で更新される。
    • 削除をチェックして更新した場合、その設定は、全てのAMPページに及ぶため、その他のAMPページは、「最新でない結果」というフラグが付く
    • 「最新でない結果」は、全て再検証する必要がある
      • AMPの検証済みURLを表示させ、オプションで表示数を100に設定する。
      • 最後のページを表示させて、全てをチェックして100ページを選択状態にした上で、再検証を選択し実行する。
      • 一つ前の100ページ分のリストに移動して、同様に、全てをチェックして100ページを選択状態にした上で、再検証を選択し実行する。
      • 以上を繰り返し、一つ前の100ページ分のリストを表示する番号として、最後の1までは実施せず、3番目で留めておく
      • その理由は、この再検証のタスクは、リアルタイムで実施されていないので、100ページの処理には、数十分かかるため、すでに完了したページが100ページ分のリストに表示される可能性があるため、複数回の無駄な再検証を避けるためである。

    WordPress プラグイン別

    現在は、以下、1つのプラグインのみです。

    Content of Table Plus

    • 目次の表示/非表示機能を使わない設定にする
    • AMPプラグインが提案するエラーが出る機能を削除設定で更新
    • 以後、新しいページに、以上の設定が自動的に採用される

    以上

    編集履歴
    2020/11/16 Mr.Harikiri
    2020/12/11、追記 (基本的な設定方法)
    2021/09/13,AMPの制限について追記
  • [WordPress] 「AMP」対応奮闘記 – プラグインAMPはVer.2.20になったけれど。[2022/01/05]

    [WordPress] 「AMP」対応奮闘記 – プラグインAMPはVer.2.20になったけれど。[2022/01/05]

    ID22520

    はじめに

    AMPページに対応すべく奮闘しています。当サイトで記事にしたAMP関連と情報リンクをまとめました。AMPプラグインはVer. 2.2.0になりました。プラグインをアップデートした際、またもや、「検証済みURL」での投稿の非表示の問題が出ました。対応策を見つけて何とか全ての投稿ページを検証済みURLのリストに登録させることができました(直近の対応)。

    Google Search Console

    Google Search ConsoleのAMP項目に、「エラー」、「有効(警告あり)」および「有効」があります。有効(警告あり)では、画像の大きさ関連のものが多く、推奨サイズを使うようにコメントが出ていることがあります。そのような場合には、投稿のアイキャッチ画像のサイズが小さいことが考えられます。当サイトでは、画像の最適化には「EWWW Image Optimizer」プラグインを使用していますが、画像のアップロード時にリサイズする設定において、推奨サイズ以下のサイズに設定されていることがあるので確認してみます。サイズが1200 x 675を推奨しているようなので、これより大きいサイズを設定し直します(例えば、2000 x 2000)。

    すでにWordPressにアップロードした画像を大きいサイズにリサイズすることはできないので、改めて同じ画像を元サイズを大きくするか、多いサイズが既にあれば、それをWordPressにアップロードして、更に、アイキャッチ画面に設定しなおしなす。

    AMPプラグインの「更新済みURL」が作成されない問題と対策

    AMPプラグインが正常に動かないことが多々あります。未だに完全解説には至っていませんが、以下の記録を続けてその内完全な解決策を見出せることを願いつつ、活動を続けていきたいと思います。

    おそらくは、AMPプラグインとその他使用しているプラグインとの相性の問題があると考えています。

    AMPプラグインのバージョンは、初期のバージョンアップの頻度からすると、現在は、その頻度は低くなっています、また、バージョンもだいぶ上がっています。また、使用経験も積み重ねているものの、このAMPプラグインについては、まだまだ挙動が読めません。まだまだ開発途上ということですね。

    2020/09/13

    投稿は存在しているのに、AMPの更新済みURLが作成されていなと、AMPプラグインの関連するページの各種操作において、タイムエラーなどを起こす。また、更新済みURLが作成されていないことは気持ちが悪いなどのデメリットがある。

    • 現象 : 投稿を新規に公開する場合、他のサイトを参照するプラグインを使用して多数のリンクを貼っていると、AMPのデータペースを作成/更新できなくなることがある
    • 具体例 : Advance Gutenberg Blocksプラグインの「Plugin」を使って、あるプラグインのリンクを10個張っている投稿の作成において、それを公開/更新した時、完了までの時間が非常に長くなる。投稿自体は作成/更新できるが、AMPの「検証済みURL」は作成されない。
    • 対策 : 投稿の公開/更新の最初に、原因であるAdvance Gutenberg Blocksの「Plugin」を取り除いて公開/更新を行って、AMPの「更新済みURL」が作成されたことを確認した後、原因であるそれを追加して投稿を公開/更新する

    AMP: a well-lit path to optimizing for Google’s page experience signal

    https://blog.amp.dev/2020/05/28/amp-page-experience/?utm_source=amp_newsletter&utm_medium=email&utm_campaign=amp_highlights_20126252

    AMPページに対応するプラグインは、このリンクにリストされています。

    「CoBlocks」には、アコーディオン・ブロックがあるので、助かっています。

    https://amp-wp.org/ecosystem/plugins/

    2021/10/10

    自宅のblog Serverを2台目として購入したDS920+に移行した時に、AMPの検証済みリストが出なくなってしまいました。データベースから消えたのか、データベースには存在するが、何らかの問題がありリスト化できないのか、理由はわかりません。

    以前に、再検証済みのリストを表示されるようにできた経験があります。その方法は、作業中の不手際でフォルダのアクセス権の設定(777とか664とかの設定)でミスした結果、全てのプラグインの無効化が生じた時です。その後、レスキュー作業で全てのプラグインの有効化を行なったことで解決した過去の経験です。具体的には、「WP Super Cache」プラグインを導入後、blogのフォルダーにパーミッション設定がおかしいので修正するように、というようなワーニングが出ました。そこで、NASにログインして、chmodコマンドで、そのフォルダーのパーミッションを設定して確認をしている時に、それは起きました。

    現在、過去の記事については、AMPの検証済みリストとして全く表示されないものの、新規に作った投稿では、AMPの検証済みリストに現れます。このことを利用して、投稿を一つ一つ開いて「更新」することで、AMPの検証済みリストに現れるようにできます。この作業は結構骨が折れます(2021/10/10 by MR.HARIKIR)。

    結局、一つ一つ投稿を開いては更新する作業を850行いました。完全な力技で対応してしまいました。本当は、こんなことはしたくはなかったのですが、他に解決策を見つけられず仕方くな実施しました(2021/11/05)。

    2021/01/05 : AMP Ver.2.20

    まだ、「検証済みURL」の問題は続いています。いっそのこと、有償版がある「AMP for WP」に乗り換えようとインストールして評価してみましたが、Free版では少しも速度アップは確認できませんでした。評価は、Page Speed Insightsを使用しています。
    対策(2022/01/05): 「検証済みURL」が作成されない場合、
    (1)AMPのデータベースが壊れている可能性があるので、「忘れる」処理をした後、投稿のページで更新する。
    (2)直近のプラグインの更新により「検証済みURL」が消えてしまいました。AMPデータベースが壊れた可能性/仕様の変更があります。実施した対応は、以下の通りです。キャッシュプラグインの少なともデータベースを無効にしてから、投稿ページを一つずつ開く操作を実施すると「検証済みURL」にリストされことを確認できたので全ての投稿ページに実施することにしました。素早く操作するには以下の方法が可能です。「投稿一覧」から一つずつ開き、その投稿の編集ページが開いたら直ぐにブラウザの戻るボタンで「投稿一覧」に戻るを繰り返して、一つ一つの投稿ページを開く処理する方法をとることです。連続操作できる数はNASの処理能力に依存します。投稿ページが開く速度が低下してきたら(5秒以上)、一旦休止してください。因みに、AMP関連のデータベースは、AMPプラグインの削除で削除されない仕様であることは開発者の間では知られていますが、その改善対応は未だ不十分の状況のようです。そのような状況下、プラグインのアップデートにより挙動の変化が毎回起こっています。まあ、ユーザーの立場で追従するのは大変です^^)。

    3つのURL

    AMP対応にすると3つのURLができます。以下の参考文献に詳しく書かれています。

    AMP URLの正体

    https://developers-jp.googleblog.com/2017/02/whats-in-amp-url.html

    編集履歴

    2020/09/13 はりきり(Mr)
    2020/12/13 Mr.Harikiri
    2021/02/11 追記 (Google Search Consoleのエラーや警告に対応する方法)
    2021/10/10,追記(AMP 検証済みリストが表示されない場合のとりあえずの対処法を「その他、問題解決」に記載)
    2021/11/05,追記(検証済みリストにリストさせるために、一つづつ記事を更新する作業を実施)
    2022/01/05,追記(AMPプラグインVer.2.20での「検証済みURL」の問題に対する対応策)
  • [WordPress] Synology (新)NASに立ち上げたWordPressから外へメールを飛ばす – WP Mail SMTP by WPFormsプラグインとGMail APIの設定 [2020/09/13]

    [WordPress] Synology (新)NASに立ち上げたWordPressから外へメールを飛ばす – WP Mail SMTP by WPFormsプラグインとGMail APIの設定 [2020/09/13]

    はじめに

    レンタルサーバーでのWordPressの運用とは違い、Synology NASにWordPressを構築して、サイト外へのメール送信するには、少し面倒な作業をしなければなりません。自分が選んだ道であり仕方がいなのです。

    今回の作業は、「WP Mail SMTP by WPForms」プラグインのインストール、およびGmail API (Google Developer Consoleの設定)によって、WordPressおよびその他のプラグインが、サイト外にメールを飛ばせるようにします。例えば、以下のケースです。

    • コンタクトフォーム・プラグイン
      • WordPressには、基本情報として訪問者のemailアドレスを記入し保管しています
      • 訪問者が、コンタクトフォームに当サイトへの質問、コメントを記載して送信するとき、その内容を、管理者メールアドレスに送信されます。この時、今回のプラグイン「WP Mail SMTP by WPForms」とGoogle Developer Consoleの「APIの作成」が必要です
    • Ultimate Member プラグイン
      • Ultimate Memberは、メンバーシップを構築できるプラグインです。
      • 訪問者が当サイトにemailを新規登録する場合、その申請内容を管理者メールアドレスに送信されると共に、訪問者が記載したメールアドレスに、確認用のメールを当サイトから送信します。いずれにも、今回の作業が必要です
    • UpdraftPlus プラグイン
      • UpdraftPlusは、WordPressとプラグインなど、全体的をバックアップ、リストアするツール・プラグインです
      • バックアップを開始した後、作業が終了した際に、管理者メールアドレスに、終了通知のemailを送信します。この送信を可能にするには、今回の作業が必要です

    準備

    「Google Developer console」でOAuth 2.0 クライアント IDを設定します。そのために、Google Developer consoleを使用可能にしてください。

    プラグインのインストール

    WP Mail SMTP by WPFormsをインストールします。

    インストール後は、「一般」から以下の設定の必要です。

    1. 以下の図のように設定します
    2. 送信元アドレス : これは、WordPressの設定から自動的に入力される
    3. 送信者名 : 同上
    4. メーラー : ここをGoogleに設定します

    次に、以下の設定が必要ですが、その値は、Google Developer ConsoleのAPIの設定と同時に進めていきます。

    1. ①と②は、Google Developer Console APIを設定して完了後に使用可能になります。そこからコピペします。
    2. ③は、このプラグインから提供させる値です。この値をGoogle Developer Console APIの「OAuth クライアント IDの作成」のURIの設定に使用します。まずは、右横のアイコンをクリックしてコピーしておきます

    API プロジェクトの作成

    Google Developer Consoleに入ります。

    1. 以下の図のような画面が現れます。以下の作業を進めます。
    2. メニューの「My Project」をクリックすると、「プロジェクトの選択」画面が現れます(図1)
    3. 右上の「新しいプロジェクト」をクリック

    1. 適当なプロジェクト名で、「プロジェクト」を作成(既存のプロジェクトにGMAIL APIがあれば、それを使用しても良い)
    1. メニューの「My Project」から作成した「プロジェクト」を選択
    2. もしも、左メニューの「認証情報」をセレクトしてあれば、選択した「プロジェクト」の「認証情報」画面が現れます
    3. その画面の一段目に、「同意画面の構成」ボタンが現れます。これをクリック。もしくは、左メニューの「OAuth 同意画面」をクリック

    1. 「OAuth同意画面」が現れるので、外部をチェック(内部はセレクトできない)して、「作成」ボタンをクリック
    1. 図は示しませんが、以下のような設定項目が現れるので設定していきます
    2. アプリケーション名 :プラグインがわかるように適当な名前
    3. サポートメール : Google Developer Consoleにログインしたメールアドレスが自動に入力されている
    4. 承認済みドメイン : harikiri.diskstation.me
    5. 「アプリケーション ホームページ」リンク : 同上(正確には、リンクですが、これでもOK)
    6. 「アプリケーション プライバシー ポリシー」リンク : 同上(正確には、リンクですが、これでもOK)
    7. 「アプリケーション利用規約」リンク : 必要ないようです
    8. 「保存」をクリック
    9. 確認画面が現れます。この設定内容は、左メニューの「OAuth同意画面」をクリックすると確認してできます。よく読んでみると、
    10. 確認ステータス : 検証は不要です、とあります。
    11. ユーザーの種類 : 外部
    12. OAuthレート制限
    13. 以上で、ようやく、「OAuth クライアント IDの作成」が可能となりました

    OAuthクライアント IDの作成

    1. 「認証情報」のメニューの「認証情報を作成」をクリックすると、更に目にメニューが現れます。二番目の「OAuthクライアント ID」をクリック
    1. アプリケーションの種類を「ウェブアプリケーション」に設定します
    1. その後、以下の設定を進めます
    2. ①は、とくに必要ないかもしれません。
    3. ②は、プラグインからのコピペです。
    1. 設定が完了すれば、メニューの「My Project」からプロジェクトを選択すると、「OAuth 2.0 クライアント ID」の項目にリストが追加されています
    2. その追加された項目リンクをクリックします。
    1. ③と④の「クライアント ID」と「クラアンスト シークレット」をコピーして、WP Mail SMTP by WPFromsプラグインの設定項目に、それぞれペーストします。
    1. プラグインの設定項目にペーストします。
    2. 最後に、「Authorization」項目で、橙色のボタン「Allow plugin to send emails using your Google account」をクリックします。
    1. Google Developer ConsoleでのAPI設定が正しく実施されていレバ、以下のような画面になります。

    以上で、プラグインとGMAILのAPIの設定が完了しました。Email Testで送信テストを実施してみてください。

    これで完了です。

    参考文献

    WP Mail SMTP Documentation

    https://wpmailsmtp.com/docs/how-to-set-up-the-gmail-mailer-in-wp-mail-smtp/

    参考文献

    Gmail APIでクライアントIDを有効にするまでの手順

    https://spica.tokyo/note/275
  • [WordPress] このサイトの表示に関係する使用している「テーマ」と「プラグイン」のリスト – [2020/09/11]

    [WordPress] このサイトの表示に関係する使用している「テーマ」と「プラグイン」のリスト – [2020/09/11]

    ID22353

    はじめに

    現在、皆さんが、このサイトに来て見てみいるページ表示に関わるWordPressテーマ、およびプラグインのリストを公開します。これからWordPressでサイトの構築をされる方の参考になれば幸いです。

    システム構成

    Synology NAS

    • 2020/12現在
    • DS920+ (DS918+からWordPressを載せ替え, 2020/07)
    • Disk Station Manager, Version 6.2.3-25426 Update 2 (2020/12現在)

    WordPress

    • Version : 5.6-ja
    • Theme : Twenty Twenty
    • Editor : Gutenberg (標準エディタ)

    表示に関係するプラグイン・リスト

    • AMP
      • ページのAMP化
    • Advanced Ads – Ad Manager & AdSense (有料)
      • 広告の自動挿入、手動挿入
    • Flex Posts – Widget and Gutenberg Block
      • ポスト・リスト表示(カスタマイズあり)
    • Table of Content Plus
      • ページへの自動的な目次の挿入
    • EWWW Image Optimizer (有料)
      • 全てのイメージを圧縮・最適化とLady Loadなど
    • Default featured image
      • feature imageを設定していない場合のDefault imageを自動設定
    • Flying Analytics by WP Speed Matters
      • レスポンス改善
    • Insert Pages
      • 表示のカスタマイズ
    • Share Buttons by AddThis
      • TwitterなどのSNSへの投稿

    以上

    編集履歴
    2020/07/11 Mr.HARIKIRI
    2020/12/15、現状にupdate
  • [PHP] プログラミング – include, require – パス [2020/07/08]

    [PHP] プログラミング – include, require – パス [2020/07/08]

    外部の関数を使うには

    プラグインの関数チェック

    プラグインの削除/停止で、使いたい関数がなくなったことも考慮して存在をチェックします

    if ( function_exists( ‘function_in_plugin’ )){ function_in_plugin(); }

    phpファイルを挿入

    • include(), require()の機能
      • include(), include_once(): ファイルが無い場合、警告するが実行停止しない
      • require(), require_once(): ファイルが無い場合、実行停止する
      • その位置に単純挿入
      • 両者で変数を共有できる
    • include(/hoge/hoge/file.php), require(/hoge/hoge/file.php)でのパスの設定
      • dirname(__FILE__) : 現在パス
      • $_SERVER[‘DOCUMENT_ROOT’] : blogのルートパス
      • 相対パス : ‘../path/file.php’) : ‘..’はパスを1つ戻ってfile.phpを探す。ない場合は、元パスも探す(らしい)。
      • SERVERの設定
        • include_path変数の変更/設定
        • set_include_path(hoge/hoge);で初期値を変更可能
        • ini_set(‘include_path’, ‘/hoge/hoge’);でも可能

    PHPの挙動に関するセッティング

    サーバー側の設定です。キャッシュや使用するメモリー容量、その他の細かな設定が可能なようです。僕の場合は、Synology NAS のDSMからWebStationを起動して、script language settingのcoreタグで数値の設定をします。

    今現在では、その設定の仕方がよく理解できていません。以下には専門用語(キーワード)を抽出してどのような内容な内容なのか理解を進めている途中です(2021/11/26)。

    FPM

    FastCGI Process Manger (FPM)は、Synology NASのWebStationからパラメータを設定できます。

    FastCGI Process Manager

    https://www.php.net/manual/ja/install.fpm.php

    APC

    APC

    https://havelog.aho.mu/develop/php/e167-php-apc-install.html

    https://www.php.net/manual/ja/apcu.configuration.php

    編集履歴

    2020/08/25 Mr.HARIKIRI