SEO対策とセキュリティで企業をバックアップします。

インターネット上のアクセスボリュームUPをお約束します。

自動AMP(Accelerated Mobile Pages)化の障害回避 WORDPRESSでAMP表示を最適化する。

自動AMP(Accelerated Mobile Pages)化の障害回避 WORDPRESSでAMP表示を最適化する。


AMPを使うためにWORDPRESSのAMPプラグインを使う方は多いのではないかと思います。その際に発生する問題はAMPプラグイン自体が万能ではないので元のページを完全にAMPできないケースが多いのです。今回はそれを回避するための方法をお話したいと思います。

AMPのプラグインはどのような処理を行っているか理解する

AMPページはAMP htmlという書式があり、一部HTMLと互換性のタグとオリジナルのタグがあります。AMPページは元のソースHTMLを見てコードの変換を行います。必要に応じてAMPプラグインはコード変換だけではなくサポートされていないタグであれば除去を行います。amp htmlではjavascriptは極めて利用範囲が制限されているため、javascrptがエラーになるケースが多いです。このjavascript絡みのエラーがWPで利用しているプラグインがエラー発生の起因となっているケースが多いのです。

どうやってAMPエラーを抑え込むか

WORDPRESSの中では投稿ページ、カスタム投稿ページ、固定ページ、カテゴリーページ、Authorページ、管理画面などページの種類が複数あって、AMPプラグインの多くはこの種類でざっくりとAMP化するか、しないかの範囲を決めているケースが多いです。AMPは投稿とカスタム投稿、主要固定ページに絞った方が良い結果になります。それ故、WPで使うプラグインで影響を及ぼすプラグインがどの類のページの場合にアンロードされていたほうが良いか考えてゆくと設定を制御する範囲が小さくなり効果的に抑え込めるようになります。WPではプラグインのロード・アンロードの関数が用意されていますので、それをページの種類やURLに合わせてロード・アンロードを行うことができます。若干、関数で指定するプラグイン名称が何を指定したらよいか分かりづらいという問題はあります。

WORDPRESSでプラグインのロード/アンロードの制御はどうやるのが一番簡単?

ページ単位でも投稿、固定などの種類も単純にis_xxxxxなどの関数で判定しロード/アンロードできますが本当に面倒くさい。でもそれを簡単にやってくれるプラグインソフトがあります。「Plugin Load Filter」です。下記のような画面で画面の種類(URLフィルターとPost typeフィルター)とプラグインの種類に応じてON/OFFのコントロールができます。

当サイトのケースではCrayon Syntaxのプラグインが一番AMP化の際に大きな障害になっていましたが、このプラグインを使ったことでAMP化でエラーがゼロになりました。非常に便利プラグインです。赤いアイコンのプラグはOFFの意味になります。

AMP Validator(Chrome 拡張機能)でエラー検証&デバッグ修正

AMPのエラーチェックやSyntaxの検証はChrome 拡張機能を使用すると便利です。Google Search Consoleの中でも検証できますが、ブラウザにコンテンツがある状態で検証したほうがわかりやすいので、私はこれを基本に修正作業を行っています。

AMP Validatorの拡張機能はここで入手

タグ: , , , , ,

WORDPRESSを使う場合のよくあるマルチWP構成をnginxで対応するには


nginxでWORDPRESSを単体で使う際の設定はネットを探せば沢山あるが、巷でよくあるのが1つのサイトに複数のWORDPRESSをサブフォルダーにインストールしているケース。このパターンの設定事例は少ない。通常Apacheで使う場合は本体の設定を行えばサブフォルダーに設置したWPは特に特別な設定は不要だが、それ以外のWEBサーバではサブフォルダー毎に設定は必要です。また、最近のサイトは殆どがスマホ対応といえばレスポンシブでサイトを作っているが、未だにPCとスマホを分離して作っているケースも有る。大抵の場合はUser-agentで転送する方法を使っているが、ではnginxで使う場合はどう設定したらよいかわからない人も多いと思うので設定例を紹介したいと思う。もうちょっと見直せばよかったけど。。。若干冗長な設定もあるのですがご勘弁を。。。php-fpmの設定については今回省略しています。

フォルダー構成

nginx本体設定

/etc/nginx/nginx.confの編集です。

仮想サーバ本体設定WORDPRESS用

/etc/nginx/conf.d/fast.confの編集です。

/blogフォルダーにあるWORDPRESS用設定

