![[WordPress] Widget Logic プラグイン [2020/12/17]](https://harikiri.diskstation.me/myblog/wp-content/uploads/2019/12/DFCE24D5-7AEA-4FF0-820C-D054B48E2D5C.jpeg)
2020/12現在、updateがされておらず、WordPress の最新Version ではテストされていますせんが、おそらく、複雑なコードになっていないと思われるので、最新のWordPressでも使用できると思います。DeveloperはWPChefさんです。
例えば、ページが、mobileに表示しているのか、PCに表示しているのかで条件を設定してやることで、あるWidgetの表示/非表示をコントロールしてくれるプラグインです。詳細は、リンクをご参照ください。
ウィジェットの表示・非表示を制御できるプラグイン Widget Logic の使い方 – vektor,Inc
https://www.vektor-inc.co.jp/post/widget-logic/
2020/12/17, はりきり(Mr)
ID22640
このblogは、レンタル・サーバーではなくSynology NASを使っています。やはり、性能的にはレンタル・サーバーに勝てません。そこで、自宅のNASを使ったblogでは、以下のような工夫が必要になってきます。
この記事では、ページのレスポンスを向上させる2つのプラグインとして、「AMP」と「キャッシュ」・プラグインを組み合わせてについて解説しています。以前は、AMP対応をせずにページレスポンスの改善を目指していたので、AMPプラグインを使用せず、Autoptimizeプラグインを使用していました。現在では、AMP対応にしてページのレスポンスの改善を図っています。
ついでに、AMPプラグインで何度も生じている「検証済み」の問題についても経験談を載せています。
これらのページレスポンスの向上プラグインなどのSoftwareの適用以前に、ネットワーク回線やHardwareスペックアップの問題もありますが、ここでは述べていません。
AMPプラグインは、HTMLを高速化するために元のHTML文やJavaScriptなどをサブセットに変換します。それがblogのページになります。投稿/ページの編集を終えて、「公開」すると、このタイミングでAMP化の変換が行われます。変換時間は、AMP化を適用していない場合と比較して、5~10秒程度余分の時間を要します。変換時間を要しただけのレスポンス改善は、目を見張ります。当サイトでは、モバイルの場合、GoogleのSpeedPage Insightsを使って測定すると、5~10倍のポイントアップが見られました。それでも、当サイトのMobileで閲覧した場合、30~40%でした。100%が最高値なのでまだまだです。PCでは、80%程度です。
更にレスポンス改善するには、「キャッシャ」プラグインを追加します。そうすると、Mobileでは、50~60%に改善されました。キャッシュ・プラグインには、WP Super Cacheプラグイン、WP-Optimizeプラグインがありますが、主に、WP-Optimizeを使っています。
今回の記事では、WP Super Cacheにするメリットについて解説します。
キャッシュプラグインにも種々ありますが、これまでに色々試しました。その結果、ここ半年間使用し続けたのは、「WP-Optimize」プラグインでした。WP-Optimzieでは、データベースの最適化やデータベース・テーブルがアントールされているテーブルなのか、無効化されているプラグインのデータベース・テーブルなのか、すでに削除されているプラグインに関するデータベース・テーブルなのか、を示してくれます。この情報を確認しながら、データベース・テーブルを削除したり管理することができます。WP-Optimizeは、データベース管理プラグインであると認識するのが妥当です。WP-Optimizeは、キャッシュ機能もありますが、これまでに試したキャッシュ・プラグインの中で僅差ですが、最もレスポンス改善効果があったため、今回まで、キャッシュ機能も有効にしていました。
WP-Optimizeプラグインには、多数の機能が搭載されています。キャッシュ機能には「プリロード」機能も使えます。全ての投稿/ページのキャッシュする機能です。
今回、WP-Super Cacheプラグインをネットで発見して、キャッシュ・プラグインとして使用することにしました。その理由は、プラグインは多機能でない方が管理がし易いと考えているからです。それに、付属的な機能では、微調整ができないことが大です。WP-Optimizeのプリロード機能では、繰り返すプリロードの時間設定しかできず微調整ができません。もう少しでも攻め込みたい。やはり、専用機能に特化したプラグインを指向したいと思います。
ただし、ネットで調べてみると、WP Super Cacheのプリロード機能、その他の機能は使用しないことを推奨しているようです。WP-Optimizeのブリロード機能を使用しても、キャッシュ機能が効いていないようです。と言うのは、WP-Optimizeでブリロードした後に、PageSpeed Insightsでランダムにベージ/投稿を選んで測定したところ、モバイルで50程度、PCで80程度とPCの測定値が低くなりました。間髪入れず、もう一度測定すると、モバイル50程度、PCで95程度と改善しました。何度やってもこの傾向は、どのページでも同様でした。
結論としては、WP-OptimizeもWP Super Cacheも、プリロード機能は、使用しない方が良いということです。
結局推奨設定は、以下の図の通りになります。プリロードの使用を推奨していないのは残念です。
上記推奨設定のサイト
https://translate.google.co.jp/translate?hl=ja&sl=en&u=https://support.tigertech.net/wp-super-cache&prev=search&pto=aue
WP Super Cacheプラグイは、プラグインのキャッシュ/ブリロードに特化しています。多数の設定項目があり微調整も可能です。初心者には優しくて、デフォルトの設定についての解説もわかりやすいです。プリロードのキャッシュファイルの圧縮の設定もできます。
繰り返すプリロードの時間の設定は、ももちろん可能です。初期値は600分です。プリロード処理が開始される時、及び100や200毎に、メールを飛ばす機能もあります。機能していることが分かるので安心ですし管理に役立っています。
今回、WP Super Cacheの試用を開始しましたが、これまで使用していたWP-Optimizeの設定は、キャッシュを無効化し、データベース管理機能のみを使用している状態に設定しました。
SpeedPage Insightsによるレスポンスの測定結果は、従前の設定の場合と比較して同等の結果でした。しばらく攻め込んでみたいと思います。結果は、随時、追記していきます。
WP-Optimizeは、キャッシュ機能だけではなく、データベース管理、イメージ圧縮などの複数の機能を備えています。
kinstaというレンタルサーバーがあります。日々、パフォーマンス改善を進めていて、WP Rocketによるキャッシュ機能に関する記事がありました。その記事では、プリロード機能は、逆にパフォーマンス低下になるので、有効化しないことを推奨しています。プリロード機能は、理想としては良い機能なのですが、実際には、技術として実用化はまだのようです。
Kinsta and WP Rocket: Now Speeding up WordPress Together, 2020/10
https://translate.google.co.jp/translate?hl=ja&sl=en&u=https://kinsta.com/blog/wp-rocket/&prev=search&pto=aue
約900ある投稿とページをプリロードする時間を比較しました。先ず、全ての投稿とページについて、AMPで再検証します。全てが完了してから、ブリロード機能を実行しました。その結果、WP Super Cahceでは約50分、WP-Optimizeでは約25分でした。WP-Optimizeの方が高速でした。
AMPプラグインを使用していて、数ヶ月前の9/21に投稿/ページの「再検証」が、以下のエラーログと共に不可になっていました。
ネットで調べてみましたが、DNSが悪いので、ローカルにDNSを立ち上げろとか、AMPのサポートでは、AMPプラグインによる不具合ではないとか、結局、原因を見つけることは、できずにいました。
WP Super Cacheを導入後、blogのフォルダーにパーミッション設定がおかしいので修正するように、というようなワーニングが出ました。そこで、NASにログインして、chmodコマンドで、そのフォルダーのパーミッションを設定して確認をしている時に、それは起きました。
WordPressの管理者画面の左のメニューが、突然シンプルになりました。原因は、プラグインの全てが無効になっていた事でした。パーミッションの設定を間違えたことで、WordPressがプラグインにアクセスできなくなり、それを受けてWordPressが全てのプラグインを無効化したものと考えられました。
パーミッションを元に戻して、プラグインが認識されるようにしました。無効化になっているプラグインの全てを1つ1つ有効化していきました。
AMPプラグインで不可であった「再検証」が問題なく機能するようになっていました。これまでは、なんだったのか?
再検証を完了した後は、WP Super Cacheによる「ブリロード」を実行しました。
Advanced Adsは、AMPページ対応の広告表示プラグインです。色々な設定が可能です。これらの表示について、実際の投稿/ページを表示させて確認しました。
今回は、AMPプラグイン導入していることを前提に、キャッシュ・プラグインの変更について解説しました。また、相変わらず、AMPプラグインにおける「検証済み」において検証ができない記事があります。また、リストにすら表示されない問題もあります。その問題となる要因は、画像数が多かったり、記事が大きかったり、など色々と考えられます。一方で、シンプルな文字のみの投稿、文書量が少ない、埋め込みリンクがない場合には、ほとんどは問題が生じることはありません。マシンのパワー不足があるのかもしれません。今後も検討を続けます。
以上
2020/11/07、はりきり(Mr) 2020/11/15、追記 (プルロード機能は使えない) 2020/12/11、追記 (文言整備)
![[WordPress] 「AMP」対応奮闘記 – プラグインAMPはVer.2.20になったけれど。[2022/01/05]](https://harikiri.diskstation.me/myblog/wp-content/uploads/2020/09/950A14EE-C10D-443A-AB7E-2A2CE17A8EFC.jpeg)
ID22520
AMPページに対応すべく奮闘しています。当サイトで記事にしたAMP関連と情報リンクをまとめました。AMPプラグインはVer. 2.2.0になりました。プラグインをアップデートした際、またもや、「検証済みURL」での投稿の非表示の問題が出ました。対応策を見つけて何とか全ての投稿ページを検証済みURLのリストに登録させることができました(直近の対応)。
Google Search ConsoleのAMP項目に、「エラー」、「有効(警告あり)」および「有効」があります。有効(警告あり)では、画像の大きさ関連のものが多く、推奨サイズを使うようにコメントが出ていることがあります。そのような場合には、投稿のアイキャッチ画像のサイズが小さいことが考えられます。当サイトでは、画像の最適化には「EWWW Image Optimizer」プラグインを使用していますが、画像のアップロード時にリサイズする設定において、推奨サイズ以下のサイズに設定されていることがあるので確認してみます。サイズが1200 x 675を推奨しているようなので、これより大きいサイズを設定し直します(例えば、2000 x 2000)。
すでにWordPressにアップロードした画像を大きいサイズにリサイズすることはできないので、改めて同じ画像を元サイズを大きくするか、多いサイズが既にあれば、それをWordPressにアップロードして、更に、アイキャッチ画面に設定しなおしなす。
AMPプラグインが正常に動かないことが多々あります。未だに完全解説には至っていませんが、以下の記録を続けてその内完全な解決策を見出せることを願いつつ、活動を続けていきたいと思います。
おそらくは、AMPプラグインとその他使用しているプラグインとの相性の問題があると考えています。
AMPプラグインのバージョンは、初期のバージョンアップの頻度からすると、現在は、その頻度は低くなっています、また、バージョンもだいぶ上がっています。また、使用経験も積み重ねているものの、このAMPプラグインについては、まだまだ挙動が読めません。まだまだ開発途上ということですね。
投稿は存在しているのに、AMPの更新済みURLが作成されていなと、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/
自宅の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)。
まだ、「検証済みURL」の問題は続いています。いっそのこと、有償版がある「AMP for WP」に乗り換えようとインストールして評価してみましたが、Free版では少しも速度アップは確認できませんでした。評価は、Page Speed Insightsを使用しています。
対策(2022/01/05): 「検証済みURL」が作成されない場合、
(1)AMPのデータベースが壊れている可能性があるので、「忘れる」処理をした後、投稿のページで更新する。
(2)直近のプラグインの更新により「検証済みURL」が消えてしまいました。AMPデータベースが壊れた可能性/仕様の変更があります。実施した対応は、以下の通りです。キャッシュプラグインの少なともデータベースを無効にしてから、投稿ページを一つずつ開く操作を実施すると「検証済みURL」にリストされことを確認できたので全ての投稿ページに実施することにしました。素早く操作するには以下の方法が可能です。「投稿一覧」から一つずつ開き、その投稿の編集ページが開いたら直ぐにブラウザの戻るボタンで「投稿一覧」に戻るを繰り返して、一つ一つの投稿ページを開く処理する方法をとることです。連続操作できる数はNASの処理能力に依存します。投稿ページが開く速度が低下してきたら(5秒以上)、一旦休止してください。因みに、AMP関連のデータベースは、AMPプラグインの削除で削除されない仕様であることは開発者の間では知られていますが、その改善対応は未だ不十分の状況のようです。そのような状況下、プラグインのアップデートにより挙動の変化が毎回起こっています。まあ、ユーザーの立場で追従するのは大変です^^)。
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]](https://harikiri.diskstation.me/myblog/wp-content/uploads/2020/09/F6908C2B-9876-4F48-B958-1D86685C00D9.jpeg)
レンタルサーバーでのWordPressの運用とは違い、Synology NASにWordPressを構築して、サイト外へのメール送信するには、少し面倒な作業をしなければなりません。自分が選んだ道であり仕方がいなのです。
今回の作業は、「WP Mail SMTP by WPForms」プラグインのインストール、およびGmail API (Google Developer Consoleの設定)によって、WordPressおよびその他のプラグインが、サイト外にメールを飛ばせるようにします。例えば、以下のケースです。
「Google Developer console」でOAuth 2.0 クライアント IDを設定します。そのために、Google Developer consoleを使用可能にしてください。
WP Mail SMTP by WPFormsをインストールします。
インストール後は、「一般」から以下の設定の必要です。
次に、以下の設定が必要ですが、その値は、Google Developer ConsoleのAPIの設定と同時に進めていきます。
Google Developer Consoleに入ります。
以上で、プラグインと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
ID22353
現在、皆さんが、このサイトに来て見てみいるページ表示に関わるWordPressテーマ、およびプラグインのリストを公開します。これからWordPressでサイトの構築をされる方の参考になれば幸いです。
以上
編集履歴 2020/07/11 Mr.HARIKIRI 2020/12/15、現状にupdate
WordPressのblogで載せる写真は、そのままのサイズでアップしてはいけません。メタデータはそのまま残っているためです。メタデータのGeotabには、位置情報が記録されています。WordPressのプラグインの内、写真のサイズを小さくしてくれるプラグインを使えば、将来にきっと困るサイトのレスポンス速度も改善するので、単にメタ情報だけを取り除くプラグインよりは合理的です。EWWW Image Optimizer というプラグインは、写真のデータサイズを小さくできるし、メタデータも削除する事ができます。無料版では、小さくできる割合が50%程度ですが、有料版では、10%未満の縮小化も可能です。確か、¥1,000で3,000枚の写真を処理できる許可がもらえます。最初は、これで試してよければ、更に購入すれば良いでしょう。
無尽蔵に写真をblogに使用するためにアップロードすると、EWWW Image Optimzerで購入した写真数を直ぐに超えてしまいます。サイズ違いもカウントされるので注意が必要です。
そこで、Mr.Harikiriは以下の方法を考えました。スライドショーにできる写真は、iOSの写真アプリでスライドショーにしてしまうのです。
そのスライドショーを写真の代替にして、写真は、削除します。削除するとEWWW Image Optimizerの可能な写真数を削減できるはずです。
2020/08/20, Mr. Harikri
2022/08/12, 追記(運用方法: スライドショーにしてしてしまう)
![[サイト運用] これまで使ってきたTooltipプラグインであるEncyclopedia Proを今後は使わないことにした – その後、再インストールして復活させた理由 [2020/12/16]](https://harikiri.diskstation.me/myblog/wp-content/uploads/2021/05/636BEFBC-B32D-43DA-82DE-670E9BF37E8A.jpg)
WordPressの投稿において，登録したワードに吹き出しをつけることができる「Encyclopedia」というプラグインに関する内容です．現在，このサイトでは，Encyclopediaによる吹き出しはしなくななりました．自分でphpコードを作り代替できるようになったこと，および，EncyclopediaはAMP対応ではななかったこと，更にサイトのレスポンスを向上させたいためです．
以下の記載は，Encyclopediaを使用しないくなるまでのプラグイン導入記です．備忘として残します(2022/11/18, by Mr. Harikiri)
Encyclopedia Proは、有料版です。Tooltip(用語を登録しておけば吹き出しを出したり、hyper linkへ飛ぶことが可能となる)プラグインです。Encyclopediaは、ページへのアクセスがあった場合に、表示の際に登録リストから、そのページに記述されているワードを検索して、リンクを付ける処理をリアルタイムで行うプラグインです。そのため、Encyclopediaに登録されている数が多くなるほど表示レスポンスが低下することが予想されますが、しぱらくは運用を続けてみます。
Pro版を購入して半年以上運用してきましたが、以下の理由のから、このプラグインを外すことにして、2020/07/11から2020/12/13までDisableにしていました。Diableの理由は、以下の通りですが、今回、Enableにした理由は、十分ではないものの対策が得られたためです。
そして、サイトはの作りは、単純化されていくことをEncyclopediaの無効化と「投稿ページにキーワードを登録する方法」で目論んだものの、やはり、インタラクティブな単語の意味の理解が可能となるEncyclopediaプラグインを外すことは残念であると考えていた。今回のEncyclopediaの再開を許容できたことは、満足している。
Simple is best, but additional better function is wonderfull!
編集履歴 2020/07/11 Mr.はりきり 2020/12/14、追記 (Encyclopedia Proの再開) 2020/12/16、追記 (SPIスコアの劣化は避けられない、現時点で8~10ポイントの低下) 2022/11/18，追記 (完全にEncyclopediプラグインを削除した)
サイトのスピード測定には、GTmetrix.comとPageSpeed Insightsがあるが、それぞれ測定方法に違いがあることを、EWWW Image Optimizerの有料版のサポートEmailで情報を頂いた。
サイトの速度改善として、画像圧縮は最初に直面してする課題です。「はりきり(Mr)サイト」では、「EWWW Image Optimizer」プラグインを使っています。Free版を使用してから有料版に切り替えました。有料版は、Free版より更に圧縮率が高くなります。3000枚単位は1000円程度ですが、割安の1万枚単位でもクレジットできます。
画像圧縮の次は、キャッシュ設定、JavaScriptやHTMLなどのコードの最適化を行います。これらの詳細については、当サイトの関連記事をご覧ください。
対策の結果を知るには、評価が必要です。
速度対策の成果を測定するには、皆さんよくご存知のGoogle PageSpeed Insightsが有名ですが、今回紹介する「GTmetrix.com」とでは、画像の圧縮形式に対してそれぞれ以下特徴があるようです。向き不向きは、さて置き、GTmetrix.comでは、どの処理にどれくらいの処理がかかったのか、そのシーケンスをチャートで詳細に得られたり、その他、詳細な分析結果が得られることが特徴です。
GTmetrix.com (サイト速度分析サイト)
http://gtmetrix.com/
編集情報 ID 9721 2020/06/15 Mr.はりきり 2020/07/24 GT metrixサイトで測定している動画を追加
以上
WordPressのプラグインで必要でなくなれば、即削除するのが通常と思われますが、そのプラグインの残骸が残るケースを体験しました。今後の教訓にすべき内容です。
以下に、その現象と対策について備忘記録します。
今後の問題発生に備えて、プラングインのアンインストール時には、必ずその対策の実施をお勧めする。
「Social Counter」は、WordPressサイトに、FaceBookやTwitterのリンクと共に、そのフォロワー数を表示するプラグインです。
AMPプラグインと相性が悪く、AMPで検証して、コードやJavaScriptのAMP最適化をした場合、カウンターの表示色や体裁が崩れてしまうことが多かったため、削除することにしました。
その結果、ページに表示されていた「カウンター」は、ショートコードをそのまま残したままになってしまいました。
最初の対応策は、キャッシュをクリアしてみましたが、効果がありませんでした。
結局、削除した「Social Counter」を再インストールして、FaceBookとTwitterのカウンターが有効になっているのを、無効にしました。すると、ページには、カウンターは表示されなくなりました。1つのページで確認した後、「Social Counter」を無効化しました。その後、他のページを表示させてみると、同じ問題が生じました。
どうやら、ページ毎に「カウンター」を埋め込んでいるようです。その機構はわかりませんが、ページが表示される度に処理しているものと考えられます。そうだとすると、これまでに、表示したことのあるページには、「カウンター」が埋め込まれているので、それを、カウンターの無効化での表示が1度は必要ということになります。
英語書くのは気合が必要なので、開発者には、気が向いたら連絡したいと思います。
という、まどろっこしい対策となりました。
本家のAMPプラグインは、データベース(DB)に残骸が残ります。そのため、直接、DBを操作する必要があるようです。これまでに経験する不具合として、検証済みURLのページに投稿が表示されなく問題があります。普通にAMPプラグインを無効化して削除するものの、残骸の残っているようで、再インストールしても、その問題は解決されずの残るというものです。DBを弄る度量はないし、仕方がないので、コツコツと作業をする羽目になるのでした(Mr.Harikiri)。
How to Remove AMP Plugin Data on Your Site (参照日 2021/10/16)
https://mainwp.com/how-to-remove-amp-plugin-data-on-your-site/
WordPressでは、プラグイン/テーマを削除したとしても、一部の独立したテーブルやデータが残るようです。以下のプラグインの説明にそのように書いてありました。インストールしていたプラグインの影響を完全になくすためには、プラグインを削除した後、関連するデータベースの削除も同時に必要だということです。
現在、AMPオフィシャルプラグインで問題が起こっています(2020/09/23)。プラグインの削除と再インストールでは、問題は同様に発生しているため、関連するデータベースの削除を考えています。その後、調査した結果は、前述のようにDBの削除しか無いようです。僕の場合は、削除が目的ではなく不具合の修正なのですが、安全策としてDBを操作せずにコツコツと他の方法で対応することにしました。
Advanced Database Cleaner
https://ja.wordpress.org/plugins/advanced-database-cleaner/
編集履歴 2020/06/06 はりきり(Mr) 2020/09/24 追記 (同問題の原因がDatabaseにあり、それの削除も必要であること。AMPプラグインでの問題の対策予定) 2021/10/16,追記(AMPプラグインの不具合は、DBのようであることについて)
![[WordPress] その昔憧れた、パーソナル・データベース生活を実現。 – イベント・プラグイン – を選定/導入する [2020/05/23]](https://harikiri.diskstation.me/myblog/wp-content/uploads/2020/05/C964CF75-1E6C-4C3C-8638-46235FE5F388.jpeg)
ID18377
初代iPadが発売されてから、iPad3くらいまでは、iPad用のDatabaseアプリが沢山ありました。
使い方としては、データベースとして残しておきたい情報や自分のイベントなどについて、その情報のデザインを自分で行い、そのフォーマットにデータをエントリーしていくものです。
以前にエントリーしたデータを見たくなった時、そのデータは検索により瞬時に得ることができます。しかも、端末がiPadやiPhoneなので、何時でも情報にアクセスできるという憧れのデーターベース生活を達成できるアプリたちでした。
編集履歴
2020/05/23 はりきり(Mr)
中でも、デザインも機能も使いやすさも優れていたのが、Mac用のデータベースソフトで知られていたFileMaker (会社名も同じ)が開発した、iPad/iPhone用の
bento
でした(2012/07/16)。
更に、機能を求めるなら、FileMakeを購入してWindows/Macにインストールし、少しフォーマットを開発すれば、以下のことが可能となる予定でした。
Windows用のFileMakerの購入も考えていましたが、2013年に突然の提供の終了となりました。
FileMaker、パーソナルデータベース「Bento」の提供を終了へ – ITmedia NEWS 2013/08/01 – より
あれから7年が経ちました(2020年)。1.5年前には、WordPressなるものがあることを知りました。WordPressには、mySQLのサブセットであるMaria SQLが搭載されていることも知りました。
その昔憧れた、「パーソナルデータベース生活」は、今日、可能になった!! のではないでしょうか。
今回は、導入編です。
WordPressのポスト機能を使用せず、イベント・プラグインを導入する理由ですが、やはり使い勝手の問題です。
4つのイベント・プラグインを選択し、インストールしました。「Setting」を一通り確認した後、イベントのエントリーの具合を以下の内容で確認しました。
を選択。
その結果、「Events Made Easy」を選定しました。更に、よりディープにつかいこんでみました。
メニュー
最小限の設定と最小限のエントリーの概要
設定項目がおおいのですが、早速使ってみるための最小限の取り扱いについて、以下にまとめました。
まだ、使い込んでいませんが、コンパクトにリスト化できれば、先ずは良しです。
以下のショートコードで、1つのイベントのタイトル(リンク付き)が1行で表示されます。全体の俯瞰には、このシンプルさが最適です。
もちろん、日付のカラム内にリンク付きで「カレンダー」表示が可能です。これもシートコードの挿入で簡単に、PAGEに配置できます。ページの属性を非公開にすれば、そのカレンダーは、パーソナルなカレンダーになります。
まだまだ、使いこなすには至っていないので、設定画面など写真のみで雰囲気を感じてください。今後、レポートしていきたいと思います。
Settingsのメニュー
Generalの設定
SEOの設定
Eventsの設定
Locationsの設定
以上