カテゴリー: ワードプレス

投稿日:

ワードプレスのテーマ変更で Google アナリティクスのタグを貼り換えたときのチェック方法。

古くからシンプルなテーマをカスタマイズして使い続けていた。
テーマチェック機能をプラグインで使用すると、「ブロックテーマに対応を推奨」という項目がいくつも並ぶ。
要するに、ワードプレスは「ログインしている管理者が表示されるすべてをコントロールできるべきだ。」という方針だ。

以前、チームで仕事をした時に、作られたワードプレスにログインしてみたら、「会社概要」固定ページの中身が空っぽだった。ワードプレスのテーマの固定ページをphpで書き出してあるというものだ。ログインしている人がいじってもレイアウトが壊れないようにするため。ということであれば、ひとつの方法ではあるのだけれども、ブログやCMSとしてワードプレスを使う意味を考えさせられた。中身のないページがあるというのは、RSS的にもよくないと考え、phpの情報を固定ページの中へ戻した。と、いったことがあったのを思い出す。

で、カスタマイズした自作のテーマから、ワードプレス公式のテーマに切り替えたときに、Googleアナリティスクのコードも設置しなおすことになった。
今までは、自作テーマの header.php に直接貼りこんでいた。公式のテーマはアップデーすると、このように直接書き込んだコードは消えてしまうため、プラグインを使ってヘッダーに Googleアナリティスクのコードを貼り付ける方法にした。（アップデートでもカスタマイズしたコードが失われない、子テーマという方法もある。）

この時、Googleアナリティクスのコードが動作しているかチェックする方法。

数日すれば、記録を表示し始めるので時間を置けばよい話ではあるけれども、うっかり、ほかのサイトのコードを貼りこんだとか、スクリプトの書式が間違っていた、なんてことがないように、心配ごとを減らす所作としてメモ。

 

 

投稿日:

ワードプレス　プラグイン　Author Category を改修

Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, string given in /Applications/XAMPP/xamppfiles/htdocs/ーーー/wp-content/plugins/author-category/author-category.php:192 Stack trace: #0 /Applications/XAMPP/xamppfiles/htdocs/ーーー/wp-includes/class-wp-hook.php(309): author_category->add_meta_box(‘post’) #1 /Applications/XAMPP/xamppfiles/htdocs/ーーー/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(”, Array) #2 /Applications/XAMPP/xamppfiles/htdocs/ーーー/wp-includes/plugin.php(476): WP_Hook->do_action(Array) #3 /Applications/XAMPP/xamppfiles/htdocsーーー/wp-admin/includes/meta-boxes.php(1599): do_action(‘add_meta_boxes’, ‘post’, Object(WP_Post)) #4 /Applications/XAMPP/xamppfiles/htdocs/ーーー/wp-admin/edit-form-advanced.php(271): register_and_do_post_meta_boxes(Object(WP_Post)) #5 /Applications/XAMPP/xamppfiles/htdocs/ーーー/wp-admin/post-new.php(75): require(‘/Applications/X…’) #6 {main} thrown in /Applications/XAMPP/xamppfiles/htdocs/ーーー/wp-content/plugins/author-category/author-category.php on line 192

 

ローカルでは、191行目を明示的に配列にすることで動作した。

191:$cat = [$this->get_user_cat($current_user->ID)];
118:$cat = [$this->get_user_cat()];
174:$cat = [$this->get_user_cat($current_user->ID)];
321:$cat = [get_user_meta($user_id,'_author_cat',true)];

ほかの118行目、174行目、321行目は、count($cat)　があるので、191行目と同じ処理とした。

投稿日:

WordPress. Briefly unavailable for scheduled maintenance. Check back in a minute.

Briefly unavailable for scheduled maintenance. Check back in a minute.

古いバージョンのワードプレスで、インストールを始めると、こんな画面に出くわすことがある。

「定期メンテナンスのため、しばらく利用できません。 しばらくしてからもう一度ご確認ください。」

ということなので、数分おいてから再読み込みして、正常に動作することが確認できた。

 

投稿日:

WordPress 画像のアップロード失敗　〇〇作成できません。この親ディレクトリのアクセス権はサーバーによる書き込みを許可していますか ?

