「wordpress」カテゴリーアーカイブ

wordpressに関する自作制作物です。他の所に提供したものもあります。色々と作り散らかしているので勝手に改変しちゃって扱い安いように使ってください。プラグイン多めでテーマもたまに作ります。

SNS連携もCDNもエンドレススクロールも全部こみこみ。wordpressプラグインjetpackを使おう

最近wordpress記事が多いですね。プラグインはどれもこれも特徴があって、入れたくなるものですが、あまり入れすぎるとセキュリティ、ページ表示速度に影響が出てきます。

jetpackはwordpressから直接提供されているプラグインで、色々な機能がセットになっています。

Jetpack for WordPress

無料で出来る設定で、特に使えそうな機能をリストアップしてみます。

  • 投稿をSNS(Facebook・Twitter・Tumblr・Yahoo!・Linkedin)に通知する
  • 低負荷でシンプルなサイト統計情報
  • いいねボタン
  • 強化された検索フォーム
  • コンタクトフォーム
  • ウィジェット表示設定をポスト、ページなどで変更する
  • youtubeなどの動画ウィンドウをショートコードで読み込む
  • WP.meドメインの短縮アドレス
  • サイトをモバイルサイト用に自動で最適化
  • カスタムCSS
  • markdown記述
  • 追加ウィジェット(ツイッタータイムラインやRSS一覧など)
  • 無限スクロール
  • CDN
  • 投稿を各種検索エンジンなどに共有
  • 動画アップロード機能

これらの機能が全て無料で使うことが出来るようになります!! ヒャッホウ!

その中でも特に御世話になっているCDNとサイト統計を軽く説明しましょう。

有効化するだけ、速CDN!

CDNとは、画像やJSファイル等をクラウド上に置いておいて、負荷を分散する手法です。cloudfireが最近流行りましたよね。噂によると爆速、というのは聞いては居たのですが、設定が面倒くさかったんですね・・・(遠くを見る目)。

jetpackなら、有効化ボタンを押すだけで速適応ですよ。それだけ。鼻血が出る簡単さですね。

実際、サイトの表示速度は0.5秒ほど早くなりました。ありがたやありがたや。

最低限の数字は見れる統計機能

さて、色々な情報がダダ漏れですが。良いんです。こんな弱小ブログのアクセス数なんて。ふへへ。

リファラ、人気記事、検索キーワードとある程度の情報が見れます。もっと詳しい情報はどうせグーグルアナリスクで見ればいいんですよ。こんくらいで十分です。wordpress上で見れるという事が重要ですよね。これがjetpackというプラグイン一個でまかなえるのだから素敵すぎて鼻血が出ます。

サイト閲覧中でも、上の帯でその日の統計が見れます。これまた素敵。チラチラ見ちゃう。素敵すぎる。

プラグインが多すぎてお悩みの方、jetpack、是非いれてみてくださいな!

 

何も考えずサイトを移転したらアクセス数が10分の一以下になった話

 

これ、何の画像かわかります? 私のサイトのアクセス数です。見たとおり、かなりパナイ降下っぷりを示しています。恐ろしい。

今、このサイトがあるドメインは「ao-works.net」という名前で、一ヶ月前に取得した物です。新しく取得したばかりだから、検索サイトからも評価が低い状態なんですね。

前あった場所はかなり時間が立ち、良ドメインではあったのですが、巣立ちという意味合いも込めて心機一転。新しくやっていこうと思ったわけです。

サイト移転はリダイレクトをしっかりと

前のサイトからこちらのサイトへ移る際、前の方では検索エンジンにインデックスさせないように設定していました。

 

「ダッシュボード>設定>表示」にあるこのチェックボックスにチェックを入れるんですけれどね。これでサイトが完全に分裂した状態です。

さらには、依存記事を一旦非公開に。結果大量の404ページが量産されることに。今考えると何してるんでしょうね、私。

301リダイレクトを選択する事

サイトを移転する – ウェブマスター ツール ヘルプ

301 リダイレクトを使用して、以前のサイトにあるすべてのページを新しいサイトに完全にリダイレクトします。これにより、検索エンジンやユーザーに、サイトが完全に移転したことを知らせることができます。最初に 1 つのセクションまたはディレクトリを移転してリダイレクトし、リダイレクトが正しく動作することをテスト、確認してから、すべてのコンテンツを移転することをおすすめします。

googleさんもこういっておられますし。301リダイレクトにしましょう。そうしましょう。

wordpressは便利なプラグインがある

