編集者権限ユーザがWP-Pollsの更新を行えるようにする小ネタ

WP-Pollsは管理者のみ更新可能なので、必要に迫られて編集者でも更新できるようにした際の小ネタ。
プラグイン本体を修正するのはおっかないので、functions.php に追記する方法をとります。

参考サイト

functions.php に追記する内容

function add_wp_polls_caps(){
	$role = get_role('editor');
	if(!$role->has_cap('manage_polls')) {
		$role->add_cap('manage_polls');
	}
}
add_action('admin_init', 'add_wp_polls_caps');

MODX リソース更新時などでAPC Cache/OPcacheをクリアする

APCやOPcacheをインストールしているサーバでMODXを動かしていると、稀に更新が画面に反映されなくて難儀したので、リソースやチャンクの更新時にキャッシュをクリアする方法を検索したもののよくわからず、下記の作業をやってみたら出来たっぽいので書き留めておきます。

  • プラグインを作成
    • プラグイン名: (適当)
    • プラグインコード:
      if(function_exists('opcache_reset')) opcache_reset();
      if(function_exists('apc_clear_cache')) apc_clear_cache();
    • チェックを入れるシステムイベント:
      • OnSiteRefresh
      • OnChunkFormDelete
      • OnChunkFormSave
      • OnDocFormSave
      • OnDocUnPublished
      • OnEmptyTrash
      • OnSnipFormDelete
      • OnSnipFormSave
      • OnTVFormDelete
      • OnTVFormSave
      • OnTempFormDelete
      • OnTempFormSave

リソースやチャンクなどを更新すると、Cached Filesがぐっと減るので、たぶんキャッシュがクリアされてるはず。


livedoor blogからWordPressへ移転する際のパーマリンクに関するメモ

ライブドアブログからWordPressに記事を移転するお仕事した際、なるべくURLを変えたくないなーと思ったのでやってみた作業メモ。

  1. 下準備
  2. WordPress側の設定
    • パーマリンク設定: /archives/%postname%.html
  3. インポート
    • WordPressは、標準でMT形式のインポート機能を追加できる。[ツール > インポート]
    • 環境によっては非常に時間がかかる。
      取込み試験を行ったさくらスタンダードでは、1件につき5秒くらい。ローカル環境では、30分で300件ほど。
    • 取り込んだ後、URLが従前と同じ形式が確認してみる。
  4. ライブドアブログ側のコメントを閉じる。
  5. DNS設定を変更し、移転完了。

パーマリンクの様式をなるべく引き継いだ場合、ひとつ面倒くさくなるのがスラッグの設定。
インポート時、ライブドアブログの記事IDを post_id にできないかといろいろやってみたのですがうまくゆかず、通常通り postname に収めることになったのですが、パーマリンクを post_id ではなく postname にすると、新規投稿を登録するたびにスラッグを設定する必要が生じます。
特に何も考えないと、今まで記事IDだった短いURLが、タイトルから再構成された長ーいものになってしまいます。しかし毎回固有IDっぽいのを割り当てるのも非常にめんどい。
スラッグへIDっぽい文字列を自動で割り当てられたら便利なので、下記サイトのコードを参考にしました。

WordPress の投稿スラッグを自動的に生成する | Simple Colors
http://www.warna.info/archives/2317/

私の場合はこんな塩梅に変更して functions.php に追記しました。

function auto_post_slug( $slug, $post_ID, $post_status, $post_type ) {
	if ( $post_type == 'post' && $post_ID > 0 ) {
		$slug = 60000000 + intval($post_ID);
	}
	return $slug;
}
add_filter( 'wp_unique_post_slug', 'auto_post_slug', 10, 4  );

$post_type == ‘post’ の部分を入れておかないと、固定ページほかあらゆる投稿タイプでスラッグが自動入力されてしまいます。
投稿タイプがpostの場合、WordPressの記事IDに60000000を足した文字列をスラッグに登録します。
60000000は適当です。今現在のライブドアブログ側記事IDが52000000あたりなので、キリの言い数字でスタートすれば分かりやすいかなというふわっとした理由によるものです。
ライブドアブログ側での最終更新の記事IDにちょっと足した数値でも良いでしょう。

記事インポート時はスルーしたいため、 $post_ID > 0 も加えました。
インポート時、wp_insert_post() が動く際には記事IDが確定していないため、$post_idは 0 のままこのフィルタに渡されます。こうしておくとインポート時にはスルーされるようになります(多分)

以上、参考になれば幸いです。


WordPress4.1.1→4.1.2以降/4.2以降にアップデートすると新規投稿できない問題と解消方法のメモ

