/* ---------- 文言「非公開：」を変更 ---------- */
function remove_page_title_prefix( $title = '' ) {
	if( empty( $title ) ){
		return $title;
	}
	$search = '/^' . str_replace('%s', '(.*)', preg_quote( __( 'Private: %s'), '/' ) ) . '$/';
	return preg_replace( $search, '会員限定：$1', $title );
}
add_filter( 'the_title', 'remove_page_title_prefix' );

元は「非公開：」の文言を削除するコードです。

そもそも非公開記事はログアウト状態では出力されないので文言を変えてもあまり意味ないですが、管理者、編集者用とかにすれば、管理上はわかりやすいかも。

参考：[WP]非公開記事のタイトルで「非公開:」の文字を表示しない方法

パスワード保護の「保護中：」を変更

こっちはもう少し需要があると思います。

/* ---------- 文言「保護中」を変更 ---------- */
function edit_protected_word (){
	return 'パスワードが必要です：%s';
}
add_filter( 'protected_title_format', 'edit_protected_word' );

非公開記事の閲覧権限を拡張する

非公開記事は、管理者権限と編集者権限でログイン中のみ出力されますが、他の権限でも閲覧できるようにしよう、というコードです。

「非公開 = 会員限定」にしたいケースでお手軽。

/* ---------- 非公開記事の閲覧権限を追加「購読者」 ---------- */
function add_read_private_subscriber(){
	$subscriber = get_role( 'subscriber' );
	$subscriber->add_cap( 'read_private_posts' );
}
add_action( 'admin_init', 'add_read_private_subscriber' );

/* ---------- 非公開記事の閲覧権限を追加「寄稿者」 ---------- */
function add_read_private_contributor(){
	$contributor = get_role( 'contributor' );
	$contributor->add_cap( 'read_private_posts' );
}
add_action( 'admin_init', 'add_read_private_contributor' );

/* ---------- 非公開記事の閲覧権限を追加「投稿者」 ---------- */
function add_read_private_author(){
	$author = get_role( 'author' );
	$author->add_cap( 'read_private_posts' );
}
add_action( 'admin_init', 'add_read_private_author' );

参考：https://eguweb.jp/wordpress/42554/

権限を元に戻す

上記コードを一度読み込むとデータベースに保存されますので、権限を削除したい場合は上記コードを削除したうえで、以下のコードをロードします。

/* ---------- 非公開記事の閲覧権限を削除「購読者」 ---------- */
function remove_read_private_subscriber(){
	$subscriber = get_role( 'subscriber' );
	$subscriber->remove_cap( 'read_private_posts' );
}
add_action( 'admin_init', 'remove_read_private_subscriber' );

/* ---------- 非公開記事の閲覧権限を削除「寄稿者」 ---------- */
function remove_read_private_contributor(){
	$contributor = get_role( 'contributor' );
	$contributor->remove_cap( 'read_private_posts' );
}
add_action( 'admin_init', 'remove_read_private_contributor' );

/* ---------- 非公開記事の閲覧権限を削除「投稿者」 ---------- */
function remove_read_private_author(){
	$author = get_role( 'author' );
	$author->remove_cap( 'read_private_posts' );
}
add_action( 'admin_init', 'remove_read_private_author' );

記事の公開状態によらないケース

「非公開 = 会員限定」にしてしまうと、本当に非公開にしたい場合、ステータスを「下書き」にするくらいしか思い当たりません。

これは結構不便。

すぐに思いつくのは、カスタムフィールドなどでフラグを立て、ループ中で条件分岐を行う方法。

if( カスタムフィールドなどの限定公開オプション：ON ){
	if( is_user_logged_in() ){
		echo '記事のループ用の内容';
	}
}else{
	echo '記事のループ用の内容';
}

※タグ、カテゴリー、ターム操作でも出来ると思いますが、面倒くさそう。

※「記事のループ用の内容」が、メインループ、各サブループで共通になってないと何か所も変える必要が出てきます。

※シングルにも同じような制御が必要です。

お手軽ゆえ

これなら、ログイン状態による制御と、公開・非公開による制御、両方が行えますが、
記事の総件数やページ送りがおかしくなる問題アリ。

ので、しっかりやるなら

サブループ：new WP_Query()の引数での操作
メインループ：add_action( ‘pre_get_posts’, ～ )での操作

などの改変で対応する必要があります。

ここまでやるなら「公開・非公開」を工夫した方が手間が少なさそうです。

2022年07月28日

WP同士の記事インポート画像取り込みプラグイン

