WordPress管理画面でDatepickerを使う

プラグインを作成してWordPressの管理画面に追加したページで、日付入力フィールドにjQueryのDatepickerを使いたい。

プラグインフォルダに追加して自分で登録しようと思っていたら、そもそもWordPressではjQueryを使っているので、わざわざそんなことをしなくていいらしい。

まず、wp-includes/script-loader.php で使いたいスクリプトの登録名を確認する。
Datepicker なら、'jquery-ui-datepicker' となっている。

プラグインで管理画面に追加したページだけでスクリプトを読み込む場合は、以下のようにする。

add_action('admin_menu', 'add_dashboard');

function add_dashboard() {
    $hook_suffix = add_submenu_page( $parent_slug, $page_title, $menu_title, $capability,    $menu_slug, $function );
    add_action("admin_print_scripts-".$hook_suffix , 'my_plugin_admin_scripts');
    add_action("admin_head-".$hook_suffix , 'my_plugin_admin_css');
}

// 使用したいスクリプトを読み込む
function my_plugin_admin_scripts() {
    wp_enqueue_script('jquery-ui-datepicker');
}

// スクリプトで使用するCSSを読み込む
function my_plugin_admin_css() {
　　wp_enqueue_style( 'my_plugin_admin-style', $plugin_url . '/my_plugin_admin.css' );

}

Datepicker のスタイルについては、ThemeRoller から別途ダウンロードして、上記my_plugin_admin.css のように読み込む。

たまにしか使わないので、日付書式の設定と初期値の設定方法もメモ
<script>
jQuery(document).ready(function($) {
    $('.term-datepicker').datepicker();
    $('.term-datepicker').datepicker("option", "dateFormat", "yy/mm/dd");
<?php if(isset($search["term"])) :?>
    $(".term-datepicker").datepicker("setDate", "<?php echo $search["term"];?>");
<?php endif;?>
});
</script>

WP_List_Tableで、絞り込み検索を表示させる

今回は、WP_List_Table クラスを extends して作成したクラスで、「絞り込み検索」を表示させる。

日本語Codexによると、months_dropdown( $post_type ) というメソッドがあるので、参考にした。

以下のメソッド

display_tablenav( $which )

テーブルナビゲーションをテーブルの上部または下部に出力します。display()の中で呼び出されるため、明示的に呼び出す必要はありません。

内で、次のメソッドが呼ばれている。

extra_tablenav( $which )

一括処理とページネーションコントロールの間に追加のコントローラーを出力したい場合はオーバーライドしてください。

ということで、作成したクラスに以下を追加する。

<?php
function extra_tablenav( $which ) {
      if('bottom' == $which) return; // テーブルの上部だけ表示する
?>
      <div class="alignleft actions">
      <?php $this->providers_dropdown();?>
      <input type="submit" name="filter_action" id="post-query-submit" class="button" value="絞り込み検索">
      </div>
<?php
}

function providers_dropdown() {
   $provider = isset( $_GET['provider'] ) ? (int) $_GET['provider'] : 0;
?>
  <label for="filter-by-provider" class="screen-reader-text">種別で絞り込み</label>
  <select name="provider" id="filter-by-provider">
      <option<?php selected( $provider, 0 ); ?> value="0">すべての種別</option>
       <option<?php selected( $provider, 1 ); ?> value="1">Twitter</option>
       <option<?php selected( $provider, 2 ); ?> value="2">Facebook</option>
       <option<?php selected( $provider, 3 ); ?> value="3">Google</option>
   </select>
<?php
}
?>

当然、実際のデータ絞り込みは、例えば、

prepare_items($_GET['provider'] )

などのように、prepare_items にクエリー変数を渡して、処理を行う。
まあ、$_GETはグローバル変数なんだから、わざわざ渡さなくてもいいけど。

WordPress管理画面の絞り込み検索をカスタマイズする

WordPressにカスタム投稿を追加しても、管理画面の一覧で「絞り込み検索」ができるのは「日付」だけだったのですが、これもカスタマイズできるということなので、やってみました。

タクソノミーで絞り込み検索する場合の例

