Wordpress5.6 Classicエディタでプレビューできない問題の原因は非推奨でした。このツールでわかりましたよ

Wordpress 5.x系のサイトを複数運営している中で、あるサイトだけ投稿、固定ページの記事内容を変更し、「プレビュー」ボタンで確認しても、変更前の内容がプレビューされる問題に悩まされていました。新規投稿時はちゃんとプレビュー効きます。一旦投稿してしまうとプレビューできなくなっています。

ぐぐるとこういう問題の場合、「プラグインを全部無効にして、検証すれば特定できる」というような内容ばかりで、運営中のサイトにダメージを与えそうで実施できずに対応を引き伸ばしていました。

Webサーバーで動くPHPのバージョンは自動的にバージョンアップするようにしています(なっていました)。そのため問題のあったサイトはPHP7.4で動いています(この記事書いている時点です)。

原因は「非推奨」でした。


結果的にwordpressの問題ではなく、プラグイン、テーマで使われているPHP関数が原因でした。
具体的には「create_function」、「allow_url_include」この2つがPHPの非推奨項目でした。

create_functionはPHP7.2で非推奨になりました(create_functionはphpの関数です)。
allow_url_includeはPHP 7.4で非推奨になっていました(この項目はphp.iniの設定値です)。

古いプラグインをバージョンアップも特に通知がないので長く使っています。こういった更新の滞っているプラグインやテーマはこの非推奨にぶち当たりやすいですね。

非推奨になっていてもワードプレスの管理画面や表示画面は通常です。一切異常は見当たりません。Gutenbergエディタではプレビューも普通に動いていました。

問題は局所的に現れるんですね。

この2つの非推奨を除去(ソースコードの修正、php.iniの修正)したところ、「プレビュー」が機能しました。


「Query Monitor」プラグインが教えてくれました


Query Monitor

このプラグインを有効にしたところ、「非推奨」の項目を利用中ってことが分りました。


格安(千円未満)のSSDプランがあるVPS一覧とプラン【さくらVPS・ConoHa VPS・mixhost VPS】比較

SSDを採用しているVPSを契約しようと検討しています。その最中に集めている情報をまとめています。ここでは2020年7月時点のSSDを採用した国内VPSの一覧がわかります。利用予定のOSはUnixであれば何でもいいと考えているのでWindowsサーバー対応の有無は詳しく調べていません。Windows Serverが使えるVPSはこちらにまとめています。



【続きはこちら】
posted by scripts at 15:26 | Comment(0) | TrackBack(0) | VPS

wordpress 迷惑なアクセスを除去している方法

レンタルサーバーでWordpressのサイトを運営していると500エラーの頻度が多いことに気がつきます。
そんなにたくさんのアクセスがあって嬉しい!って思っていたんですが、ログを工夫して見てみたら上位アクセスの多くはbotだったり、amazonawsだったりと普通にアクセスしてくれるユーザーではなさそうで、ガッカリ。

リソースを増量したり、もっとアクセス過多に対応できるサーバーへ以降すべき?って思っていたこともありましたが全くの無駄ってことに気づきました。


サイトを運営する目的を考えると集客してくれる検索サイト(GoogleやBingなど)のアクセスは歓迎したいです。誰かがSNS上で紹介した結果エビデンスを調べるために訪れる「Facebot Twitterbot/1.0」や「Linespider/1.1」なども嬉しいアクセスだと思っています。

一方、集客に貢献してくれるわけでも無いbot(例えば「SemrushBot」、「360Spider」、「MauiBot」)は、レンタルサーバーのリソースを食いつぶす厄介なアクセスです。

またアクセスログファイルに記録されたIPアドレスからドメインを逆引き(nslookupやdigコマンド)してみると、amazonawsやロシア、ウクライナ、イギリス、ポーランドなど迷惑アクセスで有名なドメインやIPアドレスだったりとがっかりする内容でした。

こういった迷惑なアクセスを除去すると、500円〜の低価格なレンタルサーバーでもそこそこ稼げる環境へと導けることとができます。
低価格レンタルサーバーのワードプレス運営で気をつけているポイント
  • 【ポイント1】公式からダウンロードできるプラグインは極力インストールしない、必要最低限にしています。

    HTMLファイルで作られたサイトにアクセスした場合、ほぼサーバーのスペックで応答できます。
    ワードプレスはPHPプログラムです。そのためメモリ上(またはスワップファイル)にプログラムがコンパイルされ、MySQLから必要な情報を取得し、HTML整形して応答しています。多少なりともサーバーへ負荷を与えます



  • 【ポイント2】 サイトを立ち上げ、ワードプレスをインストール、テーマを決定した段階で「PageSpeed Insights - Google Developers」のスコア100を目指しています。

    運営中には、影響を与えてしまうかもしれないので消極的な手段を選びがちです。そのため、初期の段階でガッツリ対策しています。

    指摘の中で、サーバーの応答時間はサーバー変えるしか無いので無視しています。

    キャッシュ系のプラグインは記事内容をほとんど変えない場合絶大な効果があります。

    テーマ自体もPHPプログラムです。凝ったテーマはそれだけでスコアを悪くすることもあるので、なるべくシンプルなテーマに切り替えるようにしています。

    スコア90以上、可能なら100を目指しています。



  • 【ポイント3】 ワードプレスが動いたリアルタイムなアクセスログを収集する

    サーバーの負担を上げるワードプレスが動作するアクセスが異常に多くなっていないか?が知りたいと思っています。


    ほとんどのレンタルサーバーでアクセスログ、エラーログを提供しているかと思います。ログ(nginxやApacheのログ)は記事へのアクセスの他、画像ファイルへのアクセス、ファビコンへのアクセス、ワードプレスの特定の脆弱性を狙ったアクセスなどが記録されています。

    このログからは、記事に関するアクセス以外はワードプレスが動作しません。

    そのため、ワードプレスが動作したときだけ別のログファイルに記録する方法を採用しています。


  • 【ポイント4】 収集したログから異常なアクセスをあぶり出し、拒絶などの対策をします。

    一般ユーザーアクセスなのか、または迷惑なアクセスなのかを見極めて、迷惑なアクセスは極力除外するようにしています。

    除外は、.htaccessファイルで制御しています。
    Deny from IPアドレス・ドメイン で拒絶、
    SetEnvIf User-Agentでユーザーエージェント指定で拒絶、
    などです。

    こうすることで極力サイトを快適にして、アクセスしてくれた一般ユーザーの方が素早く表示できるいいサイトになるよう心がけています。



