CMS構築を目的にPHPをベースとしたWordPress、CakePHPやPEARなどオープンソースを中心に解説しています

WordPressの関数「wp_head」はデフォルトでさまざまなコードを出力します。
オリジナルでテンプレートを開発する場合に、このコードが邪魔になることがほとんどです。しかし、wp_head自信を削除してしまうと、プラグインなどが正常に動作しなくなる危険性があります。
なぜなら、wp_headやwp_footerがあることを前提に開発されているプラグインが多くあり、動作に必要なコードを出力しているからです。

そこで、今回はfunctions.phpにアクションフックを記述して、不要なコードの出力を省く方法を調査します。

実際に表示されるコードと削除方法

以下、各セクションにおいて、まずwp_headを読み込むとデフォルトで出力されるHTMLソースを提示します。
次に、そのソースを表示させないため、functions.phpに書き込むアクションフックを示します。

※順不同です。また、新しいバージョンでは表示されなくなっているものもあります。

レンタルサーバの「エックスサーバー(XSERVER)」でSSH接続し、FuelPHPのoilコマンドを実行する方法です。

ある日、エックスサーバー上でFuelPHPをベースとしたWebアプリを構築しようと思い、oilコマンドでmigrateを実行しようとしたらうまくいかずエラーになってしまいました。
その際に調べた解決方法をメモとして残しておきます。

エックスサーバーでoilコマンドを実行してエラー

まずは、Windowsからputtyを使ってエックスサーバーに接続し、phpコマンドを実行してみました。phpコマンドのパスは、オフィシャルのリファレンスより「/usr/bin/php5.6」とのこと。
プログラム言語・コマンドパス | レンタルサーバー【エックスサーバー】

$ /usr/bin/php5.6 -v
PHP 5.6.22 (cgi-fcgi) (built: Jun 22 2016 03:15:28)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

問題なく動作しているようです。

PHPの画像認証ライブラリにはいくつかありますが、今回はその中でも割とメジャーな「Securimage」の使い方を調べてみます。
Securimage PHP Captcha | Free Captcha Script

画像認証は、Web画面からログインしたり、新規情報登録をする場合に、パスワードなど文字による認証だけでなく、画像により認証するしくみです。
認証画面では悪意あるプログラムなどから、総当り的に認証を試みる攻撃を受けることがあります。具体的には、認証が通るまで機械的にパスワードを打ち続けるなどです。
これらの攻撃からサイトを守るために、動的に生成された画像からコードを読み取ったり、画像をドラック&ドロップで移動させたりといったしくみで、ワンランク上のセキュリティ対策を実現します。

「Securimage」は文字列を画像として自動生成するタイプの画像認証ライブラリで、その文字列を見て入力しないと認証をパスしないしくみを実現します。

導入方法

上の公式サイト、または、GitHubのサイトより、ソースをダウンロードします。現時点での最新のバージョンは3.6.4です。
GitHub – dapphp/securimage: PHP CAPTCHA Script

ソースを解答し、フォルダごとサーバにアップロードします。
ここでは「/secureimage/」にアップロードしたと仮定します。

次に、画像認証を利用したい画面に、以下のようにして画像を表示させます。

最近、まれに以下のようなPHPエラーに出くわします

Fatal error: Can't use method return value in write context in ... on line xxx

実際に該当する箇所のソースを確認してみると、どうやら関数「empty()」に原因があるようです。

