wordpress-4.0–jaとwp-emmet-0.2.6の組み合わせで、新規投稿（執筆）画面のツールバーがまったく表示されなくなる事象が発生したのでメモしておきます。ひとまず、fixされるまではEmmetを無効化して乗り過ごすことにします。
また、今回のプラグインを導入していない場合でも、執筆時に動作する他のプラグインを疑ってみたほうが良いかもしれません。
ツールバーが表示されない事象
Emmetを無効化すると表示される
それはそうと、Emmetが使用できないのはかなり痛い……（というか、ツールバーのほうがあんまり使わないし、非表示覚悟でEmmetを有効化したほうが個人的には良いかも。）
久しぶりにPHPを触ってみると、配列の扱いで「どうだっけ？」となった箇所が幾つかあったので、色々と実験をしてみました。メモしておきます。
foreachがある言語では、宗教的な理由により可能な限りforeachを使いたいものです。ところが、ループカウンタの出力が要件としてある場合はforを使うしか無い、ように見えますが、foreachでいけます。（ただし、後で触れますが落とし穴があります。）
<pre><?php
$as = array(
"data0"
, "data1"
, "data2"
, "data3"
, "data0"
);
foreach($as as $key => $a) {
echo "id:" . $key . " value:" . $a . "\n";
}
// これでいけるし当然か……
echo $as[0] . "\n";
echo $as[1] . "\n";
echo $as[2] . "\n";
echo $as[3] . "\n";
echo $as[4] . "\n";
id:0 value:data0 id:1 value:data1 id:2 value:data2 id:3 value:data3 id:4 value:data0 data0 data1 data2 data3 data0
配列から要素を削除する場合はunsetを使用します。すると、キーごと削除されてしまうようなのです。上記foreachを使用する場合は気をつけておかなければ足元を掬われそうです。
forのcount($as)で3が取得されるため、id:2までしかループしないうえ、UndefinedのNoticeが出てしまいます。
<pre><?php
$as = array(
"data0"
, "data1"
, "data2"
, "data3"
, "data0"
);
$delkeys = array(0, 2);
foreach($delkeys as $delkey) {
unset($as[$delkey]);
}
var_dump($as);
for($i = 0; $i < count($as); $i++) {
echo $i . " : " . $as[$i] . "\n";
}
array(3) {
[1]=>
string(5) "data1"
[3]=>
string(5) "data3"
[4]=>
string(5) "data0"
}
Notice: Undefined offset: 0 in D:\xampp\htdocs\sample\unset_sample.php on line 20
0 :
1 : data1
Notice: Undefined offset: 2 in D:\xampp\htdocs\sample\unset_sample.php on line 20
2 :
キーを削除しない（イメージとしては、削除された要素分、キーを詰めて再設定？）ようにするためには下記の方法を使えば良いようです。
<pre><?php
$as = array(
"data0"
, "data1"
, "data2"
, "data3"
, "data0"
);
array_splice($as, 1, 1);
var_dump($as);
array(4) {
[0]=>
string(5) "data0"
[1]=>
string(5) "data2"
[2]=>
string(5) "data3"
[3]=>
string(5) "data0"
}
今回はあくまで実験だったため以上の書き方としましたが、キーに意味がある要件の場合は、そもそもデータ構造を見なおしたほうが良さそうです。
思った以上にハマったのでメモしておきます。備忘録レベルです。
はじまりは、Webセキュリティを攻撃者の立場から勉強しようと思い、脆弱性の残されたWebアプリケーション（Webサーバ）をローカルでたてて実験しようと考えたことからでした。調べてみると、OWASP Broken Web Applicationsという、脆弱性の残されたWebサーバとWebアプリがVM仮想イメージで配布されていることを知りました。Windows8.1のホストOSから、VMWarePlayer6.0を使ってゲストOSとして呼び出す手順が妥当と判断しました。また、脆弱性診断のためローカルプロキシツールであるBurbSuite(FreeEdition)を使用することとしました。
VMwareWorkstation10はインストーラに内包されるネットワーク設定ツールを抽出するために必要のため、インストールする必要はありません。今回はなくてもいいですが、VMwareのネットワークをツールを使ってわかりやすく学びたければ、少し重いですがダウンロードしておきましょう。
PlayerシリーズにはVMwareのネットワーク設定ツールが含まれていないため、必要の場合は、Workstaionのインストーラに含まれるツールを抽出してやります。コマンドラインで同じフォルダに移動して、下記コマンドを実行します。
./VMware-workstation-full-10.0.1-1379776.exe -e work
後は、workフォルダにあるcore.cabを解凍して、下記ファイルを「C:\Program Files (x86)\VMware\VMware Player」に移動します。もうWorkstationは用済みのため削除していただいて構いません。
「コントロールパネル＞ネットワークの状態とタスクの表示＞アダプターの設定の変更」で下記画面を開くと、VMnet1とVMnet8ができています。
ネットワークアダプターの設定
VMwareではVMを起動するときにネットワークアダプタの設定をBridge/HostOnly/NATから選択できます。それぞれの違いは下記のとおりです。今回はNATを選びますがHostOnlyでも良いです。セキュリティ脆弱のあるアプリをあげるので、念のためBridgeはやらないほうが無難です。
ネットワークの接続形態を理解するために、ここの図が非常にわかりやすかったです。
| 設定 | 使用する仮想アダプタ | 用途 |
|---|---|---|
| Bridge | VMnet0 | ゲストOSをホストOSのつながるルータへ接続したい場合。（今回は非推奨。） |
| HostOnly | VMnet1 | ゲストOSとホストOSをHUB（L2SW）で接続したい場合。 |
| NAT | VMnet8 | ゲストOSとホストOSとNATルータ（L3SW）で接続したい場合。 |
仮想マシン設定の編集
NAT接続にした前提で話を進めます。ゲストOSからインターネットに接続するためには設定が必要となります。（まあ、やらなくてもいいですが。）設定のイメージについてはここの図が非常にわかりやすかったです。ちなみに、VMnet8をvmnetcfg.exeで見てみると下記の通り。DHCPサーバ機能も兼ねているので、DHCPの設定を見てみると.128からIPアドレスが配布されるように初期設定されていました。
仮想ネットワークエディタ
DHCP設定
Windows8.1側では、インターネット接続をしているアダプタの設定画面を開いて、インターネット接続をVMnet8と共有します。（こういう設定をICSと呼ぶらしいです。）
インターネット接続の共有
あとは、VMnet8アダプタのIPアドレス設定を確認します。（ゲストOSのeth0にVMnet8（DHCP）から配布されるIPアドレス/ネットマスクに従ったIPアドレスが設定されていれば問題ありません。）このあたりのイメージは先程も紹介したこちらの記事にある画像がわかりやすいですのでぜひ参照してください。ちなみに、DHCPでIPアドレスは.128から配布される設定となっているので.1固定にしておけばゲストOSとIPアドレスが被りません。
VMnet8のIPアドレスを確認
後は、VMwarePlayerでOWASP仮想イメージを実行するだけです。root/owaspbwaでログインできると思います。Windows8.1側とLinux側で相互にpingが通り、Linuxからgoogle.com（インターネット）にpingが通り、ホストOSのブラウザから「http://192.168.137.129/」（IPアドレスはifconfigで確認）につながれば設定完了です。長い道のりでした。
BurbSuiteの配置されたフォルダにコマンドラインで移動して、下記コマンドを実行します。パス等の関係なのか、バッチファイルではうまく行きませんでした。動かない場合は、きちんとコマンドラインでフォルダに移動してから実行してみてください。
java -jar burpsuite_free_v1.5.jar
Proxy>OptionsよりIP:Portを確認します。ループバックアドレスである「127.0.0.1:8080」で待ち受けていることを確認できました。（わざわざ確認するまでもないですが。）つまり、試験するブラウザにプロキシを設定します。
ループバックアドレスの確認
試験対象のページ以外へのアクセスはループさせたくありません。そういう、プロキシ適用有無のルールを記述する方法があります。下記ファイルをどこかに配置してください。
function FindProxyForURL(url, host)
{
if(isInNet(host, "192.168.137.0", "255.255.255.0")){
return "PROXY 127.0.0.1:8080";
}
else return "DIRECT";
}
Firefoxの場合は下記のように設定します。バックスラッシュとスラッシュ問題もあるようなのでいろいろ試してみてください。
プロキシの設定
試験ページ（http://192.168.137.129/）にアクセスした時はBurbSuiteがリクエストを捉えてくれて、それ以外のページにアクセスした時は素通りしてくれるようになることを確認して全ての工程が完了です。自分、お疲れ様でした。
できない！ つながらない！ というときはWindows側アダプタの停止→開始や、Linux側アダプタのdown→upを試してください。
ifconfig eth0 down ifconfig eth0 up
非常に多くのサイトを参考にしました。感謝。
XREA+(PLUS)/CORESERVERでWordPressのWPTouchプラグインを使用した時に出るエラー（ワーニング）メッセージの回避方法をメモしておきます。
WPTouchをインストール（wp-content/pluginsにput）して有効化後に、wordpressのコントロールパネルからWPTouchの設定画面を呼び出し、Core SettingsのSave Changeをしたとき、画面上部に下記ワーニングメッセージが出力される場合があります。中身を読んでみると、ディレクトリにアクセスできなくて怒られていることがわかります。
Warning: fopen() [function.fopen]: Unable to access /virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-131850.txt in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51 Warning: fopen(/virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-131850.txt) [function.fopen]: failed to open stream: No such file or directory in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51 Warning: fopen() [function.fopen]: Unable to access /virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-131850.txt in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51 Warning: fopen(/virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-131850.txt) [function.fopen]: failed to open stream: No such file or directory in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51
まずは、wp-contentsの権限を確認してください。777等で設定されている、かつ、wp-content/wptouch-dataが作成されている場合は問題ありません。当該ディレクトリ内に複数のディレクトリが作成されていることも併せて確認します。
一方、wp-contentが755で設定されている場合は、wp-content/wptouch-dataを手で作成して、777を与えてください。
ここで、再度wordpressのコントロールパネルからWPTouchの設定画面を呼び出します。すると、先ほど手で作成したwp-content/wptouch-data配下に複数のディレクトリが作成されます。ところが、これらのディレクトリは、所有者がapacheになっています。これは、XREA系列サーバでは回避しようがないようです。
※ モジュール版PHPから作成されたファイルの所有者は「apache」になります。これらのファイルの所有者を「*****」に、パーミッションを「707」に変更します。（XREAコントロールパネルより引用）
その場合は、下記ワーニングメッセージが出力されます。スクリプトと所有者の違うディレクトリが読めないと言っています。（適当）
Warning: fopen() [function.fopen]: SAFE MODE Restriction in effect. The script whose uid is 10852 is not allowed to access /virtual/*****/public_html/wp-content/wptouch-data/backups owned by uid 1000 in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51 Warning: fopen(/virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-141529.txt) [function.fopen]: failed to open stream: No such file or directory in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51 Warning: fopen() [function.fopen]: SAFE MODE Restriction in effect. The script whose uid is 10852 is not allowed to access /virtual/*****/public_html/wp-content/wptouch-data/backups owned by uid 1000 in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51 Warning: fopen(/virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-141529.txt) [function.fopen]: failed to open stream: No such file or directory in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51
この事象はXREAのコントロールパネルより、フォルダの所有者を変更することで解決することができます。コントロールパネルから「ツール」を選択し「ファイル所有者の変更」します。
これにて一旦落着。
XREA/Value-Domain（eNom）+DiCEでDDNSの設定をやってみました。ちょっとハマった（公式マニュアルに記載のない方法）ので、メモの意味を込めて書き記しておきます。
もちろん、あたり前のことながら、ドメイン名と括りつけたいIPアドレスを持つ端末（要はサーバにするPC）から一連のオペレーションを実施する必要があります。
随分前にハマった部分ですが、今回もやり方を忘れていたのでメモしておきます。
create table sample(
id int auto_increment primary key,
name text,
type enum('うぃんどうず', 'あいおーえす', 'けーしーぴー')
) default charset=utf8;
ちゃんと文字コード指定をしてやらないと、enumの中まで化けるので注意です。適当に試したい時の、便利な対症療法ですね。
Gmailの活用術です。
随分前の話になると思います。twitterのアプリ（俗に言うbot）は、dev.twitter.comに登録する段階で権限を付与してやる必要があります。その権限がいつの間にか変更されていました。結果、私の作成したbotが動いていなかったので、原因を調べました。そのノウハウです。
殆ど忘れてたので、OAuthの復習になりました。
極論としての「brタグ廃止」を訴えてみようかと思います。
phpでtwitterbotを作ってみる（作成）の続きです。phpスクリプトが作成できたと思うので、実際にxrea+で設置してみたいと思います。