カスタム投稿を survey 、タクソノミーを jobtype とすると、

add_action('restrict_manage_posts', 'restrict_listings_by_jobtype');
function restrict_listings_by_jobtype() {
    global $typenow;
    if ($typenow == 'survey') {
        $taxonomy = 'jobtype';
        $jobtype_taxonomy = get_taxonomy($taxonomy);
        wp_dropdown_categories(array(
            'show_option_all' =>  "すべての{$jobtype_taxonomy->label}",
            'taxonomy'        =>  $taxonomy,
            'name'            =>  $jobtype_taxonomy->name,
            'orderby'         =>  'term_order',
            'selected'        =>  $_GET[$jobtype_taxonomy->query_var],
            'hierarchical'    =>  $jobtype_taxonomy->hierarchical,
            'depth'           =>  3,
            'show_count'      =>  false,
            'hide_empty'      =>  true,
        ));
    }
}

add_filter('parse_query', 'convert_jobtype_id_to_taxonomy_term_in_query');
function convert_jobtype_id_to_taxonomy_term_in_query($query) {
global $pagenow;
  global $typenow;
  if ($pagenow == 'edit.php') {
  $filters = get_object_taxonomies($typenow);
  foreach ($filters as $tax_slug) {
    $var = &$query->query_vars[$tax_slug];
    if ( isset($var) && $var>0)  {
    $term = get_term_by('id', $var, $tax_slug);
    $var = $term->slug;
    }
  }
  }
  return $query;
}

 参考

• WordPressのカスタム投稿タイプ利用時、管理画面でカテゴリの絞り込みをできるようにする

カスタムフィールドで絞り込み検索する場合の例

カスタム投稿を {my-post-type} 、カスタムフィールドを {gender} とすると、

add_action('restrict_manage_posts', 'restrict_listings_by_gender');
function restrict_listings_by_gender() {
global $typenow;
$selected = array();
if ($typenow == '{my-post-type}') {
echo '<select name="filter_gender">';
echo '<option value="">すべての性別</option>';
$selected[$_GET['filter_gender']] = 'selected';
echo '<option value="male" '. $selected["male"] . '>男</option>';
echo '<option value="female" '. $selected["female"] . '>女</option>';
echo '</select>';
}
}
add_filter('parse_query', 'gender_query');
function gender_query($query) {
global $pagenow;
global $typenow;
if ($pagenow == 'edit.php' && $typenow == '{my-post-type}' && $_GET['filter_gender']) {
$query->query_vars[ 'meta_key' ] = '{gender}';
$query->query_vars[ 'meta_value' ] = $_GET['filter_gender'];
}
return $query;
}

デフォルトで表示されている投稿日付で絞り込み検索を非表示にする

カスタム投稿を {my-post-type} とすると、

add_action( 'load-edit.php' , 'custom_load_edit' );
function custom_load_edit() {
add_filter( 'disable_months_dropdown' , 'custom_disable_months_dropdown' , 10 , 2 );
function custom_disable_months_dropdown( $false , $post_type ) {
$disable_months_dropdown = $false;
$disable_post_types = array( '{my-post-type}' );
if( in_array( $post_type , $disable_post_types ) ) {
$disable_months_dropdown = true;
}
return $disable_months_dropdown;
}
}

WordPress管理画面の投稿一覧項目のカスタマイズ

WordPressにカスタム投稿を追加して管理画面で一覧ページを表示させると、タイトルと日時または、たまに（？）作成者が表示されるが、他の情報が表示できないのかと思っていたら、簡単にカスタマイズできるらしい。

まず、投稿の場合は、manage_posts_columns、
カスタム投稿の場合は、manage_edit-（カスタム投稿slug）_columns というフィルターフックを使用してカラムを追加する。

