“WordPress” タグの記事（52件）

WordPress では、一般設定でタイムゾーンを設定することによって、投稿日時などがその地域の日時で表示されます。日本時間の場合は “東京” または “UTC+9” を設定します。

先日、ユーザー管理のために使用したプラグインで、登録日時は日本時間で表示されるのに、更新日時とログイン日時が9時間プラスされて表示されるという現象が発生しました。世界標準時（UTC）は日本時間より9時間遅れ。今回は9時間プラスなので、世界標準時で表示されているわけでもありません。

原因がわからないので、仕方なく jQuery で日時を修正することにしたのですが、実装後あらためて確認すると、一般設定で “東京” を設定しているうえに、functions.php に

date_default_timezone_set('Asia/Tokyo');

を記述していたことが原因のようでした。通常はこのように設定していても問題ないと思うのですが、プラグインのバグでしょうか、functions.php の記述を削除したら正しく表示されました。

でも折角ですし、また何か役立つ場合があるかもしれませんので、今回は表示された日時を9時間戻しましたが、世界標準時（UTC）で表示された日時を日本時間に書き替える（9時間進める）方法を記しておきます。

“世界標準時（UTC）で表示された日時を jQuery で書き替える” の続きを読む »

WordPress の投稿画面のスタイルを実際のサイトの見た目に近づけるために、ビジュアルエディタ用の CSS を作成して管理画面に読み込ませることができますね。editor-style.css などとして CSS ファイルを用意し、functions.php の中で

add_editor_style("editor-style.css");

を記述することで、ビジュアルエディタにeditor-style.css が適用されます。

しかし、これでは記事部分の CSS を変更する際に、公開画面用の CSS とビジュアルエディタ用の CSS の両方を編集する必要があります。

そこで editor-style.css を公開画面と共有すると便利です。header.php の中で style.css と共に読み込ませるか、style.css の先頭で editor-style.css をインポートすればよいわけですが、記事部分を囲む要素の class 属性の値を工夫する必要があります。

“ビジュアルエディタと公開画面で CSS を共有する” の続きを読む »

Webページを Facebook 等にシェアした際に適切な情報を表示させる OGP。これを WordPress のテーマファイルに設定する方法は、ググるといろいろ紹介されています。

その中の og:image を設定する部分の記述ですが、大抵、次のように紹介されています。

<?php
$str = $post->post_content;
$searchPattern = '/<img.*?src=(["\'])(.+?)\1.*?>/i';  // 投稿記事に画像があるか調べる
if ( is_single() or is_page() ){  // 記事か固定ページの場合
  if ( has_post_thumbnail() ){  // アイキャッチがある場合
    $image_id = get_post_thumbnail_id();
    $image = wp_get_attachment_image_src( $image_id, 'full');
    echo '<meta property="og:image" content="'.$image[0].'">'. "\n";
  } elseif ( preg_match( $searchPattern, $str, $imgurl ) && !is_archive() ){  // アイキャッチは無いが画像がある場合
    echo '<meta property="og:image" content="'.$imgurl[2].'">'. "\n";
  } else {  // 画像が1つも無い場合
    echo '<meta property="og:image" content="'. get_bloginfo('template_url'). '/images/ogp_image.png">'. "\n";
  }
} else {  // 記事や固定ページ以外の場合（ホーム、カテゴリーなど）
  echo '<meta property="og:image" content="'. get_bloginfo('template_url'). '/images/ogp_image.png">'. "\n";
}
?>

記事ページか固定ページの場合、アイキャッチ画像があればそれを、アイキャッチ画像は無いが本文に画像がある場合はそれを、画像がない場合と記事や固定ページ以外は予め用意したデフォルト画像（上記では ogp_image.png）を設定するという記述です。

ただ、Facebook の仕様では 200×200px に満たないサイズの画像は og:image として設定できないため、上記の記述では、本文内に小さい画像がある場合は、シェアした際に画像が表示されません。

そこで、画像が 200×200px に満たない場合はデフォルト画像を設定するようにしてみました。

“WordPress で og:image を設定する際に小さい画像を除外する” の続きを読む »

