ダリの雑記：WEBプログラム版

タイトル・内容のフック場所は、フロントエンド、管理画面で異なるので注意が必要です。

フロントエンドの場合

//タイトルにフックをかける（the_titleをフック）
add_filter('the_title', hoge_the_title, 1);

//内容にフックをかける（the_contentをフック）
add_filter('the_content', hoge_the_content, 1);

バックエンドの場合

//投稿一覧のタイトル表示にフックをかける（the_postをフックし、内部で処理）
add_filter('the_post', hoge_the_post, 100);
function hoge_the_post($post){
//$post->post_titleを編集する　例：$post->post_title = htmlspecialchars($post->post_title);
return $post;
}

//編集画面のタイトル入力フィールドにフックをかける（title_edit_pre'をフック）
add_filter('title_edit_pre', hoge_the_title, 1);

//編集画面の内容フィールドにフックをかける（the_editor_contentをフック）
add_filter('the_editor_content', hoge_the_content, 1);

単純に、the_titleやthe_contentにフックするだけでは、管理画面の方で反映してくれないので注意。

特に投稿一覧では、表示だけならthe_titleのフックで行けますが、クイック編集の方にも反映させる場合は、the_postにフックし、$post->post_titleに処理を加える必要があります。

固定ページでも、子ページを一覧で表示するなどの使い方をする場合があります。

その際に任意に設定できる抜粋がないと非常に困る（WPデフォルトでは無い）

固定ページでも抜粋を付ける場合は、使用しているテーマのfunction.phpにこれを追記します

add_post_type_support( 'page', 'excerpt' );

これで固定ページの編集画面にも抜粋が表示されるようになります

フォームから送られてきたファイルをメディアに登録されるようにするプログラムを作っていたのですが、実際にメディアには登録されるけど一覧でサムネイルが表示されない・・・

で、Codexをよく見たら、wp_insert_attachmentのあとに下記2つの関数も実行しなくてはならないとのこと

wp_generate_attachment_metadata
wp_update_attachment_metadata

さらにこの関数を実行するには、

require_once( ABSPATH . 'wp-admin/includes/image.php' );

の必要があります。

つまりこんな感じ。

require_once( ABSPATH . 'wp-admin/includes/image.php' );

$attachment = array(
'guid' => "（ファイルのURL）",
'post_mime_type' => "（ファイルのタイプ）",
'post_title' => "（ファイルのタイトル）",
'post_content' => '',
'post_status' => 'inherit'
);

$attach_id = wp_insert_attachment( $attachment, "（ファイル名）", 0);
$attach_data = wp_generate_attachment_metadata( $attach_id, "（ファイルのパス）");
wp_update_attachment_metadata( $attach_id, $attach_data );

これで、メディアに登録される際にサムネイルも生成されるようになりました。

今日、Movable Type6でフォルダーを作成し、「変更を保存」ボタンをクリックしたところ、以下のエラーがアラートで帰ってきました。

Ajax error: error

・・・なにこれ？

さらにカテゴリーのほうでも、同様に上記のエラーが出て保存できない。

どうしてもカテゴリーとフォルダーを追加しなくてならなかったため、phpMyAdminを入れて、そっちでデータベースに直接入れてみようかと思ったところ、なんかこっちでもエラーが出てSQLがちゃんと実行されない！？

MTに引き続きphpMyAdminでも起こるって、ほんとなんだこれ！

と思っていたら、後輩が「もしかして、WAFのせいかも」との一言。

なるほど、可能性はあると思い、サーバーのコンパネに入りWAFの設定を変更したところ、正常に動作するようになりました・・・

あー、冷や汗かいた・・・

WAFってセキュリティ高めてくれるのは良いんですが、どうも苦手です。

ちなみに今回のサーバーはzenlogicでした。

皆さんも注意しましょう。

WordPressで予約公開ができない場合、原因は色々とあります。

このことは色んなサイトで紹介されています。

• WordPressの予約投稿が失敗した時に試す4つの解決策 | OXY NOTES
• WordPressの予約投稿に失敗する原因と見るべき重要ポイントのまとめ！ | 自作PCテクニカルセンター

でも、たまに公開に失敗するなど原因がよくわからない不具合も起こります。

WordPressの予約投稿は、
一定のアクセスがないと実行されないという仕様になっています。

アクセスがないブログは予約投稿ができないといっても過言ではありません。

WordPressの予約投稿に失敗する原因と見るべき重要ポイントのまとめ！ | 自作PCテクニカルセンター

という話まであり、正直Wordpressの予約公開はあまり信用できません。

ということで、解決方法として、こんな感じのプログラムをheader.phpの先頭に入れてみました。