ワードプレスが動いたログを記録する


ワードプレスが動作した際、ログを記録するプラグインを自作し、有効化します。
ソースコードのファイル名、クラス名はかぶらない名前で適時変更してください。

またソースコード中、フルパスでログを格納するフォルダ(ディレクトリ)を指定しています。レンタルサーバーのディレクトリ構成がよくわからないって方は調べてみてください。
<?php
/*
Plugin Name: WordPress ログ記録
Plugin URI: http://サイトのURL/
Description: WordPress ログ記録
Author: scripts
Version: 1.0
Author URI:http://fanblogs.jp/scripts/
*/
class accesslog_74bee6e126ef2866d0d6ebaf38734088{
static $instance = null;
static public function getInstance(){
accesslog_74bee6e126ef2866d0d6ebaf38734088::$instance = new accesslog_74bee6e126ef2866d0d6ebaf38734088();
}
public $start = 0;
public $starttime = 0;
public $lapse = 0;
function __construct(){
$this->starttime = time()+ 9*60*60;// +9時間
$this->start = array_sum( explode(' ', microtime() ));
add_action('shutdown', array($this, 'logger'));
}
function __destruct(){
$logfile = "/フルパス/wp_access_log";
// $logfile = __DIR__ . "/../../wp_access_log"; // 相対パス ワードプレス直下

if( @file_exists($logfile) ){
$mtime = filemtime($logfile) + 9*60*60;
if( date('Ymd',$mtime) == date('Ymd', time() + 9*60*60 ) ){

}else{
$w = date('w',$mtime);
$dstfile = $logfile . "." . $w;
if( @file_exists($dstfile) ){ @unlink($dstfile); }
@rename( $logfile, $dstfile );
}
}
ob_start();
$line = "{$this->lapse} ".date("H:i:s", $this->_starttime);
$line .= " {$_SERVER['REMOTE_ADDR']} " ;
$line .= '"' . $_SERVER['REQUEST_METHOD'] .' ' . $_SERVER['REQUEST_URI'] .'"' ;
$line .= " ". $_SERVER['REDIRECT_STATUS'] ." ";
$line .= '"' . $_SERVER['HTTP_USER_AGENT'] .'"' ;
@file_put_contents( $logfile , $line.PHP_EOL, FILE_APPEND );
ob_end_clean();
}
function logger(){
$this->lapse = number_format( array_sum( explode(' ', microtime() )) - $this->_start, 3 );
}
}// class end
accesslog_74bee6e126ef2866d0d6ebaf38734088::getInstance();


例えばGoogleのボットアクセスの場合、このようなログを残すことができます。
0.299 00:00:13 66.249.79.250 "GET /" 200 "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.92 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

・いろいろとエラー処理は省いています。
・曜日ごとの最新ログファイルを残します。
・UTCで動作しているワードプレスで利用しています。日付が9時間ずれるようでしたら+9*60*60を削除することで正しい日付になります。

傾向と分析


全体のアクセスが少ない日は、7割ボット、3割ユーザーと言った感じの統計になっています。
対策を全くしていない場合、8割、9割がボットアクセスになることもあります。
日毎に傾向を捉えて、アクセスの傾向を分析していると発見があります。

同一IP、同一ボットからの激しいアクセスを見つけて、拒絶する


ボットの場合、大抵ユーザーエージェントを見ることで、わかるようになっています。

GoogleやBingなどメジャーなボット以外で激しいアクセスしているものは除外するようにしています。
Bingの場合、https://www.bing.com/toolbox/webmaster/?cc=jpにサイトを登録することでアクセスの頻度をコントロールすることができます。ただあくまで要望を伝える手段の一つでその通りに動作してくれるわけではありません。

同一IPからの激しいアクセスを見つけて、拒絶する


ボットでは無い、iPhone safariなどのユーザーエージェントを名乗ったアクセスがあったりします。
普通では違いが分かりませんが、時間を空けずにページを遷移が激しい場合スクレイピングと疑って除外するようにしています。

同一IPで複数のユーザーエージェントを名乗っているアクセスを見つける


同一IPでユーザーエージェントを変えながらアクセスし、別ユーザーを偽装するパターンがあります。
これを検出するためにはログファイルIPアドレスとユーザーエージェントの集計処理が必要です。
1つのIPで4つ以上のユーザーエージェントを名乗っている、そのIPをググってスパム等の検索結果があったら除外すると言った対応をしています。


その他:amazonawsは拒否、海外も注意が必要


amazonaws.comからのアクセスがあります。これはAmazon AWSサービスを利用しているユーザーからのアクセスで一般ユーザー扱いしなくていいと思っています。なので全拒否しています。

複数のホストから同時にアクセスすることで運営中のサイトは重くなりダメージを受けます。
海外の数10のIPアドレスから同時にアクセス(攻撃?)があったことがありました。
この時運営中のサイトは激しく重かったです。

