購入価格:2905円
評価:
この記事は約6分47秒で読めます
ぼくがWordPress(以降、WP)を本格的に触り始めたのはここ2、3年くらいなんだけど、以前はMovable TypeやJoomlaなども選択肢として上がってたと思う。だけど、最近は有無を言わさずWPが選択されるようになった感がある。
デファクトスタンダードとしてのワードプレス
WEBの世界ではしばしばねずみ算式の爆発的拡大が発生する。最近で言えば、Amazonに太刀打ちできるような通販サービスは存在しないし、出てくる気配も全然ない。
売れれば売れるほど、インフラに投下できる資金が増えるし、冒険的な施策も大胆に打てる。結果、サービスは比類なき最適化がなされ、お客さんは増加の一途。このいわゆるPDCAサイクルがほとんど天文学的な速度で回りまくっているのだから、勝てるわけがない。
普通に考えて、翌日に無料配送してなお利益を出せるようなビジネスモデルは、半端な企業サイズでは無理。郵便局の速達でさえ、今日出して翌日届く地域は限られているし、速達料金を上乗せしなくちゃいけない。
WPもまさにそんな寡占状態で、今後もしばらくはこの状態がいやでも続く。いくら一部がAmazonをボイコットしようが、便利で安いものを人は使ってしまうもの。
デフォルトでインストールされているプラグイン「Hello Dolly」は、20世紀を代表するジャズミュージシャン、ルイ・アームストロング（Louis Armstrong）の歌詞が表示されるプラグインです。なぜこのようなプラグインがインストールされているのかというと、WordPressの開発者であるマット・マレンウェッグ（Matt Mullenweg）が大のジャズファンだからです。 他にも、WordPress各バージョンのコードネームは、すべてジャズミュージシャンの名前になっています。
●WordPressのバージョン一覧 https://codex.wordpress.org/WordPress_Versions
素直にへーっと思った人は少なくないんじゃないかな。そもそも、WEB開発やWEBデザインに関する情報を紙の本で得ようとするのはナンセンスだという人もいる(ぼくはKindle版で読んだけど)。でも、どんな分野にしろ、紙の本になる過程においては、基本的に情報の質がWEB媒体に掲載される時よりも厳しく精査されると思う。
だからぼくは、WEBの情報もまた紙の本で得るというのが、遠回りのようで近道になるんじゃないかと考えている。何より、本当の意味で最先端のWEB関連技術情報を、毎日追いかけて試行して実務に取り入れて、なんてことができるのは一握りのスーパーWEBデベロッパーだけ。
ぼくを含めて凡百のWEB開発者は、紙の本になるくらい定着した情報を定期的に取り入れアップデートするだけで十分というか、精一杯なんじゃないかと思う。
もっとシンプルにならないか考える
長くWEB業界に身を置いてコードを書いていると、自然、ある一つの真理にたどりつく。それは、簡潔でシンプルなコードこそベストプラクティスだということ。
例を挙げると、カスタムフィールドを作成する時の一つのデファクトスタンダードになっているプラグイン「Advanced Custom Fields」では、同じことをするにも、以下のような二通りの方法がある。
カスタムフィールドの値を表示する カスタムフィールドの値を表示するには、「get_post_meta」関数を使います。get_post_metaは、引数にカスタムフィールド名を指定することで値を取得できます。「価格」を表示するには、カスタムフィールドのキー名は「price」なので、echoと組み合わせて次のようにします。
<?php echo get_post_meta($post->ID , 'price' , true); ?>
この記述でカスタムフィールドを表示することできました。しかし、少しコードが長くはないでしょうか。そこで”Advanced Custom Fields”には、カスタムフィールドを表示させるときに便利な関数が用意されています。Advanced Custom Fieldsが有効化されていれば、先ほどのコードは次のように記述できます。
<?php the_field( 'price' ); ?>
すごく簡単になりましたね。「the_field」関数は、カスタムフィールド名を引数に、ループ中の記事のカスタムフィールドを表示することができます。
やりたいことが出来たは出来たけど、冗長じゃないか。この疑問を心がけるだけで、格段にコードがスマートになっていくと思う。
要件定義はコロコロ変わる
WEB開発に一番重要なことは技術じゃない(最先端のWEB技術に関わっている人ではなく、凡百の開発者にとっての話)。気まぐれに飛んでくるクライアントの要望をいかに打ち返すかだ。そのためには、可能な限り静的ではなくダイナミックな設定を心がけるべきだと思う。
パラメータに記事IDを渡すと、get_permalinkはその記事のURLを取得できます。たとえば、「わたしたちについて」ページの記事IDは「50」だったので、「get_permalink( 50 )」のように記述してURLを取得します。リンクを繋げるには、echoと一緒に使用して次のように記述します。
<a href="<?php echo get_permalink(50); ?>" class="bnr" style="background-image: url('<?php echo get_template_directory_uri(); ?>/assets/img/home/bnr_about@2x.jpg')">
このhref="<?php echo get_permalink(50); ?>"の箇所は、普通に書けばhref="/about/"などとするところであるが、この方法で記述しておけば、aboutというURLをabout-usにしてほしいという要望があった場合でも、各静的リンクの記述の変更が不要になる。
もちろん、ダイナミックであるということは、読み込みのパフォーマンスに影響を与える。ブラウザがそのコードを解釈する時間が余分にかかるから。言ってみれば、人が見慣れない言葉に出くわした時に、辞書を引かなければならないのと同じようなタイムラグが発生する。
あなたがマッドサイエンティストで、究極の読み込みスピードを求めるならば、完全静的HTMLページに勝るものはない。
しかし、そのような対応は現実的ではない。かつてぼくは、十年以上前だが、ヘッダーやフッターの共通化というものを知らず、各ページにすべて静的にグローバルメニューを設置していた。
当然、メニューひとつ変更するのにも、ページ数分だけマンパワーで変更する羽目になった。単純に閲覧時の表示速度だけではなく、管理や更新のしやすさも考慮しなければ本当に使い物になるWEBサイトとは言えないと思う。
ちなみに記事IDは、該当記事や固定ページの編集画面を開いた際のURLを見ればわかる。本記事の編集画面URLはhttps://shintaku.co/wp-admin/post.php?post=6237&action=editだが、この場合は6237が記事IDとなる。
あと、このget_permalink関数をテンプレートファイルではなくWP記事内で使用するには、ショートコード化する必要があり、そのための記述をfunction.phpに追加しなければならない。以下の記事などを参照すれば難しくないので、ぜひ活用してみてほしい。
[WordPress]ショートコードで投稿IDやスラッグから記事の内部リンクを作成する