WordPress管理画面で特定のプラグインのみ使用できるユーザー権限の作成方法

adminimize7WordPressで管理画面で、特定のプラグインのみを利用できるユーザー権限を作る方法についてまとめました。

サイト運営で作業分担をするときには、作業に応じてそれぞれのユーザに適当な権限を与えることが望ましいですよね。

例えば「投稿のみ」の作業を切り分けるなら、その作業をする人に「編集者」権限をつけるだけでいいですが、【特定のプラグイン】の使用のみを可能にするのは、やり方を見つけるまでに一苦労でした。

WordPressの場合、管理者のみがプラグインを使用できるため、デフォルトの権限のままだと、管理者権限のユーザーを増やさなくてはいけなくなります。

作業をお願いされる側としても、使うのはほんの一部の機能なのに、管理者権限のメニューがずらっと並んでいたら圧倒されるし、お互い「何かあったら大変…」となんだか不安。。

 

そういうときに役立つのが今回の方法です。

管理画面のメニューから必要なプラグインメニューだけを残してそのほかを非表示にできるユーザー権限を作成できます。

 

今回は企業のFAQ(よくある質問)ページの更新だけを作業分担するため、FAQ用のプラグインのみの使用を許可するユーザーを作成しました。

その他にも、

  • ギャラリー用プラグイン
  • ニュースレター配信プラグイン
  • 広告管理プラグイン

といったプラグインだけを管理画面から使えるようにして、別の人にギャラリーの更新やニュースレターの配信、広告の更新を作業分担するというのもできるかと思います。

 

プラグインを使うので簡単ですが、ちょっとトリッキーな方法なので覚書をしておきたいと思います。

※実はこの方法、どこかのブログで見た方法なので参考サイトとしてリンクを貼りたかったのですが、そのサイトにもう一度出会うことができていません。教えてくださった方に感謝です!

用意するプラグイン

以下の二つのプラグインを組み合わせて使います。

それぞれインストール、有効化します。

 

User role editorでの設定

まずUser role editorで新しい権限(Role)を作成します。

ダッシュボードで ユーザー > User Role Editor に移動します。

Add Roleボタンで以下のポップアップが表示されるので、必要な情報を入力します。

Add new role

Role nameと Display Role Nameは必要に応じて変えてください。

Make Copy of.. のところは、購読者にします。

 

Adminimizeでの設定

次に、ダッシュボードの 設定>Adminimize で、先ほど作成したユーザー権限の管理画面での表示設定を行います。

たくさん項目がありますが、今回設定するのは

  • Admin Bar Back end options(管理画面上部のアドミンバーの表示項目)
  • Admin Bar Front end options(サイト表示した場合にページ上部に表示されるアドミンバーの表示項目)
  • Menu options(管理画面左側のメニュー項目)

の3つの部分のみです。

 

Admin Bar Back end options

管理画面上部のアドミンバーの表示項目を設定していきます。

以下のように、先ほど作った権限のユーザーに表示させたくないAdmin Bar(管理画面上部) の項目にチェックを入れていきます。

管理画面アドミンバーの設定

 

Admin Bar Front end options

サイト表示した場合にページ上部に表示されるアドミンバーの表示項目を設定していきます。

以下のように、先ほど作った権限で表示させたくないの項目にチェックを入れていきます。

ページ上部のアドミンバーの管理

 

Menu options

管理画面左側のメニュー項目の表示を設定していきます。

以下のように、先ほど作ったロールで表示させたくないメニュー項目にチェックを入れます。

管理画面メニュー項目の設定

赤い枠のチェック項目では、大メニュー配下の小メニューをまとめて非表示設定できます。逆に、小メニューの中でも特定の部分は表示させたい場合は、細かくチェックを入れて設定することもできます。

 

今回はプラグインの操作と、ユーザープロフィールの設定、メディアの管理以外はほぼ見れないように、だいぶチェックをいれました。

次に実際にユーザーを作成して、希望通りの表示になっているかチェックします。

 

作成した権限のユーザーを作成する

管理画面の ユーザー > 新規追加 からユーザーを追加します。

重要なのは、以下の項目の選択の仕方。

  • 権限グループ: 作成したロール
  • Other Roles: Administrator

と設定してください。

adminimize4

管理者としてのプラグインの使用が許可され、それにAdminimizeで設定した制限事項が適用される感じになります。

権限グループで管理者を選ぶと、Other RolesでFAQ Editorを選んでも「管理者」としてすべてのメニューが表示されてしまうので注意。また、Other RolesでAdministratorを選択しないと、プラグインのメニュー項目が管理画面に現れません。こちらもご注意を!

 

できあがったユーザー権限でログインしてみると…

アドミンバーもスッキリ!

adminimize6

 

メニュー部分も超スッキリ!

adminimize5

 

これで安心して作業を分担できますね!

以上、Wordpress管理画面で特定のプラグインのみ使用できるユーザー権限の作成方法でした。

カスタム投稿の一覧画面からカスタムフィールドをクイック編集できるようにする方法

customfield-quick-edit-in-custom-post-typeカスタム投稿で使っているカスタムフィールドを一度に編集したいときに役に立つ方法です。いちいち投稿編集画面を開かずに、一覧画面のクイック編集からカスタムフィールドの値を編集&保存できるようになります。

プラグインでできないか…と探してみましたが、Admin ColumnsのPro版(有料)でしか見つからなかったです。ザンネン!(カス
タムフィールドを一覧画面に表示するだけなら無料でできます。クイック編集がしたい場合は有料になります。)

が、実はfunction.phpにコードを追加すれば結構簡単にできることが判明。すばらしく参考になる記事があって、おかげで30分くらいで何とかなりました。ありがたい。

非常に参考になったのが記事
→ http://increment-log.com/quickedit-custom-field/

上の記事では、サンプルコードは投稿一覧画面での場合になっています。それぞれのステップの意味も分かりやすいですし、
カスタム投稿や固定ページの場合どうするか、という話も後のほうでしっかり解説してくれています。すごく素晴らしい記事なので、ぜひ読んでみてください。

