マイペースクリエイターとクリエイターはWordPressとWordくらいちがいます。WordPressを中心としたWeb系の覚え書き。
この記事は運営堂さんサイトリニューアル裏話シリーズ(5)でもあります。
今回の運営堂さんのサイトはWordPressで制作しましたが、お問い合わせフォームだけはWordPressと切り離した独自のプログラムを設置しています。
“ozn-form（オゾン・フォーム）”と名付けたこのメールフォームは、いわゆる「EFO（入力フォーム最適化）」でよく「こうしましょう」と言われている代表的なセオリーをこれでもかとばかり盛り込んだ仕様になっています。
手っ取り早い話が、以下の記事に書いてあることをすべて詰め込んでいます。
↓
EFO（入力フォーム最適化）って？フォームを改善して売上を上げるための20のテクニック｜ferret [フェレット]
*注「確認画面を省略する」は今回実施していませんが、仕様としてはできるようになっています。
せっかくなので、このメールフォームを作成した経緯についてしっかり紹介したいと思います。
ちなみに有償プロダクトです。
運営堂さんサイトリニューアルにあたって苦労したところを書き残しておくシリーズの4つ目です。
WordPressにはブログ内検索機能がありますが、あくまでブログ用のデータベースの中をさらって結果を返してきているだけなので、正式な検索用途として作り込まれているわけではない簡易的なものであることを忘れてはいけません。
以下は、それを忘れ去っていたために、しばらく悶々とした日々を送った私の夏の思い出です。
運営堂さんサイトリニューアルにあたって苦労したところを書き残しておくシリーズの3つ目です。
正直、今回一番苦労したのがこれです。
今回の要件定義で、URL構造も細かく指定がありました。
例えば、ブログならこんな感じ。
もうひとつのメインコンテンツである「ズバッと解決！GoogleAnalytics」はこんな感じ。
お気付きでしょうか。
カテゴリーアーカイブ・タクソノミーアーカイブのURLに、ターム名が入っていません。
運営堂さんサイトリニューアルにあたって苦労したところを書き残しておくシリーズの2つ目です。
今回、リニューアル・サーバ移転にあわせて、常時HTTPS化をすることになりました。
森野さんとは、昨年からずっと「折を見てやりましょう」という話をしていたのですが、結局あれもこれも変えたいね、となって今回のリニューアルに至ったわけです。
さて、HTTPS化にあたってよく言われるのが、SNSのシェア数がリセットされてしまうこと。
これの対応について、WordPressの場合だと「SNS Count Cache」というプラグインを使う方法があります。
このプラグインの説明については、検索してもらうと結構な数の記事が出てきますので詳細は割愛しますが、今回導入した目的は以下の2つです。
が、一見便利そうで人気もあるこのプラグインも万能ではなく、あまりに変化が早すぎるFacebook側のAPIの仕様変更に追随ができていないという問題があります。
今後のアップデートで変更があるかもしれませんが、2017年9月時点でSNS Count Cache バージョン 0.11.1 が抱える問題にどのように対応したかを記録しておきます。
2019.05.19追記：SNS Count Cache バージョン 1.1.2 にて、下記の問題が解消していることを確認済みです。現在は以下のような対処は必要なくなっているはずです。
独立時からずっとお世話になっている運営堂さんのサイトリニューアルのお手伝いをしました。
2011年には私がひとりでリニューアルを実施したのですが、今回はちゃんとプロジェクトチームを組んで、分業制で行いました。
おかげで私はWordPressまわりのことだけに集中できてとてもやりやすかったのですが、その中でもいくつか苦労した点や、他の案件ではまずやらないようなこともやったので、その部分を後学のために書き残しておきたいと思います。
1つ目は、「WordPressの記事を、投稿IDを維持してインポート」という点です。
まずは、なぜこういう要件になったかという説明から。
この記事はWordPress Advent Calendar 2016の20日目として書いています。
19日目のdenari01さんからのリレーです。
コアコミッターの皆さん、翻訳チームの皆さんいつもありがとうございます。
さて、WordPress4.7の新機能といえば、なんといっても長らく「やるやる詐欺」とも言われていた(?)WP REST API のコアへの実装でしょうか。
しかし、クライアントワークでひたすらブログやコーポレートサイトを作り続けている我ら下層ウェブ制作者にとっては、新関数get_theme_file_uriの登場こそ、待望されていたのではないでしょうか！
いちおうWordFesの振り返り記事です。
今回、はるばる宮崎から @miiitaka さんに飛行機で名古屋にお越しいただき、「WordPress+JSON-LDで構造化するこれからのマークアップ」というセッションを担当いただきました。
一応WordCamp Kansai 2016の同名セッションの再演なのですが、今回は45分とセッション時間も長くなり、よりブラッシュアップしていただきました。
私はスタッフ活動の合間に、サポーターブースの横のモニターでセッション中継を見ていました。
以前から構造化マークアップについて注目はしつつも、なかなかまだ業務上で要件に含まれるような案件がなく、このブログでささやかにdata-vocabulary.orgによるパンくずと、microformats.orgによるhentryについては入れてあるような感じです。
ただ、パンくずも今はGoogleでschema.orgの方が推されているようですし、全体的にちょっと古い感が出てきているのは否めません。
そんなところへ、@miiitakaさんがセッションで「構造化データをHTMLの属性に記述していくと煩雑になる。テーマと分離したい」というような趣旨のことをおっしゃっていて、
「それ！それだよ！」
と、非常に非常に共感したわけです。
テーマにはできるだけ手を入れたくないですもんねー。
そこで「JSON-LD」です。
超平たく言うと、HTMLにdata-***属性とかitem-***属性を1つ1つつけていくのではなく、1ヶ所に集めて書いちゃうという、おまとめ方式の記述のことです。
検索で数年前の情報が上位に出ているのをアップデートしたい企画第3弾（くらい）です。
wp_count_posts関数を使ってください。
以上。
Codexに「この関数は指定した投稿タイプの各投稿ステータスの投稿数を取得できます。」とありますので、たとえば「公開済み」の投稿についての総数を知りたい場合、
「WordPress日本語フォーラムについての話を」ということで、WordCamp Kansai 2016のスピーカーとしてお声掛けをいただき、2年ぶりに参加してきました！
orgのプロフィールページにスピーカーのバッジが付きました！
以前もWordPress日本語フォーラムに関するブログ記事は何度か書いていますが、それを焼き直し、最新の数字を加えた内容です。
フォーラム基本情報、フォーラムを使う前に調べること、いざ回答するときの配慮など、基本的には「初めてフォーラムで質問する」方向けの内容になっています。
WordPressで商品紹介サイトを構築して、1つの投稿（カスタム投稿でも可）が1つの商品紹介ページになる、というような設計になることってよくありますよね？
で、「お客さんや営業マン用に、各商品ごとに印刷用ページを生成したい」っていわれることもあったりしますよね？
WordPressで印刷用ページを生成するためのプラグインってあるんですが、どうしても簡易的なものなので、クライアントさんの思うような印刷用ページになるとは限りません。
そこで今回は、プラグインではなく自力で各投稿ごとの印刷用ページを自動生成する機能をできるだけ簡単な方法で実装してみたいと思います。
翔泳社さんより2019/06/05刊行。2冊目の著書です。