WordPress で画像をアップロードしようとしたところ、エラーが表示された。

「＜年＞＜月＞作成できません。この親ディレクトリのアクセス権はサーバーによる書き込みを許可していますか ?」

  • ディレクトリの権限は今どき関係ない
  • サーバーを移築して久しぶりの操作

メディアの設定で、年月フォルダの設定があったことを思い出して、設定画面を確認してみると。。

ファイルのアップロード先が、以前のサーバーのディレクトリになってる。これでは、存在しないディレクトリに書き込もうとして、エラーになるのは必至だ。

画面に表示されているように、デフォルトのアップロード先

wp-content/uploads

として、「変更を保存」して、問題なく、画像をアップロードできるようになった。

投稿日:

WordPress 2.8.4 から新しいサーバへ移築　文字化け解決

古いサーバで利用し続けていたワードプレスを、新しいサーバへ移築します。

元のサーバ

  • php4.4.4-8
  • MySQL4.0.24

ローカル

  • php8
  • 10.4.21-MariaDB

１．ワードプレス本体

そのままコピーしても動きません。新しいワードプレスを使って、wp-contentは今までのものを使用します。
プラグインや、テーマでエラーが出るので、エラーの出るプラグインやテーマは削除しておきます。

２.データベース

基本的には、以前と同じ状態で移築したいので、データベースをエクスポートインポートします。

  • phpmyadminでエクスポート
    日本語UTF8でログイン
    DROP TABLEを追加
    non エンコーディングへ変換
  • ダウンロードしたファイルをテキストエディタで開き、
    TYPE=MyISAM → ENGINE=MyISAM
  • phpmyadminでインポート
    _options　にある
    メディアアップロード先を：wp-content/uploads
    ブログのアドレスを移行先に合わせる

３．新しいワードプレス

表示は、プラグインやテーマに不具合があると真っ白の場合があります。
wp-login.php でログイン画面が出たのでログインします。

  • 画面の指示に従ってデータベースを更新
  • 日本語に設定しなおし

これで、ほぼ元通りに移築できるのですが、絵文字に文字化けするものと、文字化けしないものがあります。

🌸💛：文字化けする

⛄：文字化けしない

４．絵文字の文字化け解決

  • データベースのインポートで、文字化け。文字コードを　utf8mb4　とかの情報では解決できず。
    なにしろ、文字化けの有り無しが混在なので文字コードが原因ではない。
  • ワードプレスのエクスポートインポート機能を利用
    記事の文字化けは解消できましたが、メディアとの関連が失われてしまいます。
    記事の画像は表示されるが、記事との関連、メディア画面で表示ができない。

phpmyadmin ワードプレスのエクスポートインポートで文字化けしないなら、、と、ふと思いついたのが、

phpmyadmin でエクスポートする際に、csv形式にする

ブログ全体は試しいませんが、記事だけのことなので、記事のテーブル「_posts」を、csvでエクスポートインポート

インポートするときには、テーブル「_posts」を空にしておき、csvの区切り文字などをエクスポート時のものに合わせます。

うまくいきました。

結論

絵文字の文字化けする問題があるなら、phpmyadmin からcsv でエクスポートインポート　で解決

ただし、エクスポートしたファイルをエディタで開いたときに文字化けしているようなら、文字コードの問題だと思うよ。

投稿日:

class-wp-hook.php on line 303 ：＜php the_excerpt(); ?＞以降が表示されない

状況

テーマの編集をしているときに、<?php the_content(); ?>のかわりに、<?php the_excerpt(); ?>を使用したら、使用した部分から下が表示されない。ローカルのphp8環境。
ざっくり調べると、<?php the_excerpt(); ?>で不具合が出るのは日本語の文字数の判定がうまくいかないから、解決策に「wp multibyte patch」を使うと良いという情報があったので、逆に「wp multibyte patch」を停止して表示できるようになった。

調査

自分のローカルの開発環境

  • php8
  • WordPress 5.8.3
  • 症状：ページが以降欠ける

