タグ別アーカイブ: wordpress

org-mode で WordPress の記事を書きたい その3 スタイル追加

とりあえず、手元の emacs で書いた org-mode の記事を、 そのまんま WordPress の載せられるようになったけれど、 見た目があまりにも素気ないので、スタイルシートを追加してみる。

HTMLはともかく、デザインっぽい css には縁がなく、サッパリ分らない。 とりあえず、人様のを パクってきて 参考にしてみよう。

とその前に。 WordPressが勝手に追加したHTMLタグを削除しておく。

まずは WordPress 標準の HTML タグを排除する

remove_filter で、余計なフィルタを削除する事までは分かっている。 削除するフィルタは ‘wptexturize’、’wpautop’、’wp_richedit_pre’ あたりで十分そうだ。

ただ、どの資料や先人のブログを見ても、remove_filter を functions.php に 記述するように、とある。

今回のプラグインでも、呼び出される時に同時に remove_filter を行なうと、 とりあえず想定通りの動作はした。

無駄はあるかも知れないけれど、まぁ良いか。

プラグインに挿入したのは、こんなコード フィルタの存在確認は特に必要ないようだし、 このプラグインでは画面の種類まで気にする必要がないので、 今は、これで必要十分。

remove_filter('the_title', 'wptexturize');   // タイトルの記号を実態文字化する
remove_filter('the_content', 'wptexturize'); // 記事の記号を実態文字化する
remove_filter('the_excerpt', 'wptexturize'); // 抜粋の記号を実態文字化する
remove_filter('the_title', 'wpautop');       // タイトルの自動整形を無効にする
remove_filter('the_content', 'wpautop');     // 記事の自動整形を無効にする
remove_filter('the_excerpt', 'wpautop');     // 抜粋の自動整形を無効にする
remove_filter('the_editor_content', 'wp_richedit_pre'); // 改行とBRのあつかい

WP-Markdown や JP Markdown のソースコードを見てみると、 上と同じコードがないし、それぞれ違う実装方法を選んでいるみたいだ。

WP-markdownでは