ユーザーエージェントは偽装が可能なので絶対ではありません。ただスクレイピングのサンプルソースコードを元にアクセスしてくるパターンは簡単に分かります。ユーザーエージェントに「Python」、「Java」、「PHP」と言った利用中の言語のキーワードが入っています。


まとめ


ある程度ボットがサイトの情報を収集してくれないと集客が成り立ちません。1日1000アクセスぐらいなら7割ボットぐらいが丁度いいと思っています。

賢いボットは、サイトの負荷をなるべく上げないように分散して収集していると感じています。
賢く無いボットは、大体迷惑なアクセスですね。

「パンくずリスト」の問題が新たに検出されました。data-vocabulary.org schema deprecatedとは?


Google Search Console Teamから『サイト https://ドメイン/ で「パンくずリスト」の問題が新たに 検出されました』ってメールが届いていました。

対象のサイトはWordpressのサイトです。警告の内容は、
data-vocabulary.org schema deprecated
でした。

data-vocabulary.org schema deprecatedとは?


data-vocabulary.orgは、サイトのHTMLソースを確認するとパンくずリストに使っている箇所で利用していました。

<div id="breadcrumb">
<div itemscope="" itemtype="https://data-vocabulary.org/Breadcrumb">
<a href="https:/domain" itemprop="url"><span itemprop="title">ホーム</span></a>>
</div>
<div itemscope="" itemtype="https://data-vocabulary.org/Breadcrumb">
<a href="https://domain/category/" itemprop="url"><span itemprop="title">カテゴリ</span></a> >
</div>
</div>


Googleのwebmasterブログにdeprecatedの理由が書いてありました。
2020年4月6日より、data-vocabulary.orgマークアップは、Googleのリッチな結果機能の対象外となります。
https://webmasters.googleblog.com/2020/01/data-vocabulary.html?m=1

data-vocabularyは少数派で時代遅れ、メジャーなSchema.orgへ一本化すると記されています。

data-vocabulary.org schema deprecatedをなくす対策のHTMLとワードプレスの対応


data-vocabulary.orgマークアップをschema.orgに置き換えることで警告はなくなります。

schema.orgを利用したパンくずリストの書き方はGoogle(パンくずリスト)を参考にするのが確実です。

