WordPress 管理画面 [Error] TypeError: undefined is not an object (evaluating 'wp.i18n.setLocaleData')の解決方法

WordPressの管理画面でウィジェットの内容を変更するために外観→ウィジェットで表示されるサイドバーウィジェットのテキスト、カスタムHTMLを展開しようとするとこんな感じでタイトルや内容の記載が表示できない状態になっていました。解決方法はこちらです。

WordPress管理画面でTypeError: undefined is not an objectが発生したらやるべき事

google page insightsやSearch Consoleの指摘でなんとか解決しなきゃとググって、見つけた設定方法でWordPressのテーマへ設定を反映しています。手早く解決できますよね。

これがいけませんでした。ちょっと考えてから適用しておけば防げました。

以下のような設定をfunctions.phpに記載している場合、管理画面、通常表示どちらでも有効になります。


/*wp-emoji-releaseの無効化*/
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );    
/*link rel='shortlink'の無効化 */
remove_action('wp_head', 'wp_shortlink_wp_head');
/*link oEmbedの無効化 */
remove_action('wp_head','wp_oembed_add_discovery_links');
/*jqueryの無効化 */
wp_deregister_script('jquery');
/*プラグインの無効化*/
function dequeue_plugins_style() {
    wp_dequeue_style('wp-block-library');
    wp_dequeue_style('colorbox');wp_dequeue_style('colorbox');
    wp_dequeue_style('wordpress-popular-posts');
}
add_action( 'wp_enqueue_scripts', 'dequeue_plugins_style', 9999);

管理画面では有効にしたい場合、以下のように変更します。ワードプレス標準関数is_admin()で管理画面かどうかを判断することができます。


if( is_admin() ){ /* 管理画面 */ }
else{ /* 管理画面以外 */
/*wp-emoji-releaseの無効化*/
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
・
・
・
add_action( 'wp_enqueue_scripts', 'dequeue_plugins_style', 9999);
}/* else end */

管理画面では何もしない、それ以外の場合に処理するコード例です。管理画面がおかしい、そういえばコード修正したかもって方の参考になれば幸いです。

解決までの流れ Can't find variable: wp、TypeError: undefined is not an object (evaluating 'wp.i18n.setLocaleData')

本来の「テキストウィジェット」の表示

比較すると以下のようなことがわかりました。