if(is_home() || is_front_page()){
	//予約の投稿のみ取得（MAX20件）
	$get_posts = get_posts(array(
		"posts_per_page" => 20,
		"post_type" => "any",
		"post_status" => "future"
	));

	if($get_posts){
		foreach($get_posts as $get_post){
			//現在が予約日時を過ぎている場合
			if($get_post->post_date < current_time("Y-m-d H:i:s")){ 
				//公開処理 
				$save_post = array(
					"ID" => $get_post->ID,
					"post_status" => "publish"
				);
				wp_update_post($save_post);
			}
		}
	}
}

※トップページアクセスの場合のみ反応するようにしています。

post_statusがfutureになっている記事だけ取得し、予約日時が過ぎているものだけ、publishに更新するという簡単なプログラム

ちゃんと動いているし、負荷もそれほどかからないし問題なさそう。（※動作に責任は持ちません）

マルチサイト化されているWordpressのサーバーを移転したところ、参加サイトが表示されなくなってしまいました。

↓この部分

もちろんログインしたアカウントはすべてのサイトに所属しています。

プラグインのせいかと思って全部切ってみたのですが、治らず。

移転時にバージョンアップしたからかとも思いましたが、他のサイトで使っている同じバージョンのWordpressでは、こんな問題は起きたことがありません。

移転中だったのでベーシック認証をかけていたのですが、まさかこれじゃないだろうと思いながらも試しに解除してみたら、表示されるようになりました！

原因はベーシック認証！

こんなことあるのか・・・

ちなみに、一度表示されるようになったら、以降は再びベーシック認証をかけてもちゃんと表示されます。

ちょっと古い情報ですが、Wordpressのバージョン4.7と4.7.1はかなりヤバイ脆弱性があるそうです。

WordPress の脆弱性対策について：IPA 独立行政法人 情報処理推進機構

WordPress 4.7, 4.7.1 はAPIに致命的なバグがあって認証無しで誰でも記事を改ざんできちゃうっぽい！ - かもメモ

上記のサイトに方法が記載されておりますが、簡単に改ざんできてしまうとのこと。

簡単過ぎる！怖い！

4.7から4.7.1へのアップデートは、PHPMailerの件ですぐにアップデートされることは予想しておりましたが、またすぐに4.7.2へのアップデートでしたので、何事？と思っておりましたが、これはかなりやばい脆弱性ですね。

すぐにアップデートするのは考えものですね・・・

ちなみに、Search Consoleでもこのような警告が出てしまう始末

貴サイトが WordPress の古いバージョンである WordPress 4.7.0 or 4.7.1 を実行していることが判明しました。古いバージョンやパッチを適用していないソフトウェアは、ハッキングやマルウェアの攻撃を受けやすくなり、貴サイトの訪問者に被害が及ぶことがあります。そのため、サイト上のソフトウェアをできるだけ早く更新することをおすすめします。

おすすめどころではない、必須事項でしょ。

自分のブログも一瞬だけ4.7.1にしておりましたが、すぐさま4.7.2にアップデートしました。

※これは、現在最新バージョンである4.7.1で確認しています。

WordPressの管理画面にログインし、以下の手順で記事を作成してみてください。

①新規投稿で、スラッグ名をhogeと設定し、公開保存する。
②再び新規投稿で、スラッグ名をhogeと設定し、下書き保存する。（実際はhoge-2に変わりますが気にせずに）

※①と②の記事は別の記事です。
※スラッグ名は手動で設定してください。

①の投稿ページを、別のブラウザか、Wordpressからログアウトして開いてみてください。
公開しているにも関わらず、エラー４０４ページになってしまいます。
（pre_get_postsなどで、投稿詳細ページの取得ルールを変えている場合は起こらない可能性があります）

原因

②の投稿を作成する際、スラッグ名を「hoge」と入力すると、重複を回避するため「hoge-2」と表示されるのですが、実際は下書き保存では「-2」はつかず、そのまま「hoge」と保存されてしまいます。（データベースを確認すると、postnameがhogeとなっているレコードが２つ確認できます）

そのため、①のページを開こうとした際、②の投稿データを取得してしまい、しかし下書きのため４０４ページとなってしまうわけです。

ちなみに投稿詳細ページでのデータ取得の順番は公開日時順になっているらしく、②の下書き投稿が①の公開投稿よりも過去の公開日時に設定していると、①の投稿ページは正常に表示されます。

この現象が発生する条件は正確には以下となります。

• スラッグ名を設定することができるパーマリンク設定になっていること
  （%postname%が含まれる設定の場合）
• 投稿タイプが「投稿」であること
  （固定ページではこの現象は起きない）
• 投稿の作成・編集時にスラッグ名を任意に設定すること
  （WPがタイトルから自動的に生成する場合は、重複してもこの現象は起きない）