Google(https://search.google.com/test/rich-results)でライブテストすることができます。microdata形式に対応していました。

先ほどのソースをコード入力でテストするとリッチリザルト対象ですが、以下警告が表示されることが確認できます。
data-vocabulary.org schema deprecated(任意)と黄色で警告表記が確認できます。


元HTMLソースを
<div id="breadcrumb">
<div itemscope="" itemtype="https://data-vocabulary.org/Breadcrumb">
<a href="https:/domain" itemprop="url">
<span itemprop="title">ホーム</span>
</a> >
</div>
<div itemscope="" itemtype="https://data-vocabulary.org/Breadcrumb">
<a href="https://domain/category/" itemprop="url">
<span itemprop="title">カテゴリ</span>
</a> >
</div>
</div>

このように変更した結果、
<div id="breadcrumb" itemscope="" itemtype="https://schema.org/BreadcrumbList">
<div itemprop="itemListElement" itemscope="" itemtype="https://schema.org/ListItem">
<a itemprop="item" href="https://domain" itemprop="url">
<span itemprop="name">ホーム</span>
</a>
<meta itemprop="position" content="1" /> >
</div>
<div itemprop="itemListElement" itemscope="" itemtype="https://schema.org/ListItem">
<a itemprop="item" href="https://domain/category/" itemprop="url">
<span itemprop="name">カテゴリ</span>
</a>
<meta itemprop="position" content="2" /> >
</div>
</div>

警告がなくなりました。
data-vocabulary.org schema deprecated(任意)の警告がなくなていることが確認できます。


<meta itemprop="position" content="番号" />は必須パラメータで、省略するとエラーになります。

Wordpressの対応(stinger5)


このdata-vocabulary.org schema deprecated警告が発生しているサイトは、Stinger5テーマを利用しているサイトでした。ここではStinger5を例にしています。
変更が必要なファイルはwp-content/themes/stinger5/フォルダにあります。

Stinger5では、Breadcrumbコードが分散してソースとして埋め込まれています。
以下3つのファイルを修正します。
  1. 404.php
  2. archive.php
  3. singe.php


テーマをFTPツールでアップロードできる環境の方は、ローカルに保存したstinger5テーマからdata-vocabularyをキーワードにして対象となるファイルを特定することができます。

HTMLの修正自体はここまでご紹介している内容で対応できると思います。課題は<meta itemprop="position" content="番号" />の実現性かと思います。

このようにすることで対応できます。
・・・<span itemprop="name">ホーム</span> </a><?php $_content_no_=1;?><meta itemprop="position" content="<?php echo $_content_no_;$_content_no_++;?>" /> > </div>



<span itemprop="name"><?php echo get_cat_name($catid); ?></span> </a><meta itemprop="position" content="<?php echo $_content_no_;$_content_no_++;?>" /> > </div>

$_content_no_という変数を初期値1で定義して、出力したら+1するソースコードになります。1ファイルで2箇所修正する際の例として参考にしてください。

ホームのところはcontent="1"直書きでwhileでループしているところだけ初期値2から始める方法でも可能です。この場合、変数の宣言位置に注意してください。

変数名は何でもいいです。ただWodpressやテーマ、プラグインで利用中の変数と重複すると面倒な事態になるので分かりやすさより、被らないユニーク性を重視してくださいね。




まとめ


対応期限は、2020年4月5日までです。4月6日からエラー扱いになるかと思われます。
対策した後は、サーチコンソールで「修正を検証」お忘れなく。
検証はしばらく時間がかかります。また一度に全ての問題を警告してくれないのでGoogleのクロールするタイミングで新たに警告するURLが増えます。

「修正を検証」ボタンをクリックした1日後、合格していました。今回の修正方法で合格がもらえることが確認できました
合格したことが確認できる。(サーチコンソール>パンくずリスト>data-vocabulary.org schema deprecated>詳細を表示)



Google PageSpeed InsightsはWordpress テーマを変えるだけで100点取れる?

100点取れました。Google PageInsightsのパソコン100点の結果がわかる

取れました。ただ、Google PageSpeed Insightsのパソコン側の結果です。モバイルは99点です
Wordpressのバージョンは、5.2.1。
サーバは、エックスサーバー(X10)です。先日新サーバーに移行しました。
今回評価に使ったサイトは、2018年2月ごろからあるサイトで、テストに利用したURLは、2000文字ぐらいの規模です。

プラグインは、ページキャッシュ系プラグインなし、というかプラグインはすべて無効状態です。
100点取ったらテーマは、Wordpress標準のTwenty Nineteenです。
Twenty Nineteenです。


パソコン100点、モバイル99点獲得できた際のラボデータ(モバイル)は以下のような結果です。
パソコン100点、モバイル99点獲得できた際のラボデータのモバイル

現在レンタルしているサーバーの上限値となり得る値です。検索してサイトに訪れてきたユーザーが遅い・速いを感じる指標はコンテンツの初回イベント、速度インデックスかと思います。

グーグルの指標的には、クロールせずに見える範囲を1秒未満で表示できるのが望ましいです。
PageSpeed Insights は、ページを分析して、モバイル ネットワークでページを 1 秒未満で表示するための推奨事項にそのページが準拠しているかどうかを確認します。
developers.google.com:
PageSpeed Insights でのモバイル分析

また、上記モバイル分析ページに書いてありますが、モバイルは4G/3G回線でアクセスを前提とした速度で計測されます。そのためパソコンで90点台を取れても、モバイルは40点台という結果になったりします。

変える前のテーマでは、47点でした


当然サクサク90点台取れるかと思ったんですが・・・
高額講座で貰った高機能なテーマ

メディア作成向けの高額有料講座で貰った高機能なテーマを使っていたんですが、この通りの結果ですちなみにパソコンは91点でした。
ラボデータは意味のあるコンテツの初回イベント3.4秒、速度インデックス4.9秒でした。先ほどの結果から今レンタルしているエックサーバーだと速度インデックスは1.8秒程度はいけるはずなので、3.1秒ほど他の何かで遅くなっているってことです。
yuuryou-theme-1-labodata.jpg

レンタリングを妨げるリソースの除外で3.12sぐらい改善できるような感じでしたが、焼け石に水ですね。

これでもか!ってぐらい機能豊富なんですが、その分遅くなっている要因が複雑化していました。詳しくソースをチェックしていたところさらにがっかりしました。

有料講座で貰ったテーマの問題点
  • ソースを確認すると既知の技術を組み合わせているような感じのテーマでした。
     そのためか、scriptやstyleタグが長い傾向にある(ソースも長かったです)
  • 同じ機能のjavascriptやフォントを何度も呼び出しする傾向にある
  • 高機能な部分は、複雑な機構になっている
  • 手の施しようがない感じです。

      deferとか使ってなんとかしよう!って思わせてくれない感じでした。手強いです。

      有料テーマ 賢威8.0は、77点でした


      ワードプレスのテーマとして<a href=【賢威】8.0(ワードプレス版)を有効にしたイメージ" width=300>

      テーマを2019年5月30日にバージョンアップした【賢威】8.0(ワードプレス版)に変更し、確認するとモバイル77点とテーマを変更しただけで30点アップしました。パソコンは99点でした。
       賢威8.0のモバイル結果がわかる


      ラボデータは、意味のあるコンテツの初回イベント2.4秒、速度インデックス3.0秒でした。
      keni-labodata.jpg



      2万人を超えるユーザーが選んだSEOテンプレート【賢威】

      というフレーズが有名です。
      実際購入して感じたメリットは、長く使うほどお得感が増すっていうところです。今だと賢威を購入すると賢威6、賢威7、賢威8の3つのバージョン(ワードプレス版、HTML版)がダウンロードできます。毎年バージョンアップしているのでどんどんテーマが増えるって感じでお得に感じています。

      また、サポートがしっかりしている(ユーザーフォーラムがあります)ので、不具合とかにも真摯に対応してくれます。他の有料テンプレートに手を出したことがないので比較できませんが、新しく購入するテンプレートは、サポートフォーラムありっていうところを選びたいと思っています。


      Google PageSpeed Insightsで満点取れたけど、77点でいいんです


      Wordpress テーマを変えるだけでモバイル47点から99点、パソコン91点から満点にできることがわかったかと思います。またワードプレス標準テーマを利用するとレンタルしているサーバーの上限値を理解することができます。

      でも、満点のテーマは使いませんその理由は不便な思いをしたくないからです。
      一般的なワードプレスサイトなら標準テーマでも良いかと思いますが、47点のテーマでも、Webフォントの利用をやめたり、キャッシュ系プラグインを利用することで劇的な速度改善につながる可能性もありますね。

      また、速い結果のテーマでも、機能が足りないのでプラグインを追加しがちです。これは遅くなる要因に繋がりやすいので、初めから機能がそれなりに盛り込まれていて、そこそこ速いテーマでいいんじゃないかと思っています。

      テーマによっては、ランキング、関連ページ、ブログカード、吹き出しなど様々な便利な機能が用意されていますよね。やっぱりこれを使いたいです。

      頻繁に情報を更新するサイトだとキャッシュ系プラグインが使えないというかキャッシュすることに意味がないことがあります。このような場合は、キャッシュがない状態でもそこそこ速いテーマ(例えば賢威とか)にしたいですね。
      【賢威】



wordpress 5 記事が自動的にPublishから非公開になっていた件

どうも!Scriptsです。Wordpress5.1.1+Stinger5(かなり昔の無料版)利用中のサイトで404エラーが発生していることをGoogle Search Consoleで知りました。

該当の記事は、ブラウザでアクセスすると確かに404エラーになっています。
該当の記事をプレビューで確認したところ、「非公開:タイトル」になっていました。

でも、wordpressのデータベースに直接アクセス(mysqlコマンド)して確認しても、wp_postsは非公開になっていませんでした。
post_status は、 publishであることが確認できました。

データベース上、公開になっているのに、非公開になるパターンって一体どういう自体なんでしょうかね・・・

ググっても、試行錯誤した原因不明の対処方法ばかりで信頼できないって思いました。そこでどこでこれがpublishからprivate(非公開)に変化させているのか?原因を徹底的に調査しています。

・・・

徹底的に調査する前段階で原因ががわかりました。
mysqlに接続して、タイトルでマッチするレコードを調査したところ、投稿ページ、固定ページで同一のタイトル、urlのページがありました。

同じURLで公開、非公開のページが存在できるのがwordpressの仕様っぽいです。

公開日付1 固定ページ側 パーマリンク:サイト/パス1/ 非公開
公開日付2 投稿ページ側 パーマリンク:サイト/パス1/公開

というような感じで設定されていました。この場合、公開でなく、非公開が有効になるようです。


同じパス1になっていることが問題でした。非公開側のパス1をパス2、別のページ名に変更したところ、
投稿ページ側のサイトが非公開=>公開に変更できました。

同じような問題で困っている方は、投稿ページ、固定ページ両方のURLで一致しているものがないかを確認してみてくださいね。

mysqlコマンドが使える方は、wordpressのデータベースに接続した後、以下のようなSQLを打ち込むことで重複があるurl(post_name)を調べることができます。
mysql> select ID,post_title, post_status,post_name, post_type from wp_posts where post_name like '%キーワード%' and post_status in('private', 'publish');
キーワードは、調査したいページ名に置き換えて実行してください。





「応答速度が速い」がGoogle上位表示の秘訣!応答速度が速いサーバーは?

2018年7月からページ速度がより早い方がモバイル検索ランキング上位に表示される要素になるってご存知でしょうか?googleの公式ブログで2018/1/17に発表されているのでご存知の方も多いかと思います。
=>2018/7から「応答速度が速い」がGoogle上位表示の秘訣になるってことです。

人々はできるだけ早く質問に対する回答を見つけることができるようにしたいと考えています。研究によれば、人々はページのスピードを本当に気にしています。スピードはしばらくの間ランク付けに使用されていましたが、その信号はデスクトップ検索に集中していました。今日では、2018年7月からページ速度がモバイル検索のランキング要素となることを発表しています。
https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html


ユーザーがページを表示するまで速いのが一番ですが、サーバーが担うのは一部です。
1)【スマホ/PCの役割】URLからIPアドレスをLookup、サイトに要求する
2)【サーバーの役割】URLに該当するページを応答する
3)【スマホ/PCの役割】レスポンスで受け取っとページを描画する

