ぃまだWordPressで消耗してるよっ!

2015年末の状況ですので、今現在は変更されている可能性が多分に含まれます。
VCCW(VirtualBox・Vagrant)・WP-CLI・Wordmove・Gulp などのそれぞれのインストールと基本的な使い方は他のサイトにて確認下さい。
および、内容に未確定な内容を多く含みます。

その他の細々とした改修

WordPressとは直接関係の無い文化圏のプロダクトなどに関して

子テーマのCSSをStylus/nibをGulpで

使用しているのは子テーマなので、親テーマの差分+α程度しか修正する必要しか無いのだけど、モノは試しに、という事で、SASS/Compassではなく。
自分は変数使用とベンダプレフィックスの自動化程度しか使っておらず、少なくともそのプロダクトでなければダメという信念や極めた使い方をしていないので、Node.js/JavaScript関係で揃えようかと。1

それまではブラウザ互換の関連2 もあり、JavaScriptに苦手意識を持っていたけど、サーバサイドでJavaScriptを動かすという事は、そういう事態を一切考慮しなくて良いのが救いだった。
JavaScriptのオブジェクト型の参照などの問題に遭遇したりもしたが、概ね良好なセカイが広がっている気がしている。3

ちなみに gulpfile.js は、非常にヌルい使い方で後述するレベルだけど、この程度でも充分役に立っている印象。

ディレクトリ構成は、WordPressディレクトリ直下に DEV ディレクトリを作成。
どうでも良いけど、GULPFILE.js と大文字にしているのは、このファイル名でも問題無く認識するのと、ディレクトリ一覧の最初に表示されるので。4

wordpress
│   ├── DEV
│   │   └── CSS
│   │        ├── GULPFILE.js
│   │        ├── stylus
│   │        │   └── style.stylus
:   :        :
│   ├── wp-content
│   │   ├── themes
│   │   │   ├── hexa_child
│   │   │   │   ├── style.css
:   :   :   :   :

gulpfile.js は下記。

'use strict'
var gulp = require('gulp');
var plumber = require('gulp-plumber');
var stylus = require('gulp-stylus');
var nib = require('nib');

gulp.task('stylus', function() {
  gulp.src('stylus/*')
    .pipe(plumber())
    .pipe(stylus({
      import: ['nib'],
      use: [nib()],
      compress: true,
      linenos: false
    }))
    .on('error', console.log)
    .pipe(gulp.dest('../../wp-content/themes/hexa_child/'));
});

gulp.task('default', ['stylus']);

ついでに言うと、Wordmoveと併用する場合、本番環境に push させないように Movefileexclude: しておく程度の配慮は。

ところで以前から疑問だったのが5 、テーマ・子テーマ開発でのディレクトリ構成で、Movefileexclude: を眺めていて何となくだけど、WordPressのディレクトリ内で良いのかなぁと。
それまでのFTPでの手動アップロードだと間違えてアップしそうだけど、rsyncやWordmoveを使えば、設定作業に慣れるまでは大変なのと、パスワード管理にシビアになる必要があるけど、そういった事故は防げそうな。

なお、LiveReload/BrowserSync…今はBrowserSyncの方が旬か?…までは行わなかった。
子テーマ開発ではなく、テーマ開発だと用いるかもしれないけど、問題は、チームビルディングは経験無いのでコメントできないが、自分の場合、PHP・JavaScriptといったロジック層とCSSというプレゼン層が渾然一体となって開発する場合が多いので、逆にファイル保存時のタイミングで勝手にブラウザ再読み込みして欲しくない6 、という気持ちの方が強いので。
仮に用いるとすると、開発の最終盤でCSS微調整などの限定された場面になりそうな気がする…これはWordPressを使わない場合でも同様かと。
この機能を実演して、知らない人へのインパクトは大なのだろうけど…冷静になって考えて、実際それを使うかどうかは…何とも…7
以上、Staticおじさん脳的な発想。

参考までに下記。