function add_custom_column( $columns) { // 列を追加 $columns['(new_column)'] = '（表示列名）'; // 列を削除 unset($columns['date']); return $columns; } add_filter('manage_edit-（カスタム投稿slug）_columns', 'add_custom_column');

または、

function add_custom_column( $columns) { $columns = array( 'cb' => '<input type="checkbox" />', 'title' => 'タイトル', '(new_column)' => '（表示列名）', 'date' => '日時', ); return $columns; } add_filter('manage_edit-（カスタム投稿slug）_columns', 'add_custom_column');

次に、例えば、カスタムタクソノミーを、追加した列に表示させる場合は、 manage_posts_custom_column というフックを使用する。

function add_custom_column_id($column_name, $id) {
if( $column_name == '(new_column)' ) {
echo get_the_term_list($id, '(カスタムタクソノミーslug)', '', ', ');
}
}
add_action('manage_posts_custom_column', 'add_custom_column_id', 10, 2);

なお、追加した列の幅を制御したい場合は、Add Admin CSS プラグインが便利だ。

参考

• 投稿一覧の項目を追加・削除・並び替える方法
• 管理画面の投稿一覧にカスタムタクソノミーの列を表示させる方法

さくらインターネットのFTPサーバーにWindows7エクスプローラーのFTP機能でアップすると文字化け

さくらインターネットのマネージドサーバーでは、ファイル共有できるWebDAVが利用できる。

Windows7からは、まあまあ問題なく利用できるようなのだが、MacのFinderから使用しようとすると、頻繁にエラーが発生し使い物にならない。Mac OSXのWebDAVクライアント機能には問題があるようだ。

仕方なくMacでは、WebDAVクライアントとしても使用できるCyberduckから今年の4月位まで使用してもらっていたのだが、6月になって再度使用しようとしたら接続できないとのこと。
発生するエラーは、Interoperability failure Handshake alert: unrecognized_name である。

https://trac.cyberduck.io/wiki/help/en/howto/dav
上記ページによると、The virtual host setup by the hosting provider is most possibly misconfigured. It must accept TLS connections with SNI (Server Name Indication) extension (RFC 4366).
とある。

http://d.hatena.ne.jp/ttshiko/20121103/1351927402
また、上記ページによると、Java7からSNIがデフォルト有効になったとあり、こちらでも、Java6を使用する古いバージョンのCyberduck(Ver. 4.2.1等)では接続できることを確認している。

さくらインターネットでSNI SSLの提供を開始したのが同年2月4日とのことで、当該サーバーに設置したドメインにSNI SSLを設定したのが同年3月24日頃だったので、こりゃあ間違いなくSNI SSL関連の影響に違いないと思いサポートに連絡したのだが、

JAVA 7ではデフォルトの設定で、HTTPS通信時にSSL証明書の有無に関わらず、
SNIを確認する動作となっており、こちらがCyberduckとサーバー間の接続の際に
エラーを発生させているようでございます。

しかしながら、弊社では個々のWebDAVクライアントソフトの動作保証はしておらず、
また、マネージドサーバーという特性上、お客様個別にApacheの仕様等変更も
承っておりません。

こちらでは、４月くらいまで使用できていた環境そのままで何の変更もしていないのだが・・・。

仕方がないのでFTPサーバーで代替する。

Windows7のエクスプローラーにはFTP機能があるので、それほど違和感なく使用してもらえるだろうと思って安心していたのだが・・・。

しばらく運用していると、日本語ファイル名がたまに文字化けしていることが多くなってきた。以前Macで作成した圧縮ファイルをWindowsで解凍すると文字化けすることがあったので、それをそのままアップロードしたんだろう位に思っていたのだが、どうもそれだけではないらしい。

https://support.microsoft.com/en-us/kb/2416991/ja
上記ページによると、「Windows エスクプローラーの FTP 機能では UTF-8 エンコーディングを使用するためのネゴシエートを FTP サーバーとの間で行いますが、UTF-8 エンコーディングを使用した場合、文字コード変換が正しく機能しないため、この現象が発生します。」とのこと。
「この現象を回避するには、FTP サーバーで、UTF-8 の許可設定を無効にしてください。」だそうだ。

さくらインターネットのコントロールパネルをみても、そのような設定は見当たらない。
サポートに連絡したら、そもそも

恐れ入りますが、弊社サーバでは日本語を利用したファイル名及び
フォルダ名は、対応しておりません。

だそうだ。Webサーバーを管理するための使用なら、まあ困らないよね。

たかがファイル共有だとどこかでバカにしてましたが、簡単じゃないね。

マウスホバーで画像がせり出す

あるWebサイト[PhotoshopVIP]をみていたら、へーとなったので、メモ。

画像にマウスカーソルを乗せると、画像がページからせり出してみえる。

img:hover {

  box-shadow: 0 11px 18px rgba(0,0,0,0.2);

  -webkit-transform: translateY(-10px) scale(1.02, 1.02);

  -moz-transform: translateY(-10px) scale(1.02, 1.02);

  transform: translateY(-10px) scale(1.02, 1.02);

}

機会があったら、使ってみたい。

The Like Box plugin is deprecated and will stop working on June 23rd 2015

With the release of Graph API v2.3, the Like Box plugin is deprecated and will stop working on June 23rd 2015. Use the new Page Plugin instead. The Page Plugin allows you to embed a simple feed of content from a Page into your websites.

https://developers.facebook.com/docs/plugins/like-box-for-pages

差替えないといけないのかな。

WordPressのタイトルでiPhoneがIPhoneになるとき

あれ、iPhoneがIPhoneになっちゃってる！と投稿内容を確認しても、iPhoneと入力されている。また、WordPressが余計なお世話を・・・と思ってググると、
なんとWordPressの関数の仕業なんかじゃなく、CSSに text-transform: capitalize; という機能が！

知らなかった。

Mobile-Friendly Websites

検索結果をもっとモバイル フレンドリーに[googlewebmastercentral-ja.blogspot.jp]ですでに発表されている通り、Googleが、2015年4月21日より、ウェブサイトがモバイル フレンドリーかどうかをランキング要素として使用し始めます。

Googleのモバイルガイド[developers.google.com]に従って対策を進めましょう。

Webmaster Guidelinesを理解する

[Web] = [Google Search] の現状では、Webサイトを作成するには、Googleが公表しているWebmaster Guidelinesの理解が欠かせない。

さくらインターネットのSNI SSLでWordPressを運用できない

さくらインターネットで、SNI SSLが使用できるようになったというので、早速WordPressで構築したサイトに導入してみた。 

トップページはSSLで表示できるが、下層ページを表示させようとすると、スタイルシートやjavascript、画像等がSSLで読み込まれない。

原因を探っていると、下層ページで $_SERVER['HTTPS'] がセットされていないことが判明。

 いろいろなケースを確認したところ、WordPressのパーマリンク設定をディレクトリ形式にせず、デフォルトにすると表示できることも分かった。 

ディレクトリ形式のパーマリンクをリダイレクトする所に何かがあると考え、リダイレクト部分を突き詰めていくと、結局、以下のような .htaccess ということになる。

# BEGIN WordPress
<IfModule mod_rewrite.c>

 RewriteEngine On

 RewriteBase /
 RewriteRule ^index\.php$ - [L]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule . /index.php [L]
</IfModule>
# END WordPress

原因を切り分けるために、WordPressを使用せず、index.php で $_SERVER['HTTPS'] を表示させてみると、

実在するディレクトリ内に設置した index.php では、$_SERVER['HTTPS'] がセットされているが、
実在しないディレクトリにアクセスしてみると、$_SERVER['HTTPS'] がセットされていないことが判明した。

この現象にWordPressは関与していないわけだ。

さくらインターネットのサポートに電話したが、コンテンツに関することはサポートできないとのこと。いや、これはコンテンツに関する問題ではないでしょう。

WordPressがSSLを判定している関数は、wp-includes/functions.php 内の is_ssl() だが、以下の通り、$_SERVER['HTTPS'] をもとに判断している。さくらインターネットの SNI SSL のポートは80のままなので、ポート番号も使用できない。

/**
 * Determine if SSL is used.
 *
 * @since 2.6.0
 *
 * @return bool True if SSL, false if not used.
 */
function is_ssl() {
if ( isset($_SERVER['HTTPS']) ) {
if ( 'on' == strtolower($_SERVER['HTTPS']) )
return true;
if ( '1' == $_SERVER['HTTPS'] )
return true;
} elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
return true;
}
return false;
}

