ClassicPress で マルチサイトを立ち上げる

ちょっと時間が空いてしまいましたが、自宅サーバでClassicPressを立ち上げるプロジェクトの続きです。マルチサイト機能を使ってClassicPressを運用してみることにしますが、まずはローカルのMAMP Pro 環境でやって流れを掴んでみることにします。

今回はサブドメインでの運用を想定していて、大まかな流れは以下のようになります。

①名前解決で同じサーバに向ける
DNS周り、またはhosts で以下ドメインを1つのサーバに向けるよう設定します。
または、ワイルドカード DNS の設定をします。今回はローカルで以下のようにHOSTSをいじりました。
例:gpl.jp → 127.0.0.1
http://www.gpl.jp → 127.0.0.1
hoge.gpl.jp → 127.0.0.1
junkhack.gpl.jp → 127.0.0.1

②WEBの設定で、*.gpl.jp を同じWEBROOTを見に行くよう設定

③WEBROOTにClassicPressを展開
→wp-config.php のDB設定
DBはもう作ってあるものとします。

④WEBアクセスしてClassicPressをインストール
→ 普通にウィザードに沿ってインストールするだけです。

⑤wp-config.php へ設定を記載
define(‘WP_ALLOW_MULTISITE’, true);

⑥管理画面へログインし、サイトネットワークの設定 へ
→ サブドメイン型でインストール

⑦インストール完了すると以下のように指示が出てきます。
wp-config.php と .htaccessへ指示通りに記載

————- wp-config.php

define(‘MULTISITE’, true);
define(‘SUBDOMAIN_INSTALL’, true);
define(‘DOMAIN_CURRENT_SITE’, ‘gpl.jp’);
define(‘PATH_CURRENT_SITE’, ‘/’);
define(‘SITE_ID_CURRENT_SITE’, 1);
define(‘BLOG_ID_CURRENT_SITE’, 1);

————- .htaccess

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

⑧再度、ログオフ、ログインしてサイトネットワーク管理の管理画面にアクセス
→ 設定>サイトネットワークの設定 から各種設定
→ 管理メニューを有効化(プラグイン)

以上で、OK。新規サイトを追加する場合は以下。

①サイトネットワーク管理 から追加
サイト>新規追加サイトを追加_‹_サイトネットワーク管理__GPLJPオフィシャルサイト_—_ClassicPress.png

以上で、複数のClassicPressサイトが出来上がり。基本WordPressと同じですね。

マルチサイトの運用はいろいろ勘所がいると思いますので不定期に何か気がついたら書いていくことにします。管理系のプラグインは便利そうなのが出ているので何か見繕って使っていくと思います。

https://ja.wordpress.org/plugins/search/Multisite/

次回は、とりあえずローカルのMAMP環境で以下をやってみたいと思います。

・MAMP Pro 環境でLet’s Encryt のワイルドカードSSLを設定

うまくできるかな?

 

AdSense を設定してみるがサブドメインあかんみたい?

さて、最近このサイトを自宅サーバに引っ越すためあれこれ準備をしています。

自宅サーバになったら、AdSense もやってみたいなと思って登録しようと思いました。

Google AdSense
https://www.google.com/adsense/

が、登録中、以下のようになります。

Google AdSense

マニュアルによれば、サイトの追加からできるようですが、これをやるにはまずメインのドメインを追加して認証させないとだめみたいです。

サイトリストでサブドメインを追加または削除する
https://support.google.com/adsense/answer/9130110?hl=ja

メインのドメインっていうと、gpl.jp や http://www.gpl.jp というものですがこれはとりあえず運用していません。しかし、とりあえずサイトを起動させておかないと許可が降りないのかな? ま、そういうのはやってみればわかりますね。やってみましょう!

次のステップでは、マルチサイト機能を使ってメインドメインを動作させてみようと思います。ClassicPress でもできるはずですので動作確認も兼ねてみましょう。あと、ローカルの MAMP Pro 環境で Let’s Encrytの SSL をワイルドカードで出来るかやってみようと思います。

・ClassicPress で マルチサイトを立ち上げる

・MAMP Pro 環境でLet’s Encryt のワイルドカードSSLを設定

とりあえず、このようなネタをあげる予定です。

 

高速化その3:画像圧縮してみた!次世代画像フォーマット「WebP(ウェッピー)」を使う

以前、スマホからのアクセスをもっと速くしたいなと思っていたのですが、高速化その3で手をつけることにしました!
まず、手をつける前の状態は以下です。

E383a2e3838fe38299e382a4e383abe382b5e382a4e38388e381aee9809fe5baa6e38292e6af94e8bc83e38197e381bee38197e38287e38186

はい、2.2秒かかっていたようです。レポートには、いろいろ書いてありますが画像の項目は以下のようにアドバイスされていました。

次世代フォーマットで画像を配信する
JPEG 2000、JPEG XR、WebP で画像をエンコードすると、読み込み時間が短くなり、モバ
イル通信のデータ量も少なくすることができます。フォールバック用に PNG 画像や JPEG 画
像も用意し、未対応ブラウザにはそちらを配信するようにしましょう。