…だったのだが、ちょっと頑張ってBrowserSyncの導入を「node.js – BrowserSync reload doesn’t work (wordpress site) – Stack Overflow」を参考に、ついでにその他修正を行ってみた。
ネットを探せばVCCWでの使用方法は割と見付かるが、自分は使っていないのでちょっと苦労したが。
このStack Overflowの質問者のコードはPHPの更新までも行っているが、自分はまだそこまで行っていない。
はっきり言ってどういう原理で動いてるのかはコメントできないが、BrowserSyncのコンフィグ、 proxyhostnotify がキモなのかなぁとは思う。
なのでバージョンアップで挙動が怪しくなった時の対処はできないと思う。

なお、ディレクトリ構成を上記より変更しており、wordpress ディレクトリ内でStylusを使っていたが、これを外出しにした。
同様にURLは http://localhost/morry.duelist.org/wordpress が開発時のURLで、 http://localhost:3000/morry.duelist.org/wordpress/gulp した時のURLになっている。

微妙に疑問だったのは、例えばこの投稿だと http://localhost/morry.duelist.org/wordpress/memo_wordpress_4th.htm になるが、自動更新時にトップページを開いていた時だけしか反映されないのかと思ったが、そうではなかった。
ついでに言うと、Apacheで http://localhost を立ち上げつつ、 http://localhost:3000 って可能なの?とか疑問だったけど、それも(おそらく)問題無い模様で、こちらも原理は分かってない。

実際に導入して見た感触としては、「うん、便利だわ」だった。
エラー時は、Stylusのエラー内容が出力されつつ、そのまま止まる事無く走り続けるし。

├── dev_css
│   ├── GULPFILE.js
│   ├── stylus
│   │   └── style.stylus
:   :
├── wordpress
│   ├── wp-content
│   │   ├── themes
│   │   │   ├── hexa_child
│   │   │   │   ├── style.css
:   :   :   :   :
'use strict'
var gulp = require('gulp');
var plumber = require('gulp-plumber');
var stylus = require('gulp-stylus');
var nib = require('nib');
var browserSync = require('browser-sync');
var reload = browserSync.reload;

var paths = {
  src: {
    stylus: 'stylus/*.stylus'
  },
  dest: '../wordpress/wp-content/themes/hexa_child/'
};

gulp.task('stylus', function() {
  gulp.src(paths.src.stylus)
    .pipe(plumber())
    .pipe(stylus({
      import: ['nib'],
      use: [nib()],
      compress: true,
      linenos: false
    }))
    .on('error', console.log)
    .pipe(gulp.dest(paths.dest))
    .pipe(reload({stream: true}));
});

gulp.task('watch', function() {
  browserSync({
    proxy: "localhost/morry.duelist.org/wordpress",
    host: "localhost",
    notify: false
  });
  gulp.watch(paths.src.stylus, ['stylus']);
});

gulp.task('default', ['watch']);

MAMPやめました

以前から割とコマンドラインでPHPを叩くので、MAMPのPHPへのパスを .bashrcPATH してると、brew doctor で妙なワーニングメッセージが出た記憶があり、若干鬼門気味になっている。8
なので、新MBA購入に合わせてMAMPをやめた。
各プロダクトのインストールはHomebrewを使わず、Apache(2.4.16)とPHP(5.5.27)はMBAのモノ、MySQLはOSX用のインストールパッケージ(5.5.45)、phpMyAdminは入れず9Sequel Proを。
正直、Apache・PHP・MySQLのコンフィグレーションは学習がてらとは言え、設定やパーミッション関係のトライ&エラーの連続で、次に同じ事ができるかと言われると自信が無い。
ついでに言うと、MySQLのバージョンアップに伴うパラメタ変更など、考えただけでもアタマが…
…なので、VirtualBoxとVagrantは余程何かの縛りが無い限りは選択肢として考えられず、MAMPはその筋の専門家でない自分には消耗しない有用なアプリだと思う…10

PHPのビルトインWebサーバーでWordPress