よく使うプラグイン、久しぶりに更新。

Export media with selected content
エクスポートファイルがなんかデカい

Export media with selected content

記事のインポートで面倒くさい「記事中の画像とアイキャッチ」の取り込み。

色々なプラグイン、やり方がありますが、「Export media with selected content」がえらく簡単にやってくれる。

有名なのかな？記事もたくさん見つかりますが、下記を参考に。

【WordPress】ブログの記事と画像を、別サイトに移行する方法

※記事中、プラグイン名のスペルが違ってるのでライブラリから見つからなくて焦った。

エクスポートファイルがなんかデカい

プラグインを有効にすると「Export media with selecter content」のオプションが追加されます。

で、エクスポートしてみるとやけに時間が掛かるし、ファイルサイズもかなりでかい。

多分、画像そのものを吸い出してるんだと思う。

で、取り込む側は「添付ファイルをダウンロードしてインポートする」にチェックを入れるだけ。

アイキャッチもバッチリ再現される。

カスタムフィールドに挿入した画像もOK。

後処理は何もなし。

全てのケースにおいてコレだけで済むかは分からないけれど、通常のインポートはかなり楽できる。

2022年03月24日

クローズドサイト向けプラグイン

会員限定、社内用サイト等、登録ユーザーだけが閲覧できるサイトを作る時に便利なプラグイン。

全部公式ディレクトリにあるのでリンクはなし。

ユーザーをCSVでインポート
- Import and export users and customers
  - - 「Force users to reset their passwords?」
    - 「Never update passwords?」
- Import Users from CSV
ログイン・ログアウト
- WP Maintenance Mode
- Maintenance

ユーザーをCSVでインポート

Import and export users and customers

翻訳されると「ユーザーと顧客のインポートとエクスポート」。

CSVでインポート・エクスポートが出来る。

設定項目も多くて便利そうなんだけど、パスワード周りが難しい。

CSV通りにインポートしたいのだけれど、どうしても変わっちゃう。

「Force users to reset their passwords?」

Yes/No

「Never update passwords?」

ドキュメンテーションに記載されているパスワードに更新
ユーザー更新の際にパスワードを更新しない
はい。新しい権限グループを追加し、既存のものを上書きしません

こういった選択肢があるけれど、どれを選んでもCSV通りにならない。

エクスポートしても、やはりデータ通りにならない。

ダウンロード数、★の数ともにダントツだったので、何か設定を間違ってるんだと思うけれど、今回は単純なインポートだけできれば事足りる案件だったのでパス。

Import Users from CSV

こっちはインポートだけ。

オプションもほとんどないけど、パスワードは素直にインポートしてくれた。

今回はこちらで。

管理画面からダウンロードできるサンプルのCSVでは、

「user_login,user_email,user_pass,first_name,last_name,display_name,role,custom_usermeta_1,custom_usermeta_2」

以上のデータが例示されてるけど、

「show_admin_bar_front」（フロントエンドにツールバーを表示する／しない）もインポートできた。

WP標準のテーブルは普通にインポート出来るんだと思う。

ログイン・ログアウト

色々なやり方があると思うけど、今回はログアウトしたらすぐに閲覧できなくしたかった。

WP標準のパスワードやベーシック認証だと、クッキーの有効期限内だと閲覧できちゃう。

ので、今回はメンテナンスモードを利用。

WP Maintenance Mode

WP標準のログイン画面に近い。

「メンテナンス中」等の文言は変更可。

ある程度のCSSは、管理画面でコントロールできる。

ログイン後のリダイレクト、アナリティクス、no-index等のメタタグなど、いろいろ細かく設定できる。

Maintenance

翻訳されると「メンテナンス」。

ログイン画面は独自デザイン。こちらもある程度のカスタマイズは可能。

「メンテナンス中」等の文言も変更可。

リダイレクト、アナリティクス、メタタグ等のオプションは無し。

「WP Maintenance Mode」は一度動作が不安定になった。（ログイン不能）

別ブラウザ・別アカウントでも管理画面を開いていたので、プラグインの無効化⇒有効化をしたところリセットできたようで、その後は安定。最悪FTPでプラグイン削除が必要だったかも。

細かい設定が必要なければ「Maintenance」でも十分かな。

2022年01月27日

2022年02月16日

wp_is_mobileの判定や、新旧iPadの挙動など

最近のiPadでは「SafariとChromeで表示がいろいろ変わっちゃう」というところから始まり、改めて確認したり、実機を数種試してみたところでメモ。