私の場合、今後また必要になるかもしれないのがおそらくカスタム投稿一覧の場合なので、この記事では備忘録として、カスタム投稿の一覧の場合の手順とサンプルコードを載せています(と言ってもほぼ同じですが…)。

今回の前提条件

以下が今回やりたかったことです。

  • カスタムフィールドはプラグインAdvanced Custom Fieldsで作成したテキストフィールド
  • カスタム投稿タイプの一覧画面に上のカスタムフィールドのカラムを追加し、クイック編集で編集したい

以下のサンプルコードでは

カスタム投稿タイプ「コスメ」: post_type = cosmetic
カスタムフィールド「旧価格」: ラベルがOld price、カスタムフィールド名はold_price
カスタムフィールド「新価格」: ラベルがNew price、カスタムフィールド名はnew_price

とします。cosmetic、old_price、new_priceのところは適宜変更します。

まず最初にfunction.phpのバックアップを取って、何かエラーが起きたり、画面が真っ白になった場合は、バックアップしたfunction.phpにFTP経由で戻せるようにしておいてください。

 

まず最初の1,2のステップでカスタム投稿の一覧画面にカスタムフィールドのカラムを追加し、値を表示させる設定から始めていきましょう。

カスタムフィールドのカラムと値をカスタム投稿一覧に表示

カスタム投稿の一覧画面にカスタムフィールドのカラムを追加

カスタムフィールドのラベルと名前を以下のように設定して、カスタム投稿の一覧画面にカラムを追加します。以下のコードはfunction.phpに追加します。

カスタムフィールド名やラベルなどは適宜変更してください。
add_filterの第一引数の文字内にカスタム投稿のpost_type(ここではcosmetic)を入れるようにします。

 

追加したカラムに値を表示させる

カラムができたら、そのカラムの中に各カスタム投稿の値を表示させます。(ここでは各コスメの旧価格と新価格を表示させる感じですね。)

以下のコードをfunction.phpに追加します。

ここでもカスタムフィールド名やラベルなど上のコードで太字で示したところは適宜変更してください。
add_filterの第一引数の文字内にカスタム投稿のpost_type(ここではcosmetic)を入れるようにします。ここまでで表示はできるようになります。

 

さて重要なのはここから!クイック編集でカスタムフィールドの値を編集・保存可能にします。

カスタムフィールドをクイック編集から変更・保存可能に

クイック編集の中にカスタムフィールド(旧価格、新価格)の入力フィールドを作る

以下のコードをfunction.phpに追加します。

old_price、new_price、Old price、New priceのところは適宜変更します。ここではadd_actionの第一引数はこのままで大丈夫のようです。

 

クイック編集時に既存の値をフィールドに表示できるようにする

既にカスタムフィールドに値が設定されている場合(例えばコスメの新価格と旧価格の値がすでに設定されている場合)、クイック編集をクリックしたときに、それらの値をポップアップ表示される編集画面で引き継いで表示させる必要があります。

これにはjQueryを使った処理が必要になるので、以下の手順でjavascriptファイルを作り、それを読み込む設定をします。

admin_edit.jsという空のファイルを作成し、以下のコードをペーストします。

 

このファイルをテーマフォルダ内の任意の場所にFTPなどでアップロードします。ここでは、テーマフォルダの中のjsフォルダにアップロードしています。テーマフォルダは、Wordpress本体のルートディレクトリ/wp-content/theme/の中にあります。

上のjavascriptファイルをクイック編集時に実行する設定をfunction.phpに追加します。

cosmeticのところと、admin_edit.jsファイルのディレクトリは適宜変更します。

 

クイック編集での変更を保存する

最後にクイック編集で変更した値を保存する設定です。

 

これで無事完了です。上手くいったかどうか編集して確認してみてください。

 

参考サイト

http://increment-log.com/quickedit-custom-field/

http://www.wp-tech.net/wordpress_tips/2122/

http://codex.wordpress.org/Plugin_API/Action_Reference/quick_edit_custom_box

WordPress4.4 でタグクラウドの表示がおかしい!?1分で解決する方法をシェアします

WordPress4.4にバージョンアップ後に、「タグクラウドの表示がおかしくなった!」「ただのリンクみたいになっている!」という不具合が出ているようです(私のブログでもありました)。タグクラウドの文字サイズを揃えている人はおそらくこの不具合を見ていると思いますが、簡単な解決方法があったのでこの記事でシェアしたいと思います。

WordPress4.4でのタグクラウドの不具合について

WordPressにあるタグクラウドのウィジェットですが、デフォルトではタグに含まれる記事の数に応じてタグ名のフォントサイズが変化するようになっていますよね。(この記事のサイドバーにあるタグクラウドみたいな感じ)

記事数が多ければ多いほど、タグ名のフォントが大きくなるので、そのブログがどんな情報をたくさん書いているのかが視覚的に分かっていいのですが、色々な理由からフォントサイズを揃えてる設定をしている方も多いと思います。

私ももう一つのブログのほうでは、文字を揃える設定をしています。デザインがそのほうがパシッと決まる感じがするのと、記事数の少ないタグも見過ごされなくて済むかなと。(記事数が少ないからと言って価値が低いわけじゃないですからね)

具体的には、function.phpに以下のフィルターを追加すれば文字の大きさが同じになります。

 

WP4.3では問題なかったのが、4.4にアップデートした後から表示がおかしい。

タグクラウド WP4.4での不具合まずウィジェットタイトルが表示されないし、タグクラウドに適用されていたCSSが効かなくなっていてあたかもリンクの羅列のようになってました。キャッシュが変に残っちゃったのかとか、色々考えたものの、キャッシュをクリアしてもダメだし、CSSも特に変更した覚えはありません。

ソースを見てみてみたら、ウィジェットタイトルも出力されていないし、普通ならウィジェットを囲うはずのdivタグもない。ということは、CSSじゃなくてコードの出力の時点で問題が起きているということですね。

それにしても・・・かなり残念な表示です(笑)

 

文字サイズを揃えるフィルターで不具合が起きていた