未対応、というか、Apacheの mod_rewrite 同等のルータスクリプトを書く必要があるとの模様なので、対応しない気味のpend。
うろ覚えだが、WordPressを動かすだけ、テーマ開発するだけ、ならばルータスクリプトは不要かもしれないが、自分の様に「パーマリンク設定」を変更して、.htaccess に何等かの記述が必要になる場合、上記の様なルータスクリプトが必要じゃないかなぁとうろ覚え(or 間違った解釈?)。
しかしビルトインWebサーバー自体は、Apacheの DocumentRoot 以外でも起動できるのと、別にPHPスクリプトを起動させる必然性も無いので、さくっとHTML5UPのテーマを確認するなどの使用で重宝している。
面倒があるとすると、Chromeブラウザの場合だと、URL履歴機能とURLのポート番号の照合というかヒットさせてしまうというか、妙な挙動をしてしまう事で11 、キレた。

なお、WP-CLIにも wp server という機能が存在する模様。

WordPressに関して

プラグイン

少し前までは、functions.php で実装するのではなく、プラグインで実現する方向だったが、

  • WordPressバージョンアップで突如動かなくなった
  • 年スパンでメンテされなくなった12

…という事態が目立つ様になった。

前者は引数を操作できるショートコードのプラグインで、元々は functions.php で実装する事が可能なのをプラグインに肩代わりさせただけなので、プラグインの使用を諦めて functions.php で実装した。13

後者は脚注のプラグインで、代替できるプラグインは数点あるのだが、メンテされなくなったプラグインの機能に存在したショートコードが実装されていないなど…という状況。
本音を言えば、自分がメンテされなくなったプラグインを今のWordPress流に書き換えて全世界に…というのが「優しい世界」なのだろうけど、あるべきプラグインの記述の作法が分からない、調べていないのでpend。14
取り敢えず機能不十分だけど代替できるプラグインが存在したのでそれを使用しているが、今後は functions.php に実装するかもしれないし、そうではないかもしれないし、といった状況。

今見たら

うわ、本家.jp見たら、ローカルも本番環境もダメダメじゃん…

  1. PHP バージョン 5.6 以上推奨
  2. MySQL バージョン 5.6 以上推奨

古い PHP や MySQL しか利用できないレガシーな環境でも、PHP 5.2.4 以上、かつ MySQL 5.0 以上であれば WordPress は動作しますが、公式なサポートが終了しているため、サイトがセキュリティの脆弱性にさらされる危険性を理解したうえで利用してください。

HTMLからMarkdownコンバージョン

面倒にも程があるが手作業で対応していたため一部HTMLのままだったが15 、ふと手を止めて絶対あるだろう、という事で、HTMLをMarkdownへ変換
リアルタイムに変換してくれるのと、サーバ側の実装が無い16 ので、データを覗き見される事は無いだろう(と思う)という安心感から多用して作業がだいぶはかどった。
ソースを覗き見したが、reMarked.jsを使っているらしい。

過去ログのサルベージ

ブログ引っ越しの度に投稿の取捨選択や記事の統合をしてきたので、1998年スタートの割には、現在このブログは60記事にも満たないが、それらをバックアップしていたので、何となく見直してみた。
特に2000年から2010年頃の投稿は、「ゴミ」としか言い様の無い投稿に紛れて、中には「へぇ、自分、こんな事考えてたのか、こんなコトしてたのか、あったなそういうの、全く忘れてたわ」(一方で「全然思い出せん、何だこれは?」)と思うのもあり、多少なりともサルベージの方向で考えている。
ただし2010年以降は、TwitterやFacebookで満足してるのか、ブログする、という事がほとんど無くなったので(でなければ別ネット人格アカウントのシャウトとかなので、同一ネット人格として公表しない方針)、投稿そのものが存在しないが。

あとはどうでも良いけど、投稿数が少ないのでWordPressのカテゴリを廃止してタグで一本化したり…17

Humans.txt の導入

まぁどうでも良いのだけど。
そう言えば以前 FOAF(Friend of a Friend) というのがあったけど、あれってどうなったのだろうかと。

WordPressで humans.txt の導入はプラグイン経由でも可能みたいだけど、そこまでせずとも、という事で、テーマに直書き。

<link rel="author" href="<?php echo esc_url( home_url( 'humans.txt' ) ); ?>" />

少なくとも、Chrome Appspector プラグインには補足されている模様。
内容は推して知るべし。