wp-config.php のデバッグモードを true にした様子

Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function “new_excerpt_mblength” not found or invalid function name in /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/class-wp-hook.php:303 Stack trace: #0 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/plugin.php(189): WP_Hook->apply_filters(110, Array) #1 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-content/plugins/wp-multibyte-patch/wp-multibyte-patch.php(266): apply_filters(‘excerpt_mblengt…’, 110) #2 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/class-wp-hook.php(303): multibyte_patch->excerpt_mblength(110) #3 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/plugin.php(189): WP_Hook->apply_filters(110, Array) #4 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/formatting.php(3841): apply_filters(‘excerpt_length’, 110) #5 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/class-wp-hook.php(303): wp_trim_excerpt(‘<p>php\xEF\xBC\x98wordpr…’, Object(WP_Post)) #6 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/plugin.php(189): WP_Hook->apply_filters(”, Array) #7 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/post-template.php(429): apply_filters(‘get_the_excerpt’, ”, Object(WP_Post)) #8 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/post-template.php(394): get_the_excerpt() #9 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-content/themes/dekirukana/index.php(17): the_excerpt() #10 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/template-loader.php(106): include(‘/Applications/X…’) #11 /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-blog-header.php(19): require_once(‘/Applications/X…’) #12 /Applications/XAMPP/xamppfiles/htdocs/xxx/index.php(17): require(‘/Applications/X…’) #13 {main} thrown in /Applications/XAMPP/xamppfiles/htdocs/xxx/wp-includes/class-wp-hook.php on line 303

公開環境

  • php7.4
  • WordPress 5.8.3
  • 症状：対象部分が表示されない　 […] だけだ。ループの記事タイトルや、フッターは表示できている。

 

対策

「wp multibyte patch」を停止

以前から運営しているサイトでは、使用している可能性の高いプラグイン。自分もお世話になっています。
100万以上にインストールされているようだ。
<?php the_excerpt(); ?>を使う人がいないのかな。

投稿日:

class.bcn_rest_controller.php on line 64

php８wordpress デバッグモードで、プラグイン　Breadcrumb NavXT　を使用すると下記のようなエラーが表示される。

Deprecated: Required parameter $endpoint follows optional parameter $args in /＊＊＊/public_html/www.komagane-skiclub.com/contents/wp-content/plugins/breadcrumb-navxt/class.bcn_rest_controller.php on line 64

以下のページを参考にさせていただいた。

https://wporg.ibadboy.net/support/topic/php-8-deprecated-class-bcn_rest_controller-php-on-line-64/

もちろん64行目

protected function register_rest_route($namespace, $route, $args = array(), $override = false, $endpoint)
↓
protected function register_rest_route($namespace, $route, $endpoint, $args = array(), $override = false)

投稿日:

WordPress サイトヘルス

環境

  • 仮想　CentOS8
  • ルーター越しにDMZで外部へ公開
  • BIND 稼働

サイトヘルスのステータス

REST API リクエストはエラーのために失敗しました。

解決策

CentOS8 の hosts にローカルIPを追記：192.168.8.13 ****.jp

解決策に至る過程

このままでも、ワードプレスやプラグインの更新ができないわけではない。
調べたページには、パーマリンクや.htaccessをいじることで解決した例がある。
数年前に組んだ CentOS7 の仮想サーバでは、同じ問題が出ていなかった。
このサーバで「Broken Link Checker」が正常に動いていなかったので、hostsいじったなあ、という経験から。自分自身を正常にチェックができないなら、経路の問題ということで、試したら解決。
CentOS8 のLAN設定にDNSに「192.168.8.13」を追加しても解消しなかった。

サーバ本体のドメインは、hostsに反映されていたけど、
サイトを追加するたびに、hosts にも追記が必要なのは面倒だなあ。

投稿日:

headspace2

「headspace2」キャッチコピーはSEO対策用とされているが、デザインの反映に便利なプラグインだ。ページのヘッダーやフッターにコードを入れられるほか、タイトルタグの書き換えなどもできる。
今日現在で2万ほど有効になっているとある。が、もう長いこと新しいワードプレスのバージョンでは動かない。

  • トップページだけ（if(is_front_page() ):でもできる）
  • サイト全体（テーマで対応できる）
  • 各ページごと（類似したプラグインでこれができるのが見つけられない。）
  • カテゴリごと（類似したプラグインでこれができるのが見つけられない。）