2)の部分をできる限り速くするのがサーバーの役割です。これ以外の部分はユーザーの範疇です。例えば高性能なスマホなら速く表示できるし、ユーザーの使っている回線が速ければ素早く表示できます。

速いサーバーはレスポンスが早いということになります。レスポンスが遅いと離脱率が上がり、記事を見てもらえない可能性が高くなります。
サイト表示が2秒遅いだけで直帰率は50%増加!

操作開始時間が1秒のサイトと3秒のサイトを比較しても、3秒のサイトは1秒のサイトに比べ、ページビューが22%低下、コンバージョン率は38%低下、直帰率は50%上昇してしまう
Impress:Web担当者



応答速度が速いレンタルサーバーの定義


サーバー ハードウェアのスペックで注目したいのは、SSD採用かどうかです。VPSや専用サーバーならCPUコア数、メモリも重要ですね。多ければ多いほどピーク時に対応しやすいメリットがあります。反面価格も高くなるのでトレードオフです。

ポイント1)SSDを採用している


ファイルへのアクセスが高速になります。ページのキャッシュ(ファイル)、データベースクエリの結果キャッシュ(ファイル)、PHPコード(ファイル)、ファイルにアクセスするシーンは多いです。
ベースのRead/Writeスピードが高速なSSDは有利です。SSDを採用しているレンタルサーバー、VPSサーバー、専用サーバーは多いです。

ポイント2)HTTP/2 or QUICに対応している


サイトのSSL対応はGoogleのページランキングの要素の一つです。HTTPS化のメリットの一つはHTTPより速くなることが期待できるHTTP/2、QUICを使えるようになることです。

HTTP/2は、HTTPS通信時にEdge/Chrome/Safari/Opera主要ブラウザが使えるプロトコルです。サーバー(HTTPデーモン)がHTTP/2に対応している必要があります。
HTTP/2のメリットは、クリティカルパスを短くできる可能性を秘めています。優先度制御や非同期でのリクエスト/レスポンス処理が可能です。ブラウザの進化によりHTTP/2に対応しているサイトは、Webページを表示する見かけ上のスピードを向上することが期待できます。

QUIC(Quick UDP Internet Connections)は、GoogleがHTTP/2より安全で高速なレスポンスを目指し、Chrome/Operaブラウザで使えるプロトコルです。サーバーがQUICに対応している必要があります。
chrome://net-internals/#quic
で動作状態を確認することができます。デフォルトではアクティブになっていました。