wp_is_mobileの中身
wp_is_mobileやuser agentなどを色々なデバイスで見てみる
参考：user agent（Safari）のコピペ
サブメニューの挙動
- 今のところ、新旧iPadで期待通り動くスクリプト
キャッシュ
- 新しいiPadでも、SafariとChromeの表示を常に合わせる

wp_is_mobileの中身

元々どういう目的で作られたものかは知りませんが、中身は

ブラウザ情報を覗いて
あらかじめ設定された文字列が含まれていたら
文字列ごとに条件分岐して
真偽を返す

というだけのもの。

「is_mobile」も中身は大体同じと思います。

wp_is_mobileやuser agentなどを色々なデバイスで見てみる

現在、ブラウザ右に貼り付いている青いヤツで確認。

厄介なのが最近のiPadのSafari。（調べたのは第4世代iPad Air、OS 15.2～）

mobile判定、user agent、デバイス情報がくっちゃくちゃな感じ。

デフォルト（環境設定（Safari）「デスクトップ用Webサイトを表示」オン）
wp_is_mobile：false、またuser agentにiPadを含まない
環境設定（Safari）「デスクトップ用Webサイトを表示」オフ
wp_is_mobile：true、またuser agentにiPadを含む

無理矢理まとめると、

基本的にはタッチデバイスであり大画面でもある。
wp_is_mobileの判定は、ユーザーの設定次第で変わる。
また常に「iPadである」と特定できるuser agentは無いので、wp_is_mobileをカスタマイズしてもどうにもならない。

「iPad Safari is_moile」等で探すとたくさん見つかる記事の通り。

アップルはなぜこうしているか、をどこかの記事で見かけた気がするのですが、URLを失念。

たしかこんな感じだったと記憶しています。

十分に大きいスクリーンでは、（タッチデバイスであっても）PC用サイトを表示すべき

一方グーグルは、

スマートフォン、タブレットでは、mobile用サイトを表示すべき

のようなことを言っていると思う。（mobileに最適化されたサイト、だったかな？）

参考：user agent（Safari）のコピペ

古いiPad Air