調べてみたところ、タグクラウドの文字サイズを制御する(そろえる)ために使っている上のフィルターがWordpress4.4で不具合を起こしてしまうようでした。フィルターをコメントアウトして次回のバージョンアップを待つという手もありますが、解決策を提案してくださっている方がいて、おかげでちゃんと表示できるようになりました!

参考:[resolved] WordPress 4.4 update broke Tag Cloud

 

具体的には、以下のように変更します。

 

この解決策を考えてくれた人の解説によれば、

Until WP 4.3.x, wp_tag_cloud function was used to directly output (‘echo’ => true), which is the function’s default behavior. In WP 4.4, however, the function is used to set the tag cloud into a variable as a string, without output (‘echo’ => false).

The original description of the custom function overrides the default arguments, where ‘echo’ is set to false. So tag cloud was output at wrong timing (before output of wrapper and title). To resolve it, arguments should not be override, instead, custom arguments should be merged with default arguments.

引用元: [resolved] WordPress 4.4 update broke Tag Cloud

 

私が適当に訳した感じだと、

 

WordPress4.3.xバージョンまでは、wp_tag_cloud関数は直接出力されるのがデフォルトの動作だった(’echo’ => true)が、4.4バージョンではこの関数はタグクラウドを文字列として変数にセットするようになった、つまり直接出力ではなくなった(’echo’ => false)。

このような変更が加えられたところに、以前のフィルター(カスタム関数)を使うとどうなるか。

フィルターがデフォルトの引数を上書きしてしまい、これが原因でウィジェットタイトルやウィジェットのラッパーの出力の前にタグクラウドが出力されてしまう。

これを解決するためには、引数が上書きされずに、カスタム引数をデフォルトの引数にマージ(結合)されるようにする必要がある。

 

訳すとかえって分かりにくいですね。。スミマセン。ようは

$args = wp_parse_args( $args, $my_args );

の一行を加えることで、フィルター内で定義した引数ともとの引数を結合させ、その結合させた引数を返すことで、問題が解決されたようです。

私のブログのタグクラウドもちゃんと表示が戻りました!

tagcloud-wordpress4.4-fixed

WordPressの次期バージョンでどうなるかわかりませんが、4.4でタグクラウドが変になった!!とお困りの方は、一度function.phpでこんなフィルターを使っていないかどうかチェックしてみてください。

BootstrapをWordPressテーマに組み込んでレスポンシブ対応のナビゲーションメニューにする方法

wp-bootstrap-navこの記事ではWordpressのテーマを自作する際に、Bootstrapフレームワークを使ってナビゲーションメニューをレスポンシブ対応させるための設定について書いています。

WordPressではナビゲーションメニューを動的に作成してくれるテンプレートタグwp_nav_menu()がありますが、これとBootstrapの組み合わせ方について具体的なコードの書き方の例を載せてみました。

 

用意するもの

まずは以下のファイルをそれぞれダウンロード。(jQueryやBootstrapをCDNからの読み込みにしている場合はnavwalkerのみダウンロード)

jQuery

jQueryはBoostrapを動かすために必須なので、まだテーマに組み込んでいない場合はダウンロードする。上のリンクから公式サイトに行って「Download the compressed, production jQuery 1.11.3」のリンクをクリック。ダウンロードしたファイルを自分のテーマのjsフォルダに入れておく。

 

Bootstrap

Boostrapをまだ組み込んでいない場合は上のリンクからダウンロード。ダウンロード後、zipファイルを解凍してbootstrap.min.cssとbootstrap.min.jsを自分のテーマのcss,jsフォルダにそれぞれ入れておく。

 

Bootstrap navwalker

ナビゲーションメニューを表示させるwp_nav_menu()タグにBoostrapを組み込むためのクラス。上のリンクからダウンロードし、wp_bootstrap_navwalker.phpをテーマフォルダに入れておく。

 

function.phpに記述すること

 

header.phpに記述すること

headタグ内に以下のタグを記述してBootstrapのCSSファイルを読み込み。

 

bodyタグ内、ヘッダーのナビゲーションメニューを表示させたい部分に以下のコードを記述する。

 

wp_nav_menu()のパラメータのmenu_classの部分は、Bootstrapで用意されているクラスを記述している。fallback_cbとwalkerのところは上記のとおりに記述。その他は適宜変更してOK。

具体的なパラメータの設定方法については以下を参照

テンプレートタグ/wp nav menu

 

footer.phpに記述すること

Bootstrapのjsファイルの読み込み。

 

出力されるHTMLタグの例

以下のようなHTMLタグが出力される。

 

CSSだけでAmazon商品をAmazonJSプラグイン風にカッコよく紹介する方法を考えてみた【サンプルつき】

ブログを書いていると自分が使用していてすごく良かったものを紹介したいときがあります。せっかく紹介するなら、収益化もかねて…ということで各種ASP、Amazonアソシエイトや楽天アフィリエイトを経由して商品リンクを作成するのですが、Amazonアソシエイトの商品リンクをデフォルトの表示のまま使うと、何だかサイズも微妙だし、見た目も格好悪い

AmazonJSプラグインを使うとかなり格好よく商品を紹介できるのですが、色々検討した結果、AmazonJSは使わないほうがいいかも、という結論に至りました。そんなこんなで行き着いた方法が、今回ご紹介する、「CSSだけで簡単にAmazon商品を格好よく紹介する」方法です。

まずはAmazonJSの利用を断念したいきさつから。後半では(大そうなものではないですが)CSSサンプルもあわせて紹介します。

AmazonJSプラグインのいいところ

AmazonJSプラグインというのは、Wordpressの投稿画面からボタン一つでAmazonアソシエイトの商品リンクを簡単に作成することができるAmazonアソシエイト利用者向けWordpressプラグインです。

プラグイン公式サイト

Amazonが提供している記事埋め込み用の商品リンクって、悲しくなるくらいなんだか格好悪いですよね…。

例)デフォルトの商品リンク↓

Amazonデフォルト商品リンク

例)AmazonJSを使った商品リンク↓

