少し前からWordPressもくもく勉強会にアドバイザーという肩書で参加させていただいてます。
そもそも比較的小規模な勉強会であってもアドバイザーなんて肩書は僕には荷が重いんですが、今参加している会の前身の勉強会に初めて参加した際に親切にしていただいた方からのお誘いであり、せっかくお声がけいただいたのと、質問など受けて一緒に考えるのは漫然と参加してるよりも自身の勉強になるかもという思いでお引き受けしました。
※ということで、肩書に比して実力不足なのはご容赦ください。
さて、勉強会では参加者の方から質問を受けてその場で一緒に解決していくわけですが、僕も引き出しはそれほど多くないのですぐにはわからず、その場で調べてみて初めて知ることも多く、とても勉強になっています。
それをその場で終わらせるとまた忘れてしまったりでもったいないので、僕自身の勉強と、初めてWordPressを触った方が躓いたときの一助となるよう、今回からメモ程度で記録として残すようにしたいと思います。ナレッジとかエビデンスとかそういう感じで。
さて今回は2017/10/21に開催されたもくもく勉強会についてのメモです。
カスタムフィールドの運用
膨大な量のカスタムフィールドを設定していて、かつそのカスタムフィールドの値によってページごとに表示を変えるという動きを実装するにあたり、ヘッダで全てのカスタムフィールドの値を読み込んでその後if文で分岐するという作りになっていて、そもそもそのやり方自体WP的にありなのかどうか、というところからの質問でした。
勉強し始めて少し経つと、自分のやり方が正しいのかどうかという点は気になりますよね。僕も正しいコードが書けているとは言い難いですが、その方のその部分のコードを拝見してみた限りで気になったのが、全てのカスタムフィールドについて個別に関数で値を読み込んでいた点です。
カスタムフィールド一個ごとにDBへリクエストを投げ、返り値を固定文言の個別の変数に格納する処理になっていて、DBへの負荷と、変数のメンテナンス性が気になりました。
カスタムフィールドの値は一括で取得してPHP側で展開したほうがいよいのではないかということ、そして、個別の変数ではなく配列やオブジェクトなどを用いて、動的に生成される枠に値を格納して使用したほうが良いのではないかというアドバイスをしました。
SSL化したら下層のCSSが読み込まれない
さくらサーバでSSL化したら下層のデザインが全て崩れてしまった、とのご質問でした。
少し前にさくらサーバは無料SSLサーバー証明書の提供を始めまして、常時SSL化を推奨しています。
さくらサーバはサーバの仕様上WordPressで常時SSL化するとリダイレクトループという現象が起こり、正常に動作しません。以前は自分でそれを防ぐ記述をfunctions.phpなどに書く必要があったのですが、今はさくらサーバが公式にプラグインを提供してくれています。
SSLの設定も管理画面から簡単にできるので、設定してこのプラグインを導入するとそれだけでSSL化が完了します。
WordPress内のhttpで記述されたURL設定もプラグインがhttpsに書き換えてくれるとのことで、基本的には全てプラグイン任せでSSL化を行うことができます。
ただし例外はいくつかありまして、httpのままURLが残ってしまう場合があります。
以下は勉強会で共有されたページですが、さくらでのSSL化について詳しく書かれており、その中でもその件について触れられています。
僕もつい何日か前にSSL化を行ったのですが、その際にはプラグインで設定したローディング画像がhttpのままでセキュリティ警告が出てしまいました。こちらはプラグインの設定画面からhttpsに設定しなおすと、無事にSSL化が完了しました。
さて前置きが長くなりましたがこの方の場合は下層でデザインが崩れるとのことで、検証ツールで確認したところ下層でCSSが読み込まれていませんでした。
ソースを見ると下層ではCSSのURLがhttpのままになっており、httpsでページを開いた際に弾かれてしまっていたようでした。
その場ではテンプレートを細かく検証出来なかったのですが、
- CSSが読み込まれるヘッダーのパスが固定のURLとなるような書き方になっているのではないか
- CSSのパスを自動的にWordPressの設定に基いて記述する書き方があるので、そちらで対応したほうがよいと思う
とアドバイスして、そこからはご自身での対応をお願いしました。
そもそもその質問者の方はとある会社で事務方として勤務されており、そのサイトは業者に依頼して作成されたものだそうで、テンプレートでどう書かれているか、もしかするとテンプレートとは、というところも充分には把握されていないかもしれませんでした。
もう少し突っ込んで具体的にお話できればよかったと思います。申し訳ありませんでした。
WPで作成したサイトの操作方法がわからない
この質問者の方も自分の事業に関するサイトを業者に依頼して作成したけれど、その操作方法などについて詳しい説明を受けないうちに作った方と連絡が取れない状態になったとのことで、基本的に何をどうすればよいのかわからない、とのことでした。
そのサイトはECサイトで、決済システムはオリジナルのプラグイン化されており、そちらについては僕の方で扱うには力不足であり、かつもくもく勉強会でアドバイスするレベルを遥かに超えていると思ったので、それに関する質問は決済会社およびECの決済システムなどに明るいウェブ制作業者に正式に依頼してお話したほうがよい、とのお返事をしました。
上記以外に何点か質問を受けました。
Akismet
プラグインのどれを有効にしてどれを無効にするべきかとの質問を受けました。基本は必要なプラグインを必要に応じて使用すればよいのですが、デフォルトで入っているプラグインについていくつか説明を行いました。
中でもAkismetはスパムを劇的に減らすことができるので有効にしたほうがよいとおすすめして、有効にする手順を一緒に行いました。
akismetの動作にはAPIキーが必要で、有効にしたら画面の指示に従って進めれば取得できますが、何点か躓くかもしれない点がありました。
まず、APIキーの取得が、WordPress.comのアカウントを取ることから始まること。
このWordPress.comとは？というのを説明するのに少し手間取りました。
ここはWordPressを扱っていて一度はみんな疑問に思うところだと思いますし、自分の中でも整理する意味で簡単にまとめます。
まず「WordPress」はざっくり言うと無料のブログツールの名前です。
そのファイル一式の配布を行うサイトがwordpress.orgです。
最近はレンタルサーバー会社の自動インストールで設置できるのでWordPressを使うだけの人は意識することが無いかもしれませんが、こちらからWordPressのプログラム一式をダウンロードしてレンタルサーバなどに自分でアップロードして使うのが一般的な利用法でした。（簡単インストールなどは、その手順をサーバ会社が代行してくれている状態です）
この設置の際、インストールしたサーバに独自ドメインが設定されていれば独自ドメインでWordPressを運用することが出来、かつどこまでも自由にカスタマイズすることが可能です。
そしてもうひとつ、wordpress.comというURLが存在します。
これはWordPressをインストールしてブログサービスとして提供しているAutomaticという会社があり、そこが提供するブログサービスのURLがwordpress.comです。ameblo.jpなどと概念としては一緒です。
wordpress.comにアカウントを作成すればWordPressが無料で利用できますが無料での利用はカスタマイズの幅が狭く、有料でのオプションもありますが、自分の思い通りのカスタマイズにするにはやはり自分のサーバに設置するほうが自由度は高いです。
整理すると、WordPressを利用するには２つの方法があります。
- wordpress.comにアカウントを作成して、無料ブログとして利用する
- wordpress.orgからプログラムをダウンロードして、自分のサーバに設置して利用する
この２つです。
ここでAkismetの話に戻るとAkismetは先述のAutomatic社から提供されているプラグインであり、利用にあたっては、wordpress.comのアカウントを作成して発行されたAPIキーを使用してAutmatic社の技術を利用する必要があるので、wordpress.comにアカウントを作ることが必須となります。
アカウントが作成できたらあとは画面の指示通り進めるとAkismetが利用できます。
一点だけわかりづらかったのが、Akismetは基本無料で利用できるのですが登録画面で料金設定のスライダーが有料プランの位置でデフォルトとなっていること。
これは登録時に０円の位置にスライダーを動かして、無料登録することが可能です。有料登録の必要はありませんのでご注意ください。
管理画面でJSが動かなくなる現象
質問者の方の管理画面を開いた際、記事詳細や固定ページ詳細画面でJSが効かない状態になっていました。
ビジュアルとテキストの切り替えや、メディアの挿入などが一切反応しません。
確認したところWordPressは最新で、プラグインも有効にしているものは最新の状態でした。
検証ツールで確認したところload-scropts.phpでエラーが出ており、「WordPress load-scripts.php」などでググってみたところその対処法が紹介された記事をいくつか見つけました。
ただいずれも古く、以前のバージョンでの内容だったので、根本的な原因は有効化したプラグインとのコンフリクトなどなのかな…と思ったのですが運用中のサイトなので迂闊に止めて調べるわけにもいかず…。
load-scripts.phpはjsをまとめて連結するスクリプトのようで、CODEXにも「JavaScript 連結の無効化」という、ダメなら止めちゃいなよ的記述も見つけたので、取り急ぎwp-config.phpに以下を書き加えて連結を無効化することで対応したところ、正常に動作するようになりました。
define( 'CONCATENATE_SCRIPTS', false );
こちらはさらに調べてみるとキャッシュをクリアするだけでよいとの記事も散見するので、それで対応可能であればそのほうがよかったかもしれません。
ブログカスタマイズ
次はブログカスタマイズの個別の対応でした。
画像にタグをつけられると聞いたが…
これは何のことかはっきりわからなかったのですが、SEO的観点からの話のようでしたので、とりあえずAltに代替テキストを設定する方法をアドバイスしました。
WordPressにおいてはメディア一覧から画像を配置する際に、画像をクリックして選択した画面の右側に表示された情報（投稿に挿入ボタンの上）の、「代替テキスト」の蘭に入力してから「投稿に挿入」を押して配置すれば、HTMLタグの中に自動で挿入されます。
メニューを整理したい
使用しているテーマではカスタムメニューでグローバルメニューが構築されており、
大カテゴリ›小カテゴリ
大カテゴリ›小カテゴリ
大カテゴリ›小カテゴリ
となっているのを、
一覧›大カテゴリ›小カテゴリ
›大カテゴリ›小カテゴリ
としたいとのこと。
こちらは管理画面の外観＞メニューで該当のメニューを開いて、「一覧」という名称でリンクをつけない（#などを入力しておく）項目をひとつ作って、その下に現在の階層構造を維持したまま配置し、メニューの階層構造をひとつ深くするやり方をアドバイスしました。
カスタマイザー
カスタマイザーで変更可能な内容だったので、カスタマイザーでの対応をおすすめしました。
キャッシュの利用
これはご質問の意図を僕が理解できているかが怪しいのですが、WordPress側で管理している画像についてAmazonS3などの外部ストレージに同じ画像を置いてキャッシュとして参照させようとしていて、その自動化の手法について検討されているようでした。
その方はそれをプラグインで実現しておられたのですが、キャッシュしたい画像をURLはそのままで画像だけ入れかえた場合（WPのメディア管理で画像だけ再アップロードするなどを使用）に、外部ストレージのほうの画像が更新されない現象が起きていて、それをなんとか解消する手段、またはもっとよいプラグインは無いかという質問でした。
僕はその辺りの知見は持っていなかったので正直にそれを申し上げたところ、それならばURLはそのままで画像だけを入れ替える機能というのは、WPの運用において一般的に起こることなのかどうか、という質問を受けました。
それについては、普通にブログやCMSとして運用している限りで、コンテンツの一部として配置した画像でそれを行う可能性は低いのではないかというお答えをしました。
既存テーマの活用
既存の無料テーマを使って構築したサイトをカスタマイズしたい、とのご質問でした。
その方はまずBizVektorを用いてサイトを構築されて、なかなか思い通りに行かずLightningに切り替えてみたようです。
カスタマイザー内で設定項目を一緒に探してみると結局全てカスタマイザーで対応可能な事柄で、数ヶ月うまくいかないと悩んでいたことが、あっさり解決したとのことでした。
カスタマイザーで簡単設定、という売りのテーマは多いと思いますが、実際にブロガーさんなど文系寄りでPCそのものには明るくないという方が使った場合に、カスタマイザーでもまだわかりづらいというか、見ないもしくは設定する箇所にたどりつけない、という現実は相変わらずありそうです。
ローカル環境構築
すでに運用されているサイトのテスト環境としてローカル環境にコピーしてみたら下層がNOT FOUNDになってしまった、というご質問でした。
URLをlocalhostに変更したのでパーマリンク設定の更新が必要ですが、スクリプトを使用してDBを直接書き換える形でURL設定を変更しので、管理画面上は更新されてても.htaccessがうまく動いてない状況ではないかと思われました。
そこで一度管理画面からパーマリンクの更新をやってもらったのですが改善せず。
ファインダーで確認すると.htaccessのタイムスタンプが更新されていないということに気づきました。
どうやら管理画面から更新をかけても.htaccessが上書きされてないようです。
結局エディタで.htaccessを開いて上書き保存を一度行うと、無事下層が表示されるようになりました。
書き込み権限などが正しく設定されていなかったんでしょうか。
動いたのでよしという感じで解散してしまいそれ以上突っ込めなかったんですが、そのあたりはできれば正確に把握しておきたかったところです。しかしながらPCは質問者さんのものなのでとりあえず今回の調査としてはここまでで。
雑感
このもくもく会が発足した当初と今では、参加者の層が少し変わって来ているように感じました。
以前は自分含めてウェブ制作者がWordPressをもっとうまく構築するための知見や、詳しい方々とのコネクションを得る場として参加することが多かったような気がします。
そして現在はWordPressを使って何か事業を行いたい方、例えば納品してもらったサイトを自分でいじりたいだとか、ブロガーとして自分でサイトをカスタマイズしたいなどで、アドバイスを求めて駆け込み寺として参加するパターン。
軽々しく「先生」なんて呼ばれるのは、あまり好きじゃないなあ、なんて思います。
今回はこんな感じです。