確認した事象

  • ちょっと古くから使っているWordPressのサイトにおいて、WordPress4.1.1から4.1.2以降へアップデートすると、新規投稿できない/既存記事を更新すると文字化けする。

原因っぽいこと

  • DBがujisのまま
  • DBはutf8だが、一部テーブルのCHARSETがujisのまま(textboxはこのケース)

確認しておくこと

  • DBのダンプデータをエディタ等で開き、「CHARSET=ujis」を検索する。問題が発生している場合、たぶん見つかる。
    (textboxの場合、25テーブル中10あった)

対処方法

  • 暫定措置

    下記フォーラムを参照。
    https://ja.forums.wordpress.org/topic/150103#post-208912
    WordPress4.2.1では2593行目を修正。
    https://core.trac.wordpress.org/browser/tags/4.2.1/src/wp-includes/wp-db.php#L2593

  • ここでやってみた対処方法

    フォーラムにはCHARSETを変換するのが良さそうとあったので、この際だからきちんとやってみる。

    • 作業前提
      • DBは charset utf8 にしてあった
    • やったこと
      • mysqldumpするかphpmyadminでエクスポート
      • 書き出したデータを開いて、CHARSET=ujis を CHARSET=utf8 に置換
      • utf8なDBを新たに作ってインポート
      • wp-config.php のDB設定を変更して再ログイン
      • 新規投稿できるか確認する

うまいこと投稿できるようになりました。ありがとうございました。


QuickCacheがZenCacheになった

Image 2015-03-16 at 3.05.36 午後

WordPressのキャッシュプラグイン「QuickCache」の有料版がとても便利なので、「QuickCache Proを使うべきn個の理由」みたいな記事をいずれ書こうと思ってたら、「ZenCache」になって価格設定が変わり、有料版を少し勧めづらくなってしまいましたが、今のお仕事では欠かせないプラグインです。

キャッシュの生成条件が柔軟で、UserAgentやCookieの値によって別々のキャッシュを生成できるので、端末や任意の機能による表示切替が容易に行えて便利です。
他のキャッシュプラグインは分からないのですが、 require(‘wp-load.php’); が入っている外のページもキャッシュしてくれます。

従前のライセンスを購入してる人は、自動的に3年間のUnlimited-Site Licenseが与えられてるので、ちょっとお得。

マルチサイト運用の場合、一部の不具合が残っているので、ZenCacheに移行する際はご注意ください。

あとこれも。


謹賀新年

本年もどうぞ宜しくお願い申し上げます。


clearQueue() や stop() でクリアできない時

なんかどういうわけか、$(‘foo’).clearQueue() をやってもキューがうまくクリアされない事が今日もあり、色々試してみたところ、
$(‘foo’).clearQueue().stop().clearQueue()
とやったらようやくクリアされた。上記の解消法は偶然かと思ったけど、今回も同様だった。不思議。


Source Han SansとNoto Sans Japaneseをfont-familyに適用してみる

日本語入り能登さんとソースさんをfont-familyで使ってみるテスト。

Noto Sans Japanese

font-family: "Noto Sans Japanese",  sans-serif;
font-weight: normal;

sample1b

Source Han Sans

font-family: "Source Han Sans", sans-serif;
font-weight: normal;

sample1a

font-weight:normal の場合はどちらも変わりないのですが、font-weight:100 の場合はちょっと違いました。

Noto Sans Japanese

font-family: "Noto Sans Japanese", sans-serif;
font-weight: 100;

sample2b

Source Han Sans

font-family: "Source Han Sans",  sans-serif;
font-weight: 100;

sample2a

Source Han Sans の場合は ExtraLight が表示されるのに対し、Noto Sans Japanese は Thin じゃなくて Light の模様。

ついでに16pxで100から900まで指定してみる。

Noto Sans Japanese (16px)

Source Han Sans (font-size 16px)

そのままではWebフォントとして使用できるサイズではないので、サブセットを書き出してどこかで使ってみたい。


2014 謹賀新年

2014

これからも細々と宜しくお願い申し上げます。


[WordPress小ネタ] 特定のタグを設定した時、投稿表示の前に確認文言を表示する

制約のあるコンテンツを表示する前に、確認事項の同意をとっておきたい時などに使えるかもしません。
single.php の the_content() の部分を下記の具合に変更し、

if(has_tag("foo")) {
	if(isset($_COOKIE["hogehoge"])) {
		the_content();
	} else {
		※ 確認文言 ※
	}
}

この確認文言の中のどこかに、下記のようなcookieをセットするJavaScriptを入れ、クリックを促します。

<a href="javascript:void(0);" onclick="document.cookie='hogehoge=1';location.reload();">確認事項に同意します</a>

きちんとcookieがセットされれば、the_content() が表示されるはず。

» サンプル