この作業を行っていて思ったのは、JetpackのOGPってちょっと気持ち悪いかなぁと。
(参考:Jetpack OGPとTwitterカードタグのカスタマイズ – セルティスラボ

フロントページの設定

見ての通り、このテーマHexa(を親テーマとして使用)は、はっきり言って、ぱっと見のユーザインタフェースが「不親切」だと思う一方で、アフィリエイトなどを考慮していないのでシンプルな作りであるとも。
自分は後者の理由でこのテーマを採用しているが、それにしても…だったので、フロントページを設定した。
方法は各所で検索できるので割愛するが、特に深い理由も無く、通常のブログ同様のイメージで最新投稿を get_option('posts_per_page') 件、まぁ、せっかくなのでタグクラウド、更にせっかくなのでツイート18functions.php にショートコードとして実装。

全然深刻ではな無いけどちょっと気持ち悪いなぁというレベルで問題があるとすれば、自分は超未来日付で、HTMLタグ・エレメントの一覧(レイアウト確認用)、サンドボックス、ショートコードのサンプル一覧などの非公開の投稿がある。
一般モードではフロントページとブログ一覧の表示内容は同一で非公開投稿は表示されないが、管理者モードの場合、フロントページは一般モードと同等、ブログ一覧は非公開投稿は表示されるので、管理者モードではフロントページに非公開投稿が表示されるのが正しいのかもしれないけど。
もしかしたら WP_Query で書き換えれば何とかなるかもしれないけど、そこまでする気力が。

で、ここからがStaticおじさん全開。
「非プログラマさんがPHP含むテーマカスタマイズに足を突っ込むと、変にPHPをややこしく考えないかなぁ」と余計な心配を。
正直、下記が正しい書き方なのか分からないが。

global $post;
$post_save = $post;
$args = array(
    'posts_per_page' => get_option( 'posts_per_page' )
   ,'offset'         => 0
    :
  );
foreach( get_posts( $args ) as $post ) {
  setup_postdata( $post );
    :
}
$post = $post_save;
wp_reset_postdata();

別に一旦 $post を保存するとか、foreachsetup_postdata するとかは、(他の言語にもある)「呪文」「おまじない」なので、「そうなんだ、じゃぁ時間がある時にもう少し深く」でいいのだけど、 foreach の値変数に $post を「指定しなければならない」というのには、ちょっと抵抗を感じた…19

…書いていて「逆恨み」「犬の遠吠え」にしか聞こえないのは承知の上で。

highlight.js の導入

今まで使っていなかったのは、ソースコードを掲載する事がそんなに無かったので。
プラグインでも色々と存在すると思うが、デザイン的にしっくり来なかったので使わず。20
導入に関しては他サイトを参考に header.php に下記を追加。

<link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.1.0/styles/github.min.css"/>
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.1.0/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>

固定ページにタグと抜粋を設定

ちょっと思う事があり追加。
Web検索すれば簡単にヒットするので詳細は割愛。

それにしてもとStaticおじさんは思った

ERPパッケージの導入が始まった頃なので、Windows95から98、Windows NTの頃かと思う。
意訳だが「極力、パッケージをカスタマイズしないで使いましょう、変えるのは業務手順の方です」と警鐘を鳴らす程だったので、まぁ、そういう時代だったのだと思う。
印象としては、INとOUTのパラメータを弄ったりしていた印象だが、実際のトコロは良く分からない。
ここで今更ガラパゴス乙と言いたいのでは無く、今の自分のWordPressの使用方法って…と怖気付く事があるが、少なくともコアな本体やテーマには手を付けてなく、外部ファイルの読み込みという疎結合な仕組みにしているが、改ページや脚注といったデータの持たせ方をトリッキーな仕組みにしているので、まだ当面はこの仕組で大丈夫かもしれないけど、何時までも使えるとは限らない、という心構えだけはある。
…というのがこちら側の業務要件だとすると、一方のWordPress本体は、現状ではWordmoveを通じて移行しやすい状態、全投稿を吐き出し、手作りのコンバートプログラムを通じて、新しい環境に合うフォーマットに変換できる状態にはしているけど21 、やっぱり面倒だろうなぁとは思う。
仮にそういう状況になったとしても、おそらくは事前に何らかのアナウンスがあり、それなりの縮退期間を経た後の、マスとしては緩やかな移行になると思われるが。

想定されるシナリオとしては、WordPressのバージョンアップに伴う仕様変更でトリッキーな処理が微妙に挙動が変になり、都度修正が生じるだろうなぁというのは覚悟の上だけど、WordPress本体に関しては正直何ともで、そりゃ長く使えるに越した事は無いが、あの当時の自分は何を想って業務に携わってたのか…

いやホント、ブログって盆栽を育てる感覚に近いのかなぁと、割と昔に思った事を思い出したりした。

特にオチは無いが、ふとそんな事を。

2015/12/28

Menu of this post

  1. 1. だらだらと
  2. 2. WP-CLI・Wordmove
  3. 3. 最もよく見られた投稿をJetpack APIから取得
  4. 4. 関連する投稿を実装してみる
  5. 5. その他の細々とした改修

Footnotes

  1. 1. 他にはElectronとか。

  2. 2. コピペで動かす事はできるかもしれないが、あるOSのあるブラウザのあるバージョンの挙動が変なので修正して、と言われても、正直、対応できる自信が無いし、そもそもこれらのテスト環境を全て揃えるのは困難。

  3. 3. 今更ながら第一印象や相性、多分こう書けばこう動くだろうという、推論が効くのって相当ウエイトが高いのではないかと思う。

  4. 4. 仮にチームビルディングに自分が参加した場合、これはそのチームの方針に従います。

  5. 5. 何せボッチなもんで…

  6. 6. プログラミング時に絶対にエラーコーディングをしないヒトには物凄く有用かと思う。

  7. 7. チームビルディングで指示があれば、当然それに従う所存。

  8. 8. 同様に、当初はNode.jsのOSX用パッケージを導入していたが、もの凄い量のメッセージ(C/C++?のインクルードファイルがどうの…)が出たので、これもnodebrewに換装した。

  9. 9. データをマウス操作だけで見れるのは当然としても、データベースとユーザを簡単に作成できる、というのが一番の有り難みだった気がするが、それらとインストール&設定の手間を考えると、だった。

  10. 10. けど128GBしか無いので余計なプロダクトを入れたくなかった。今後明示的に別バージョンのPHPが必要になった場合、phpbrewあたりかと。

  11. 11. 8080を指定したのに、以前確定させた8000に「勝手に」変わってしまうなど、なのかなぁ…不明。いずれにせよ素直でない印象で、こうなると履歴削除以外方法が無いのかなぁと。

  12. 12. まさかと思うけどこの辺を突かれた…んじゃ…

  13. 13. 投稿画面で操作できるのは有り難いけど、ユーザさんが適宜追加削除したり、無闇矢鱈に増減するモノでも無いし、という事で。

  14. 14. 昨今はセキュリティ関連が特に問われるので、おいそれと公開できるのか公開できないのか…もはやここまで来ると、ボッチでは如何ともし難い事を実感する。

  15. 15. アンカータグをMarkdownに置換するsedぐらいは…と思いつつも。

  16. 16. 以前自分もAjax経由で、PHP MarkdownとPHP Markdown Extra(と脚注)をパースさせる実装を行ったが。ただ、このサービスに限らないが、Markdownパーサによって微妙に方言があるのか無いのか、例えばDT・DDタグを解釈したりしなかったり。

  17. 17. CMSとして使う場合はカテゴリは必須かと思うけど、ブログだけの利用だと、タグだけでも問題無いのではないかと。

  18. 18.statuses/user_timeline – ユーザーのツイートを取得 | Twitter Rest API 日本語リファレンス」参照。

  19. 19. で、じゃぁお前は何が良いと言うのだ、代案出せ!とか突っ込まれると頭を下げるしか無いです。

  20. 20. …というのもあるし、完全なコードを記載する事があるのか無いのか分からない状況。仮に完全なコードを記載する場合(今回やってるけど)、GitHubを使った方が、とは思う。

  21. 21. おそらくは何割かは自動コンバートできず手動になるのではないかと思う。