if (!empty($command->getMessage())){
...

調べてみると、PHP 5.4以下では関数「empty()」や「isset()」は、引数には関数の戻り値ではなく変数を設定しなければいけないようです。

対策1:関数の戻り値に変数を割り当てる

PHP 5.4以下では、以下のように変数を割り当てることで、エラーを回避できます。

$message = $command->getMessage();
if (!empty($message)){
...

対策2:PHPのバージョンを5.5以上にする

この現象はPHP 5.4以下で発生するので、サーバ環境を5.5以上、5.6や7.xにアップグレードすることでエラーを回避できます。

最近このエラーを見かけるようになった理由として、
一部サーバ環境で5.6や7.xへのアップグレードが進む中、パッケージも環境が5.6以上などを奨励するように設計されています。
そんな中、やや古めの自社サーバやレンタルサーバの環境では5.4以下が残っているため、パッケージをインストールした際にPHPエラーが発生するようです。

PHPの関数「mail()」で添付ファイル付きのメールを送信する方法です。

今回、日本語対応を前提に、ラッパー関数である「mb_send_mail」を使います。

添付なしメールを送る場合

通常、添付なしでメッセージのみのメールを送る場合は、以下のように記述します。

$to = "【送信先メールアドレス】";
$subject = "【メールタイトル】";
$message = "【メール本文】";
$additional_headers = "【オプションでメールヘッダに文字列追加】";
mb_send_mail($to, $subject, $message, $additional_headers);

$additional_headersには、送信元メールアドレスなどをセットします。

$header = "From:【送信元メールアドレス】\n";

これにプログラム上で任意のファイルを添付するためには、$message部分と$additional_headers部分に以下のようなフォーマットで追記します。

巷では、少し前からWordPressのxmlrpc.phpへの攻撃というのが流行りだしたようです。
今回、私もその被害に合うことになり、経緯と対策をまとめておきたいと思います。

問題の発端

ある日突然、当ブログへのアクセスが悪くなりました。
ブラウザでアクセスしようとすると、8割ぐらいの頻度で503エラーになってしまいます。

503 Service Temporarily Unavailable

共有サーバで複数サイトを運用しているので、試しに他のサイトにアクセスしてみると同じ症状です。
ページのほとんど503エラーが返され、サイトにアクセスすることができません。

503エラーなので、サーバにアクセスが集中して高負荷状態になり、繋がりにくくなっていることが考えられます。

「爆発的に人気が急上昇したページでも?」と淡い思いを抱きながらも、アクセス解析サイトを確認してみました。
しかし、解析結果に特に目立った変化はありません。
それもそのはず、503はそもそもサイトにアクセスできていないエラーなので、Google Analyticsなどの解析結果には反映されません。

FuelPHPのmigration機能は、コマンドラインやプログラムから簡単にDBのテーブルを操作、管理できます。
ドキュメントは少なく、その概念を理解するのには少々苦労しますが、使いこなせば非常に便利です。

そこで、私がこれまでに実行したmigrateコマンドを、ここに随時、メモとして書き留めておきたいと思います。

migrateの実行

テーブルの追加、削除、カラム追加、削除や変更などの設定を、oilコマンドを使ってmigrationファイルを生成することができます。
例えばテーブル「sample」を作成する場合は、以下のコマンドを実行します。

php oil generate migrate sample (...カラムの設定などは略)

するとフォルダ「/fuel/app/migrations/」に「001_create_sample.php」というファイルが生成されます。
このファイルの中にはテーブルの定義が記述されており、以下のmigrateコマンドを実行することで、実際にDBに反映されます。

php oil refine migrate

generateコマンドを実装する度に「002_」、「003_」と連番でmigrationファイルが生成されていきます。
これはDBの状態をバージョン管理するためであり、以下のようにコマンドを実行することで、いつでもDBの状態を変更できます。

php oil refine migrate:current	(最新の状態にする)
php oil refine migrate:up	(バージョンを一つ新しくする)
php oil refine migrate:down	(バージョンを一つ古くする)
php oil refine migrate --version=10	(指定したバージョンに更新する)

つまり、migrationファイルを適切に管理することで、本番環境、ステージング環境や開発環境など各環境でDB設定を同期できます。

それでは、具体的にさまざまなDB操作に関するmigrateコマンドを記していきます。

FuelPHPはMVC(Model、View、Controller)フレームワークとして知られていますが、『ビューモデル(ViewModel)』というオプションが存在します。

その名の通り、ViewとModelの中間の担うクラスなのですが、今回はその利用方法を勉強したいと思います。
※実際のイメージではControllerとViewの間?

「ビューモデル」とは?

「ビューモデルとは?」ですが、
例えばMVCで構築する場合、任意のテーブルの情報を取得し画面に一覧として表示する処理を考えます。

Controller内でModelからデータを取り出し、HTMLコードで整形し、Viewに渡して表示させます。
それに対して以下のような意見が出ることがあるでしょう。
「HTMLの整形はビューでやるべきでコントローラの中でHTMLタグを扱うべきではない」

一方で、ModelのデータをViewに渡して、View内でループさせたり値のフォーマットを調整したりしてHTMLを整形させます。
そうすると以下のような意見もあります。
「View内では表示処理のみで、あれこれロジックを組むべきではない」

はたまたこんな事言う人も。
「Modelはそれ自身の役割があるからController内(またはView内)で呼び出すべきじゃない」

。。。決めの問題で、どっちでもいい気がします。

そんな時、そんな処理はViewModelに記述しましょう!

FuelPHPの機能を活用して、良い感じで他言語対応サイトを構築できないか、考えてみました。

そこで、クラスAgent、Cookie、Langを活用したサイト構築にトライしてみました。
今回は、日本語ユーザがブラウザでアクセスした際は日本語表示で、そうでない場合は英語表示でサイトを切り替えることを目指します。

言語ファイルの用意

まず、言語を切り替える文言について、言語ファイルを「/fuel/app/lang/」に用意します。
ファイル名は任意ですが、各言語はフォーマットを含めて統一させます。
例えば以下のファイルを用意します。

WordPress 4.4にアップデートしてから、記事に投稿した画像の出力まわりがおかしくなりました。
Firefoxでサイトを確認してみると、それまで画像が表示されていたところが表示されなくなっている。。。

ソースをチェックすると、画像メディアを追加してサムネイルを表示していた部分が以下のようになっていました。

<img src="/images/sample-300x250.jpg" alt="サンプル" width="300" height="250" class="size-medium wp-image-3114" srcset="/images/sample-300x250.jpg 300w, /images/sample.jpg 525w" sizes="(max-width: 300px) 100vw, 300px" />

「srcset」や「sizes」など見慣れない属性が追加されています。

どうやら、レスポンシブに対応するべく追加された新しい機能のようです。
ブラウザサイズに応じて画像を切り替えたり、Retinaディスプレイなど解像度の高いデバイスに対応したりと、
レスポンシブサイトにおいて、あらゆるデバイスに対して最適な画像を動的に出力してくれるようです。
つまり、画像が荒れたり、必要もないのに全てのサイズの画像を読み込んだりといったリスクを避けることができるようです。
※この技術の詳細についてはまた次回の宿題とします。。。

Monthly Archives

Search