ということで、WebP に変換することことにしました。変換には方向性として2つあり、1つはクラウドサービスでWebPに変換してもらうのを利用する方法。もう1つは、自サーバの機能を使ってWebP に変換する方法です。後者は、PHPがimagemagic をサポートしていてそのフォーマットにWebP がある場合に有効です。

phpinfo.phpにアクセス → サーバー設定のレポートを見る。
「imagick」項目の “ImageMagick supported formats” という行に「webp」があればサポートしています。

現在はまだテストサーバで mamp でやっていますので、これはサポートしていないことがわかりました。自分でサーバを作るときは対応させる予定ですが、今のところは外部クラウドのWEBサービスを使って高速化がどのくらい進むか確認してみようと思います。

パッと思いつくのは、https://tinypng.com/ のサービスです。

TinyPNG Compress PNG images while preserving transparency

これをWordPress(ClassicPressでも利用可)で利用するPlugin があるので使うことにします。

Compress JPEG & PNG images
https://ja.wordpress.org/plugins/tiny-compress-images/

Plugin を有効にして、API をゲット(月に500まで利用可)です。メディア設定の自動リサイズを無効にして、medium_large_size_h のパラメータも以下から0 にしておきます。

https://yourdomain/wp-admin/options.php

設定は以下のようにしておきました。

高速化 アリエクでポチった JunkHack と Compress JPEG PNG images アリエクでポチったJunkHack ClassicPress

どのくらい高速化が進んだか確認してみましょう!

モバイルサイトの速度を比較しましょう

結果、1.7秒です。0.5秒改善しましたね!

あとついでなので、Autoptimize プラグンで JS と CSS の最適化をしておきました。これは有名なんで説明は省略。

Autoptimize
https://ja.wordpress.org/plugins/autoptimize/

結果、高速化その3では最終的に、1.2 秒にまで改善できました。

モバイルサイトの速度を比較しましょう

あと、0.3秒ほど頑張れば1秒以下になって「速い」の部類に入るかと! あとはサーバ側でがんばりましょうか。

・・・高速化その4 に続く

高速化その2:ClassicPress を入れてテーマを調整

宅内サーバのテスト環境で、テーマの調整とClassicPress を試しにインストールしてみました。Classicpress logo wordmark gradient on transparent

enひかりの IPv6 トンネルもかなり有効だと思いますが、なかなか良いスコアが出たので記録しておきます。ちにみに、純粋なClassicPress にした速度向上というのはわずかです。テーマの部分が大きいかなという印象です。

PageSpeed Insights

Google の PageSpeed Insights の結果です。ずっと99% であと1% が上がらなかったのですが、画像の遅延読み込み(※1)を行なったら100% になりました。現在のWordPress.com 上にあるデータと変わりないのに、テーマとかWordPress 本体を ClassicPress にして enひかりの v6ひかり+固定IPの環境にしただけです。 1秒未満なので、とりあえずは十分な結果がPCは出ていますね。ちなみに、開発環境は以下の通り。

WEB:NGINX1.13.2(MAMP Pro)
PHP:php7.4.1(MAMP Pro)
DB:MySQL 5.7.26(MAMP Pro)

Server CPU:AMD Ryzen 5 3600
RAM:32GB
DISK:SSD

CMS:ClassicPress 1.1.2
テーマ:Sustyバージョン: 1.0.0
WP Plugin:
 Akismet Anti-Spam 4.1.4
 AMP 1.4.4
 Broken Link Checker 1.11.11
 Catch Infinite Scroll 1.7
 Lazy Load 0.6.1
 Switch to ClassicPress 1.2.0
 WordPress インポートツール 0.7
 WP Super Cache 1.7.1

 ※1・・・画像の遅延読み込みとは、ブラウザが最初に「スクロールせずに見える」ページの画像のみを表示し、スクロールしたときに画像を読み込むということです。これらを簡単に実現するため、Lazy Loadを使っていますがやり方はいろいろあるようです。

モバイル環境については、まだ向上の余地がありそうです。JS の調整がまだ残っています。

PageSpeed Insights

ClassicPress は、wordpress5.3.2 から switch-to-classicpress プラグインを入れて行いましたがなんのトラブルもなくできました。ClassicPress にして明確になったのが、jetpackプラグインはない方が絶対的に速いです。また、ストレージ容量が ClassicPress は20MB くらい減りファイル数も300くらい減りました。

今の所、可もなく不可もなくといったところでしょうか? しかし、良いなと思うのは ClassicPressバージョン1.xは、長期サポート(LTS)バージョンということで安定して動作してくれそうな気がします。プラグインも同じようにインストールすることができて、動作するものは「Compatible with your version of ClassicPress」と表示されますので目安になりますね。

プラグインを追加 アリエクでポチったJunkHack ClassicPress

というわけで、方針としては ClassicPress を使っていくことにしました。そして、jetpackプラグインはもう使わないことにします。テーマは、Sustyをカスタマイズして使うことにします。