/etc/nginx/conf.d/sub/blog.confの編集です。

/communityフォルダーにあるWORDPRESS用設定

/etc/nginx/conf.d/sub/community.confの編集です。

アクセス制御用の共通設定

/etc/nginx/conf.d/sub/common.confの編集です。

fastcgi用の共通設定

/etc/nginx/conf.d/sub/fastcgi.confの編集です。

タグ: , ,

DockerでWORDPRESSを導入する際のDataBaseバージョン(MySQL or Mariadb)要注意。


昨今、大人気のDockerですが、システムはもちろんのこと中でも教育用に使われる機会は多いのではないかと感じます。WORDPRESSやLinux、各種言語の環境を素早く整えるために便利だと感じます。

初心者だけではなく、ITの専門家でも幅広くやっている方と一つに特化してやっている方で別れると思います。特に言語系技術とサーバ系技術は一緒で考えがちですがスケールが大きくなってくるとサーバ技術をきちんと持っているかどうかの違いが生じてきます。

そんなとき言語系でやられている専門家の方はDockerを使うことでハードルがぐんと下がるのではないかと思います。

前フリは長くなってしまいましたが、インターネットの世界ではWORDPRESSやPHPといった環境は圧倒的にWEBアプリケーションの中では使用頻度が高いためDockerで使用する人も多いと思います。

ということで、実際にDockerでWORDPRESSを使って見ようと思いました。

※今回はMariadbでWORDPRESSを使用したため問題なくあっさりWORDPRESSのインストールができましたが、Mariadb/MySQLを使う場合はバージョンをLatestバージョンにしてしまうと間違いなくハマります。環境による違いもあるのでDBエラーコネクションが表示される場合は以下のMySQL5.7.xをオススメします。

この原因はMySQLのバージョンがLatestだとVersion 8になってしまいWORDPRESSとのインターフェイスが取れなくなってしまうからです。ネットでもかなりVersion 8を無意識にインストールして接続できない問題で苦しんでいる方が多いようでした。この理由はcaching_sha2_passwordがMySQL8のデフォルト認証プラグインに変更された事が原因です。 どうしても、MySQL8で対処したい方はmy.cnfでデフォルト認証プラグインを変更してDocker imageへコミットの上、再度コンテナ作成が必要です。

旧来の認証プラグインを使うように変更(変更後MySQL再起動が必要)



WORDPRESSで使う場合はMySQLのバージョンを5.7.xがよろしいと思います。下記のような感じで バージョン指定します。

【MySQLで接続する場合】

もし、様々な問題が生じたらやはりアプリ環境へログインして分析することが大切!

【デバッグは環境にログインしてアプリの設定を確認しよう】

タグ: , , , , ,

CentOS7/CentOS6 共通h2o HTTP/2対応Web サーバのインストール with WORDPRESSで動かしてみる。


h2oサーバの導入の動機

h2oを使ってみようと思った理由はHTTP/2.xで通信できることかな。最近のGoogle検索順位は早さも大切な評価ウェイトをしめているためサイトの速度アップは重要なことです。
このHTTP/2.xのプロトコルはHTTPS通信において表示速度を向上させ並列してリクエストを処理できるため、表示速度が向上します。
Nginxも早いのですが、H2OはそのNginxを凌ぐ早さで表示できるようです。通信スレッドはマルチプロセス・マルチスレッド方式です。CPUのコア数に合わせてnum-threadsを設定すれば良いようだ。

h2oのレポジドリーの追加

h2oのインストールはCentOS7/CentOS6で共通です。基本はyumのレポジトリーに以下の記述を追加し保存するだけでyum経由でレポジトリー からのインストールが可能になります。

h2oのインストールと起動

h2oを実際にyumを使ってインストールし、起動する手順になります。

ユーザh2oの作成とドキュメントルート作成&WORDPRESSの設置

SSL & WORDPRESSを動かす際のコンフィグレーション例(h2o.conf)