• 設定したスラッグ名に自動的に連番がつくこと
  （すでに公開されている投稿記事が存在している場合）
• 保存時に下書き保存すること
  （公開保存なら大丈夫）
• 下書き保存した投稿記事と同じＵＲＬの公開中の記事が存在すること
  （連番なしのURLと完全一致する公開中の投稿記事があること。日付やカテゴリーがパーマリンクに含まれる場合で、これらが異なる場合はこの現象は起きない）
• 公開保存されている投稿より、下書き保存した投稿の方が、公開日時が未来に設定されていること

という条件なので、投稿でも命名規則を決めてスラッグ名をきっちり設定するという運用を行っている（例えばニュースなら「news20160120」と設定する）サイトの場合以外は起きないので、なかなか見つかりづらい不具合ではあると思われます。

対策

ひとまず４０４エラーを回避する方法ですが、functions.phpに以下を追記すると、回避できます。

add_action('pre_get_posts', 'custom_pre_get_posts' );
function custom_pre_get_posts($query){
if ( is_admin() || ! $query->is_main_query() ){
return;
}
if($query->is_single && !$query->is_preview){
$query->set( 'post_status' , 'publish');
}
}

要するに、公開されているものを開けばよいのですが、なぜ下書きのものを取得しようとしてしまうのか、不思議です・・・

なお、この方法で４０４エラーは回避できますが、もう１つ問題があります。

該当の公開中の記事を編集すると、こっちは重複を回避しようとしてスラッグ名の後ろに「-2」がついて保存されてしまうことです。（なんでやねん）

スラッグ名が変わっても、一応リダイレクトしてくれるみたいですが、下書きの方の記事が「hoge」で公開保存されたら、完全に入れ替わっちゃいます。

結局気を付けるしかないのが現状ですね・・・

冒頭でも書いていますが、これはバージョン4.7.1で起こっています。

もしかしたらこれより古いバージョンでは起きないかもしれません。

また、さらにバージョンアップされたら起きなくなるかもしれません（というか起きなくなってくれ）

フック！フック！フック！

フックは便利ですね！

ということで、テーマで投稿一覧の各投稿のメニューをカスタマイズする方法のメモです。

下図のように、メニューに「サンプル」を追加する場合

テーマのfunctions.phpに以下を追記します。

function custom_post_row_actions($actions, $post) {
//$actions['（キー）'] = '<a href="（リンク先）" title="">（ラベル）</a>';
$actions['sample'] = '<a href="/sample.php" title="">サンプル</a>';
return $actions;
}

add_filter('post_row_actions', 'custom_post_row_actions',10,2);

いらないものを消す場合は、unsetします。（以下クイック編集を削除する）

function custom_post_row_actions($actions, $post) {
unset($actions['inline hide-if-no-js']);    //クイック編集
return $actions;
}

add_filter('post_row_actions', 'custom_post_row_actions',10,2);

以下デフォルトのメニューです。

参考サイト

投稿一覧に独自リンクを追加する:WordPress私的マニュアル

このサイトのURLを

https://nandani.sakura.ne.jp/

から

https://nandani.sakura.ne.jp/

に変更しました。（wwwなし）

理由はwwwあり・なし両方でアクセスできるとSEO的に良くないのが１点（いまさら）

もう１つは、さくらインターネットのサブドメイン（○○○.sakura.ne.jp）でSSLが使えるのが、www無しのみだったので、https://nandani.sakura.ne.jp/をメインURLとしました。（httpsの方がSEO的に良いらしいので。さくらインターネット特有のくせで、記事ページにhttpsでアクセスするとおかしくなるため、まだ変えてませんが。）

そうしてみたところ、Search Consoleのインデックス数が激減。

まあ当たり前です。

これまでは「https://nandani.sakura.ne.jp/」で登録されていたのに、wwwなしになったわけですから。

しばらくしたら治るだろうと思っていたのですが、一向に増える気配はなく、何ならどんどん減っていきます。

ただでさえ減ってたのに！

なんで？と思い、よくよくSearch Consoleに送っているsitemap.xmlを見てみたら、そこに記述されているURLが「https://nandani.sakura.ne.jp/」になっているではありませんか。

サイトマップ書き出しには「Google XML Sitemaps」を使っているのですが、どうやらキャッシュっぽい感じで残っており、それが送信されてたらしい。

通りで全然インデックスされないわけだ。

ということで、設定＞XML-Sitemapから設定を更新したら、無事「https://nandani.sakura.ne.jp/」で出力されるようになりました。

インデックスが減っていたとはいえ、あんまりアクセス数は変わってないんですよね。

メインの流入はGoogleからのはずなんだけどなぁ。