もう、やけくそで、上の関数を常に true を返すように書き換えてやったら、SSLで表示できた。

このままでは、さくらインターネットのSNI SSLでWordPressを運用するのは無理だね。

さくらレンタルサーバーの共有SSLを使うによると、共有SSLと同じような仕様のようだ。

2015.5.7更新
とりあえず、現状は上記サイトで述べられている共有SSLへの対応と同じ方法で運用してます。

2018年3月、さくらインターネットのレンタルサーバー仕様変更で$_SERVER['HTTPS'] がリダイレクトで消去されなくなったとのこと。

Facebookのアプリを公開し忘れる

「Opauthでソーシャルログインを実装する」の「Facebookでログイン」を実装する際に、https://developers.facebook.com/apps/でアプリを登録して、自分では動作確認ができたので、すっかり終わったつもりでいたのだが、他の人がログインできないとのこと。

Facebookアプリは、登録すると development mode になって、開発者自身のアカウントでは動作するが、公開しないと全ての人には利用できないようだ。

Status & Review の一番上で Do you want to make this app and all its live features available to the general public? と聞かれているので、トグルスイッチをONにしようとすると、You must have a valid Contact Email specified to make this app available to all users.とTool tip が出て、ONにできない。Settings のContact Email に自分のEmailを入力して、Status & Reviewに戻ると、今度はトグルスイッチをONにできた。