ポイント3)次世代HTTPサーバー(Nginx、LiteSpeed)とキャッシュ機能が使える


HTTPサーバーといえばApacheが有名ですね。2018年6月時点、同時アクセスのパフォーマンスに着目したNginx、さらに高速化を目指しているApacheと互換性のあるLiteSpeed、次世代HTTPサーバーがレンタルサーバーでも利用できるようになっています。

同じハードウェアでHTTPサーバーの処理能力が向上するものなの?疑問ですよね。LiteSpeedで検証データが公開されています。LiteSpeedはApahceの10倍処理能力があります。
LitespeedはApacheの10倍、NginxはApacheの4倍処理能力が高いことがわかるグラフ

出典:https://blog.litespeedtech.com/2018/03/05/compare-openlitespeed-to-nginx-and-apache/
このグラフは1秒間にリクエストをどの程度アクセスを受け入れられるかを示しています。グラフが高いほど優秀です。
このグラフからApache上のWordpressサイトでW3 Total cacheを有効にしたサイトを1とすると、Nginx+FastCGI Cacheは4.24倍、litespeed(オープンソース版)+LSCacheは10.24倍処理能力が向上できることがわかります。

これらの要件を満たすレンタルサーバーは?


XSERVER、mixhost、JETBOY、この3つのレンタルサーバーです。

XSERVERのポイント


ポイント1)全プランRAID10構成のSSD採用 200GB〜
ポイント2)次世代nginxサーバーを採用
ポイント3)FastCGI、HTTP/2が使える
ポイント4)最安X10プラン 初期費用3,000円+1年契約で月額1,000円相当です。
ホストサーバーは20コアCPU & 192GBメモリのハイスペックサーバーです。このスペックを複数人で共用し、利用します。

公式で詳しくチェック=>エックスサーバー



mixhostのポイント


ポイント1)全プランRAID10構成のSSD採用 50GB〜
ポイント2)次世代LiteSpeedサーバーを採用
ポイント3)HTTP/2&QUIC完全対応
ポイント4)最安スタンダードプラン 初期費用無料+1年契約で月額980円相当です。
ポイント5)VPSのようにユーザーごとメモリ、CPUなどのリソースが割り当てられます。(3vCPUs / 2GBメモリ〜)
ホストサーバーは24コアCPU & 256GBメモリのハイスペックサーバーです。

公式で詳しくチェック=>MixHost



JETBOYのポイント


ポイント1)RAID構成のSSDを採用しています。
ただし、SSDデータベース&HDDのハイブリットSSD構成のサーバーもあるようです。
ポイント2)次世代LiteSpeedサーバーを採用(LiteSpeedエンタープライズ版) 、LScacheプラグインも使えます
ポイント3)HTTP/2完全対応
ポイント4)最安ミニSSDプラン 初期費用1,000円+1年契約で月額290円相当です。
ポイント5)VPSのようにユーザーごとメモリ、CPUなどのリソースが割り当てられます。(1コア / 512MBメモリ〜)
ホストサーバーは24コアCPU & 256GBメモリのハイスペックサーバーです。

スタンダードプランは、ストレージ40GB、3コア、メモリ2GB構成で初期費用3,500円+1年契約で月額1,280円相当です。

公式で詳しくチェック=>JETBOY




まとめ


今回ご紹介したサーバーはいずれもお試し期間があります。ホストサーバーのスペックはほぼ横並びです。お試し期間でパフォーマンスをチェックし、Google上位表示しちゃいましょう!

ワードプレスのユーザー名、パスワードを忘れたをphpMyAdminを使わずに解決する

ワードプレスのユーザー名、パスワードが思い出せない"

ユーザー名、パスワードを記憶していたアプリの障害で消えていた、久しぶりのログインでユーザー名、パスワードを忘れている、ワードプレスのパスワードリセットには、ユーザー名、またはメールアドレスが必要になりますよね。ユーザー名、メールアドレスも覚えていない・・・、大丈夫です。phpMyAdminで解決できます。phpMyAdminが使えないサーバーですか?大丈夫です。これからご紹介するアップロードする方法でユーザー名、メールアドレス、パスワードリセットでワードプレスのユーザー名、パスワードを忘れたを解決できます。

これからご紹介する方法は、ご自身のサイトにファイルをアップロード、http/httpsでアクセスしてユーザー名を表示されたり、パスワードをリセットします。ご紹介しているのはソースコードのみです。ソースコードをコピペしてワードプレスが動いているディレクトリに配置する必要があります。


ワードプレスのユーザー名、メールアドレスがわからないを解決するアップロードファイル


ワードプレスのユーザー名、メールアドレスは、MySQLデータベース(wp_users)に保存されています。これからご紹介するPHPソースコードをwp-config.phpと同じディレクトリに配置してください。配置し、http/httpsでアクセスし、知りたいことがわかったら配置したファイルを削除することを忘れないでくださいね。
<?php 
require_once( __DIR__ . "/wp-config.php");
$wusers = $wpdb->get_results('select * from wp_users;');
?>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>Page Title</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<h2>wp_usersを詳しくみる</h2>
<p>ワードプレスのユーザーテーブルの情報を表示します。</p>
<form action="./rescue-show-users.php" method="post">
<select name="user_id"><?php
foreach( $wusers as $data ){
echo <<< EOM
<option value="{$data->ID}">{$data->userlogin}({$data->display_name})</option>
EOM;
} ?></select><button name="show_userinfo">ユーザ情報表示</button></form>
<?php
if(isset($_POST['show_userinfo'] ) ){
$target = false;
foreach($wusers as $data){
if( $data->ID == $_POST['user_id'] ){
$target = $data;
}
}
if( $target ){
ob_start();
print_r($target);
$contents = ob_get_contents();
ob_end_clean();
echo "<p>{$contents}</p>";
}else{
echo "<p>失敗です</p>";
}
}
?>
</body>
</html>

