WordPress Jetpack pluginを強制的に止める

非常に限定的な状況での話なのですが、とあるWordPressサーバで Jetpack プラグインが動作しなくなるということがあり相談を受けました。

動かないなら止めればいい、と思うのですが、Jetpackの管理画面も、プラグインの停止リンクも、真っ白やデザインの無いページに遷移してしまい、プラグインを止めることができません。

自分の管理下のサーバなら、直接サーバをいじればいいのですが、サーバーにログインする権限がなく、pluginフォルダを削除できません。(サーバに触れるなら、プラグインのファイルを消してしまえば終わりです) mysqlの直接アクセスも許されていないので、プラグインの利用フラグを直接オフにすることもできません。

WordPressの管理画面だけは管理権限があるので、これでなんとか止めよう、となると、管理画面からの「プラグイン」の「編集」しかありません。

jetpack/jetpack.php を単に止めただけでは、Jetpack の処理は起動しなくなりますが、Jetpack プラグインを停止・削除できないのは同じです。そこで、jetpack.php の冒頭にある要求WordPressのバージョン番号

define( ‘JETPACK__MINIMUM_WP_VERSION’, ‘4.5’ );

を、現在のWordPressバージョンより大きな数字、たとえば’10.0’とかに書き換えて保存することで、Jetpackのバージョンチェックが走り、プラグインは停止してくれました。

一旦停止状態になれば、管理画面から削除してしまうことも可能です。

globalとlocalのphpunitバージョンが違う時に出たエラー

phpunit の実行で以下のようなエラーメッセージが出た場合、


PHPUnit 4.5.1 by Sebastian Bergmann and contributors.

PHP Fatal error: Call to undefined method PHPUnit_Framework_TestResult::warningCount() in ~akky\AppData\Roaming\Composer\vendor\phpunit\phpunit\src\TextUI\ResultPrinter.php on line 185

Fatal error: Call to undefined method PHPUnit_Framework_TestResult::warningCount() in ~\akky\AppData\Roaming\Composer\vendor\phpunit\phpunit\src\TextUI\ResultPrinter.php on line 185

これは、composerで定義されたlocalにあるphpunit(./vendor/bin/phpunit)を呼ぶつもりで、globalにインストールされたphpunit(version 5.1.6)を呼んでいるために発生しているエラーのようです。

phpunitのバージョン表記が、なぜかlocal側の4.5.1で出てくるのでちょっと気づかなかったのですが、


$ ./vendor/bin/phpunit

とlocalのphpunitを呼ぶと、エラーは起こらなくなりました。

Laravelプロジェクトでも同様のエラーが報告されていました。globalのphpunitをuninstallすると解消した、というコメントもありますがつまりはそういうことでしょう。

composer.json で新しいphpunitが指定されていればこのトラブルは起こらないのでしょうけど、phpunitを更新するとテストが動かなくなる、ということもあるので、他のプロジェクトを持ってきてテストするとこういうことも起こるでしょう。

PHPUnit-skelgenでnamespaceを使ったクラスのstaticメソッドに対する生成コードがnamespaceエラーになる件

PHPUnit3.7.13で、Skelton Generatorユーティリティーを使ってannotationからのテストコード生成をしたら、なぜか実行時にエラーになってはまったので記録。

ここで指摘されてるんですがOpenのままですね。

phpunit-skelgenを使いたいのでstatic関数を使わない、となると本末転倒なので、pearで入れた(最近はComposerでも入るらしい。試してない)コードに手動でパッチをあてて解決。

SebastianBergmann\PHPUnit\SkeletonGenerator\Test.php
line. 299
// 'className' => $this->inClassName['fullyQualifiedClassName'],
'className' => $this->inClassName['className'],

line 324
// 'className' => $this->inClassName['fullyQualifiedClassName'],
'className' => $this->inClassName['className'],

[追記 2016-03-09] PHPUnit 5.1.7 になってもこの問題は解消していません。若干行番号がずれてますが同じ修正で対処できます。

しかし、Packagistのphpunit/phpunit-skeleton-generatorが、abandond となっています。もうスケルトンジェネレーターはやる気がないんでしょうか…

symfony1.x+propel1.3+MySQL5.1/5.5で生成したSQLのCreate TableがType=InnoDBで失敗する場合の対処法

サーバーをMySQL5.0から5.5に変えたら、symfony1.2+propelでbuild:allした際に生成されたSQLがエラーで動かなくなりました。

このようなエラー

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘Type=InnoDB’ at line 13

MySQL5.1以降で、テーブルのエンジン指定でtype=が使えなくなり、engine=と書かなければいけなくなったようです(table_optionのところ)。propel1.4以前のジェネレーターでは”type=InnoDB”のようなSQL文を生成しているので、古いpropelを使っているsymfony1.xではMySQLを5.1以上に変更した際にテーブルが生成できなくなってしまいます。

symfony1.2がpropel1.3-devを更新することはなさそうなので、これを回避するには、自分でpropelにパッチをあてることになります。

(symfony)/lib/plugins/sfPropelPlugin/lib/vendor/propel-generator/classes/propel/engine/builder/sql/mysql/MysqlDDLBuilder.php

163行目の

$script .= “Type=$mysqlTableType”;

を、

$script .= “Engine=$mysqlTableType”;

に修正。

Windows版MongoDBの設定ファイル指定と、Web UI無効化

mongodはデフォルトで、port 28017 にアクセスすることでブラウザから動作をモニターできる、というのをSymfony2勉強会で教えてもらいました。

このHTTPインタフェースは、/etc/mongodb.conf に

nohttpinterface = true

のように設定することで止められます。(設定できる項目についてはここ)

しかし、Windowsの場合は? mongodb.conf をmongod.exe と同じ場所においてみましたが、別に読み込んでくれません。


> mongod --config mongodb.conf

と明にファイルを指定することはできましたが、デフォルトのconfファイルの場所というのがあるかはわかりませんでした。

また、このWeb UIからRESTで格納されたデータを参照するためには、


> mongod --rest

のオプションをつけて起動する必要がありました。(デフォルトでオフ)