[Types - Custom Posts and Taxonomies]を更新して、はまる

Types - Complete Solution for Custom Fields and Types をバージョン 1.6.5.1 に更新したら、Taxonomyが設定された投稿一覧を表示する際に、archiveのテンプレートで表示されず、index.php が適用されてしまう。

例）
http://example.com/（post_type）/?（Taxonomy_slug）=（Taxonomy名）

朝から絶望的な気持ちで、オプション等を確認していたら、query_varのチェックを外したところ、元に戻った。

「query_var」の下にある説明が、またよくわからない。

クエリーを妨げるために偽とする或いはクエリーをカスタマイズするためのストリング。初期設定に$taxonomyがクエリーとしてが使用されます。
初期設定: $taxonomy

まあいいかと思って、よく見たら、単に[query_var]が無効になってTaxonomyが反映されなくなっただけだった。やはり[query_var]のチェックを外すことはできない。

バックアップしてあった前のバージョンに戻したらなおったので、前のバージョンで運用する。やはりプラグインは怖い。

（追記 2015.4.16）
今日、バージョン 1.6.6.2に更新したら治ってました。更新履歴によると、1.6.6.1で対応したっぽい。

PHPのIF文で、はまる

PHPのIF文の2つの異なる構文、即ち、

if ( 「論理式」 ) {
  「真の処理」
}else {
  「偽の処理」
}

および

if ( 「論理式」 ) :
  「真の処理」
else :
  「偽の処理」
endif;

において、下の構文の処理内に、上の構文をいれた以下のようなコードを書いたところ、文法エラーが発生した。

if ( 「論理式1」 ) :
  if ( 「論理式2」 ) {
    「処理1」
  }
else :
  「処理2」

endif;

Parse error: syntax error, unexpected ':' in XXX（else : の行）
あれ、どこかで括弧閉じ忘れたかな、としばらく右往左往・・・

以下の様に変更すると、エラーは発生しない。

if ( 「論理式1」 ) :
  if ( 「論理式2」 ) :
    「処理1」
  endif;
else :
  「処理2」

endif;

以下のリンク先ページにある、「注意: 同じブロック内で別の構文を混ぜて使うことはできません。」というのは、このことなのか。

http://php.net/manual/ja/control-structures.alternative-syntax.php

ただし、これを以下の様にしてもエラーは発生しなかった。

if ( 「論理式1」 ) :
  if ( 「論理式2」 ) {
    「処理」
  }else {
    「空文」
  }

endif;

組み合わせによって、エラーが発生したりしなかったりするようだ。まあ、そもそも別の構文を混ぜちゃだめだと言われれば仕方ないけど、通っちゃう場合もあるというのは混乱を招くよね。