以前、「Peter’s Collaboration E-mails」と「User Role Editor」、そして「WP Post Branches」プラグインを使って、公開中のページを更新する際の承認フローを実装した記事を書きました。
→ 公開中のページを公開したまま編集して承認待ちにする

これでうまく実装できたかに思えたのですが、ひとつ問題がありました。どんなに検証を重ねていても、いざ運用してみると見えなかった問題が明らかになるということは多々あります。

今回の案件、元々それぞれのコンテンツに対して担当者は1人という設定だったのですが、運用開始時点でいくつかのコンテンツに対しては複数の担当者が携わることになり、そこで問題が見つかりました。それは次のようなパターンです。

“WP Post Branches プラグインによるブランチの作成者をログインしているユーザーに置き替える” の続きを読む »

WordPress で承認フローを作成する場合、「Peter’s Collaboration E-mails」と「User Role Editor」の2つのプラグインを組み合わせる方法が、多くのブログ等で紹介されています。その基本は「Peter’s Collaboration E-mails」で承認者を設定して、寄稿者が投稿した際に承認者にメールで通知されるようにし、「User Role Editor」では、寄稿者にファイルのアップロード権限を付けたり、独自のロールを作成したりするというものです。

今回、承認フローが必要な案件があり、上記のプラグインを導入して実装しました。さらに「Peter’s Post Notes」プラグインも導入して承認依頼や差し戻しの際のメールにコメントを追加できるようにしました。

しかし、これだけでは実現できないことがありました。それは、公開中のページを差し替える場合の承認フローです。ページを公開したままの状態で、寄稿者が内容を修正して承認待ちとし、承認者が確認してページを差し替えるという流れが必要ですが、WordPress には差し替え用のページを作る機能はありませんので、公開中のページは修正した流れで即更新することになります。また、そもそも寄稿者は公開中のページを編集することができません。「User Role Editor」で寄稿者に公開中のページを編集する権限を付けることは可能ですが、そうすると、そのまま更新するこも可能になってしまいます。

そこで、「Revisionary」と「WP Post Branches」という2種類のプラグインを試してみました。機能としては「Revisionary」がマッチしていますが、機能が特化している故に様々な問題があり、最終的に「WP Post Branches」を使い、不足する機能を他のプラグインや設定で補うことで、目的のフローを実装することができました。

“公開中のページを公開したまま編集して承認待ちにする” の続きを読む »

WordPress の管理画面はレスポンシブwebデザインにより、スマートフォンからでも容易にサイトを更新することが可能です。（WordPress に限らず、最近多くの CMS で管理画面でもレスポンシブwebデザインが採用されていますね）

スマートフォンからよくアクセスする場合、ホーム画面にwebクリップを保存すると便利ですが、そのまま保存したのではアイコンがログイン画面のサムネイル画像となってしまいます。たとえ対象のWebサイトにwebクリップアイコンを設定してあったとしても、ログイン画面には適用できません。そこで、ログイン画面にwebクリップアイコンを設定してみました。

まず、144×144ピクセル以上のアイコン画像を用意します。Webサイトのロゴでも WordPress のロゴでもいいでしょう。用意したアイコンを、使用しているテーマディレクトリの images ディレクトリに保存します。

wp-login.php を開き、149行目 </head> の手前に以下のコードを挿入します。

<link rel="apple-touch-icon-precomposed" href="<?php bloginfo('template_url'); ?>/images/clip-icon.png" />

※clip-icon.png は保存したアイコン画像のファイル名です。

これで、ログイン画面をホーム画面に保存すると、設定したwebクリップアイコンが適用されます。

なお、WordPress をバージョンアップすると wp-login.php が置き換わります。一度ホーム画面に保存してしまえば影響ありませんが、再度保存する場合は、改めて書き替える必要があります。

WordPress をマルチサイトで運用するとき、複数のサブサイトの投稿をまとめてメインサイトに表示したい場合があります。

今回、メインサイトとサブサイト（ネットワーク全体）の投稿を時系列にまとめ、メインサイトのフロントページ（ウェブサイトのホームページ）に最新の10件を表示し、一覧のリンクから遷移するページでは全件を20件毎にページ分割して表示、更にネットワーク全体の投稿をまとめた RSS を配信するという実装を試みました。

