備忘録: 日本語キーワードに基づいたリンクを本文中に自動設定するWordPressプラグインを試してみる

以下の要件で、キーワードに基づいたリンク設定を本文中で自動的に行うプラグインをあれこれ使って探してみたので、結果をメモしておきます。

  • 管理画面上でキーワード・URLの設定ができる。
  • 日本語キーワードが使える。
  • 本文中に複数存在する場合、最初だけリンク設定する。
  • いつでも使用終了できるよう、投稿内容自体の書換は行わない。

WordPress公式プラグインディレクトリにて非公開(または却下)になっているもの

  • WP Keyword Link(2015.09.21現在非表示になっている)

WordPressの仕様変更による動作不全、日本語非対応などのため使用不可

  • Affiliate Link Builder
  • Auto Affiliate Links
  • Automatic SEO Links
  • SEO Content Links
  • SEO Smart Links
  • Keyword to URL
  • WP KeyLink

投稿内容の書換が必要

日本語対応だけど最初の1つに限定できない

要件を満たすもの


【解決済】さくらのレンタルサーバでPHP5.6を使用すると、file_get_contenst等でSSLエラーになることがある件と、当座の解消法

★追記:2016-04-30

さくらのレンタルサーバの「標準のPHP」が5.6になってたので、改めて確認したところ、SSLエラーは解消されていました。

さくらのレンタルサーバ・さくらのマネージドサーバにて標準のPHP[PHP5] のバージョンを変更します
http://support.sakura.ad.jp/mainte/functionaddentry.php?id=17892

−−−−−−−−−− 以下、解消前の記事 −−−−−−−−−−

スクリーンショット 2015-09-02 10.02.18

しばらく前から、さくらのレンタルサーバでPHP5.6が選べるようになって大変嬉しいのですが、PHP5.6からSSLの扱いが変更になったことと、サーバの証明書の関係で、readfilefile_get_contents などでHTTPSなURLを参照すると、下記のようなエラーになることがあります。

Warning: readfile(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in /foo/var/ssl_test.php on line 1

Warning: readfile(): Failed to enable crypto in /home/foo/bar/ssl_test.php on line 1

Warning: readfile(https://tbx.sakura.ne.jp/test.txt): failed to open stream: operation failed in /home/foo/bar/ssl_test.php on line 1

PHP5.6に設定した後から、他所のファイル読込みやPOSTが一部できなくなって、調べてみたら上記のようなエラーがありました。

root権限のないサーバではやれることに制限があるものの、HTTPSなファイルの読込みを維持したいので、ひとまずは以下のいずれかの方法で解決します。
サポートへリクエストを送ったので、いずれ解消されると思います。

  1. ピア証明書の検証を行わない。 任意の証明書を読ませるオプションを追記する

    php – file_get_contents(): SSL operation failed with code 1. And more – Stack Overflow

    (追記)
    この次の方法でエラーが解消されない場合は、ソースコードをいじることになりますがこの方法が適しています。
    検証を迂回するのはさすがにまずいですね…

  2. php.ini に新しい証明書を認識させる

    ComposerからLaravelを導入しようとしてOpenSSL周りのエラーで困った件 – Qiita

    さくらはphp.iniを編集できるので、新しい証明書を認識させてやります。

    新しい証明書を cacert.crt などにリネームし、適当なところへ配置して下記のようにフルパスを記述します。

    curl.cainfo=/home/foo/bar/cacert.crt
    openssl.cafile=/home/foo/bar/cacert.crt


編集者権限ユーザが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フォントとして使用できるサイズではないので、サブセットを書き出してどこかで使ってみたい。