WordPressでポストバックしたら404 Not Foundになった。

WordPressの固定ページにフォームを設置してポストバックしたら、404 Not Foundになった。

さんざん試行錯誤した揚句、フォームの項目に名前（name="name"）が含まれると発生することが判明。

post変数を「name="name1"」等に変更したら回避できた。名前空間の衝突には注意すべし。

Opauthでソーシャルログインを実装する

サイトで会員登録するのは自分でも抵抗があるので、ソーシャルログインを実装してみた。

Opauthは、PHPにおける認証処理を標準化してくれるフレームワークだ。

https://github.com/opauth/opauth

上記サイトから、ZIPをダウンロードして展開したら、

1) libをサイトのドキュメントルートにコピーする。
2) 認証用として例えばauthというディレクトリをドキュメントルートに作成する。
3) authの中には、展開したexampleフォルダの中の、index.php、callback.php、.htaccessおよびopauth.conf.php.defaultをコピーする。
4) opauth.conf.php.defaultをopauth.conf.phpにリネームする。
5) opauth.conf.phpの'path' => '/'を'path' => '/auth/'に書き換える。
6) opauth.conf.phpの'security_salt'にランダムな文字列を設定する。
7) opauth.conf.phpのStrategyを、例に従って記述する。

Strategyに記載するパラメーターは、各プロバイダのサイトでアプリケーション登録をすると得られる。

プロバイダのアプリケーション登録ページの例
Facebook
Twitter
Google+

プロバイダ毎のStrategyは以下からダウンロードして、lib/Opauth/Strategyの下にプロバイダ名のディレクトリを作成してコピーする。

https://github.com/opauth/opauth/wiki/List-of-strategies

例えば、Facebookであれば、

lib/Opauth/Strategy/Facebookの下に、FacebookStrategy.phpをコピーする。

Twitterの場合は、Vendor/tmhOAuthディレクトリもコピーする。

認証手続きを開始するには、opauth.conf.phpで設定した'path/(プロバイダ名)'にアクセスする。

私の場合は、Strategyが見つからないというエラーが出たので、opauth.conf.phpのStrategyに以下のパラメータを追加した。

例えば、Facebookであれば、
'Facebook' => array(
            'app_id' => '（app_id）',
            'app_secret' => '（app_secret）',
            'strategy_url_name' => 'Facebook'
)

Googleの場合は、Googleサイト側でError: redirect_uri_mismatchという画面が出てしまい、認証画面が表示されなかったので、以下のパラメータも追加してみた。

'Google' => array(

            'client_id' => '（client_id）',

            'client_secret' => '（client_secret）',

            'redirect_uri' => 'http://（ドメイン）/auth/Google/oauth2callback',

            'strategy_url_name' => 'Google'

)

なお、Googleは、https://console.developers.google.com/project でリダイレクトURLを設定する必要がある。

しかし、結局Googleで認証ができない。

試行錯誤しているうちに、なぜか認証できるようになった。

Googleは、GoogleApps for Workでも感じたが、設定しても反映するまでの遅延が大きいようなので、設定したらある程度時間を置く必要があるのかもしれない。24時間以上かかる場合もある？

サーバー間の同期に時間がかかっているのだろうか。設定方法に自信がない場合は、設定が終了するまでになんともいえない無為な時間が流れるのは、かなり困る。

アプリの設定に表示されないのも、そのせいかと思っていたら、アカウント権限という別ページで管理するようだorz

[PHPによるHTTP 認証]$_SERVER["PHP_AUTH_USER"]が取得できない

PHPによるHTTP 認証[php.net]ができることを知って、早速試してみたのだが、認証画面が繰り返し表示されてしまう。

$_SERVER["PHP_AUTH_USER"]が取得できていないようだ。

Webを検索してみると、さくらのレンタルサーバーだとPHPがCGIとして動作するため、うまく動作しないとの情報が。

よく見ると、php.netにも以下の情報がありました。

There are .htaccess which actually works for us (cPanel + phpsuexec) unless others failed. Perhaps it may help someone.

# PHP (CGI mode) HTTP Authorization with ModRewrite:

RewriteEngine on