301リダイレクトを設定するには「.htaccess」ファイルを弄る必要があります。どのFTPソフトとかで直接ファイルを触るので、知識が無いとちょっと怖いですね。中身も意味不明な呪文みたいなのが書かれてますよ。私にはちんぷんかんぷんです。ええ。

というわけで素直にwordpressプラグインに頼ります。

WordPress › Redirection « WordPress Plugins

日本語対応でわかりやすく、正規表現が扱えます!ワオ!

 

設定はこんな感じです。詳しいプラグインの解説なのでは他のサイトが詳しくやってくれるので割合しまして。

前のサイトと、今のサイトではちょっとパーマリンクの設定が違います。前のサイトでは語尾に「.html」がついていたのですが、今のサイトではついていないのです。

「(.*).html」という表記は、.htmlまでを全て認識しつつ、「.html」の前の部分だけを記憶する、という正規表現の表記です。

対してリダイレクト先の設定の「http://ao-works.net/$1」にある「$1」は、記憶した文字列をここに追加する、という意味です。

設定したら、実際にリダイレクトできるかどうか試してみましょう。

http://cre.jp/honyomusi/see-uss-picture-summary-just-to.html

アドレスに注意してアクセスしてみてくださいね。

あとは結果を黙して待つ。

手遅れな気もするのですが、とりあえず結果をまってみようと思います(汗

数ヶ月後くらいにどうなったのかの経過報告をさせていただきますね・・・。

wordpressのパーマリンクを自由に制御する

wordpressライフ楽しんでますか。おーいえー。

今回はパーマリンクについてです。

よくある形ですね。しかし、単純にタイトルをパーマリンクにするだけだけではなく、色々と自動で追加したい、という事があるかもしれませんね。たとえばタグとか、カテゴリとか。

そういう時には少し工夫しないと行けません。

function parm_rep($title) {
if($_POST['post_name'] == "") {

挟む処理

return $title; 
} return $title; }

add_filter('name_save_pre', 'parm_rep');

で、これがそのフィルターです。通常であれば、タイトルがそのままポストネームになりますが、この処理を挟む事で色々と付け加えたり削除したりする事が出来ます。「if($_POST[‘post_name’] == “”)」は、ポストネームが空なら、というif文です。既に設定されていた場合はスルーする感じですね。

function parm_rep($title) {
if($_POST['post_name'] == "") {
return "test"; 
} return $title; }

add_filter('name_save_pre', 'parm_rep');

例えばこうすると、ポストネームが未決定の場合、自動で「test」という文字列が入る、という処理になります。

私の場合はこれを利用してポストネームを英訳してパーマリンクにしたりしてますよ。

 

こんな感じです。先のフィルターを使って、処理でマイクロソフトの翻訳APIを通してパーマリンク化してます。実際便利。

wordpressのMOファイルに悩んでるならMOキャッシュプラグイン「001 Prime Strategy Translate Accelerator」が良いよ!!

やっほー! 楽しいwordpress生活、楽しんでますか?

私はそろそろこのハイテンションキャラ疲れて来ました。四月くらいからはダウナー系でやっていこうと思います。

さて、wordpressの高速化の話題は尽きませんね。オブジェクトキャッシュとかファイルキャッシュとか。キャッシュキャッシュ。もうこれでもかというくらいキャッシュ。どんだけ重いんだwordpress!! まあいんです。それでも私はwordpressを愛してますから。

さて、前置きは置いておいて、MOファイルですよ。

元々英語のwordpressを日本語化するファイル群、それがMOファイル

wordpressは日本の物じゃないですよね。それが日本語で利用できるのはMOファイルのおかげです。英語の文言を表示する前にこいつに問い合わせて、日本語化できれば日本語にして返すわけです。

が、まあ一つ一つの文言毎にこいつを読み出すわけです。もちろん処理もします。ただ文字を読み出すためだけに!!!

これ一つ一つの項目にmoファイルから該当文言と付き合わせて表示しているわけですよ。そりゃあ重くなりますよね。そこで今回の「001 Prime Strategy Translate Accelerator」ですよ!

単独動作が可能な実際素敵プラグイン

[browser-shot width=”450″ url=”http://wordpress.org/plugins/001-prime-strategy-translate-accelerator/”]

入手はここから。

MOファイル系のプラグインで有名所は「WordPress › MO Cache « WordPress Plugins」があったりしますが、これは他にもキャッシュ系のプラグインを導入しなければなりません。加えて、私は過去に痛い目をあっております。→「MO cache」はもしかするとすさまじい容量を食うかもしれない。 – aoringo works

ですがこのプラグインは違います。そもそもMOファイルを使わないという選択が出来るのです! ΩΩΩ<な、なんだってー!

 

これがその画面です。私はダッシュボードやログインは普通に翻訳し、サイト部分は翻訳させないようにしています。テーマファイルは私が直接弄り倒しているので翻訳する部分もほぼゼロですからね。

 

ちゃんとサイト表示の時は上の帯部分が翻訳されずに英語になっているのが確認出来ます(管理人だけが見えるのですがね、これは)

ダッシュボードなどの部分の速度を早くしたければ、設定でキャッシュするようにすると良いと思いますよ!! 好みでどうぞ。

 

「MO cache」はもしかするとすさまじい容量を食うかもしれない。

MO casheは、他のキャッシュ系のプラグインに組み合わせて利用するwordpress高速化プラグインです。プラグイン等の言語ファイルである「.mo」をキャッシュする事により、動作速度を向上させる・・・・そうなのですが、これがなんと4GBにもなってました。

なんですか4Gって。意味分かりません。びっくりですよ。

実際の閲覧では他のキャッシュ系プラグインでまかなえますし、moファイルが動作するのは大抵ダッシュボードくらいです。なので当ブログではMO cacheは停止しました。

むーん。他の人のMO cache利用ではどのような容量になっているのでしょう。少し気になりますね。

[browser-shot width=”450″ url=”http://wordpress.org/plugins/mo-cache/”]

あくまで私の環境では4GBになった、というお話なので参考程度にどうぞ~。

プログラム等のコードハイライトを「WP Code Prettify」に変更したよ!

チャオ! この挨拶に特に意味は無いよ。

wordpressでのブログ執筆はとても楽しいですよね。楽しいんですが、色々な種類の記事をごちゃまぜで書いてる私には困った事も多いんですよ。

 

wordpressでの記事作成では、完成記事に近いブレビューをみながら編集する「ビジュアル」と、htmlタグを直接いじいじしながらやる「テキスト」の二つの編集モードがありますよね。私はへっぽこ日曜プログラマーなので、両方使ってます。

で、本題のコードハイライトプラグインなのですが。これがもう大変なわけですよ。両方を行ったり来たりしてるとこのコードが変な変換をされてしっちゃかめっちゃか。最終的には文字化けみたいになっちゃったり崩れまくりだったわけです。

それで今回見つけたのが「WP Code Prettify」ですよ。ショートコードではなくpreタグによる記述なので、ビジュアルエディタとテキストエディタを行き来しても影響をありませんよ!わーい。

[browser-shot width=”450″ url=”http://wordpress.org/plugins/wp-code-prettify/”]

<?php if(function_exists('wp_pagenavi')): ?>
 <?php wp_pagenavi(); ?>
 <?php else : ?>
 <div class="navigation">
 <div class="alignleft"><?php previous_posts_link(__('Previous page')) ?></div>
 <div class="alignright"><?php next_posts_link(__('Next page')) ?></div>
 </div>
 <?php endif; ?>

ちなみにこんな感じです。うん、良い感じですね!

もしも今後、このプラグインを削除したとしてもpreタグでは残るので最低限の見た目も保証されます! 安心!!

記事下部にアマゾン商品広告を検索・表示するwordpressプラグイン「aoringo amazonradming」

はじめに

おーいえー! ブログ運営頑張ってますか!? 私はほどほどです! むしろ最近怠けてました。おーいえー。

アマゾン広告は、商品を勧めつつ紹介料も貰える素敵なブログツールの一つです。しかし、一つの商品を紹介するなら問題は無いですが、アットランダムにその時最新の商品広告を出したい。そういう時ってあると思います。少なくとも私はありますよ。

そういうわけで作成しました。特定の検索ワードで商品を検索し、ランダムに表示するアマゾン広告プラグインを。いえいいえい。

機能

幾つか機能があります!

  • ウィジェット広告
  • 自動記事下広告
  • 記事毎指定キーワード商品広告
  • 記事に設定されたカテゴリを検索キーワードにする
  • 毎回商品ランダム入れ替え
  • 結果キャッシュ機能

ざっとこんな感じです。

導入

ダウンロードしてプラグインを有効化したあとダッシュボードの設定から「アマゾン広告設定」を選択して各種必要な設定を入力。

 

上三つはアマゾン広告に必要な各種設定です。簡単ですね。下二つですが、

「記事デフォルト検索ワード(空だとカテゴリをキーワードとする)」は基本的に検索する商品のキーワードを入力します。サイトの内容が全てプログラムに関するものだったら適当に「プログラム」とか入れておけばそれっぽい商品を毎回検索してくれます。空のままだと記事に設定されたカテゴリを元に検索します。これにより記事が「php」のカテゴリだったらphpの商品を、「wordpress」のカテゴリならwordpressの商品を出してきますよ。むっちゃ便利やん!?

「記事下表示件数(0だと表示しない)」は記事の最後につけるアマゾン商品広告の数を設定します。最大数は多分20件くらいまでです。それ以下だと順番や商品を毎回ランダムに入れ替えて表示してくれます。これで既視感無く広告を出せますね。むふふん。

ウィジェットの所では「アマゾン広告」という物が登場していると思うので、それを好みの場所においてください。こちらもキーワードや数を設定する事で商品を出せますよ。実際便利。

記事別キーワード設定機能

プラグインを有効にすると編集画面にメタボックスが追加されます。

普通は無記入で問題無いですが、この記事だけはこの商品を出したいな、という時があると思います。そういう時はここに指定の文字列を入れてください。そうするとその記事だけ商品が変わります。

キャッシュ機能

キャッシュはwordpress標準のキャッシュ関数を使っています。mysqlに保存するタイプなので、mysqlが汚されるのが嫌な人は導入しないでください。

css無し

適当にdivを吐き出すのでcssで整えてください。基本的に私好みに作ったのでご自由に修正してくださいね! わーい!

ダウンロード

こちらからダウンロードだぜぇ!

wordpressプラグイン「W3 Total Cache」を導入している人は管理者メニューが見えていないか確認しよう

WordPress › W3 Total Cache « WordPress Plugins
Easy Web Performance Optimization (WPO) using caching: browser, page, object, database, minify and c …

タイトルなが。

W3 Total Cacheはとても便利です。php処理の結果をキャッシュしそれを表示します。アクセスするたびに毎回処理をしていても無駄ですものね。ありがたい存在です。

しかし!! そのキャッシュの内容に、管理者である貴方用の表示が収納されている可能性があります! 具体的には、

 

こういうのです。

名称がよくわかりませんが「管理者メニュー」って感じですかね。この画面を表示してすぐに別デバイスで確認すると、管理者メニューが丸見えじゃないですか!!!

そこから中に入ろうとするとパスワード画面ではじかれるわけですが、あまり気持ちのいいものではありません。閲覧する人にとっても使い道のないリンクは邪魔なだけです。

管理者が閲覧したときはキャッシュを保存しないように設定しましょう。

ダッシュボード>Performance>Page Cache>Don’t cache pages for logged in users

 

これでログインしているユーザはキャッシュされなくなりました。安心!

wordpressでの投稿前にTRPGリプレイ文体をPHP処理で整形する

TRPGネクロカ「箱庭茶会 コンベンション」灰色卓リプレイpart0 – キャラ作成から始動 | aoringo works

リプレイのスタイルを少し変更し、名前を太字にしてみました。あとは改行されてもスペースを置かないように変更。一般的なリプレイ本と同じ文体ですね。

投稿する時にphp処理を挟む

文章を太字にするには「<b>」タグを利用します。つまり、リプレイの名前に全てこれを埋め込む必要があるのですね。執筆してる段階でそれらを入れていくのは疲れるものです。

グリーンマン:「”私”は構わないのだが。本当に案内せずともよいのかね?」
アン:「故郷を追われた時から覚悟を決めているわ。例え骨になろうともそれが私の運命。受け入れる覚悟は出来ている!」
グリーンマン:「そうか。残念だ。本当に、残念だ。骨になるなんて、そんなの、本当に、もったいない・・・」と笑みを称えて二人を見送ります。

これを、

<b>グリーンマン:</b>「”私”は構わないのだが。本当に案内せずともよいのかね?」

<b>アン:</b>「故郷を追われた時から覚悟を決めているわ。例え骨になろうともそれが私の運命。受け入れる覚悟は出来ている!」

<b>グリーンマン:</b>「そうか。残念だ。本当に、残念だ。骨になるなんて、そんなの、本当に、もったいない・・・」と笑みを称えて二人を見送ります。

こうしたいのです。wordpressでは、一度の改行で「<br>」、二度の改行で「<p>」としても処理されるので、改行を自動でつけるようにもしたいところ。

そういうわけで、ゴリゴリ書いていきますね。

投稿時に内容に処理を挟むには「content_save_pre」フィルター

名前の通り、内容を保存する前に働くフィルターです。

function replace_post_cont($text) {
  $text = preg_replace_callback('/(trpgreplay.*?>)(.*?)(?=</div>)/ius', "trpgreplay", $text);

  return $text;
}

add_filter('content_save_pre', 'replace_post_cont');

記事を保存するときに、「replace_post_cont」関数が働きます。「replace_post_cont」は記事を正規表現で整えるために用意しました。

「preg_replace_callback」は正規表現により抜き出した内容を、さらに関数を使って処理を挟むことができます。かなり便利です。

TRPGリプレイはdivタグの「trpgreplay」クラスを使用しているので、これを検索、中身を抜き出しています。

function trpgreplay($matches) {
  $text = preg_replace("/r/ius", "", "$matches[2]");
  $text = preg_replace("/n+/ius", "n", "$text");
  $text = preg_replace("/n(?!n)/iu", "nn", "$text");
  $text = preg_replace("/^(?!<)(.*?:)/ium", "<b>$1</b>", "$text");
  return $matches[1].$text;
}

そしてリプレイを整形しているのがこれです。「$matches」配列の[0]はマッチングした全体、[1]は$1にマッチングした部分、[2]は$2にマッチングした部分が収納されています。この場合、[1]には「trpgreplay”>」が、[2]には「リプレイの内容」が収納されています。

  $text = preg_replace("/r/ius", "", "$matches[2]");

内容のデータには「r」と「n」といった改行コードが混在している可能性があるので、「r」をまず全て消します。(正規表現じゃなくて普通の置換でよかったかも)

$text = preg_replace("/n+/ius", "n", "$text");

連続した改行を全て単発の改行に直します。これでエディタで執筆した内容の改行がゆらいでも大丈夫です。

  $text = preg_replace("/n(?!n)/iu", "nn", "$text");

単発の改行を二つの連続した改行に直します。一旦クリーニングして再度二度改行してるわけですね。

  $text = preg_replace("/^(?!<)(.*?:)/ium", "<b>$1</b>", "$text");

行の始めが「<」で始まらない場合は「:」までをbタグで囲むという処理です。ここをミスると「<b><b><b><b>」とひどいことになります。

最後にreturnで戻して完了。最終的な形は下記となります。

function trpgreplay($matches) {
  $text = preg_replace("/r/ius", "", "$matches[2]");
  $text = preg_replace("/n+/ius", "n", "$text");
  $text = preg_replace("/n(?!n)/iu", "nn", "$text");
  $text = preg_replace("/^(?!<)(.*?:)/ium", "<b>$1</b>", "$text");
  return $matches[1].$text;
}
function replace_post_cont($text) {
  $text = preg_replace_callback('/(trpgreplay.*?>)(.*?)(?=</div>)/ius', "trpgreplay", $text);
  return $text;
}

add_filter('content_save_pre', 'replace_post_cont');

完璧! 満足ちゃん。

スマフォでのブログ表示が崩れていたので見ている端末によって表示を変えるようにしました

はじめに

ぴゃああああー!!

実は今まで、このブログの見た目になってから主にappleのスマート端末にて表示が崩れている問題を抱えていました。解決がめんど時間を中々見つけられず今まで放置しておりましたが、今回手を加えることにしました。

閲覧している端末を識別して処理を変える

どうやら問題はスライダーにあるようでした。pcでの閲覧には特に問題ないのですが、スマートフォンなどで閲覧すると、スライダー部分の黒が下まで伸びちゃうんですね。JavaScriptの処理周りで不具合があるようです。

そもそもスライダー自体が画像を多用する関係上、野外で使用するであろうスマートフォンでの閲覧には負荷が高めです。スライダー、無くしちゃいましょ。

ユーザーエージェントによってPCとスマートフォン(iPhone / Android)を振り分ける方法いろいろ(PHP / JavaScript / .htaccess等) | HTML5 – CSS3 mag

こちらのphpでの処理を参考に、「PC閲覧での表示の場合のみスライダーを表示」という形にしてみました。

  <?php
  if (is_front_page()) { //トップぺージだった場合
  $ua = $_SERVER['HTTP_USER_AGENT'];
  if ((strpos($ua, 'iPhone') === false) && (strpos($ua, 'iPod') === false) && (strpos($ua, 'Android') === false)) { //スマートフォンではなかった場合
  ?>

こういう感じです。

iphone、ipad、android、それぞれのユーザーエージェントでは無かった場合、PC用のスライダーを表示します。

お手軽ですね。

しっかりばっちり!!