AmazonJSデフォルト商品リンク

見栄えの違いは一目瞭然!興味がある方は以下のサイトの解説がとても親切で参考になります。

WordPressでアマゾン・アソシエイトを簡単設定!Amazon JSプラグイン

 

私も「これは!!!」と思って早速使ってみたのですが、わざわざAmazonのサイトからアソシエイトリンクを取ってこなくても、投稿画面上で商品を検索して記事内にAmazonの商品リンクを貼りつけられるのでスゴく楽。こんな簡単に格好いいリンクができて気分も上々!

最近執筆した記事でも、AmazonJSは今後もずっと使いたいプラグインの一つに入れていました。

2015年も外せない有用WordPressプラグイン30選と利用停止プラグイン

 

しかし、使ってみるとわかるのですが、AmazonJSには幾つかデメリットもあるんです。

AmazonJSのダメだったところ

私が「これはちょっとな」と思ったデメリットは・・・

  1. 高速化プラグインとのバッティングが多い
  2. 商品名のテキストがh4タグで表示される
  3. 価格を含めた商品情報が表示される

の3つです。一つずつコメントしていきます。

 

高速化プラグインとのバッティングが多い

AmazonJSはキャッシュ系プラグイン、遅延読み込み(LazyLoad系)のプラグインなどの相性が悪く、商品画像のところがロード中になってぐるぐる回ったままになってしまうことがあります。私も何度かこの現象は経験しましたが、ネットで調べてみると結構よくあることみたいですね。。

 

商品名のテキスト部分がh4タグで表示される

h4の見出しやh5の見出しの本文中で使っているときに、AmazonJSで商品リンクを作るとその商品タイトルのところもh4タグになるので、見出しの階層がぐちゃぐちゃになってしまう可能性があります。

記事の構造化が正しくない=SEO的によくない なので、これもちょっと困るなと思いました。。

 

価格を含めた商品情報が表示される

Amazonアソシエイトでは、クッキーの有効期間が24時間。例えば、あるユーザーが当ブログ内の商品リンクをクリックして、24時間以内にAmazonで商品を購入すれば、紹介した商品じゃなくてもアソシエイト紹介料がつきます。なので、アフィリエイト的にいえば、まずその商品リンクを「クリックしてもらう」ことが重要

それが、AmazonJSで商品リンクを作ると、商品名や画像だけじゃなくて、価格などの商品情報が表示される。人によってはその情報だけで満足してしまいクリックしない、ということもあり得るんじゃないかと。クリックが少なければ当然、売り上げのポテンシャルも下がりますので。

私はAmazonJSを使用する前は、デフォルトの表示ではなくて、商品名と商品画像のリンクを普通に貼り付けて紹介していたのですが、なんとなくAmazonJSにしてからクリック数が少なくなったような感じがしました。ハッキリとは言えないですが、価格とか分からないほうが、リンクをクリックしてみたくなりません?^^;

 

 

というようなデメリットを考えた結果、考え付いたのが、AmazonJSっぽい感じでCSSとHTMLコードを自作すれば色々解決するんじゃない?というアイデア。早速作ってみました^^

 

CSSだけで簡単にAmazon商品リンクを格好よく表示する

完成版はこんな感じです。

 

商品画像と商品タイトルのみで詳細な情報は表示しない、シンプルな表示ですが、ただ単に商品画像を貼り付けたりするより見栄えがいいですし、統一感も出るかなと。

基本はAmazonアソシエイトサイトから商品リンクのHTMLをコピペして使うだけ、表示をCSSで変えているだけなので他のプラグインとのバッティングももちろんありません。また、商品タイトルタグの部分には見出しタグも入っていないので記事内の構造の問題もこれで解決です^^

 

そんな大そうなことは本当にしていないですが、簡単なやりかたとHTML 、CSSを以下に載せておきます。

 

まず、繰り返し使用できるように、以下のコードをAddQuickTagに登録。AddQuickTagのことが何かわからない場合はGoogle先生に聞いてみてください。とても便利プラグインなのでぜひ使うことをお勧めします。

 

以下のCSSをカスタマイズ用のcssファイルかdesign.cssに加える。

divの幅や、色、フォントサイズはお好みに調節してください。

 

商品リンクはAmazonアソシエイトのサイトから、画像リンクとテキストリンクをそれぞれコピーして、上記HTMlの「ここに画像コード」「ここにタイトル」のところに貼り付けるだけです。

(AmazonJSに慣れちゃってわざわざAmazonアソシエイトサイトからコードを取ってきたくないという方は、AmazonJSから画像コードとテキストコードを取得することもできますね。)

パーマリンクを投稿名ベースに変更するなら超簡単な.htaccessでのアクセス転送設定がおススメ

number to nameパーマリンクを変更するとソーシャルメディアでの記事のシェア数がゼロになってしまうので本当は変更しないのがいいんですが、それでも今回思い切ってやろうと決意したのには色々理由があります。

この記事では、なぜパーマリンクを数字ベースから投稿名ベースにしたのか、そして投稿名ベースにするときに旧URLからのアクセスを簡単に引き継いでくれる設定方法をまとめてみました。

私が数字ベースのパーマリンクをやめたくなった理由