WP Over Network プラグインを利用して実装したのですが、ページネーションでつまづきました。試行錯誤のうえ、最終的にどうにか実装できたので記しておきます。

“マルチサイトにおけるネットワークの投稿の表示” の続きを読む »

一つの WordPress で構築したサイトの中でブログを運営している場合に、サイト全体を検索対象とするサイト内検索と、ブログ記事のみを検索対象とするブログ内検索の両方を設置したいということがあります。

ブログ内検索に WordPress の検索機能を利用し、サイト内検索は Google カスタム検索を利用するというのも一つの方法ですが、今回、既に WordPress の機能でサイト内検索を設置しているこのサイトに、WordPress の機能でブログ内検索を追加しました。

サイト内検索のフォームは共通のヘッダーに設置されているため、ブログの各ページでは検索フォームが2つ存在することになります。追加するブログ内検索のフォームはサイドバーに設置します。

また、その検索結果のページのデザインはそれぞれ異なるものとし、ブログ内検索の検索結果はブログのデザインの中で表示させます。

“検索フォームと検索結果ページを複数設置する” の続きを読む »

WordPress に様々な投稿タイプを追加することができるカスタム投稿タイプや、カテゴリやタグのような分類を追加することができるカスタム分類。これを管理画面から設定できるプラグインとして、有名なもので Custom Post Type UI や Custom Post Type Generator などがあります。

これまで、Custom Post Type Generator を使っていましたが、先日バージョン 2.3.0 が公開され、これに更新したらカスタム投稿タイプやカスタム分類のラベルが消えて名前（スラッグ）と同じになり、管理画面のメニューからも消え、カスタム分類アーカイブのパーマリンクも変わってしまいました。こういうことがあるから、出来るだけプラグインを使わない方がいいんですね。

これを機に、これまで構築したサイトも含め、カスタム投稿タイプとカスタム分類についてプラグインの使用をやめ、function.php で定義する方法に変更しました。

既に function.php には様々な記述をしているため、管理しやすいように custom-post-type.php というファイルを作ってこれに記述し、function.php に読み込むようにしています。（custom-post-type.php の記述はこの記事の最後に記載）

いくつかのサイトを同じようにしてプラグインから function.php による定義に変更していきましたが、一つだけマルチサイト機能を使って複数のサイトを作り、それぞれに異なるカスタム投稿タイプを設定しているサイトがありました。

“マルチサイトでサイト毎にカスタム投稿タイプを使う” の続きを読む »

WordPress サイトで Google アナリティクスを導入する場合（トラッキングコードをテーマファイルの header.php などに貼り付ける場合）、そのままでは投稿のプレビュー画面もカウントされてしまいます。また、テストサーバでテーマの編集やプラグインのアップデートを行っている場合も同様にカウントされます。

Google アナリティクス側でフィルタを設定して回避することもできますが、クライアントからトラッキングコードを渡された場合など、Google アナリティクスへのログイン権限がない場合、テーマファイルの中で回避することになります。

プレビュー画面を除外する場合については多くのブログ等で紹介されていますが、WordPressの条件分岐タグ is_user_logged_in() を使います。このタグでログインしているかチェックし、ログインしていない場合にトラッキングコードを適用します。

テストサーバを除外する場合はホーム URL の値を使います。例えばテストサーバの URL に “local” が含まれているのであれば、home_url() にこれが含まれているかをチェックし、含まれていない場合にトラッキングコードを適用します。なお、home_url() の代わりに、php の $_SERVER['REQUEST_URI'] を使ってもよいでしょう。

<?php if ( !is_user_logged_in() && strpos(home_url(), 'local') === false ): ?>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');

ga('create', 'UA-XXXXXXXX-X', 'auto');
ga('send', 'pageview');

</script>
<?php endif; ?>

!is_user_logged_in() && strpos(home_url(), 'local') === false で、ログインしていない、且つ URL に “local” が含まれない場合にトラッキングコードを読み込んでいます。

なお、Google Analytics Dashboard for WP などのプラグインを使用する場合は、プラグインの設定でログイン中を除外することができます。また、テスト環境ではプラグインをインストールしないか無効にすることで回避します。