このページにも「headspace2」を検証用に入れた。

  • ワードプレス　define(‘WP_DEBUG’, true);
  • https://github.com/blueblazeassociates/headspace2
  • http://blog.it.churaumi.tv/wp-headspace2-warning-declaration

を参考にさせていただき、手元でエラーのない状態にできた。

投稿日:

アクセス多すぎ

あるサイトのお手伝いで、アクセス数を増やしたくて、SEOなんたらのプラグインを試してみた。
いろいろ連携が必要なのですぐ使うのをやめてアンインストールした。

アクセス解析プラグインの記録には、アクセスがガンガン来ているように見える。が、実体はない。

ドメインを変えて、リダイレクトがかかると、追いかけられることはなかった。他のサイトに近いアクセス。

投稿日:

WordPress 脆弱性

２月６日の日付で、Google にて案内がされていた。

4.7、4.7.1 をアップデートして、4.7.2へ。
バージョン情報が、4.7.2の状態でもなぜか、Google Chrome で警告が出たらしい。
WordPress のダッシュボードでもアップデートの案内がある。
マイナーなアップデートが多くあるようだ。

投稿日:

Broken Link Checker　で謎のリンク切れ　700件以上

リニューアルで、ワードプレスのインストールディレクトリを変更。この時点ではリンク切れをなくすことができていた。
次に、サーバを引っ越し

  • Appache
  • MySQL
  • php

それそれ、新しいバージョンのサーバスペースへ引っ越した。
引っ越しは、データをコピー、データベースはエクスポート、インポート。DNS 変更の手順。

ところが、Broken Link Checker　で謎のリンク切れ　700件以上が発生。
対象の記事のデータ（テキストタブ）を探しても、該当するリンク元アドレスはない。
以前、どこかの記事、MySQL の肥大化の記事で、何かしらのバックアップが残ると読んだ記憶があったので、簡単に解決できると思っていたけど、解決する所作を見つけられない。
とりあえず、年ごとに分けているワードプレスの古いものからサイトのメンテナンスをしているうちに、リンク切れが解決していることに気付く。

  • WordPress 自動保存
  • MySQL のバックアップ（？）

を読みこんでエラーが出ている場合は、対象の記事を「更新」することで解決。
ただし、更新してすぐに、Broken Link Checker　でチェックしてもすぐには反映されないので、慌てず、こつこつ。

投稿日:

デザイナー様むけ文字サイズポイントの指定

  1. 1234567890、あいうえお、亜意宇絵尾　この文字は　8ポイント指定
  2. 1234567890、あいうえお、亜意宇絵尾　この文字は　10ポイント指定
  3. 1234567890、あいうえお、亜意宇絵尾　この文字は　12ポイント指定
  4. 1234567890、あいうえお、亜意宇絵尾　この文字は　無指定（15px theme）
  5. 1234567890、あいうえお、亜意宇絵尾　この文字は　14ポイント指定
  6. 1234567890、あいうえお、亜意宇絵尾　この文字は　ポ18イント指定
  7. 1234567890、あいうえお、亜意宇絵尾　この文字は　24ポイント指定
  8. 1234567890、あいうえお、亜意宇絵尾　この文字は　36ポイント指定

 

投稿日:

WordPress サイトルートで wp のディレクトリにリダイレクトされる

サイトルートからみて wp というフォルダにワードプレスを設置。
で、サイトルートのアドレスで表示する場合。
今までできていたのに、最近作成したサイトで普通にこれができない！
数週間、解決できずにいたけど細かく見ていくことで解決。

・アクセス解析では、いったんhome にアクセスしてからリダイレクトされている。
→トップページの設定に「固定ページ」が指定されているとリダイレクトされるね。
→パーマリンクが「基本」以外だとリダイレクトされるね。（ cache の利用が想定されるので数字ベースで設定が多い）
・テーマ内の「index.php」をカスタマイズしていると、リダイレクトが起こらない。