Mozilla/5.0 (iPad; CPU OS 12_5_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.2 Mobile/15E148 Safari/604.1

第4世代iPad Air

デフォルト
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15
「デスクトップ用Webサイトを表示」をオフ
Mozilla/5.0 (iPad; CPU OS 15_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Mobile/15E148 Safari/604.1

iPhoneXS

デフォルト
Mozilla/5.0 (iPhone; CPU iPhone OS 15_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Mobile/15E148 Safari/604.1
「デスクトップ用Webサイトを表示」をオン
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15

サブメニューの挙動

wp_is_mobileで色々制御していて、SafariとChromeの違いで一番困るのがサブメニュー付きのナビゲーション。

構文は、ワードプレス標準のメニューと仮定して、、

CSS :hoverでサブメニューの出し入れ、アンカーの挙動をdoubletaptogoなど制御している場合、古いiPadやAndroidでは期待通り動く。
新しいiPadでは、タップでサブメニューは開くが、この状態でさらに2回タップしないと遷移しない。（tripletaptogoになっちゃう）

ほかにも、親項目が「<a>アンカー</a>」だとサブメニューが開かなかったり、bodyのタップでサブメニューが閉じたり閉じなかったり、と色々。

今のところ、新旧iPadで期待通り動くスクリプト

jQuery(document).ready(function(){
	jQuery('#navigation-menu ul li').hover(function(){
		jQuery('ul:not(:animated)', this).slideDown(100);
	}, function(){
		jQuery('ul.sub-menu', this).slideUp(100);
	});
	jQuery('#page').on('click', function(e){
		jQuery('ul.sub-menu', this).slideUp(100);
	});
});

#navigation-menuは、メニューのラッパー。メニュー名で左右されたくないので。

範囲外をタップで閉じるようにしていますが、「body」だと閉じないので、ひとつ内側のラッパー（ここでは#pageにしてますが、テーマによってマチマチなはず。）にしています。

参考記事：jQuery: ドロップダウンメニューの作り方

キャッシュ

Is_mobileの判定でいろいろやってる場合、SafariとChromeを行ったり来たりすると、キャッシュによってis_mobile状態も維持されて非常に不安定。

キャッシュ関係のプラグインは一切なし。

同じURLを違うブラウザでしつこく閲覧する、という開発者ならではの行動なので、それほど気にしなくていいとは思うけど、、、

キャッシュ共有の仕組みは調べてもよくわからない。AMPなんとか？？

新しいiPadでも、SafariとChromeの表示を常に合わせる

メディアクエリー・スクリーンサイズでの振り分けが一番簡単ですが、ナニカ事情がある場合。

1、Safariでも常にハンバーガーを出す

JavaScriptのタッチデバイス判定だけ。簡単で、動作も一番確実だと思います。

タッチデバイスではハンバーガー
非タッチデバイスではPC用

1-b、「IE非対応」で良ければ

IE無視なら、JacaScript不要、メディアクエリーだけでも処理できます。

PC用	{
	display: none;
}
ハンバーガー	{
	display: block;
}
@media ( hover: hover ) and ( pointer: fine )	{
	PC用	{
		display: block;
	}
	ハンバーガー	{
		display: none;
	}
}

タッチデバイス判定や、:hoverに関するあれやこれやも簡単に処理できるので、これからは多用しそう。

参考：下記記事で詳しく解説されています。いろいろ出来るのね～。

CSSのメディアクエリを使ってレスポンシブに対応させる書き方

2、ChromeでもPC用ナビを出す

これはかなり面倒だし、よくよく検証しないとアブない。

タッチデバイスではハンバーガー
非タッチデバイスではPC用ナビ
user agentに「iPad」が出現していて、かつスクリーン短辺が820px～ならば、例外的にPC用ナビ（OSのバージョンでもいいかもだけど、どっちが長期間確実かなぁ？？わからん。）

2-b、縦位置ではハンバーガーを出す

さらに「縦位置ではハンバーガーを出す」なら更に縦横条件を追加するわけだけど、今度はSafari用にも指示が必要。

こっちにはキーワード「iPad」が出現しない可能性大なので、

タッチデバイス
user agentにMacintoshまたはiPadが出現
スクリーン短辺が820px～
縦位置

を満たすように条件づければいいはず。ややこしいね。

さらにさらに

ナビゲーションを上部に固定するような場合、ページ内遷移用にスクリプトを使うケースが多いと思います。

これもハンバーガー・PC用ナビで多少の差があるはずなので、スクリプトにも条件分岐を入れて切り替えなきゃならない。

JavaScript、なんちゃってメディアクエリー

screenじゃなくてwindowでやればもっと簡単ですが、CSSやディベロッパーツールと合わせたかったので。

jQuery(function(){
	var screenWidth = screen.width;
	var screenHeight = screen.height;
	if ( screenWidth <= screenHeight ) {
		var screenLongSide = screenHeight;
		var screenShortSide = screenWidth;
	} else {
		var screenLongSide = screenWidth;
		var screenShortSide = screenHeight;
	}
	var breakPointMiddle = 768;
	var orient = window.onorientation;
	if( Math.abs( window.orientation ) === 0 || Math.abs( window.orientation ) === 180 ){
		if ( screenShortSide > breakPointMiddle ){
			var view_wide = 'wide';
		} else {
			var view_wide = 'narrow';
		}
	} else {
		if ( screenLongSide > breakPointMiddle ){
			var view_wide = 'wide';
		} else {
			var view_wide = 'narrow';
		}
	}
	/* ---------- デバイス水平方向幅で分岐 ---------- */
	if ( view_wide === 'narrow' ) {
		var headerHight = 65;
	} else {
		var headerHight = 105;
	}
});

スムーススクロールの余白切り替えなどに。

ハンバーガー、PC用ナビの高さを同じにしちゃう、って手もあるけど、、、

「Jquery依存スクリプトでブレークポイント使ってるの、あったなぁ」と思いだして調べてみると、やっぱりあった。

「window.matchMedia」だけで出来るのね。

:hoverイミュレーションを検知できないのかな、と思って少し検索すると、それっぽい記事がわんさか見つかる。古いiOSでの不具合とか、むしろ:hoverを無効にしたいとか。議論の種だったのね。

「タッチしたつもりなのに遷移しない」と感じることが多いけど、これか。

キチンと調べたら、この記事も色々ひっくり返りそう。

※余談。JavaScriptの判定をそのままphpの関数に出来たらかなり便利な気がしますが、ajaxを使わないと無理みたいで手に余る。でもそのうちチャレンジしてみようかな。

キリがないので、結局JavaScriptのスクリーン幅判定だけで制御することにしました。

ナビゲーションについては、でかければPC用・小さければハンバーガー
サブメニューはタッチデバイスでもどうにか動かす。
wp_is_mobileは一切使わない

まだまだスッキリはしていませんが、ひとまずここでひと区切り。

発見・再認識がたくさんありました。

ブログ記事一覧