今回はSSLを使ってh2o環境でWORDPRESSを動かすケースのh2o.confを挙げてみたいと思います。
let’s encryptを使ってSSLライセンス取得し、実験してみました。Let’s Encrypt取得のやり方はここ
ドキュメントルートに/opt/html/content1として、実行ユーザはh2oユーザを新たに作り設定しています。
nginxにも似ている書き方にも感じますが、インデントで設定の範囲がきまるので注意しましょう。
尚、fastCGIをh2oは直接管理できるので通常行うようなfastCGIの設定は不要です。
SSL証明書の項目設定の中でCAファイル(認証局証明、中間証明等)を設定する箇所はありません。
従ってサーバ証明書とCAファイルはcatコマンドで結合を行ってください。結合後に結合ファイルの終点と開始点の間に改行が正しく入っていなかったらエラーになりますので必ず結合の後にチェックが必要です。
最初にサーバ証明書が来るようにするのがポイントです。尚、LetsEncryptの場合fullchain.pemが既に結合されたものです。

おまけ:ソースからのh2oコンパイル

CentOS6.10のデフォルトのgccバージョン(4.4.7)では宣言エラー(同じ関数名で異なるタイプ宣言)が出てしまいました。しかしHomebrewで導入しているgccのバージョン(5.5.0)では 問題なくコンパイルが完了しました。gccバージョン毎のプロトタイプ宣言の解釈と処理の違いがあるようです。尚centOS7,centOS8では簡単にコンパイルできます。ライブラリーが足りないと途中出てきますが2つほどマニュアルでライブラリー追加すれば問題ありません。Ubuntu系の最新バージョンではソースコード中のUINT_MAXをUINT8_MAXに置き換える作業がありましたがこちらもすんなりコンパイル出来ます。

タグ: , , , , , ,

最新WORDPRESSマルウェア感染事情


WORDPRESSのマルウェア感染は、年々酷くなっているように感じています。これは政府のセキュリティへの関心を促す動きとは逆行していますが事実です。セキュリティへの関心はサイトを運営する人にとっても、かなり意識の向上は感じるのですが結果を見ると芳しくない状況です。それはユーザのセキュリティソリューションへの過度な期待が裏側にあると思うのです。



WORDPRESSはホームページを作成する有益なCMSとして世界ナンバー1ですが、残念ながらプログラムにマルウェア感染したサイトもWORDPRESSが非常に多い。脆弱性対策を促進するためにWORDPRESSのバージョンをアップさせなさいと様々なネットや記事でも取りざたされているわりに一向に感染は減らない状況と言えます。



実はここにトリックがあるのです。厳密に言うとWORDPRESSのシステムの脆弱性というよりはプラグイン、テーマファイル、利用ユーザの使い方と環境に問題があるため感染しているケースが多いと思います。



まずユーザが認識を改めるべきは、プラグイン、テーマファイルはマルウェア、スパイウェアのバックドアの巣窟なのだということ。ユーザが自由にカスタマイズしてWORDPRESSのシステムが及ばない世界(認知しない)だから防ぎようがない範囲なのです。



多くの運営者はCMSの管理画面ログインの防御を真っ先に考えます。しかし昨今のマルウェア感染状況を見る限りでは管理画面ログインやフォルダーを固定IPでブロックしても改竄はなくなっていません。この理由は簡単でプラグイン、テーマファイル、アップロードフォルダーはセキュリティ制限が緩い状況にあるからです。認証が生じない、IP制限が及ばないとなると予め不正な事ができるプラグインやテーマファイルをユーザにインストールさせてしまえば、バックドアを仕掛けるのは簡単。



WORDPRESSの中には新規でプラグインやテーマを検索&インストールする機能がありますがそこに登録されているものはすべて安全と考えるのは早計です。公式サイトに登録時に厳しいいチェックが入っているわけではないので導入はユーザの自己責任となっています。



また、仮に登録時にマルウェアスキャンをかけても検知されないようなアプローチもあります。そのケースは不正コードを暗号化したり、コードをシュレッドして分散することで見つからないようにしています。結局不正コードをいつでもアップロード、あるいはイネーブルにして外部から操作できる仕組みを導入しているためドキュメントルート直下のファイルやWORDPRESSのシステムファイルも改竄きてしまいます。これらは固定IPブロックや管理者ログインを制限しても無駄なのです。



このケースでは、1サーバに複数のドメインサイトを保有している環境で試しにそのうちの1つの仮想サーバを停止して、停止したサイトのフォルダーが改竄されるか実験してもたことがあります。結果は仮想サーバを停止しても該当ドメインのフォルダー配下のファイルは改竄されました。もはやWEBの仕組みで改竄スクリプトを動かしているのではなくLinuxOSの仕組みで改竄を行ってることがわかります。こうなってくると他の感染源となっているドメインサイトをクリーニングしないと改竄は止まりません。



タグ: , , ,

1 2 3