RewriteCond %{HTTP:Authorization} ^(.*)

RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]

Then you need small piece of php code to parse this line and then everything will work like with mod_php:

if (isset($_SERVER['HTTP_AUTHORIZATION']))

{

$ha = base64_decode( substr($_SERVER['HTTP_AUTHORIZATION'],6) );

list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode(':', $ha);

unset $ha;

}

でも、ロリポップではやはり動作しない。まあ、PHPで認証すればいいと言われればその通りだ。

WordPress + Bootstrap

WordPressにBootstrapを組み込んでみた。簡単にResponsible対応になり便利だ。

[Custom Post Type UI]プラグインで作成したカスタム投稿にアクセスできない

Custom Post Type UI（バージョン 1.0.2）で作成したカスタム投稿を使用していたサイトで、WordPressを4.1から4.1.1に更新したところ、カスタム投稿へのアクセスが404 Not Foundになってしまった。

Custom Post Type UIの設定（Edit Post Types）で、Select a post type to edit.から確認したところ、作成した投稿タイプは残っているようだ。

残っていた投稿タイプを選択して、なにも変更せずに[Edit Post Type]ボタンをクリックしたところ、アクセスできるようになった。

ひやひやさせる。

WordPress更新時にWarning: 予期しないエラーが発生しました。WordPress.org かこのサーバーの設定に何か問題があるかもしれません。

レンタルサーバーの古いプランでWordPressサイトを運用していると、WordPress本体やプラグインの更新確認および更新時に以下のようなメッセージが表示されることがある。

Warning: 予期しないエラーが発生しました。WordPress.org かこのサーバーの設定に何か問題があるかもしれません。問題が続くようであれば、サポートフォーラムを参照してみてください。 (WordPress は WordPress.org との安全な接続を確立できませんでした。サーバー管理者にご連絡ください) in /****/****/wp-includes/update.php on line xxx

Warning メッセージに従って、ソースを参照してみると、

$raw_response = wp_remote_post( $url, $options );
if ( $ssl && is_wp_error( $raw_response ) ) {
  trigger_error( __( 'An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.' ) . ' ' . __( '(WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.)' ), headers_sent() || WP_DEBUG ? E_USER_WARNING : E_USER_NOTICE );
  $raw_response = wp_remote_post( $http_url, $options );
}

wp_remote_post()で、https接続しようとして失敗するとWarningを表示させ、その後、httpで接続し直す。

PHPを5.3以上にするとWarningが発生しなくなったという報告がWeb上で複数認められたが、残念ながら PHP 5.2.4より高いバージョンに上げられないプランなので、放置するしかない。

WordPressメディアライブラリの「この固定ページへのアップロード」が表示されなくなった

あるWordPressサイト（バージョン 4.1.1）で、いつからかわからないが、「固定ページを編集」の「メディアを追加」で表示される「メディアを挿入」画面で、「タイプで絞り込み」のドロップボックスから「この固定ページへのアップロード」が表示されなくなっていることに気付いた。

やはりプラグインから疑う。

一つ一つ停止しながら確認したところ、「WCK - Custom Fields and Custom Post Types Creator」（バージョン 1.1.4）を停止したところ、表示されることが判明した。

しかし、WCKを停止するとWCKで作成したカスタム投稿も表示されなくなってしまう。
functions.phpに自分でカスタム投稿を作成すれば、既存のカスタム投稿を引き継げるんだっけ・・・と思いながら、WCKの「Start and Settings」の画面を見ていたら、個別の機能を無効にできるようだ。

とりあえずカスタム投稿を使用できればいいので、Custom Post Type Creator　のみ有効にして残りを無効にしたところ解決した。

入れるプラグインを増やせば、このようなリスクも増えるのが悩ましいところだ。

ところが、別のサイトで同じくWordPress（バージョン　4.1.1）と「WCK - Custom Fields and Custom Post Types Creator」（バージョン 1.1.4）の組み合わせで上記現象が起きていないことを確認した。単純に「WCK - Custom Fields and Custom Post Types Creator」（バージョン 1.1.4）を犯人にするわけにはいかないようだ。