./wp-markdown.php:79:  remove_filter( 'bbp_new_reply_pre_content', 'bbp_code_trick',  20 );
./wp-markdown.php:80:  remove_filter( 'bbp_edit_reply_pre_content', 'bbp_code_trick',  20 );
./wp-markdown.php:81:  remove_filter( 'bbp_get_form_reply_content', 'bbp_code_trick_reverse',  10 );
./wp-markdown.php:85:  remove_filter( 'bbp_new_topic_pre_content', 'bbp_code_trick', 20 );
./wp-markdown.php:86:  remove_filter( 'bbp_edit_topic_pre_content', 'bbp_code_trick', 20 );
./wp-markdown.php:87:  remove_filter( 'bbp_get_form_topic_content', 'bbp_code_trick_reverse', 10 );
./wp-markdown.php:91:  remove_filter( 'content_save_pre', 'balanceTags', 50 ); //Remove balanceTags and apply after MD -> HTML
./wp-markdown.php:125: if ( remove_filter( 'content_save_pre', 'wp_filter_post_kses' ) ) {

jetpack-markdownでは

./markdown/easy-markdown.php:137: remove_filter( 'wp_insert_post_data', array( $this, 'wp_insert_post_data' ), 10, 2 );
./markdown/easy-markdown.php:138: remove_filter( 'edit_post_content', array( $this, 'edit_post_content' ), 10, 2 );
./markdown/easy-markdown.php:139: remove_filter( 'edit_post_content_filtered', array( $this, 'edit_post_content_filtered' ), 10, 2 );
./markdown/easy-markdown.php:141: remove_filter( '_wp_post_revision_fields', array( $this, '_wp_post_revision_fields' ) );
./markdown/easy-markdown.php:143: remove_filter( 'content_save_pre', array( $this, 'preserve_code_blocks' ), 1 );
./markdown/easy-markdown.php:161: remove_filter( 'pre_comment_content', array( $this, 'pre_comment_content' ), 9 );
./markdown/easy-markdown.php:238: $this->kses = remove_filter( 'content_filtered_save_pre', 'wp_filter_post_kses' ) && remove_filter( 'content_save_pre', 'wp_filter_post_kses' );
./markdown/easy-markdown.php:568: remove_filter( 'wp_revisions_to_keep', '__return_false', 99 );

WordPressのどこを勉強すれば、こういう方法を思いつくのかな?

せめてソースコードのスタイルシートは綺麗に

さて、問題のスタイルシート。 WordPressのHTMLタグを取り除いたので、ひとまず見られる位になったので、 もう少し華やかにしてみたい。

出来るだけ楽をしたいので デザインに自信ないので、出回っている物を流用しよう。

検索すると、 Highlight.js と SyntaxHighlighter が見付かった。 軽量で扱い易そうな Highlight.js を有り難く使わせて頂こう。

javascriptの設置と登録

Highlight.js は、名前の通り javascript なので、 どこかのサーバに置いて、 WordPress に教えてあげる必要がある。

そこではたと困るのが、プラグインのフォルダを知る方法。 探してみると、それっぽいのが結構色々みつかる。

Highlight.js から zenburn.css を選んだとすると。 こんな感じ?

wp_enqueue_script('org2html-highlight', plugin_dir_url( __FILE__ ) . 'script/highlight.pack.js');
wp_enqueue_style('org2html-style', plugin_dir_url( __FILE__ ) . 'style/zenburn.css');

動く以前に、何か怒られた。

login_enqueue_scripts hooks. Please see Debugging in WordPress for more information. (This message was added in version 3.3.) in ... /wp-includes/functions.php on line 3622

検索してみると、一旦関数にして add_action で登録しろって事らしい。 なので、それっぽく書き直してみよう。

function my_enqueue_scripts() {
    wp_enqueue_script('org2html-highlight', plugins_url('script/highlight.pack.js', __FILE__ ));
    wp_enqueue_style('org2html-style', plugins_url('style/zenburn.css', __FILE__ ));
}
add_action('wp_enqueue_scripts', 'my_enqueue_scripts');

あと、本文の方に javascript の実行部分を追加して、作業完了。

$html .= '<script>hljs.initHighlightingOnLoad();</script>';

おぉ〜 良い感じになった。

想定外の文字が意外に多くて、時々パーサが失敗してるけど… まぁ、良いか。そのうち直そう。

emacs org-mode で WordPress の記事を書きたい その2 TDDでプラグインを書いてみた結果…

PHPUnitでテストしながら実装してみたのでサーバに載せてみたところ、
Wordpressでは予定通りに動作しない。

ローカルでは問題なく動作したんだけれども。。。

# 動作結果の確認
Webサーバに転送してみたところ、うまく動作しない。
空行検出を含む一部の正規表現が、ローカルと違う動作結果を出していた。

原因は、PHPのバージョン違いか、文字コードか、WordPress固有の問題か?
それとも他の原因?

順に確認していこう。

# PHPのバージョン違い
ローカルのPHPは

PHP 5.5.27 (cli) (built: Jul 23 2015 00:21:59)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

サーバは 5.3 だったけれど、 5.5.19 に切り替えてみても、
結果は変わらなかった。

# 文字コード
ローカルでは、UTF-8。
WordPress も標準は UTF-8 のはず。

# WordPress固有の問題? テスト用のサーバでデバッグ
本番WordPressでは怖いので、以前作ったまま放置していた 別の WordPress でテスト。

こっちのサーバは、デバッグ用の設定になっている。

wp-config.php:84
define(‘WP_DEBUG’, true);

すると、3箇所に問題が起きていた。

Notice: Undefined index: text in /home/somof/somof.net/public_html/hawaii/wp-content/plugins/org2html/orgParser.php on line 189
Notice: Undefined index: args in /home/somof/somof.net/public_html/hawaii/wp-content/plugins/org2html/orgParser.php on line 387
Deprecated: Function split() is deprecated in /home/somof/somof.net/public_html/hawaii/wp-content/plugins/org2html/orgParser.php on line 96

暗黙の配列を、暗黙のNULLと仮定していたのを怒られているのと、
splitは廃止せい、という事らしい。

未定義のチェックを追加して、split() を、explode() に交換すると、
警告は無くなった。

# WordPress固有の問題? テスト用のサーバでデバッグ
ローカルに本番環境が無いので、サーバでログを吐かせてみると、

if (“” === $line) {

の行が動いていない事が分かった。
なんてことはない、WordPressの中の改行コードに ‘\r’ が混じっていたので、
‘\r’ を削除するコードを追加して、動作するようになった。

そのうち、サーバ側のPHPを 5.3 に戻しておこう。

# このプラグインを正しく成長させるにはWordPressの探求が必要そう
このプラグインは、要はテキストにHTMLタグを追加するフィルタなのだけど、
WordPress自身もHTMLタグを追加してくるので、
細かいことまで調整しようとすると、厄介。

せっかく、<PRE><CODE>で囲んでも、WordPressが改行に<BR>を追加してくる。

なので、間延びした表示になってしまった。

今回は、プラグイン側で泥縄的に最低限の見栄えまで帳尻を合わせたけども、
本当はちゃんとしないといけないんだろう。

CSSで調整しようにも、余計なタグを挿入されてしまうので、うまくいかない。

WordPress自体には、それ程興味もないしなぁ。

gitの設定とBitbucketのリポジトリ作りなおし

うっかり、gitのユーザ設定を忘れていたせいで、
Bitbucketに個人名で push していた。

Macのどこから個人名を見付けたのか分からないけど、
ちゃんと gitの user.name を指定すれば問題は解決。

$ git config –global user.name “somof”
$ git config –global user.email “somof@XXXX.ne.jp”

きれいさっぱり、リポジトリを削除して作り直し。

# Bitbucketのリポジトリを削除
左の「設定」から、「リポジトリを削除」を選択する。

# もう一回、Bitbucketにリポジトリを作成する
Bitbucketの「概要」から「リポジトリ作成」を選択。

出来たリポジトリは [org2html](https://bitbucket.org/somof/org2html.git)

今作ったリポジトリのページで、
Setting > デプロイ鍵 > 鍵を追加 から、公開鍵をコピペしておく。

# ローカルのgitリポジトリを削除して、作り直し
綺麗にフォルダごと作り直した後、新たに。

$ git init
$ git remote add origin https://somof@bitbucket.org/somof/org2html.git

何かコミットしておく。(でないとpushできないので)

$ git push –set-upstream origin master

あぶないあぶない。

PHPの勉強。あんがい面白い言語なんだな

WordPressのプラグインを作るために勉強したPHPの特徴のまとめ。

# 演算子の注意点
暗黙キャストの結果、予想外の結果になる場合があるので、要注意。

数字として不都合なく使えている様で、実際は文字列の事がある。
数字として比較したい場合は、明示的に数字にキャストするか、
厳密な比較(===)を使う。

また、演算子は左結合で少し変っているので、括弧を使って演算順を明示した方が良い。

# 配列
添字配列と連想配列が同じ、混在も可能。

キーが浮動小数点や論理型の場合、整数に丸められる。
更に、添字(風に書いた)配列は、実際には数字をキーにした
連想配列と同等なので、うっかり連想記憶の書式で重複させないこと。
重複した場合は、後の定義が有効になる。

キーが定義されているかどうかは array_key_exists($key, $array) が使えるが、
isset($array[‘key’]) の方が、たいていの場合高速に動作する。

# ブロック構文
中括弧{}だけでなく、 if/endif、switch/endswitch、while/endwhile、
for/endfor、foreach/endforeach が使える、

HTMLに混在して書く時に便利。

# 文字列からの関数呼び出し

call_user_func(‘funcname’, arg1, arg2…)
call_user_func_array(‘funcname’, array())

# lambda関数
create_function()関数があるのだけれど、見難いので、
function() {} 構文の方が良い。

# オブジェクトの複製ができる
python同様、複製しない代入は基本的に参照扱いになる。
複製が必要な場合は、以下のようにする。

$obj2 = clone $obj1;

# マルチバイト対応の文字列処理

–enable-mbstring で mbstring 関数を有効にする。
別途libmbflライブラリが必要。

大抵の場合は、標準の ereg_~関数で間に合いそうだけど。
必要に応じて。

|—————————————————————-+——————————————|
| 関数 | 用途 |
|—————————————————————-+——————————————|
| int mb_ereg(string $pattern , string $string [, array $regs ]) | マルチバイト文字列に正規表現マッチを行う |
| | |
|—————————————————————-+——————————————|

# 便利関数や定数など
|——————————————–+——————————–|
| 関数 | 用途 |
|——————————————–+——————————–|
| var_dump() | 変数の出力 |
| array_output($array) | 配列を一行ごと出力する |
| | |
| get_defined_constants() | 定義済み定数一覧 |
| get_defined_functions() | 定義済み関数一覧 |
| | |
| function_exists($name) | 関数の存在確認 |
| array_key_exists(l$key, $array) | 配列内のキーの存在確認 |
| | |
| split(‘,’,$str) | おなじみの文字列分解 |
| constants($name) | 名前の文字列から定数を取り出す |
| | |
| $funcname(); | 文字列 $funcname の名前の関数 |
| $$varname | 文字列 $varname の名前の変数 |
| | |
| isset($var) | 変数が定義されているかどうか |
| isarray($var) | 配列かどうか |
| | |
| intval($val), floatval($val), strval($val) | キャストする |
| | |
| get_resource_type($res) | |
| array_map(‘funcname’, $array) | |
| this/self/parent/static | |
|——————————————–+——————————–|

|—————+————————————|
| マジック定数 | 用途 |
|—————+————————————|
| __LINE__ | ファイル上の現在の行番号 |
| __FILE__ | ファイルのフルパスとファイル名 |
| __DIR__ | そのファイルの存在するディレクトリ |
| __FUNCTION__ | 関数名 |
| __CLASS__ | 名前空間も含んだクラス名 |
| __TRAIT__ | トレイト名 |
| __METHOD__ | クラスのメソッド名 |
| __NAMESPACE__ | 現在の名前空間 |
|—————+————————————|

# その他のTIPS
## エラー抑制演算子

$var = @$_GET[”];

など書くと、_GETにエラーがあっても、エラーが抑制される。

## 定数の定義
二通りの方法がある。

define(‘ORG_TYPE_TEXT’, 1);
const ORG_TYPE_TEXT = 1;

定数の場合、先頭の$は必要ない。
また、文字列から定数を取り出すには、constants()関数を使う。

$name = ‘ORG_TYPE_TEXT’;
echo constants($name), PHP_EOL;

constは、名前空間に影響を受ける。

## 配列の初期化
空ブラケットで追加しながら初期化することも出来る。

$vararray[] = ‘ar1’;
$vararray[] = ‘ar2’;
$vararray[] = ‘ar3’;
$vararray[] = ‘ar4’;

## 三項演算子

条件式 ? 式1 : 式2

条件式 ?: 式1

とも書ける。
この場合、条件式が真のときには条件式の値を、偽の場合は式1を返す

PHP で使う日本語正規表現のあれこれ

WordPressのプラグインを作るのに、日本語の正規表現が必要なのだけれど、
ぐぐると、何やら情報が混乱ぎみだったので、調べた結果だけをまとめておく。

まぁ、 WordPressのコーディングルールを見て、正式に公開する気は無くなったので、
自分(と自身で何とか出来る人)だけ使えれば良いのだけど。

orgのテーブルだけ変換するプラグインを作った時には何も考えなかったけれど、
Unicodeに対応するのは結構面倒だ、という話。

出来れば関わりたくない。
調べた結果、org-modeのタグを見付けるだけなら、意識しなくて良さそうだ。

# 正規表現の種類
まず、正規表現自体が3種類もある。(汗)

|———+———–+——————————-|
| 名称 | 種類 | 備考 |
|———+———–+——————————-|
| pcre | Perl 互換 | preg_~関数 |
| | | UTF-8 のみ扱える |
| | | パターン修飾子に u を指定する |
| | | 注意点がそれありに有る |
|———+———–+——————————-|
| mbregex | mbstring | mb_ereg~関数 |
| | | 別途インストールが必要 |
|———+———–+——————————-|
| regex | POSIX | 非推奨 |
|———+———–+——————————-|

余計なインストールを避けるなら、 pcre 一択。

とりあえず見付けた、pcre(Perl互換正規表現)の問題一覧。

– 対応する日本語コードは UTF-8 のみ
– UTF-8 を使う場合は、パターン修飾子に u を指定する(PCREのドキュメントに見付からないけど)
– 処理の制限値があり、越えると 0(マッチしない)を返す
– 文字クラス(alnum,alpha,ascii…)の動作が曖昧?ドキュメント上は日本語にマッチしないはずだけど。。。
– 「.」はデフォルトでは改行にマッチしない

# 使用する関数やライブラリ;mb_~は必要か?
mbstring を使う場合のデメリットはこんな感じ。

– WordPressのプラグインのために追加インストールが必要
– 内部エンコーディングとは別に、検索対象の日本語コードを指定する必要がある

追加しなきゃならないのは、今回は致命的だなぁ。

問題あるにせよ、気をつければ pcre(preg_match/preg_replace)で十分事足りそう。
日本語自体で正規表現を書かなければ良いのだし。

# Unicodeの制御信号、異体字セレクタなどの影響
日本人としては信じ難いことに、Unicodeには似た漢字を同じコードで表わす仕様がある。
Standardized VariantsとかVariation selectorとか、見たところ場当たり的に追加された様だ。

実際には、見付けたいのはアスキー文字の部分なので、
例えば「.*」に漢字を含めてくれるのなら、今回は気にしなくて良い。

問題の頻度を想像するに、起きてから対策すれば良い程度のものだろう。
そして今回は、起こりそうにない。(起さない… きっと)

wordpress PHP 正しいプラグインを作る作法;コードスタイル編

乱立していたスタイルを整理してくれたという方々に敬意を表して、
コードスタイルなどは、基本的には PSR に従うことにする。

だけども。
WordPress に必要な固有のルールもあるので、まとめておく。

# まず、PSRからの抜粋。

## 名前空間とクラス名の記構造

\<ベンダー名>\(<名前空間>\)*<クラス名>

区切り文字にバックスラッシュを使って良いらしい。
アンスコ”_”に、意味はないとか。

#+BEGIN_SRC php
// PHP 5.3 以降:
namespace Somof\WPPlugin;

class Org2Html
{
const VERSION = ‘0.1’;
const DATE_APPROVED = ‘2015-08-22’;
}
#+END_SRC

## ソースファイルの分割
クラス、関数、定数などを宣言するためのファイルと、
副作用のある処理を行うためのファイルは、分けるべき。

出力の生成部分はもちろん、
初期化ファイル(ini設定)の変更も副作用と考える。

## 命名規則
– クラス名は、StudlyCaps(単語の先頭文字を大文字で表記する記法)記法
– クラス定数は全て大文字とし、区切り文字にはアンスコを用いる
– メソッド名はcamelCase記法

## アクセス修飾子
– アクセス修飾子を、全てのプロパティ、メソッドに定義する
– abstractとfinalはアクセス修飾子の前に定義する
– staticはアクセス修飾子の後に定義する
– public : クラス内、クラス外のどこからでもアクセス可能
– private : 同じクラス内からのみアクセス可能
– protected : 同じクラス、及び子クラスからアクセス可能
– final : 拡張による変更禁止 (クラスとメソッドのみ)

# WordPress に必要なルール

以下、 [[http://wpdocs.osdn.jp/WordPress_%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E5%9F%BA%E6%BA%96][WordPress コーディング基準]] からの抜粋。

## シングルクォートとダブルクォート
シングルクォートとダブルクォートを適切に使い分ける。

– 文字列で何も評価しない場合は、シングルクォートを使う。
– セキュリティ上、HTML出力ではダブルクォートを使うべき
– 文字列で HTML クォートをエスケープする必要はほとんどない
– 例外は JavaScript
– ダブルまたはシングルクォートのどちらかを強制されるときがある

## WordPress の Data Validation について

## インデントとブレース、スペースの使い方
スペースではなく、本物のタブを使う。
むむむ。 これは守らないかも。

## include_once 対 require_once
include_once と require_once を適切に使い分ける。

「これら2つの構文は、 エラーの扱い方を除けば全く同様に振舞います。
 エラーが発生するとどちらも Warning を出力しますが、
 require() を使用している場合は Fatal Error となります」

## 正規表現
Perl 互換の正規表現 (PCRE, preg_ 関数) を使うこと。
POSIX 互換関数よりも好ましい。

## PHP ショートタグは禁止
PHP のショートタグ (<? … ?> や <?=$var?>)は使わない。
常に、完全な PHP タグ (<?php … ?>) を使う。

## 変数、関数、ファイル名と演算子
変数名、関数名はアルファベット小文字を使い、
単語の区切りはアンダースコア (_) を使う。
キャメルケースのような形式) は不可です。

ファイル名は動作を説明できるアルファベット小文字の名前とし、
単語の区切りにはハイフン (-) を使う。

1回しか使わない変数を作ってはいけない。

比較演算の時には、定数を左に、変数を右側に置く。

関数の引数のフラグは、意味の分かる値にしてください。
true/falseではなく、呼び出す側が読める文字列で渡す。

# さて、どんなルールにするか。

違和感のあるのは以下のルール。

– インデントにスペース禁止
– ファイル名のハイフン
– 命名規則で camelCase禁止
– 一度しか使用しない一時変数の使用禁止

手元にある、人の書いたプラグインを見ると、
camelCase禁止以外は、あまり守られていないみたいだ。

WordPressで公開する訳でなし、PHPの勉強の意味で長い目で見れば、
PSRに従っておいた方が良さそう。

WordPressのプラグイン開発。PHPのツールとJenkinsプラグインの用意

PHP関係のパケージの管理は、 composer を使う。

# まずは、composer のダウンロード。

$
$ curl -sS https://getcomposer.org/installer | php
$

composer には、他に以下のようなコマンドもある。

$ composer.phar install # 先に composer.json にパッケジを書いておく
$ composer.phar update
$ composer.phar remove # composer.json を編集して update の方が分り易い

# PUPUnitのインストールのお試し
PHPは趣味にしか使わないから、インストール先は global にしておく。

$
$ composer.phar global require “phpunit/phpunit=4.0.*”
$

これで ~/.composer に phpunit がインストールされる。
(この後直ぐにアンインストールしたけど)

この段階で “phpunit/phpunit=4.8.*” だと、依存関係を解決できなくて
実際にはインストールできない。

# PHP ビルドツール Phing をインストールする

~/.composer/composer.json を編集して、
phing だけ追加して composer.phar update してみると、
いろいろお勧めされる。

phing/phing suggests installing phpdocumentor/phpdocumentor (Documentation Generator for PHP)
phing/phing suggests installing sebastian/phpcpd (Copy/Paste Detector (CPD) for PHP code)
phing/phing suggests installing phpmd/phpmd (PHP version of PMD tool)
phing/phing suggests installing pdepend/pdepend (PHP version of JDepend)
phing/phing suggests installing phploc/phploc (A tool for quickly measuring the size of a PHP project)
phing/phing suggests installing phpunit/phpunit (The PHP Unit Testing Framework)
phing/phing suggests installing phpunit/php-code-coverage (Library that provides collection, processing, and rendering functionality for PHP code coverage information)
phing/phing suggests installing pear/versioncontrol_svn (A simple OO-style interface for Subversion, the free/open-source version control system)
phing/phing suggests installing pear/versioncontrol_git (A library that provides OO interface to handle Git repository)
phing/phing suggests installing pear/archive_tar (Tar file management class)
phing/phing suggests installing tedivm/jshrink (Javascript Minifier built in PHP)

ドキュメントにはSphinxを使うので phpDocumentor はイイかな。。。
いらない物もあるし、以下の様にして、再度 update。

{
“require-dev”: {
“phing/phing”: “*”,
“phpunit/phpunit”: “4.*”,
“squizlabs/php_codesniffer”: “*”,
“phploc/phploc”: “*”,
“pdepend/pdepend” : “*”,
“phpmd/phpmd” : “*”,
“sebastian/phpcpd”: “*”,
“theseer/phpdox”: “*”
}
}

これで実際にインストールされたのは以下のパッケージ達。

|———————————–+———+—————————————————————-|
| packeage | version | desc. |
|———————————–+———+—————————————————————-|
| doctrine/instantiator | 1.0.5 | A small, lightweight utility to instantiate objects in PHP … |
| nikic/php-parser | v1.3.0 | A PHP parser written in PHP |
| pdepend/pdepend | 2.1.0 | Official version of pdepend to be handled with Composer |
| phing/phing | 2.11.0 | PHing Is Not GNU make; it’s a PHP project build system or b… |
| phpdocumentor/reflection-docblock | 2.0.4 | |
| phploc/phploc | 2.1.4 | A tool for quickly measuring the size of a PHP project. |
| phpmd/phpmd | 2.2.3 | PHPMD is a spin-off project of PHP Depend and aims to be a … |
| phpspec/prophecy | v1.5.0 | Highly opinionated mocking framework for PHP 5.3+ |
| phpunit/php-code-coverage | 2.2.2 | Library that provides collection, processing, and rendering… |
| phpunit/php-file-iterator | 1.4.1 | FilterIterator implementation that filters files based on a… |
| phpunit/php-text-template | 1.2.1 | Simple template engine. |
| phpunit/php-timer | 1.0.7 | Utility class for timing |
| phpunit/php-token-stream | 1.4.6 | Wrapper around PHP’s tokenizer extension. |
| phpunit/phpunit | 4.8.5 | The PHP Unit Testing framework. |
| phpunit/phpunit-mock-objects | 2.3.7 | Mock Object library for PHPUnit |
| sebastian/comparator | 1.2.0 | Provides the functionality to compare PHP values for equality |
| sebastian/diff | 1.3.0 | Diff implementation |
| sebastian/environment | 1.3.2 | Provides functionality to handle HHVM/PHP environments |
| sebastian/exporter | 1.2.1 | Provides the functionality to export PHP variables for visu… |
| sebastian/finder-facade | 1.2.0 | FinderFacade is a convenience wrapper for Symfony’s Finder … |
| sebastian/git | 2.0.1 | Simple wrapper for Git |
| sebastian/global-state | 1.0.0 | Snapshotting of global state |
| sebastian/phpcpd | 2.0.2 | Copy/Paste Detector (CPD) for PHP code. |
| sebastian/recursion-context | 1.0.1 | Provides functionality to recursively process PHP variables |
| sebastian/version | 1.0.6 | Library that helps with managing the version number of Git-… |
| squizlabs/php_codesniffer | 2.3.3 | PHP_CodeSniffer tokenizes PHP, JavaScript and CSS files and… |
| symfony/config | v2.7.3 | Symfony Config Component |
| symfony/console | v2.7.3 | Symfony Console Component |
| symfony/dependency-injection | v2.7.3 | Symfony DependencyInjection Component |
| symfony/filesystem | v2.7.3 | Symfony Filesystem Component |
| symfony/finder | v2.7.3 | Symfony Finder Component |
| symfony/yaml | v2.7.3 | Symfony Yaml Component |
| theseer/directoryscanner | 1.3.1 | A recursive directory scanner and filter |
| theseer/fdomdocument | 1.6.1 | The classes contained within this repository extend the sta… |
| theseer/fxsl | 1.1.1 | An XSL wrapper / extension to the PHP 5.x XSLTProcessor wit… |
| theseer/phpdox | 0.8.1.1 | A fast Documentation generator for PHP Code using standard … |
|———————————–+———+—————————————————————-|

# コード品質を高める、おなじみっぽい名前のツール達
CppUnitが会社の規定に合わないので、xUnit系のテストを触るのは始めてだ。
他に C++でもお世話になった記憶のあるPMDの親戚達もインストールされた。

– PHPUnit: xUnitの親戚。PHPテストコードを実行する
– phpcs (php_codesniffer): コーディング規約チェック
– phpmd: 怪しい実装方法の箇所をチェック
– phpcpd: コードの重複をチェック

# Jenkinsプラグインのインストール
Jenkins のプラグインには、 PHP Plugin と Phing Plugin をインストール。
これだけで依存するパッケージが細々とインストールされる。

あれ? DRY plugin が選べなくななってる。
最近の Jenkins に対応していないらしい。

自動的にインストールされた “Duplicate Code Scanner Plug-in” って言うのが
代わりに使えそうなので、このまま進めよう。

# カバレッジツールが入ってない
PHPUnitからxdebugを呼び出して計測するつもりなのだけど、
xdebugが composerでインストールできていない。

[xdebug](http://xdebug.org/docs/install) を読むと、
自分でビルドする必要がありそう。

brewでも入れられるけど、PHPはせっかくcomposerで管理しているので、
混乱が無いようにしておきたい。

まだ使わないので、おいおいインストールすることにしよう。

#+BEGIN_COMMENT
/etc/php.d/xdebug.ini に以下の設定を追加。
zend_extension=/usr/lib64/php/modules/xdebug.so

http://www.spiceworks.co.jp/blog/?p=4188

http://qiita.com/khironori/items/c145d7e3eed7b2a5a01a
#+END_COMMENT

emacsのorg-mode で WordPress の記事を書きたい

org-mode で書いた記事を、そのまま WordPress に投稿したい。

方法は、大きく分けて二つある。

– org-mode で HTMLに変換してからコピペする
– org-mode の書式を解釈する WordPress のプラグインを新たに作る

org-mode側でHTMLに変換する方法は、
WordPressの記事一覧が酷い事になるのが目に見えている。

いつかは画像も自動で組込みたいし、
後者の、プラグインを新たに作るのが良さそう。

車輪の再発明ぽくてイヤだけど、自分で使う目的だし、
自由が効く方が良いか。

問題はむしろ、PHPの開発経験が全く無いこと。

orgのテーブルを変換するプラグインは小さかったので、
一旦pythonで書いてから、本番サーバ上でPHPに移植する
という、恐しい開発方法だったけど。

今回は、ちゃんとテスト環境をそろえて開発したい。

テーブルプラグインの開発では、
WP-MarkDown の不具合(バグの様な仕様)で、
保存する度に記事を壊されて無駄に時間がかかってしまった。

WP-MarkDown とはオサラバして、スッキリ開発したい。

で。

対応したいタグは、こんなもの。

– 段落タイトル 3段階
– 段落
– コード
– テーブル
– 引用
– 段落
– 強調/イタリック
– リンク
– リスト
– *インライン画像
– (入れ子リスト)
– (番号リスト)

これだけ変換するには、
テーブルプラグインの構造では間に合わないので、
きちんと文章を構文解析する必要がある。

それに、ちゃんとしたテスト環境を作ってから開発したいし
新調した MacBookPro に合わせて、CI環境を再構築しないと…

wordpressのプラグインを作ってみる org-modeのテーブルをそのまま使いたい!その2

org-modeで書いたテーブル

みたいなのを、
blogに書くときにプラグインでHTMLのtableに加工したい。

という訳でプラグインを自作したものの、
org-modeで書いたテーブルがあると
WP-MarkDownが書式を壊してしまって動かない。

プラグインの優先度を上げて先に編集すれば、
最初の編集ではどうにかなるけれど、
再編集ができない。(トホホ)

かと言って
WP-MarkDownを使わないのも不便だし
自分でMarkDown機能を実装するのも面倒臭い。

という訳で、
WP-MarkDownに対抗する暫定対応を加えた。

で、こんな感じに動作する。

ヘッダがある場合。

|——+——+————|
| 名前 | 価格 | 日付 |
|——+——+————|
| あれ | 100 | 2015/01/01 |
| これ | 1000 | 2015/02/01 |
| それ | 99 | 2015/03/01 |
|——+——+————|

ヘッダが無い場合。

|——–+——|
| あっち | 100 |
| そっち | 1000 |
| こっち | 99 |
|——–+——|

めんどいなぁ。

wordpressのプラグインを作ってみる org-modeのテーブルをそのまま使いたい!

org-modeで書いたテーブル

みたいなのを、
blogに書くときにプラグインでHTMLのtableに加工したい。

雰囲気、こんなので良いみたい。

これを /wp-content/plugins/ に置く。

ん?
こんなエラーが出たぞ。

あ〜
WordPressの画面からは、ちゃんとZIPに固めてからでないと
アップロードできないみたいだ。

しょうがないので、サーバーに直接アップロードしよう。

おー。 動いた動いた。

↓こんな感じになった。

|——+——+————|
| 名前 | 価格 | 日付 |
|——+——+————|
| あれ | 100 | 2015/01/01 |
| これ | 1000 | 2015/02/01 |
| それ | 99 | 2015/03/01 |
|——+——+————|

|——–+——|
| 場所 | 距離 |
|——–+——|
| あっち | 100 |
| そっち | 1000 |
| こっち | 99 |
| ?? | 99 |
|——–+——|

変換する関数自体は通勤時間の間に完成したのだけど、
なんか、いろいろ他のプラグインとかち合っていて、
サーバー上で動くまで半日かかってしまった。

スタイルは、他のプラグインに取られたままだし。

記事を編集し直そうとすると、 WP-MarkDown が元記事を壊しちゃうし。。。

案外簡単にプラグインをつくれることは分かったけど、
人に公開しようと思ったら、
そうとう検証に時間をかける必要がありそうだなぁ。これは