ということで、いろいろいじったり試したりしたけど、固定ページをトップページに表示する設定をやめ、テーマ内の「index.php」で直接トップページになる記事を読み込むように変更。それから、ブラウザのキャッシュがあるとリダイレクトされるので、履歴を消去。（これが良くわからない。最近のブラウザではこれが起こる。説明ページにもわざわざリダイレクトの方法が記述されている。）

これで、サイトルートのアドレスで、ワードプレスのコンテンツを表示できる。

複数のアドレスで同じコンテンツが表示されるのは、SEO的に良くないといわれるけれど、作業的には、経験上これが一番安定していると思う。複数のワードプレス設置も可能だし、トップページの切り替えもストレート。

以前は承知していたと思うけど、遠回りしてしまった。

解決策まとめ（2022年１月　追記）

ワードプレスの階層が違うアドレスとサイトルートで、同じ表示をさせるには、

  • 固定ページをサイトルートに表示する設定ではない（最新の投稿）
  • サイトルートの「index.php」はワードプレスのディレクトリを示す
  • サイトルートの「.htaccess」はワードプレスのディレクトリを示した内容

 

投稿日:

サイトルートに行けない！

１階層下にあるワードプレス。
コンテンツは表示できるけど、サイトルートへ行こうとすると、ワードプレスのディレクトリへリダイレクトされてしまう。

５月の中旬くらいから。

  1. デイレクトリ名を変えたケース
    既存のAというディレクトリ、Bを追加して、サイトルートから見るディレクトリをBに変更した。
    ある環境から、検索で、Aがヒット、そこから、サイトルートを表示しようとしても、Bを表示せずにAを表示してしまう。
    ほかの環境では、ちゃんとBが表示される。
  2. 新規サイトでのケース
    テストページ、ディレクトリCで構築。サイトルートでの表示にOKが出たので、サイトルートからCを表示する設定にする。ここで、サイトルートのアドレスでブラウザに表示させようとするも、ディレクトリCにリダイレクトされてしまう。

1）のケースでは、Aを削除することで、Bが表示されるようになった。
ただし、サイトルートが表示されているかは不明。

2）のケースでは、Cをあきらめて、サイトルートにワードプレスを移築。
ここで、ブラウザによって、リダイレクトの動作に違いが出てくる。
ブラウザとネットワークの設定を確認。
キャッシュ削除とプロキシ自動検出をOFFで期待通りに表示できるようになった。
Firefox とIE はプロキシの自動検出がONだった。

既存のサイトでは、ディレクトリの構造が同じでも、リダイレクトされることはない。

同じサーバでもバーチャルサイトの設定の違いがある？（１.確認できず、2.不明）
サーバの通信環境の設定？（１.キャッシュなし、2.不明）
ブラウザの設定？

ブラウザの設定変更なんて、閲覧者に周知できない！

もしくは、最新ブラウザのバグ？

解決策（2021年１月追記）

・ワードプレスの階層がサイトルートでない状態、
このとき、
ワードプレスの「表示設定」で固定ページを選んでしまうと、サイトルートに行けない。
ワードプレスで階層の違うアドレスとサイトルートで、同じ表示をさせるには、

  • 固定ページをサイトルートに表示する設定ではない（最新の投稿）
  • サイトルートの「index.php」はワードプレスのディレクトリを示す
  • サイトルートの「.htaccess」はワードプレスのディレクトリを示した内容
投稿日:

WordPress 攻撃対策

https://wpdocs.osdn.jp/ブルートフォース攻撃

のページに、リファラーのないPOST を拒否するという手法。
攻撃ロボットがポストするときには、ログインページを開くことなく、POST を繰り返すから、リファラーが違っていれば拒否するという発想。しかも、
RewriteRule (.*) http://%{REMOTE_ADDR}/$1 [R=301,L]
というのは、カウンターアタックになっている。別のサイトにフォームだけおいて、POST してみたら、自分のサーバのエラーページが表示された。

試してみたけど、攻撃は、この条件をクリアしているようで POST に成功しているようだ。ログインページはセキュリティプラグインで変えているのになぜ POST できているのか？

サーバのログを見ると、/xmlrpc.php からポストしている。
xmlrpc も条件に加えて、RewriteRule　をサイトのエラーページにする。

これで様子見。