このブログを始めた3年前くらいまでは、数字ベースのパーマリンク(例 https://ruuski.net/web/archives/123/)はWordpressブログの表示が最も速くSEO的にベストだと言われていました。

当時はベストチョイスだったものも、Wordpress本体のバージョンが上がって数字ベースじゃなくても表示速度に問題なくなった現在、数字ベースがいいというのはすでに過去の話。

今は、カテゴリ名や投稿名を入れるほうがSEOにいいと言われています。これが、一番の理由。

 

私はもう一つのブログを運営してて、そっちのほうは

ドメイン/カテゴリ/投稿名

の形でパーマリンクを設定しているのですが、このブログより記事数も少なくてドメイン年数も少ないのに、アクセスが順調に伸び、今では当ブログよりも多くのアクセスを集めているんです。別に自分で二つとも運営しているからいいんですけど、手間暇かけている方がアクセスに伸び悩んでいるのはなんか悔しい(笑)

もちろん、アクセス数はブログが扱うテーマやコンテンツの質によるところが大きいので、パーマリンクを変えたからと言ってアクセス数が劇的に変わるということはないと思います。

でも、「SEOにはこれが最適!」といわれているのに、そうじゃない形のパーマリンクを使い続けるのは微妙だ…と思っていました。

 

ようは気持ちの問題っていうことですね。。

今後、さらに記事を増やしてく時に、このままの数字ベースで自分は我慢できるのか、と考えた結果、

「やっぱりケリをつけておこう」と。

 

.htaccessでごく簡単にURLの転送(古いURLから新しいURLへ)ができることも、今回の決定を後押しした要素です。(やり方は後述)

 

じゃあどんなパーマリンクがいいのか

変えると決めてからは、再度、どのパーマリンクの形がいいのか、考えました。
最近、主流になっているのは、以下の2つのタイプです。

 

1.ドメイン/カテゴリ名/投稿名/ のタイプ

パーマリンク: /%category%/%postname%/

例えば

locatimefree.com/デザイン/お洒落なブログに使える無料画像サイトPhotopin/

のような感じですね。日本語だとURLが長くなってしまうので、スラッグで英単語を設定し、

locatimefree.com/design/photopin-free-image-for-stylish-blog/

のような感じにすることもよくあります。

 

2.ドメイン/投稿名/ のタイプ

カテゴリと投稿名はスラッグで英単語を使い長いURLにならないようにするのが

パーマリンク: /%postname%/

この場合はカテゴリがないのでシンプルに

locatimefree.com/お洒落なブログに使える無料画像サイトPhotopin/

あるいはスラッグで英単語を設定し、

locatimefree.com/design/photopin-free-image-for-stylish-blog/

のような感じなります。

 

当ブログはこれまで何度もカテゴリの追加・削除が繰り返されてきたので、カテゴリをパーマリンクに含めるのはリスクが高い、ということで、2番目の投稿名だけのシンプルなパーマリンクを設定することに決めました。

 

ちょっと面倒だったのが、日本語を使ってURLが長くなるのを防ぐために、これまでの記事のタイトルスラッグを見直して英単語で設定しなおしたこと。でも、ついでにダメ記事を消したり、古い情報を編集したりなど、見直す機会にもなったのでよかったです。

前述しましたが、ソーシャルメディアでの記事シェア数がたくさんある方は、それが全部消えてしまうのはあまりにもったいないので、パーマリンクは変更しないほうがいいです。私みたいに「どっちにしろ大してシェア数もないし…」と開き直れる人だけ変更しましょう。

 

パーマリンク変更時に古いURLへのアクセスを新しいURLにリダイレクトする

WordPressの場合、プラグインを使ってリダイレクトする方法もあるようですが、私は.htaccessに一行追加するだけでOKな方法がとても楽チンでよかったです。

 

まずはWordpressのダッシュボードから 設定 > パーマリンク設定 を開き、共通設定のところで「投稿名」を選んで保存します。

パーマリンクの変更自体はこれだけですが、このままだと古いURLにアクセスが来た時に、404エラー(ページが見つかりません)になってしまいます。

 

そこで、古いURLへのアクセスを新しいURLに転送するために、.htaccessにリダイレクトの設定を追加します。

 

追加するコードは以下の手順で取得できます。まず以下のサイトにアクセス。

How to change your WordPress Permalink Structure

 

記事の最後のほうにGenerate Redirectsという緑色のボタンがあるのでクリックします。

すると以下のようなツールが表示されますので、順に必要な情報を入力していきましょう。

htaccess code for parmlink redirect

サブフォルダのところですが、Wordpressがサブフォルダに配置されていても、サイトのURLにそのフォルダ名が入っていないなら入力する必要はありません。例でいうと、このブログもサブフォルダwpにWordpressがインストールされているのですが、表示上はhttps://ruuski.net/web/wp/… と言う風にフォルダ名wpが入ってしまわないように設定しています。この場合はサブフォルダを入力しないでいいということです。

 

最後にGenerate Redirectボタンをクリックすると、生成されたコードが表示されます。

url redirect code for htaccess

このコードを.htaccessファイルの最後に追加します。FTPなどでサーバーから.htaccessファイルをローカルにダウンロードし、一行追加してサーバーにアップロードすればOK。

.htaccessはWordpressが配置されているサーバーのルートディレクトリにあります。「一行追加するだけだから」と油断せず必ず、.htaccessのファイルをバックアップして、何かあったらすぐに元に戻せるようにしておいてくださいね。

 

このように.htaccessで制御する方法の詳細は以下の二つのサイトを参考にさせていただきました。今回のパーマリンク変更を検討するうえでとても有益な情報がありました。ありがとうございます。上の説明では物足りないという方は、お二方のサイトを参考にしてください。

WordPress向けSEO上級編:適切なパーマリンクへの変更と複数言語への対応

パーマリンク変更を.htaccessでリダイレクトする方法。

モバイル端末かを判別するis_mobile関数の使い方と機能しないときの対処法

mobileこの記事は、モバイル端末とPCからのアクセスで処理を分けたいときに便利なWordpress関数wp_is_mobileとis_mobileの使い方について書いたものです。

 

Googleの検索アルゴリズムの変更で「モバイルフレンドリー」が実施される(2015年4月21日に導入)という発表があってから、色んなサイトやメールマガジンでこのことについて取り上げられているのを頻繁に見かけるようになりました。

 

これだけ騒がれているとスマホ対応済みだから大丈夫だと思っていても、何となく不安になります(笑) SEO Japanさんの記事を見ても、なんだか凄そうな感じ。。。

Googleのモバイルフレンドリー・アルゴリズムはパンダやペンギン以上のインパクトを与える

 

今後、WEBサイトはモバイル対応必須だということで、まだ未対応のWordpressサイトやブログなら、テーマをモバイル対応のものに変更するとか、あるいはプラグインWPtouchなどを導入するといった対応が必要になってきそうですね。

 

それと同時に、もう一つ知っておくと便利なのが、モバイル端末からのアクセスかどうかで処理を分けられる関数です。この記事では、Wordpressに標準で実装されているwp_is_mobile()と、function.phpにコードを追加することで実装できるis_mobile()関数について解説していきます。

 

スマホ・タブレットか、PCかで処理を分けるWordpress関数wp_is_mobile()

WordPressに標準で実装されているwp_is_mobile関数は、スマホ・タブレットをひとまとめにモバイル端末と判断します。

返り値がtrue: モバイル(スマホ・タブレット)からのアクセス

返り値がfalse: PCからのアクセス

ということですね。

 

使い方は、PHPのみでの処理なら以下のように記述します。

 

HTMLと組み合わせるときはこんな感じです。

 

ただ、このwp_is_mobile()のように、スマホとタブレットを合わせてモバイル端末とみなすより、スマホをモバイル端末、タブレット・PCをそれ以外という風に分けて処理したいときのほうが実は多かったりします。

そこで登場するのが自作関数is_mobile()。

 

スマホか、それ以外かで処理を分ける自作関数is_mobile()

繰り返しになっちゃいますがis_mobileの場合は返り値が以下のようになります。

返り値がtrue: スマホからのアクセス

返り値がfalse: スマホ以外(タブレット・PC)からのアクセス

 

実装はとても簡単で、ダッシュボードで外観 > テーマの編集にアクセスし、function.phpを開いて以下のコードを追加するだけです。

色んな人がいろんなところで同じような関数を作成していらっしゃいますが、いつも参考しているElloraさんのサイトに記述されていたものをコピペさせていただきました。ありがとうございます。

【WP初心者向け】is_homeとis_mobileを使ってカスタマイズの幅を広げよう!

 

あとはwp_is_mobile()の時と同様に、以下のように処理を分ければOKですね。

PHPのみでの処理の場合

 

HTMLと組み合わせるとき

 

is_mobile関数がうまく効かないときはキャッシュ系プラグインを疑え

WordPressでキャッシュ系のプラグインを使っている場合、is_mobile関数がちゃんと効かないことがあります。

私も最初is_mobileがちゃんと機能しなくて、PHPのコードがどこかで間違ってるのかと何度も確認したり、それでも結局よく分からずじまいで、ずいぶん困っていましたが、ようやく原因を見つけました。

どうやらサイトの表示を高速化するために使っているキャッシュ系プラグインW3 Total Casheが原因だった模様。

 

以下の記事に、W3 Total Cacheが原因でスマホ対応化プラグインWPtouchがちゃんと動かないという話とその解決方法が書かれていますが、is_mobile関数も同様の方法でちゃんと機能するようになりました。

WordPress の W3 total cache と WPtouch を併用するには除外設定が必要だ

 

W3 Total CacheのPage CacheとMinifyの設定画面で、Regected user agentsのところにモバイル端末一覧を追加するだけでよかったんです^^ 一覧は上のサイトからコピーしてくださいね。

rejected-user-agents

 

最後に、このis_mobile関数はどんなふうに活用できるのか、についてちょっとしたアイデアをシェアしたいと思います。

is_mobile関数の使って広告表示もモバイルフレンドリーにする

is_mobile関数の使い道は色々あると思いますが、私の場合はAdsenseの広告を表示するときに重宝しています。

Adsenseの広告サイズにはレスポンシブというのがあって、端末のサイズに合わせて広告サイズを調整してくれるのですが、これだと大きな余白に小さめの広告サイズで表示されることがあったりと、なかなか調節が難しく、だったら自分でis_mobile関数を使って広告サイズを切り替えてしまおう、ということで以下のように設定しました。

 

スマホの場合→ 320 x 100 ラージ モバイル バナー または 300 x 250 レクタングル

タブレット・PCの場合→ 728 x 90 ビッグバナー

 

PCだとビッグバナーのサイズは非常に効果があるのですが、横幅の狭いスマホではビッグバナーだと途中で表示が切れてしまうんです。

分かっていながら、しばらくそのままにしていましたが、スマホで横幅の狭い広告を表示されるようにしたら、モバイル端末での広告クリック数がPCからのクリック以上に増えました。(もっと早くやっておけばよかった・・・)

サイトやブログからの広告収入はアクセス数はもちろん、表示サイズや配置場所がかなりモノをいうということですね。ぜひ試してみてください。

WordPressサイトをデバッグ!Pleiades All in oneの設定手順

この記事では、Wordpressサイトのローカル開発環境をXAMPPとEclipsePDTで作るための手順をまとめています。

WordPressでも既存のテーマを利用したシンプルなウェブサイトやブログなら、ローカルで動かさずに直接サーバーにアップしてコンテンツを追加していくので十分いけますし、ちょっとしたデザインの変更や機能の追加などもダッシュボードからの編集でなんとかなりますよね。

 

これまでは私のWordpressの利用レベルもそんな軽い感じだったのですが、最近、オリジナルテーマを作りはじめたり、クライアントから依頼されたウェブサイトに、条件検索フォームを組み込む必要がでてきたりして、一気に「デバッグできるローカル環境がほしい!」モードになってきました。

 

WordPressサイトをローカルホストで動かすのに欠かせないXAMPPは既に使用中だったのですが、これに加えてPHPのデバッグ環境がどうしても欲しくなり、久々にEclipseを使うことにしました。(この時のこの変数の中身がどうなってるのか見たい!!!って思っちゃうとね・・・)

Eclipseはプログラマー勤務時代にJavaの開発で使っていたのですが、当時から開発環境の設定は本当に嫌い(ぜったい何かしらで躓いちゃうから)で、Google先生にお世話になりつつ、あれこれ5日間くらい手間取ってようやく全てが何とか動くように。。こんな苦労は二度としないためにも、この記事に一発、手順をまとめておこうと思った次第です。

前提条件

今回、XAMPP + Eclipse PDTを使い始めるにあたって、「こんな条件下でゴニョゴニョやっていました」という前提条件をまず挙げておきたいと思います。

  • OS: Windows 7 (64ビット)
  • Cドライブ直下にxamppを設置済み
  • 複数のWordpressサイトをローカルホストにインストール済み

上記のような状況ですので、今回の記事は、Wordpressを初めてローカルホストにインストールするのではなく、ローカルホストで動いている既存のWordpressサイトをEclipseで編集・デバッグできるようにするという流れになっています。

 

最初の試みと失敗

以前もEclipseで開発環境を作るときはAll in One パッケージを使っていたという記憶があり、Pleiades All in One PHPというのがとっても便利そうだったので、これをダウンロードすることにしました。

Pleiades All in One PHPには、xamppも含まれ、xdebugというデバッガーもxamppに設定済みだったり、eclipseでphpで開発するためのPDTとか、eclipseでphpを動かすために必要なものが一通りそろっているようです。

ただ私の場合、すでにxamppは利用していたので、Pleiadesの中のxamppではなく、Cドライブ直下にあった既存のxamppと今回ダウンロードしたeclipseを組み合わせて使おうという考えになり、この方向で設定を進めていきました。

が、これが原因で、いろんなところでエラーが発生。。。

 

Eclipseのほうではwordressサイトが見れなかったり(アクセス権がないエラー)、そのエラーを治すためにApacheの設定をいろいろいじっているうちに、今度はブラウザからwordpressサイトのトップページ以外Object not foundエラーになり、パーマリンクの設定をしなおしたけど結局エラーは消えず・・・などなど。

まだまだ、開発環境の設定の怖さを甘く見ていた初日。 「やっぱりダメだったか・・・」と痛い思いをしながら解決を試みたものの、モグラたたきのようにあちこちで発生しつづけるエラーには収集がつかなくなりました。(トホホ)

 

そんなときに、とあるサイトで「素直にPleiadesだけ使えばすんなりいく」みたいな言葉を発見。この言葉でふと我に返り、既存のxamppを使うというこだわりはやめて、Pleiadesに含まれるxamppを利用しようという結論に至ったのでした。

ここまでが大体ウダウダしながら2日間。今まで使っていたPleiadesはごっそり削除して、新たにzipファイルを解凍してやりなおし。以下、あらためて手順はPleiadesをダウンロードするところから始めます。

 

Pleiades All in One PHPのダウンロード

ダウンロードサイト: http://mergedoc.sourceforge.jp/

まず上のサイトからPleiades All in One をダウンロードします。私の場合、eclipseの現時点の最新版Eclipse 4.4 Luna、64bit Full EditionのPHP版を選んでダウンロードしました。(結構ボリュームがあるzipファイルなので、場合によってはちょっと時間がかかります。)

 

ダウンロードが無事に終わったら、zipファイルを解凍します。ここでの注意点は、二点。

  1. 解凍する場所をデスクトップなどパスが深くなるところに解凍しない。エラーが起きる可能性があるので。cドライブ直下(C:\pleades)のようにパスが長くならない場所に解凍する
  2. 解凍ソフトにLhaplusを使わない。ちゃんと解凍ができないらしいです。知らないでLhaplusで解凍し、見事eclipse.exeが起動しませんでした。。Windows7デフォルトの展開ウィザードか、7zipを使う。私は7zipでいけました。

 

解凍も結構時間がかかるので気長に待ちましょう。私のようにすでにxamppを使っているという方は、ここでバックアップを取っておいてください。

 

既存XAMPPからデータをバックアップ

  • データベースのバックアップ

まず、以前に使っていたXAMPPを起動し、ApacheとMySQLをスタートさせて、phpMyAdminにアクセス。今後も利用したいデータベースをエクスポートしておきます。エクスポートは普通にデータベースを選んでエクスポートボタンをクリックすれば、ファイルのダウンロードがはじまります。

あと、xamppやmySQLにパスワードを設定している場合はそれもメモっておくと後で楽です。

 

  • ファイルのバックアップ

xamppフォルダのhtdocsの中にあるフォルダのうち、今後も利用したいものを別の場所にコピーしておきます。

 

ここまでできたら、XAMPPのコントロールパネルを終了します。Pleiadesのダウンロードが完了していたら、ここで一度PCを再起動しておきましょう。

※既存のxamppは残しておいても起動さえしていなければ、Pleiades内のxamppとの間で特に問題は起きないので、私はあえてアンインストールしないで進めました。(何かの時にすぐ戻せるように・・・)

 

Pleiades内のXAMPPの初期設定

解凍されたpleaiadesフォルダをエクスプローラで開き、その中のxamppフォルダ内からsetup_xampp.batを見つけてダブルクリックします。

次に、xampp-control.exeを実行し、コントロールパネルを開きます。いつものようにApacheとMySQLのstartボタンをクリック。

※Apacheの起動でエラーになる場合、既存のxamppが実行中になっていないか、またSkypeなどの他のプログラムとのポートのバッティングがないか、チェックしてください。(Skypeの設定が問題の場合は、Skypeにログインし設定>詳細>接続にて「追加の受信接続にポート80と443を使用」のチェックを外します。)

 

ブラウザからhttp:// localhost/xampp/にアクセスし、以下のように表示されればOKです。

xamppようこそ

ここで、セキュリティ関係の設定をします。

上のページの左サイドバーのメニューから「セキュリティ」をクリック。表示されたページに「これらのXAMPPページは一般的にネットワーク経由でアクセス可能です」「MySQLユーザルートにパスワードがありません」「PhpMyAdminはネットワーク上から自由にアクセスできてしまいます。」といった警告がある場合、設定が必要になります。

 

同ページの「そのような問題をすべて修正するには、単純に次のツールを使ってください。」の下にあるURL

http://localhost/security/xamppsecurity.php

にアクセスします。「MYSQL 項目: “ROOT” パスワード」と「XAMPPのディレクトリ制御 」の項目を入力します。これまでxamppを使っていた方は、その時のユーザー名、パスワードを入力しましょう。

 

http://localhost/phpmyadmin/にアクセスして、ログインが成功すれば初期設定完了です。

※phpMyAdminのアクセスでエラーが起き、エラーメッセージにconfig.inc.phpの設定がどうのこうのうと書かれている場合、pleiades/xampp/phpMyAdmin/config.inc.phpを開いて、/* Authentication type and info */のパスワード設定がちゃんとされているかチェックしてみてください。パスワードが設定されていない場合は、xamppのセキュリティページで入力したパスワードを入力してファイルを保存し、再度phpMyAdminにアクセスしてみてください。

 

XAMPPにバックアップデータを取り込む

既存xamppから移行したいデータがある方は、バックアップしておいたwordpressサイトのデータをpleiades内のxamppに取り込んでいきます。以下の2点を行います。

  1. xampp/htdocsフォルダ内からバックアップ(コピー)しておいたフォルダ・ファイル類をpleaiades/xampp/htdocs内に配置
  2. エクスポートしておいたmySQLのデータをphpMyAdminからインポート

 

ここまでできたら、ローカルホストからwordpressサイトにアクセスできるかチェックします。

http://localhost/wordpressサイトのルートフォルダ名/wp-admin/

で、ダッシュボードにアクセス。

※ここでデータベースのユーザー・パスワードに関するエラーが出たら、htdocs/wordpressサイトのルートフォルダ/wp-config.phpを開き、DB_USER、DB_PASSWORDに書かれているユーザー名、パスワードをphpMyAdminのユーザに追加してください。

 

無事にダッシュボードにアクセスできることが確認できたら、次はサイトのトップページや他のページを開けるかどうか確認しておきます。

 

さて、ここまででPleiades内のxamppの初期設定と、既存サイトデータの移行が完了しました。ここから、wordpressサイトのデバッグ環境=eclipse の設定を行っていきます!

 

 

EclipseにWordpressサイトをプロジェクトとして追加する

ここからが今回の肝、まずはpleiades/eclipse/eclipse.exeを実行し、eclipseを起動。起動には少し時間がかかるけど気長に待ちます。

もしここで起動されない場合は、zipの解凍がうまくいっていない可能性あり。Pleiades eclipse Luna 4.4の場合、pleiades/eclipseのフォルダ内は以下のような構成になっています。

pleiadesのeclipseフォルダ構成

見比べてフォルダがなんか足りないなと思ったらPleiadesを別の場所に解凍しなおし、その中のeclipseフォルダだけごっそりコピーしてくればOK。

 

起動されると、最初にワークスペースの場所を聞かれますが、今回はpleiades/xampp/htdocs/にwordpressサイトのフォルダを配置しているので、デフォルトで入力されている ../xampp/htdocs/のままでOKボタンをクリックします。

 

プラットフォームが表示されたら、ファイル>新規>PHPプロジェクトを選択。

ウィザードが表示されるので、プロジェクト名に今回編集したいwordpressサイトのルートフォルダ名(xampp/htdocフォルダに配置してあるwordpressサイトのフォルダ名)を入力します。

ここ、重要なので、しつこくキャプチャも載せておきますです。(こんなこと分からないのは自分くらいかもしれないですが、最初は適当なプロジェクト名を付けて全然うまくいかなかったので。。)

eclipseでPHPプロジェクト作成

 

このようにするとワークスペース(../xampp/htdocs/)内にあるwordpressサイトのフォルダ以下をプロジェクトとして編集することができるようになります。上記のウィザードでは、Javascriptサポートにチェックをいれてあとは「次へ」でどんどん進んで完了すればOKです。

以下のようにプラットフォームにwordpressサイトが追加されました!ツリーを展開して、wp-adminなどのフォルダやphpファイル類が読み込まれていることを確認してみてください。

eclipseにwordpressサイト追加

 

Eclipseでwordpressサイトをデバッグする

さて、Eclipseでwordpressサイトをデバッグするには、もう少し設定が必要になります。

ウィンドウ>設定>PHP>PHP実行可能ファイルを選択し、追加ボタンをクリック。

eclipse php実行ファイルの設定

名前のところには分かりやすいようにPHPのバージョンなどを入れておくといいです。実行可能ファイルとphp iniファイルをpleiades/xampp/php/php.exeとphp.iniにそれぞれ設定し、PHPデバッガーにXDebugを選択してOKをクリックします。

 

次に、デバッグの構成を作成します。

実行>デバッグの構成をクリックし、画面左側のPHP Webアプリケーションを右クリックして「新規」を選択します。

eclipseデバッグ構成1

 

以下のような画面が表示されたら各項目を設定していきます。

eclipseデバッグ構成2

名前は分かりやすいようにプロジェクト名などを入力します。

ファイルのところはプロジェクト名(ルートフォルダ)/index.phpを入力。

URLには、デバッグしたいページを設定します。トップページをデバッグしたい場合は自動生成をチェックすればいいですが、それ以外の場合は、自動生成のチェックを外し、そのページのURLに合うように入力する必要があります。ここがうまく設定できていないとデバッグがうまく行われないので注意してください。

 

次に「デバッガー」タブをクリックし、以下のようにデバッガーがXDebugになっていることを確認します。

eclipseデバッグ構成3

 

適用ボタンをクリックして閉じます。

以上で、デバッグの設定が完了しました!

 

実際にデバッグするには、XAMPPでApacheとMySQLが起動されている必要があります。起動していない場合は、XAMPPコントロールパネルでApacheとMySQLをstartさせましょう。

eclipseでデバッグを実行します。実行>デバッグをクリックしてもいいですし、緑色の虫マークをクリックしてもデバッグを開始できます。パースペクティブの変更のポップアップがでたら許可します。

index.phpの最初の行でブレークされればデバッグが無事、動いていることになります。ホッと一息ですね^^ デバッグしたい部分にブレークポイントを貼ってガンガン中身をチェックしてデバッグを加速させていきましょう!!

 

終わりに

WordPress + XAMPP + Eclipse(PDT)の組み合わせで検索すると、かなり親切な解説をしてくれているサイトが幾つかあってとても参考になりました。特に、以下のサイトの説明に大変お世話になりました。ありがとうございます!