このPHPのファイル名は、rescue-show-users.phpです。ファイル名を自分のお好みに変えることができます。そその際は、ソース中のformの太字の部分も合わせて変更してください。
【ポイント】
  • ポイント1 データベースのホスト名、パスワード、全て不要。設定済みのwp-config.phpを利用しています。
  • ポイント2 wp_usersテーブルの内容をコンボボックスから選んで「ユーザ情報表示」ボタンで表示できます
  • ポイント3 選択したユーザーの情報を全て出力しています。

やっていることわからなくても、ソースコード全部見れますよね。安心してください。
【出力例】
以下のような出力で確認できます。ユーザー名は、user_login、メールアドレスは、user_emailをそれぞれ確認することでわかります。
stdClass Object ( [ID] => 1 [user_login] => user_login
[user_pass] => user_pass
[user_nicename] => user_nicename
[user_email] => user_email@example.com
[user_url] => [user_registered] => yyyy-mm-dd hh:mm:ss
[user_activation_key] =>
[user_status] => 0
[display_name] => display_name )

(見やすいように改行しています)

PHPソースコードをwp-config.phpと同じディレクトリに配置することでユーザー名、メールアドレスが確認できるようになります。

ワードプレスのパスワードがわからないを解決するアップロードファイル


ワードプレスのパスワードをPHPからリセットすることができます。ただリセット自体は、ワードプレスの機能にもともとある方法(/wp-login.php?action=lostpassword)を使った方が良いかと思います。ユーザー名もしくはメールアドレスがわかればパスワードをリセットすることができます。
先にご紹介したワードプレスのユーザー名、メールアドレスがわからないを解決するアップロードファイルでユーザー名、メールアドレスがわかります。

=>ユーザー名、メールアドレスがわかればパスワードはリセットできます。


登録されているメールアドレスが解約済みだったり、使えなくなっている場合は、ワードプレスのユーザー名、メールアドレスがわからないを解決するアップロードファイルでIDを調べた上で以下ファイルをアップロード、アクセスすることで変更できます。
以下の例の太文字の部分がIDです。
stdClass Object ( [ID] => 1 [user_login] =>・・・)


太字のWP_USERSの変更したいID、新しいメールアドレスの部分をご自身の環境に合わせて書き換えてください。
<?php 
define('WP_USERSの変更したいID', 1);
define('新しいメールアドレス','user@example.com');

require_once( __DIR__ . "/wp-config.php");
$wusers = $wpdb->get_row("select ID, user_login,user_email from wp_users where ID=" . WP_USERSの変更したいID);
?>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>Page Title</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<h2>確認</h2>
<p><?php
if( count($wusers) == 0 ){
echo "<b>指定したIDに誤りがあります。更新できません。IDを見直してください</b>";
}
else if( strlen(trim(新しいメールアドレス)) <= 3){
echo "<b>新しいメールアドレス間違えていませんか?見直してください。</b>";
}
else if( isset($_POST['update']) == false ) {
echo "ID={$wusers->ID} (ユーザー名:{$wusers->user_login})<br><b>現在登録されているe-mailアドレス:{$wusers->user_email}</b><br><br><b>変更後のe-mailアドレス:".新しいメールアドレス ."</b><br>変更後のe-mailアドレスに変更します。「更新」ボタンをクリックで変更します。";
?>
<form action="./rescue-email-change.php" method="post"><button sytle="font-size:x-large" name="update">更新</button><form>
<?php
} else {
$ret = $wpdb->update('wp_users', array('user_email'=>新しいメールアドレス), array('ID'=>WP_USERSの変更したいID ), array('%s'), array('%d') );
if( $ret == false ){
echo '<b style="color:red">データベース更新に失敗しました。</b>';

}else{
echo "更新しました。";
}
echo "<br>現在データベースに登録されているメールアドレス<br>";
$wusers = $wpdb->get_row("select ID, user_login,user_email from wp_users where ID=" . WP_USERSの変更したいID);
print_r( $wusers );
}
?>
</p>
</body>
</html>

このPHPのファイル名は、rescue-email-change.phpです。ファイル名を自分のお好みに変えることができます。そその際は、ソース中のformのaction部分も合わせて変更してください。
【ポイント】
  • ポイント1 確認画面を表示します。「更新」ボタンをクリックすることで更新します。
  • ポイント2 データベースのホスト名、パスワード、全て不要。設定済みのwp-config.phpを利用しています。
  • ポイント3 現在のemailアドレスも合わせて表示します。必要ならコピペしてどこかに記録しておいてください。


まとめ


いかがでしたでしょうか。phpMyAdminが使えないサーバーで、パスワードをを忘れても、この方法でワードプレスにログインできます。

Wordpressショートコードの一覧を表示する方法

ワードプレスのテーマは標準で使えるTwenty Seventeenから有償テーマまですごい数ありますよね。サイトごとにテーマを変えた方がいいっていう話もあるので無料、有償を含めたくさんのテーマテンプレートを使っています。主に有償のテーマになりますが、機能がてんこ盛りの場合もあったりします。記事の投稿を助けてくれるショートコードの機能が豊富ってことです。これからご紹介する方法は、テーマのショートコードの一覧が欲しいって時に使える方法です。

WordpressのAPIに一覧を表示する関数はあるの?


