Translation
カレンダー
February 2019 S M T W T F S « Nov 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 検索
Categories
Archives
- November 2013 (1)
- January 2013 (1)
- July 2012 (1)
- May 2012 (1)
- March 2012 (3)
- February 2012 (4)
- January 2012 (9)
- December 2011 (5)
- November 2011 (6)
- October 2011 (9)
- September 2011 (5)
- August 2011 (12)
- July 2011 (7)
- June 2011 (10)
- May 2011 (12)
- April 2011 (12)
- March 2011 (2)
- February 2011 (6)
- January 2011 (3)
-
Recent Posts
Recent Comments
- infonitascom on 高度なコメントサービス、「DISQUS」をWordPressに導入する
- Bharath Sago on 初心者による初心者のためのPHP講座 第8回 ループ処理
- Aidan Castles on IEのレンダリングモードをタグで明示的に指定する
- 三浦 on Google Translate API v1の終了とWordPressの翻訳プラグイン
- Masanori Hasegawa on 高度なコメントサービス、「DISQUS」をWordPressに導入する
redcockerの関連サイト
万年筆関連のリンク
文具関連のリンク
革製品関連のリンク
フィード
-
Recent pins
Unable to load Pinterest pins for 'redcocker'-
Tag Archives: WordPress
WP SyntaxHighlighter バージョン1.5 リリース
「WP SyntaxHighlighter バージョン1.5」をリリースした。 最新の「WP SyntaxHighlighter」をダウンロード バージョン1.5では、「WP SyntaxHighlighter Widget」というウィジェットを追加している。 このウィジェットは、標準のテキストウィジェットに近いが、テキストエリア内のソースコードの強調表示が可能である。 また、バージョン1.4からは、コメント欄に入力されたソースコードの強調表示が可能となっていたが、ソースコードを強調表示するためには、<pre>タグを手入力してソースコードをマークアップする必要があり、けして使い易いものではなかった。 そこでバージョン1.5では、必要に応じて、コメント欄にソースコードを<pre>でマークアップするためのテキストリンクボタンを追加出来るようになっている。 コメント欄にペーストしたソースコードを選択、反転表示した状態で、対応する言語のテキストリンクをクリックすると<pre>タグでマークアップされる仕組みになっている。 ただし、このボタンを追加できるのは、WordPress 3.0以上の標準のコメント欄に限る。 なお、同様のテキストリンクボタンを「WP SyntaxHighlighter Widget」にも採用しているが、こちらはWordPress 2.8以上で動作する。 同梱のサンプルプラグインで追加できる言語の数も増え、「DOSバッチファイル」と「Objective-C」を新たに追加した。
EZ zenback バージョン1.4 リリース
「EZ zenback バージョン1.4」をリリースした。 最新の「EZ zenback」をダウンロードする 前回のメジャーアップデートから日が浅いが、ごく簡単な修正で「EZ zenback」を適応できるサイトが増える事が分かり、コードの追加、変更箇所自体は少ないものの、メジャーアップデートと位置づけた。 リリースを早めた理由は、重大なバグを発見したからである。 バージョン1.4では、コメントが許可されていないページ、つまりコメント欄が表示されていないページでも「zenback」の表示が可能になった。 この機能の追加により、コメントを許可していないサイトでも「EZ zenback」の利用が可能になった他、一部にコメントを許可していないページがある場合でも、それらのページで「zenback」の表示が可能となった。 ※管理画面の「設定」->「ディスカッション」や投稿や固定ページの編集画面の「ディスカッション」でコメントを許可していない場合。 また、標準のコメント欄を「DISQUS」で置き換えている場合も、コメントを許可していないページがあれば、それらのページで「zenback」の表示が可能である。 「DISQUS」の場合は当てはまらないが、標準のコメント欄を、他のコメントシステムをで置き換えている場合は、この機能を試す価値があるかもしれない。場合によっては「zenback」が表示される可能性がある。 ちなみに、「zenback」の表示位置は、本来、コメント欄があるべき位置となる。 ただし、この機能が使えるは、WordPress 3.0以上のみとなる。 WordPress 2.8.xまたは2.9.xで、「EZ zenback」と「DISQUS」を併用してる場合は、この機能は働かない。 実は、このバージョンの準備中に、今まで全く気づかなかった重大なバグを発見した。 標準のコメント欄を使用し、かつ「EZ zenback」設定で「zenbackタグを追加」を有効にしていない場合は、「zenback」が表示されないという不具合を修正している。 このサイトでも「EZ zenback」を利用しているが、コメントシステムに「DISQUS」を使っているため、このバグに関しては、恥ずかしながら全く気づいていなかった。 「zenbackタグを追加」は、デフォルトでは、無効になっているオプションであるため、おそらく、多くのサイトで「EZ zenback」をインストールしても「zenback」が表示されないという不具合が発生していたものと思われる。 この場でお詫びさせて頂く。 また、本来は「add_action()」とすべきところに「add_filter()」を使用していたため、これを修正している。 今のところ「WordPress」では、アクションフックとフィルターフックを厳密に区別していないため、これに関しては影響は無かったはずだ。
「WordPress.com Stats」から「Jetpack by WordPress.com」に移行
「WordPress.com」が提供するアクセス解析、「WordPress.com Stats」を使用しているが、プラグインの「WordPress.com Stats」をアップデートしたところ、「Jetpack by WordPress.com」をダウンロードを促すメッセージが表示された。 今後、「WordPress.com Stats」を利用する場合は、プラグイン「WordPress.com Stats」に代わって「Jetpack by WordPress.com」を使いなさいと言う趣旨らしい。 「Jetpack by WordPress.com」はインストールし、有効化しただけでは利用することは出来ないが、設定は自体はごく簡単で「WordPress.com」のアカウントでログインするだけで良い。 設定を完了すると、プラグイン「WordPress.com Stats」は自動的に無効化された。 「Jetpack by WordPress.com」を使うことは自体は問題ないのだが、私にとっては不要な機能まで付属している。 Twitter Widget・・・ツィートを表示するウィジェット。個人的には不要。 WordPress.com Stats・・・アクセス解析。これが必要。 Gravatar Hovercards・・・コメントでプロフィールなどを含むホバーカードが表示出来るらしい。個人的には不要。 After the Deadline・・・スペル、文法、スタイルのチェックを提供。個人的には不要。 Shortcode Embeds・・・YouTube、Flickrなどのメディアを埋め込めるショートコードを提供する。個人的には不要。 LaTex・・・複雑な数学の数式を書くためのマークアップ言語。私とハクション大魔王には不要。 Sharedaddy・・・共有サービスらしいが詳細不明。個人的には不要。 WP.me Shortlinks・・・URL短縮サービス。個人的には不要。 現時点で「Jetpack by WordPress.com」で提供されるサービスは上記の通りで、全て無料である。 幸い設定画面で、サービス毎に有効化/無効化できるようになっていたので、「WordPress.com Stats」以外の不要なサービスは、無効化した。 「WordPress.com Stats」の画面は、プラグイン「WordPress.com Stats」を使っていた時とは若干違ったものになっている。 作業を完了したところで、不要になったプラグイン「WordPress.com Stats」を管理画面から削除しようとしたところエラーが発生したが、一応、削除は出来たようだ。
EZ zenback バージョン1.3 リリース
「EZ zenback バージョン1.3」を公開した。 最新の「EZ zenback」をダウンロードする バージョン1.3では、「zenback」を表示するウィジェットが追加された。 これによって、コメントの前、または後ろに「zenback」を表示する以外にウィジェット上で表示させるという選択肢が加わった。 例えば、全てのページに表示されるポジションにウィジェットを追加したとしても、ウィジェットは、「EZ zenback」の設定に従い、投稿、固定ページまたは両方で表示され、アーカイブページなどでは表示されない仕様になっている。 また、ウィジェットの表示位置によっては標準のスタイルのままでは見栄えが悪くなるため、設定画面から、スタイルシートを追加できるようにしている。 以上の変更と合わせて、設定画面のデザインを少し変更した。
WordPressのプラグインでデータベースをバックアップ
先日、サーバーの移行を行った。 移行と言っても、単に今まで利用していたサービスが無くなるので別のサービスに強制的に移されたと言った方が正解で、特に私の方でする作業はなく、作業は、レンタルサーバー会社任せだった。 とは言え、念のためデータベースのバックアップを取ることにした。 データベースは、WordPressで利用しているだけなのでWordPressのプラグインを使ってバックアップするのが手っ取り早い。 以前から「WP-DB-Backup」をインストールはしていたのだが、全く使っていない。 つまり、あまり褒められたことではないが、今まで一度もデータベースのバックアップをとったことが無かった。 この機会に、バックアップ用のプラグインを再度比較してみた結果、「WP-DBManager」を使うことにした。 WP-DBManager 「WP-DBManager」は、GamerZ氏が公開するプラグインで、同氏は「WP-PageNavi」、「WP-Polls」、「WP-PostViews」、「WP-PostRatings」、「WP-DownloadManager」、「WP-UserOnline」、「WP-EMail」、「WP-Print」、「WP-Sticky」と言った人気プラグインの作者でもある。 私自身も「WP-DBManager」の他、「WP-PageNavi」、「WP-DownloadManager」、「WP-PluginsUsed」利用している。 このプラグインは、データベースのバックアップ、リストア、バックアップの定期的な実行、最適化、修復などの機能を持っている。 インストール後、バックアップファイルを格納するディレクトリが外部から参照されないように、同梱の「htaccess.txt」を「.htaccess」にリネームしてアップロードする必要がある。 単に手動でバックアップするだけなら使い方は難しくないはずだ。 バックアップするテーブルを選択するオプションなどはなく、単に実行すればWordPressで使用してるテーブル全体をバックアップしてくれる。 幸いにもリストアを試す機会が無かったので、問題なくバックアップファイルからリストア出来るかは不明だが・・・。 沢山の人気プラグインを公開しているGamerZ氏だが、プラグインの作り方に少し癖がある。 それは、仮に翻訳ファイルがあったとしても、それをダウンロードファイルに同梱していない場合が多い点だ。 「WP-DBManager」も例外ではなく、日本語の翻訳ファイルは用意されているが、 http://plugins.trac.wordpress.org/browser/wp-dbmanager/i18n/ から別途ダウンロードし、「WP-DBManager」のルートディレクトリにアップロードする必要がある。 ちなみにファイル名が「-ja.mo」で終わるファイルが日本語の翻訳ファイルである。 翻訳ファイルの所在については、説明をよく読めば書いてあるのだが、見逃しやすいので注意が必要だ。 同氏の場合は、リポジトリの「branches」の下のディレクトリか、ルートに別のディレクトリを作って、保管されていることが多い。 ただし、翻訳ファイルの多くが、最新のバージョンに完璧に対応している訳ではない。
WordPressと無関係なPHPファイル上で、WordPressの関数を実行する方法
WordPressには、便利な関数やフックが用意されているが、当然、これらはWordPressに無関係なphpファイルでは利用できない。 WordPress経由で読み込まれたphpファイルのみが対象となる。 私の作成したプラグインの中には、Javaスクリプトから読み込まれたphpファイル上で、WordPressの関数を実行しているものがある。 しかし、プラグインに含まれるphpファイルと言えども、Javaスクリプト経由である以上、WordPressとは全く無関係なファイルであり、本来は、WordPressの関数は利用不可能である。 実は、強制的にWordPressに関連付ける方法がある。 ただし、本来WordPressの関連のないファイルでWordPressの関数を実行するということは異例なことであり、これを行う際は、セキュリティ上の注意も必要だ。 方法は簡単で「require_once()」で「wp-load.php」を読み込んでやれば良い。「wp-config.php」と「admin.php」を読み込む方法もあるが、「wp-load.php」の方が良いだろう。 以下で解説する方法は、直接「wp-load.php」を読み込むのではなく、まず「wp-load.php」を読み込む処理を書いたファイルを準備し、「require_once()」を使って、それを読み込む方法である。 この方法は「Syntax Highlighter Compress」を参考にした。 複数のファイルで「wp-load.php」を読み込む必要がある場合でも重複した処理を記述する必要がなく、便利である。 まず、次のような記述のファイルを準備する。 <?php $path = ”; // It should be end with a trailing slash if (!defined(‘WP_LOAD_PATH’)) { $classic_root = dirname(dirname(dirname(dirname(__FILE__)))).’/'; if (file_exists($classic_root.’wp-load.php’) ) { define(‘WP_LOAD_PATH’, $classic_root); } else { if (file_exists($path.’wp-load.php’)) { define(‘WP_LOAD_PATH’, $path); } else { exit(__(“Could not find wp-load.php”)); } } } //Load wp-load.php require_once(WP_LOAD_PATH.’wp-load.php’); ?> 続いて、WordPressとは無関係なphpファイルの先頭に以下のように記述して、先ほど作成したファイルを読み込めばよい。 require_once( dirname( dirname(__FILE__) ) .’/my-bootstrap.php’); 場合によっては、セキュリティのために権限やその他条件チェックも行ったほうが良い。 例えば、上記の構文に続いて以下のような構文を追加する。 if ( !is_user_logged_in() || !current_user_can(‘edit_posts’) ) wp_die(__(“You are not allowed to access this file.”)); 上記の例では、このファイルをリクエストしたユーザーが、ログインユーザーでない場合、記事の投稿権限を持たない場合は、処理を中断している。