タイトルのラベル、入力エリア(input type=text")がない
「メディアを追加」ボタンが消えている
ビジュアル、テキストのタブが消えている
入力エリア（textarea）がない
削除、完了リンクはある
「保存しました」ボタンが「Saved」ボタンとして未翻訳の状態である

本来表示されるべき内容が消えてしまっている？あります。通常のコンテンツにアクセスしてウィジェットのエリアは普通に表示されていました。

一体いつから消えていたのか？ウィジェット系の更新頻度は低いです。そのため、どれくらい前から消えていたのか判断できませんでした。

解決方法は？「Wordpress サイドバーウィジェット不具合」等でググりました。該当しそうな情報が見つかりません。

原因となりそうなキーワードを集めるためにブラウザーのデバッガー（Safari：右クリック→要素の詳細を表示、Chrome：右クリック→検証）を起動したところ、エラーが多数発生していたことがわかりました。

15箇所 ReferenceError: Can't find variable: wp
1箇所 TypeError: undefined is not an object (evaluating 'window.wp.editor')
1箇所 ReferenceError: Can't find variable: tinymce

このエラーを見て、ぴん！っと閃きました？

そういえば、通常サイト側の対応で、jqueryのURLをテーマ（header.php）に直書きしたことを思い出しました。
wordpressでのjquery呼び出しを削除するため、functions.phpに以下を追加しました。


・
・
wp_deregister_script('jquery');
・
・

よく良く考えると上記のような指定では管理画面、通常サイトを含めて全てjQueryが無効になってしまいますね。

↓管理画面の場合は対象外！という処置をしました。


if( is_admin() ){ }else {
wp_deregister_script('jquery');
}

修正したらエラーの内容が変わっていました（アップロードして検証ツールのログを確認したところ）。

Can't find variable: wpエラーは解消しました。

~~15箇所 ReferenceError: Can't find variable: wp~~
~~1箇所 TypeError: undefined is not an object (evaluating 'window.wp.editor')~~
7箇所 TypeError: undefined is not an object (evaluating 'wp.i18n.setLocaleData')
1箇所 TypeError: undefined is not an object (evaluating 'wp.mediaWidgets.init')
4箇所 TypeError: undefined is not an object (evaluating 'wp.mediaWidgets.modelConstructors')
1箇所 TypeError: undefined is not an object (evaluating 'wp.textWidgets.idBases')
1箇所 TypeError: undefined is not an object (evaluating 'wp.codeEditor.defaultSettings')
1箇所 TypeError: undefined is not an object (evaluating 'wp.customHtmlWidgets.idBases')
ReferenceError: Can't find variable: tinymce

これらエラーは、jQueryを除去した方法と同じようなremove_action、wp_dequeue_style、wp_deregister_scriptなどを対策で追加した影響で発生しています。

同じようにis_admin()関数で判断することで対処しました。

エラーはなくなり、サイドバーウィジェットのテキストは展開されるようになりました！

まとめ

ワードプレスの管理画面外観、サイドバーウィジェットの内容を編集できない！っていうところからの解決するまでの流れが分かったかと思います。ちょっとしたfunctions.phpへの修正でこんな影響が出るとは・・・ワードプレスの修正って、簡単だけど難しいって思いましたよ。

WordPress管理画面でTypeError: undefined is not an objectが発生したら、修正したテーマのfunctions.phpを見直すことでエラーをなくすことが分かったかと思います。

functions.phpへの修正はできる限り、影響範囲を抑えるため条件分岐タグis_adminを使った方がいいですね。

is_admin()

ダッシュボードまたは管理画面の表示中かどうか

これ以外にもたくさんありますが、管理画面かどうかで判断するのが一番確実だと思います。

初めはWordPressのバグかと疑ってフォーラムとか検索しまくりました。でも結局は自分で設定した変更による影響でがっくりきましたよ・・・

この記事の投稿時点のワードプレスのバージョンは「WordPress 5.6.2 」です。

【このカテゴリーの最新記事】

posted by scripts at 12:34 | Comment(0) | TrackBack(0) | ワードプレス

2020年12月18日

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

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

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

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

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

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

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

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

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

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

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

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

Query Monitor

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

posted by scripts at 11:55 | Comment(0) | TrackBack(0) | ワードプレス

2020年07月03日

格安（千円未満）の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

2020年05月30日

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円～の低価格なレンタルサーバーでもそこそこ稼げる環境へと導けることとができます。
低価格レンタルサーバーのワードプレス運営で気をつけているポイント

【ポイント１】公式からダウンロードできるプラグインは極力インストールしない、必要最低限にしています。
HTMLファイルで作られたサイトにアクセスした場合、ほぼサーバーのスペックで応答できます。
ワードプレスはPHPプログラムです。そのためメモリ上（またはスワップファイル）にプログラムがコンパイルされ、MySQLから必要な情報を取得し、HTML整形して応答しています。多少なりともサーバーへ負荷を与えます
【ポイント２】 サイトを立ち上げ、ワードプレスをインストール、テーマを決定した段階で「PageSpeed Insights - Google Developers」のスコア100を目指しています。
運営中には、影響を与えてしまうかもしれないので消極的な手段を選びがちです。そのため、初期の段階でガッツリ対策しています。

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

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

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

スコア90以上、可能なら100を目指しています。
【ポイント３】 ワードプレスが動いたリアルタイムなアクセスログを収集する
サーバーの負担を上げるワードプレスが動作するアクセスが異常に多くなっていないか？が知りたいと思っています。

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

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

そのため、ワードプレスが動作したときだけ別のログファイルに記録する方法を採用しています。
【ポイント４】 収集したログから異常なアクセスをあぶり出し、拒絶などの対策をします。
一般ユーザーアクセスなのか、または迷惑なアクセスなのかを見極めて、迷惑なアクセスは極力除外するようにしています。

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

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

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

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

またソースコード中、フルパスでログを格納するフォルダ（ディレクトリ）を指定しています。レンタルサーバーのディレクトリ構成がよくわからないって方は調べてみてください。

<?php
/*
Plugin Name: WordPress ログ記録
Plugin URI: http://サイトのURL/
Description: WordPress ログ記録
Author: scripts
Version: 1.0 
Author URI:https://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を削除することで正しい日付になります。

傾向と分析

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

posted by scripts at 11:21 | Comment(0) | TrackBack(0) | ワードプレス

2020年01月22日

「パンくずリスト」の問題が新たに検出されました。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（任意）の警告がなくなていることが確認できます。

Wordpressの対応（stinger5）

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

Stinger5では、Breadcrumbコードが分散してソースとして埋め込まれています。
以下３つのファイルを修正します。

404.php
archive.php
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_という変数を初期値１で定義して、出力したら＋１するソースコードになります。１ファイルで２箇所修正する際の例として参考にしてください。

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

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

まとめ

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

「修正を検証」ボタンをクリックした１日後、合格していました。今回の修正方法で合格がもらえることが確認できました。

合格したことが確認できる。（サーチコンソール＞パンくずリスト＞data-vocabulary.org schema deprecated＞詳細を表示）

posted by scripts at 10:00 | Comment(0) | TrackBack(0) | ワードプレス

2019年06月07日

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

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

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

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

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

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

グーグルの指標的には、クロールせずに見える範囲を１秒未満で表示できるのが望ましいです。

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

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

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

当然サクサク９０点台取れるかと思ったんですが・・・

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

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

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

有料講座で貰ったテーマの問題点

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

posted by scripts at 09:54 | Comment(0) | TrackBack(0) | ワードプレス

2019年05月10日

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 固定ページ側パーマリンク：サイト/パス１/ 非公開
公開日付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');
キーワードは、調査したいページ名に置き換えて実行してください。

posted by scripts at 21:25 | Comment(0) | TrackBack(0) | ワードプレス

2018年06月08日

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

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

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

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

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

速いサーバーはレスポンスが早いということになります。レスポンスが遅いと離脱率が上がり、記事を見てもらえない可能性が高くなります。

サイト表示が2秒遅いだけで直帰率は50％増加！

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

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

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

ポイント１）SSDを採用している

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

ポイント２）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

で動作状態を確認することができます。デフォルトではアクティブになっていました。

ポイント３）次世代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/
このグラフは１秒間にリクエストをどの程度アクセスを受け入れられるかを示しています。グラフが高いほど優秀です。
このグラフからApache上のWordpressサイトでW3 Total cacheを有効にしたサイトを1とすると、Nginx＋FastCGI Cacheは4.24倍、litespeed(オープンソース版)＋LSCacheは10.24倍処理能力が向上できることがわかります。

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

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

XSERVERのポイント

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

公式で詳しくチェック＝＞エックスサーバー

mixhostのポイント

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

公式で詳しくチェック＝＞MixHost

JETBOYのポイント

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

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

公式で詳しくチェック＝＞JETBOY

まとめ

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

posted by scripts at 18:06 | Comment(0) | TrackBack(0) | レンタルサーバー

2018年02月25日

ワードプレスのユーザー名、パスワードを忘れたを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を利用しています。
ポイント２ wp_usersテーブルの内容をコンボボックスから選んで「ユーザ情報表示」ボタンで表示できます
ポイント３選択したユーザーの情報を全て出力しています。

やっていることわからなくても、ソースコード全部見れますよね。安心してください。
【出力例】
以下のような出力で確認できます。ユーザー名は、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部分も合わせて変更してください。
【ポイント】

ポイント１確認画面を表示します。「更新」ボタンをクリックすることで更新します。
ポイント２データベースのホスト名、パスワード、全て不要。設定済みのwp-config.phpを利用しています。
ポイント３現在のemailアドレスも合わせて表示します。必要ならコピペしてどこかに記録しておいてください。

まとめ

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

posted by scripts at 12:19 | Comment(0) | TrackBack(0) | ワードプレス

2018年02月21日

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]と書いて、プレビューボタンでショートコード一覧を見ることができますよ。

posted by scripts at 17:38 | Comment(0) | TrackBack(0) | ワードプレス

<<前の10件 1 2 3 4 5.. 次の10件>>