WORDPRESS:タグのアーカイブ|ネットマーベラス(株)データアップロード詳しい開発実績など(非公開)....主要取引先(非公開)....お見積り出し(IP認証+Oauth)隠しノウハウ、隠し資料など(IP認証+Oauth)インターネット上のアクセスボリュームUPをお約束します。WORDPRESSでAMP表示を最適化する。WORDPRESSでAMP表示を最適化する。担当者AMPを使うためにWORDPRESSのAMPプラグインを使う方は多いのではないかと思います。その際に発生する問題はAMPプラグイン自体が万能ではないので元のページを完全にAMPできないケースが多いのです。今回はそれを回避するための方法をお話したいと思います。htmlという書式があり、一部HTMLと互換性のタグとオリジナルのタグがあります。AMPページは元のソースHTMLを見てコードの変換を行います。必要に応じてAMPプラグインはコード変換だけではなくサポートされていないタグであれば除去を行います。htmlではjavascriptは極めて利用範囲が制限されているため、javascrptがエラーになるケースが多いです。このjavascript絡みのエラーがWPで利用しているプラグインがエラー発生の起因となっているケースが多いのです。やってAMPエラーを抑え込むかWORDPRESSの中では投稿ページ、カスタム投稿ページ、固定ページ、カテゴリーページ、Authorページ、管理画面などページの種類が複数あって、AMPプラグインの多くはこの種類でざっくりとAMP化するか、しないかの範囲を決めているケースが多いです。AMPは投稿とカスタム投稿、主要固定ページに絞った方が良い結果になります。それ故、WPで使うプラグインで影響を及ぼすプラグインがどの類のページの場合にアンロードされていたほうが良いか考えてゆくと設定を制御する範囲が小さくなり効果的に抑え込めるようになります。WPではプラグインのロード・アンロードの関数が用意されていますので、それをページの種類やURLに合わせてロード・アンロードを行うことができます。若干、関数で指定するプラグイン名称が何を指定したらよいか分かりづらいという問題はあります。WORDPRESSでプラグインのロード/アンロードの制御はどうやるのが一番簡単?ページ単位でも投稿、固定などの種類も単純にis_xxxxxなどの関数で判定しロード/アンロードできますが本当に面倒くさい。それを簡単にやってくれるプラグインソフトがあります。typeフィルター)とプラグインの種類に応じてON/OFFのコントロールができます。Syntaxのプラグインが一番AMP化の際に大きな障害になっていましたが、このプラグインを使ったことでAMP化でエラーがゼロになりました。非常に便利プラグインです。赤いアイコンのプラグはOFFの意味になります。拡張機能を使用すると便利です。Consoleの中でも検証できますが、ブラウザにコンテンツがある状態で検証したほうがわかりやすいので、私はこれを基本に修正作業を行っています。担当者nginxでWORDPRESSを単体で使う際の設定はネットを探せば沢山あるが、巷でよくあるのが1つのサイトに複数のWORDPRESSをサブフォルダーにインストールしているケース。このパターンの設定事例は少ない。通常Apacheで使う場合は本体の設定を行えばサブフォルダーに設置したWPは特に特別な設定は不要だが、それ以外のWEBサーバではサブフォルダー毎に設定は必要です。最近のサイトは殆どがスマホ対応といえばレスポンシブでサイトを作っているが、未だにPCとスマホを分離して作っているケースも有る。場合はUser-agentで転送する方法を使っているが、ではnginxで使う場合はどう設定したらよいかわからない人も多いと思うので設定例を紹介したいと思う。見直せばよかったけど。若干冗長な設定もあるのですがご勘弁を。php-fpmの設定については今回省略しています。フォルダー構成nginx本体設定/etc/nginx/nginx.confの編集です。/etc/nginx/conf.d/*.conf;}仮想サーバ本体設定WORDPRESS用/etc/nginx/conf.d/fast.confの編集です。conf.d/sub/community.conf;}/blogフォルダーにあるWORDPRESS用設定/etc/nginx/conf.d/sub/blog.confの編集です。conf.d/sub/common.conf;}/communityフォルダーにあるWORDPRESS用設定/etc/nginx/conf.d/sub/community.confの編集です。conf.d/sub/common.conf;}アクセス制御用の共通設定/etc/nginx/conf.d/sub/common.confの編集です。conf.d/sub/fastcgi.conf;}fastcgi用の共通設定/etc/nginx/conf.d/sub/fastcgi.confの編集です。Mariadb)要注意。Dockerですが、システムはもちろんのこと中でも教育用に使われる機会は多いのではないかと感じます。WORDPRESSやLinux、各種言語の環境を素早く整えるために便利だと感じます。初心者だけではなく、ITの専門家でも幅広くやっている方と一つに特化してやっている方で別れると思います。言語系技術とサーバ系技術は一緒で考えがちですがスケールが大きくなってくるとサーバ技術をきちんと持っているかどうかの違いが生じてきます。そんなとき言語系でやられている専門家の方はDockerを使うことでハードルがぐんと下がるのではないかと思います。前フリは長くなってしまいましたが、インターネットの世界ではWORDPRESSやPHPといった環境は圧倒的にWEBアプリケーションの中では使用頻度が高いためDockerで使用する人も多いと思います。いうことで、実際にDockerでWORDPRESSを使って見ようと思いました。wordpress※今回はMariadbでWORDPRESSを使用したため問題なくあっさりWORDPRESSのインストールができましたが、Mariadb/MySQLを使う場合はバージョンをLatestバージョンにしてしまうと間違いなくハマります。環境による違いもあるのでDBエラーコネクションが表示される場合は以下のMySQL5.7.xをオススメします。8になってしまいWORDPRESSとのインターフェイスが取れなくなってしまうからです。8を無意識にインストールして接続できない問題で苦しんでいる方が多いようでした。この理由はcaching_sha2_passwordがMySQL8のデフォルト認証プラグインに変更された事が原因です。imageへコミットの上、再度コンテナ作成が必要です。default_authentication_plugin=mysql_native_password12[mysqld]default_authentication_plugin=mysql_native_passwordWORDPRESSで使う場合はMySQLのバージョンを5.7.xがよろしいと思います。バージョン指定します。該当アプリの環境(シェル)へ接続します。この例ではmariadbへ接続します。コンテナーIDをステータスから拾い接続します。該当アプリの環境(シェル)へ接続します。この例ではmariadbへ接続します。コンテナーIDをステータスから拾い接続します。WORDPRESSで動かしてみる。担当者h2oサーバの導入の動機h2oを使ってみようと思った理由はHTTP/2.xで通信できることかな。最近のGoogle検索順位は早さも大切な評価ウェイトをしめているためサイトの速度アップは重要なことです。このHTTP/2.xのプロトコルはHTTPS通信において表示速度を向上させ並列してリクエストを処理できるため、表示速度が向上します。Nginxも早いのですが、H2OはそのNginxを凌ぐ早さで表示できるようです。通信スレッドはマルチプロセス・マルチスレッド方式です。CPUのコア数に合わせてnum-threadsを設定すれば良いようだ。h2oのレポジドリーの追加h2oのインストールはCentOS7/CentOS6で共通です。インストールが可能になります。Fedora#baseurl=https://dl.bintray.com/tatsushid/h2o-rpm/fedora/$releasever/$basearch/gpgcheck=0repo_gpgcheck=0enabled=1h2oのインストールと起動h2oを実際にyumを使ってインストールし、起動する手順になります。WORDPRESSを動かす際のコンフィグレーション例(h2o.conf)今回はSSLを使ってh2o環境でWORDPRESSを動かすケースのh2o.confを挙げてみたいと思います。encryptを使ってSSLライセンス取得し、実験してみました。Encrypt取得のやり方はここドキュメントルートに/opt/html/content1として、実行ユーザはh2oユーザを新たに作り設定しています。nginxにも似ている書き方にも感じますが、インデントで設定の範囲がきまるので注意しましょう。fastCGIをh2oは直接管理できるので通常行うようなfastCGIの設定は不要です。)を設定する箇所はありません。従ってサーバ証明書とCAファイルはcatコマンドで結合を行ってください。結合後に結合ファイルの終点と開始点の間に改行が正しく入っていなかったらエラーになりますので必ず結合の後にチェックが必要です。最初にサーバ証明書が来るようにするのがポイントです。LetsEncryptの場合fullchain.pemが既に結合されたものです。10000おまけ:ソースからのh2oコンパイルCentOS6.10のデフォルトのgccバージョン(4.4.7)では宣言エラー(同じ関数名で異なるタイプ宣言)が出てしまいました。問題なくコンパイルが完了しました。gccバージョン毎のプロトタイプ宣言の解釈と処理の違いがあるようです。centOS7,centOS8では簡単にコンパイルできます。ライブラリーが足りないと途中出てきますが2つほどマニュアルでライブラリー追加すれば問題ありません。Ubuntu系の最新バージョンではソースコード中のUINT_MAXをUINT8_MAXに置き換える作業がありましたがこちらもすんなりコンパイル出来ます。カーネルの起動エントリーを減らし/bootの空き容量を確保。担当者WORDPRESSのマルウェア感染は、年々酷くなっているように感じています。これは政府のセキュリティへの関心を促す動きとは逆行していますが事実です。セキュリティへの関心はサイトを運営する人にとっても、かなり意識の向上は感じるのですが結果を見ると芳しくない状況です。それはユーザのセキュリティソリューションへの過度な期待が裏側にあると思うのです。WORDPRESSはホームページを作成する有益なCMSとして世界ナンバー1ですが、残念ながらプログラムにマルウェア感染したサイトもWORDPRESSが非常に多い。脆弱性対策を促進するためにWORDPRESSのバージョンをアップさせなさいと様々なネットや記事でも取りざたされているわりに一向に感染は減らない状況と言えます。実はここにトリックがあるのです。厳密に言うとWORDPRESSのシステムの脆弱性というよりはプラグイン、テーマファイル、利用ユーザの使い方と環境に問題があるため感染しているケースが多いと思います。ユーザが認識を改めるべきは、プラグイン、テーマファイルはマルウェア、スパイウェアのバックドアの巣窟なのだということ。ユーザが自由にカスタマイズしてWORDPRESSのシステムが及ばない世界(認知しない)だから防ぎようがない範囲なのです。多くの運営者はCMSの管理画面ログインの防御を真っ先に考えます。昨今のマルウェア感染状況を見る限りでは管理画面ログインやフォルダーを固定IPでブロックしても改竄はなくなっていません。この理由は簡単でプラグイン、テーマファイル、アップロードフォルダーはセキュリティ制限が緩い状況にあるからです。認証が生じない、IP制限が及ばないとなると予め不正な事ができるプラグインやテーマファイルをユーザにインストールさせてしまえば、バックドアを仕掛けるのは簡単。WORDPRESSの中には新規でプラグインやテーマを検索&インストールする機能がありますがそこに登録されているものはすべて安全と考えるのは早計です。公式サイトに登録時に厳しいいチェックが入っているわけではないので導入はユーザの自己責任となっています。仮に登録時にマルウェアスキャンをかけても検知されないようなアプローチもあります。そのケースは不正コードを暗号化したり、コードをシュレッドして分散することで見つからないようにしています。結局不正コードをいつでもアップロード、あるいはイネーブルにして外部から操作できる仕組みを導入しているためドキュメントルート直下のファイルやWORDPRESSのシステムファイルも改竄きてしまいます。これらは固定IPブロックや管理者ログインを制限しても無駄なのです。このケースでは、1サーバに複数のドメインサイトを保有している環境で試しにそのうちの1つの仮想サーバを停止して、停止したサイトのフォルダーが改竄されるか実験してもたことがあります。結果は仮想サーバを停止しても該当ドメインのフォルダー配下のファイルは改竄されました。WEBの仕組みで改竄スクリプトを動かしているのではなくLinuxOSの仕組みで改竄を行ってることがわかります。なってくると他の感染源となっているドメインサイトをクリーニングしないと改竄は止まりません。Updateが進まなくなった場合の対処や大型Update後のゴミ掃除。GZIP圧縮、コンパイルキャッシュ。viewsApacheにおけるSSL設定品質の肝。viewsApacheログからセキュリティアタックの解析をする。