ありません。
ショートコード名がわかっていれば、存在を確認するshortcode_exists関数があります。ショートコード名が知りたいって時には使えませんよね。


ショートコード一覧を表示する方法


ご存知のようにワードプレスはPHPで作られています。日本語マニュアルもWordPress Codex 日本語版でしっかり整備されています。オリジナルのソースコードも見ることができますよね。

4.9.4のワードプレスのショートコードのソースがあります。tags/4.9.4/src/wp-includes/shortcodes.php

別にリンク先は見なくてもいいです。ショートコードを実行する方法の関数(do_shortcode)、ショートコードを追加する(add_shortcode)、ショートコードを削除する(remove_shortcode)などの関数のソースコードがリンク先にあります。

一覧を表示する関数はありませんよね。でもショートコードはどこかに保持されています。それがわかるんです。$shortcode_tagsです。

ここに全部格納されています。

グローバル変数で参照できます。つまり以下のようなカスタム関数やプラグインを作ることでショートコードの一覧を表示することができます。
function ショートコード一覧( $atts ) {
global $shortcode_tags;
$ret="<ol>";
foreach( $shortcode_tags as $name => $obj ){
ob_start();
print_r( $obj );
$content = ob_get_contents();
ob_end_clean();
$ret .= "<li>{$name}:{$content}</li>";
}
return $ret . "</ol>";
}
add_shortcode('list_shortcodes', 'ショートコード一覧');


この関数をfunctions.phpに入れるか、独自のプラグインを作って見てください。

記事や固定ページに[list_shortcodes]と書いて、プレビューボタンでショートコード一覧を見ることができますよ。



PHP5で動く、PHP7なんか動きが違う、原因は何?どこをチェックするのがいい?

PHP5とPHP7の違いは、ワードプレスを使っている限りほとんど意識することはありません。レンタルサーバーのコントロールパネルからPHPのバージョンを5.6.x系から7.0、7.1、7.2系に切り替えるだけでそのまま動きます。互換性の問題は発生しないのが素晴らしいです。よく考えられたアップデートだと思っていたんですが、5.6.x系・7.0系=>7.1系のアップデートは、とても気づきにくい罠がありました。知っていましたか?負の offset をサポートするようになりました。って一文でfile_get_contentsが別物の動きをしていました。

PHP5.6では、思い通り、設計通りの動作をしていたプログラムがありました。
このプログラムは、macOSで動かしていて、先日macOSをSierraからHigh Sierraにアップグレードしました。
macOS Sierraは、PHP5.6系です。macOS High Sierraは、PHP7.1系がすぐに使える状態で入っています。
この違いは、プログラムの結果が求めている動作をしていないことで初めて知りました。


PHPのマイグレーションをページに新機能、新しい関数、下位互換性のない変更点、推奨されなくなる機能、変更された関数、その他の変更など、PHPのバージョンをあげる前に注意するべきポイントがまとまっているので参考にしています。
メニューから各バージョンのマイグレーションを選択することができます。
参考:PHP7.0.xからPHP7.1.xへの移行

今回、発生した問題は、この移行ページに掲載されていました。
PHP 7.0.x から PHP 7.1.x への移行>変更された関数 >ファイルシステム
file_get_contents() now accepts a negative seek offset if the stream is seekable.

さらりと1行でまとまっています。

file_get_contents関数はファイルを読み込んだり、URLからWEBページを取得できるよく使われる関数の一つです。
PHP5のfile_get_contents関数の説明はこんな感じでした。
PHP5が最新だった頃のfile_get_contentsの解説(php.net)

それが、PHP7.1の変更後、このように変わっていました。
php7.2.2が最新の頃のfile_get_contentsの解説(php.net)


違いわかるでしょうか?そうです!$offsetのデフォルト値が-1から0に変わっています。マニュアル上はこのように変わっていますが、PHP5.6はいままで通り-1を渡しても0と同じ意味です。

一方、$offsetに-1を渡すようなプログラムをPHP7.1以降で動かすと、 ストリームの末尾からのオフセットと解釈されます。

=>PHP5で動く、PHP7.1で動きがおかしい原因はこれでした。

関数のデフォルト値って不変、ずっと変わらないものって思い込んでいました。現実は、バージョンアップで変わることがあるってことです。ファイル名以外、引数を指定することがないって方も多いかと思います。

作り込んだライブラリで、拡張性を持たせるためにPHPのデフォルト引数も全て受け付けるようなラッパー関数、ヘルパー関数はPHPのデフォルト値を自作関数、メソッドの引数にコーディングすることが多いです。


PHP5で動いていたものがPHP7で動かなくなったら、チェックすべきポイント


PHPのマイグレーションには、たった1行の変更点の記載でしたが、インパクトが大きいってことがわかったかと思います。
自作関数、自作メソッドでPHPのデフォルトを書いているところは、マニュアルを参考にし、再確認するのが良いかと思います。

この際、マイグレーションページを見ながら、記載のある関数を使っているかgrepやIDEの検索機能をフルに使ってチェックするのが効率的です。


=>マイグレーションページをインデックスにし、関数のマニュアルとソースを比較!


まとめ


繰り返しになりますが、PHP5とPHP7の違いは、ワードプレスを使っている限りほとんど意識することはありません。今回のfile_get_contentsに関しても完全互換性があり、ファイル名のみの指定で使っていると同一です。でもデフォルト引数の違いがありましたね。拡張性を考えたメソッドやヘルパ関数は標準と同じような引数を許可するような設計はこういった変更のインパクトが大きいって思いましたよ。

0と-1で別物の動きになってしまいますから・・・


posted by scripts at 10:50 | Comment(0) | TrackBack(0) | php
最新記事
最新コメント
タグクラウド
カテゴリアーカイブ