タグ別アーカイブ: Wordpress

[WordPress]WordCampTokyo2015に行ってきたよ

タグ: | 投稿日: 投稿者:

どうも、ニタです。

先日、WordPressの交流会WordCamp Tokyo 2015に参加してきました。
WordCamp Tokyo 2015

wctokyo_2015-10-31 10 42 47

このところ、WordPress関連のことしか書いていませんが、WordPressが好きすぎるので良いかなと勝手に思ってます。

今年のWordCamp Tokyoのテーマが「More Publishing」ということで、WordPressのテーマやプラグインに関するセッションやワークショップの他に、サイト運営者やブロガーといった、「情報発信」を行う方を対象にしたセッションも多く見られました。

今回は、私が参加したセッションの中で、興味深かったセッションの感想など書いていこうと思います。

【基調講演】「なんとなく」の壁を越えよう!自信を持って WordPress を選択するためのヒント

 

WordPressの運営会社Automattic社に所属の数少ない日本人スタッフ、高野直子さんによる基調講演。

  • Web全体の24.8%のWebサイトがWordPressで作られていること
  • 数あるCMSの中でもWordPressが利用率58.8%と圧倒的なシェアを誇っていること
  • TimeやTHE NEW YORKER、TOYOTA ブラジルといった大規模サイトから男木島図書館のサイトといった小規模サイトもWordPressで作られている

Webサイトを立ち上げるにあたり、ベースシステムにWordPressを選択するいくつかの根拠として、上記のことなどを説明していました。
WordPressが素早いWebサイト構築に向いていて、カスタマイズしやすいからこその、WordPressの利用率なのかもしれません。

また、年内リリースが予定されている次期バージョン、WordPress 4.4の特徴も紹介していました。
私が気になったものは、以下のもの。

WP REST API

REST API経由で外部から記事の取得や、記事の更新などが出来るようになります。
外部サイトやアプリから記事の取得更新が可能になり、情報発信の頻度、速度の向上が見込まれます。

このAPIを使用したアプリやWebサービスの開発をするのも面白いかもしれません。

Responsive Images

HTML5のsrcset属性を利用した、画面やウィンドウサイズなどのユーザーの端末環境に最適な解像度の画像を配信するのが、Responsive Imagesです。

これは、RICG Responsive Imagesというプラグインがコアに統合された形になります。通常通り画像をアップロードすれば、自動的にsrcset属性が追加され適宜画像が指定されるようになるようです。

スマホやタブレット端末、高解像度モニタなどユーザー環境が多様化し、画像サイズ指定に悩まされていた方も多いと思いますが、Responsive Imagesはその解決策の一つだと思います。

embed(記事の埋め込み)

Twitterのツイートや、はてなブログのブログカードのようにWordPressの記事を外部サイトに埋め込む事ができます。
参照リンクや引用文をただのテキストではない見せ方をすることで、記事の見栄えが良くなったり、情報発信の楽しさが増えるのではないでしょうか。

ただし、SSLサイトで非SSLサイトのコンテンツを埋め込むことは出来ないようです。(機能としてNGな訳ではなく、ブラウザ側でブロックされるでしょう)

Content Publishing in 2016

Human Made社のNoel Tockさんによる、情報発信の形の変化や対応策についてのセッション。
Noelさんは、レストランサイトを構築できるWebサービスhappytablesなどを数多くのサイトをプロデュースしています。

記事を公開し自分のWebサイトへユーザーを誘導するのに、従来のSNSや外部サービスの利用だけでは、今後誘導し難くなるとされています。
スマホやタブレット端末の普及に伴い、Webサイトの他にアプリやWebサービスも数多く公開されていますが、それらを利用するユーザーの所有時間は1日24時間と変わりません。
そういった限られた状況において、いかに自分のWebサイトやコンテンツを見てもらう時間をユーザーから取れるのかが重要になってきます。

海外の有名サイトの情報発信方法を参考に、ユーザーの環境に寄り添った、自分のコンテンツに適した情報発信方法をいくつか紹介していました。

WordPressで行う継続的インテグレーション 入門編  -プラグイン開発・保守地獄から学んだこと-

Custom Post Type Permalinksなど有名プラグインを多く開発しているToro_Unitこと占部さんのセッション。

 

ざっくり要約すると、「PHP Unit使ってテスト駆動開発しないと地獄見るぜ」。
WordPressには「WP_UnitCase Class」というPHP Unitを継承したテスト用クラスも用意されているから、プラグイン開発するなら使ってみれば良いじゃない。ということでした。

WordPressをCUIでコントロールできる「WP_CLI」にある、プラグイン作成コマンドにも標準でテストコードやTravis CI用のymlファイルが生成されるので、テストコードを書いて損はないと思います。

ホント、テストは大事ですよ…

※「WP_CLI」はVagrantで構築できるWordPress開発環境の「VCCW」にも入っているので、WordPressサイトやプラグイン開発は、VCCWを使うのをマジお薦めします。

The Best Practices of Making WordPress Site Multilingual

多言語サイトをWordPressで構築する際のいくつかの方法について。

 

スライドにあるような、WordPressのマルチサイト機能や多言語対応プラグインなどの紹介がありました。
なかでも「YarakuZen」という翻訳サービス(商用有料)が気になりました。
すでにプラグイン化されているので、今度試してみたいと思います。

Webサイトをめぐるセキュリティ状況と効果的な防御方法~WordPressを題材として~

セキュリティと言ったらこの方、徳丸さんのセッションはWordCampでも人気のセッションだったと思います。
WordPressがカスタマイズしやすいCMSだからこそセキュリティにはコストを掛けるべきではないでしょうか。
自分でカスタマイズしたことで、セキュリティホールを自ら開けてしまうケースもあれば、セキュリティを考慮せず作られたプラグインを使っている場合もあります。
WordPressではセキュリティを高めるプラグインも多く公開されているので、それらを使ったセキュリティ対策も一つの手かと思います。

ライターと制作者のメディアの作り方

セッションタイトル通りですが、ライター、制作者の立場から、WordPressサイトでのサイト設計、コンテンツ設計についてディスカッションが行われました。
登壇されたのは、LIGブログの元編集長、コンテンツ制作会社ノオトでライターをしている朽木 誠一郎さんと、フリーランスWebデザイナーのおおはらかずきさん。

おおはらかずきさんが運営しているブログサイトは、225記事で月間100万PVを稼いでいる人気サイトです。

私は最近、当社コーポレートサイトにてFAIRWAY NEWSを運営しているので、記事を制作する上でのコツを多く聞けて有意義なセッションでした。

まとめ

wctokyo_2015-10-31 22 34 48

WordPressは他のCMSと比較してもカスタマイズしやすいCMSだと思います。
それ故に開発者だけでなく、デザイナーやブロガーなどのコンテンツ制作者など多くの人に利用されているCMSだと今回のWordCampに参加し改めて感じました。
様々な使い方が出来、テーマやプラグインが利用できる反面、セキュリティを万全にしなければならないし、情報発信方法、ユーザーに知ってもらう手段なども時代に合わせて変えていかなければいけません。

基本的なことですが、サイト構築、コンテンツ制作の上で大事にしなければならないことだと思いました。
それではまた。

追伸

先月拙作のWordPressプラグインをアップデートしました。
新機能として「ロールバック機能」を追加しています。
これは一度予約更新で更新した投稿内容を、日時指定で更新前の状態に戻すことができます。
予約更新する投稿内容を期間限定で表示させる場合などに使えると思います。


[WordPress]需要度低めだけど意外と助かるカスタマイズ3選

タグ: , | 投稿日: 投稿者:

こんにちは、ニタです。
WordPressを利用したWebサイトを開発する際、既存テーマファイルをカスタマイズしたり、プラグインをインストールしていきます。
それでも対応できないものは、使用するテーマファイル内のfunctions.phpにコードを記述するなどして対応していきます。
今回は、その中でも需要度低めな?カスタマイズ方法をいくつかご紹介します。

generatorのmetaタグを削除

WordPressでは、headタグ内にgeneratorのmetaタグが挿入されます。
これはページ作成ツールの情報なのですが、あまり必要性がないのと、セキュリティ面を考慮しても削除したほうが良いです。
※バージョンを外部に晒すことになるので、WordPressをアップデートしていない場合、攻撃対象になるため。

利用中のテーマファイルにある、functions.phpに以下を追記すると、generatorのmetaタグが作成されません。

if(has_action('wp_head','wp_generator')) {
    remove_action( 'wp_head', 'wp_generator' );
}

これだけでもページのソース上からは削除されますが、同時に生成されるRSSフィードなどにも生成ツール情報が書き込まれるので、そちらも削除します。

$actions = array( 'rss2_head', 'commentsrss2_head', 'rss_head', 'rdf_header',
'atom_head', 'comments_atom_head', 'opml_head', 'app_head' );
    
foreach ( $actions as $action ) {
    if ( has_action( $action, 'the_generator' ) ) {
        remove_action( $action, 'the_generator' );
    }
}

WordPressからのメール送信でSMTPを利用する

WordPressには、wp_mailというphpmailerを使用したメール送信関数がデフォルトで備わっています。

関数リファレンス/wp mail – WordPress Codex 日本語版

サイトポリシー上、SMTPを利用してメール送信する場合は、phpmailerの設定処理をカスタマイズして対応します。
こちらも、functions.phpに記述します。
send_smtp_emailという関数名は適宜変更しても構いません。

add_action('phpmailer_init','send_smtp_email');
function send_smtp_email( $phpmailer )
{
    // SMTP有効設定
    $phpmailer->isSMTP();

    // メールサーバーのホスト名
    $phpmailer->Host = "使用するSMTPサーバ名";

    // SMTP認証の有無(true か false)
    $phpmailer->SMTPAuth = true;

    // SMTPポート番号(25,465,587など適宜) 
    $phpmailer->Port = "587";

    // SMTP認証時のユーザー名
    $phpmailer->Username = "ユーザー名";

    // ユーザーのパスワード
    $phpmailer->Password = "パスワード";

    // SMTP暗号化方式(tls か ssl)
    $phpmailer->SMTPSecure = "tls";

    // 送信者メールアドレス
    $phpmailer->From = "test@example.com";
    
    // 送信者名
    $phpmailer->FromName = "送信者名";
}

テーマ内でセッションを使う

基本的にWordPressのフロント側では、PHPのセッションは使用していません。
ページによってはセッションを利用したページ処理があると思います。
セッションを使う場合はこんな感じでfunctions.phpに記述します。
common_session_startという関数名は適宜変更しても構いません。

add_action('init', 'common_session_start');
function common_session_start(){
    if(!isset($_SESSION)){
        session_start();
    }
}

いかがでしたでしょうか。
ちょっとニッチなカスタマイズでしたが、ご利用いただければと思います。
それでは。


[WordPress]A/Bテスト用プラグイン「MaxA/B」

タグ: | 投稿日: 投稿者:

最近「痩せた?」と聞かれるようになりました。
糖質制限ダイエットはすごいですね。決して仕事が原因じゃないです。こんにちは、ニタです。

Webサイトのデザイン、レイアウト、文言、機能などを最適化するために、A/Bテストで効果を測る場合があります。
A/Bテストとはざっくり言いますと、用意された複数のバージョンのページ(バージョンA、B)にアクセスしたユーザをランダムに振り分けて、ユーザの反応(目標となる成果が得られるか)を計測するテストのことです。

今回は、WordPressで構築したWebサイトでのA/Bテストの設定、実施方法を解説します。
※ここでは、テスト対象ページ「バージョンA」と、別バージョン「バージョンB」を比較調査するテストの設定を説明します。

「MaxA/B」を使ったテスト設定

WordPressでのA/Bテストは「MaxA/B」というプラグインを使用します。
MaxA/B
「MaxA/B」を使うと、指定された固定ページでのA/Bテストが可能になります。

また、既存の投稿・固定ページを複製するプラグイン「Duplicate Post」を使用することで、効率よくテストページ作成ができるので、こちらもインストールします。
Duplicate Post

各プラグインインストール方法

各プラグインは以下の手順でインストールします。

  • WordPress管理画面「プラグイン」 > 「新規追加」に移動
  • 「Duplicate Post」の場合、検索のテキストフォームで「duplicate post」を検索
  • 「MaxA/B」の場合、検索のテキストフォームで「maxab」を検索
  • 各プラグインが表示されるので、「今すぐインストール」ボタンからインストール開始
  • インストールが成功したら、プラグインを有効化する

テスト対象の固定ページを複製、編集

テスト対象ページ「バージョンA」を複製し、別バージョン「バージョンB」のページを作成します。
「Duplicate Post」をインストール、有効化すると、固定ページ一覧のテスト対象ページに「複製」というメニューが増えるので、そちらからページを複製します。

img_maxab_004

複製が完了すると、「下書き」状態で複製されます。
複製先を「バージョンB」としてタイトル、スラッグ、記事内容を適宜編集し、ページを公開します。

A/Bテストのテスト設定

つづいて、MaxA/Bでテスト設定を登録します。MaxA/Bの設定画面に移動し「Add New」ボタンから、テストを追加します。
img_maxab_005

img_maxab_001

新規テスト設定画面が表示されるので、各項目を選択、設定し「Create」ボタンでテストを作成します。
各項目の内容は以下のとおりです。

項目名 設定内容
Name テスト名称
Original page テスト対象のオリジナルページ。公開中の固定ページから選択する。
ページ選択すると、ページURLが表示される。
Variation page 1 テスト対象ページの別バージョンのページ。固定ページから選択。
Variation page 2 別バージョンページ2番目。バージョンが複数ある場合、選択する。
Variation page 3 別バージョンページの3番目。
The conversion page 目標ページ。テスト対象ページから遷移し最終的に成果が得られるページ。
問い合わせページの問い合わせ完了ページなど。
"Is on another site somewhere else (enter URL)"を選択すると外部URLを入力指定できる。外部URLを選択すると、登録後外部URLのページに追記するスクリプトが表示される。
Experiment ends when テスト終了のタイミング。
・It is manually stopped:手動停止
・Total traffic reaches:合計アクセス数(指定)
・Each page reaches at least:ページ毎のアクセス数(指定)

今回はテスト対象ページと別バージョン1ページ、目標ページを設定し、手動停止でテスト登録します。
登録後、テストが開始されます。

スクリプトの設置

目標ページを外部URLに設定した場合、テスト登録後、目標ページに追記するJavaScriptが表示されます。

img_maxab_002

目標ページ(外部URL)のheadの閉じタグの直前に追記するコードが表示されます。

テストの状況確認

テスト登録後、テストは即時開始されるので、実際にテスト対象ページにアクセスしてみます。
テスト対象ページと別バージョンページへの振り分けはセッションに登録されるので、セッション登録されないChromeのシークレットウィンドウやFirefoxのプライベートウィンドウでアクセスすると分かりやすいです。

ページの振り分けの確認をし、目標ページまで遷移したら、MaxA/Bの設定画面を確認します。

img_maxab_003

各バージョンへのアクセス率、目標ページへの到達率が表示され、どのバージョンのページが効果的かが分かるようになっています。
また、実施中のテストを中止したり終了のタイミングを変更するには、詳細画面から編集ができます。

img_maxab_006

今回紹介したプラグインでのA/Bテストの他に、GoogleAnalyticsにある「ウェブテスト」というA/Bテスト計測も同時に行うことで、より詳細なテスト結果が得られます。
GoogleAnalyticsの設定方法などは、後日改めて説明したいと思います。
それでは、良いテストライフを。


WordPressでajaxを使う

タグ: , , | 投稿日: 投稿者:

こんにちは、ニタです。

早速ですが、WordPressのプラグインを更新しました!

アイキャッチ画像と更新日を予約更新対象に追加しました!
iframeタグが消えたり、brタグなどに追記したstyle定義も消えないようにしました!
予約更新内容でのプレビュー機能はもう少し先になりそうです!

どうぞよろしくお願いします!
See you again next time, Enjoy WordPress Life!!

と、

これでおしまいとは、いきませんよねぇ…。
では、改めて。

WordPressでもajaxをカンタンに使いたい

WordPressのテーマやプラグインを開発していると、投稿データや外部からのデータをスムーズに取得したい時があります。なるべくスマートに。ajaxとかで。
例えば、投稿一覧ページをページングからajax読み込みによる無限スクロールにしてみたり、プラグインで下のような読み込み機能に使ってみたり…

多少コツが要ります

しかし、WordPressのフロント側のルーティングはすべてコンテンツページとして表示されるので、ajax用のJSONを返すページ(エンドポイント)を作り、そこへPOSTかGETでアクセスさせればajax通信できるわけではありません。
ですが、WordPressの管理画面はajaxをバッキバキにキメていて、そのための機能が用意されておりますので、そちらを使ってajax通信を行います。

基本的な実装の流れはこんな感じです。

  1. wp_ajax_ホニャララというアクションフックを追加し、そのアクションフックに関数を登録。
  2. POSTかGETでのリクエストを受け取って、求めているデータをJSON形式で返却する関数(アクションフックに登録する関数)を作成。
  3. データ取得用のJavaScriptの作成。

実際に作ってみよう

では、先ほどの流れを基に何かしら作ってみます。
前述の図にあった、URLからサイト情報を取得するajaxを実装してみます。
また、ここで使うプラグイン接頭辞はwpmra_とします。

1. アクションフックの追加

ここで追加するアクションフックは、後述するエンドポイントにフックさせることでアクションフックに登録した関数を呼び出すようになっています。
そのため、アクションフックの名前はwp_ajaxと自分で決めたアクション名を繋げたものになります。
wp_ajax_ホニャララホニャララの部分を決めて追加します。
プラグイン接頭辞を含め、以下の様なアクション名と関数名にしました。

add_action('wp_ajax_wpmra_fetch_site_info', 'wpmra_fetch_site_info');

また、フロント側で使いたい場合、WordPressへ未ログインのユーザー向けにwp_ajax_nopriv_ホニャララというフックが用意されているので、そちらを使用します。
ですが、こちらは未ログインユーザー向けのみのものらしく、これだけをアクションフックに追加すると今度はログインユーザーには有効にならないという謎仕様になっております。
ですので、同じ関数を呼び出すアクションフックを2つ追加します。

add_action('wp_ajax_wpmra_fetch_site_info', 'wpmra_fetch_site_info');
add_action('wp_ajax_nopriv_wpmra_fetch_site_info', 'wpmra_fetch_site_info');

2. 登録した関数の作成(JSON返却用)

1.で追加したアクションフックで呼び出している関数wpmra_fetch_site_infoを作成します。

function wpmra_fetch_site_info() {
    $res = array(
        'status' => 'NG',
    );
    if(isset($_POST['post_title'])) {
    // POSTで送信されたURLからRSS情報を取得する
        $rss = get_wpmra_fetch_feed($_POST['post_title']);
        // サイトタイトル、URLを配列へ
        if($rss) {
            $res['status'] = 'OK';
            $res['data'] = array(
                'title' => $rss->get_title(),
                'url' => $rss->get_permalink(),
            );
        }
    }
    // 配列をJSON形式で出力
    header('Content-Type: application/json; charset=utf-8');
    echo json_encode($res);
    exit();
}

// $urlからRSSのFeedデータを取得
function get_wpmra_fetch_feed($url){
    include_once ABSPATH . WPINC . "/feed.php";
    
    $rss = fetch_feed($url);
    if(!is_wp_error($rss)){
        return $rss;
    }
}

簡単に解説しますと、WordPressのwp-includes/feed.phpを使用してRSSのURLからFeed情報を取得し、その中からサイトタイトルとサイトURLをJSON形式で出力しています。
出力後は必ずexit()die()を使って終了させます。

アクションと関数は出来ましたが、JavaScriptでJSONデータを取得するためのURLを知らないといけません。
wp_ajax_のエンドポイントは、サイトURL/wp-admin/admin-ajax.phpになります。
フックに追加した関数を呼び出すには、リクエスト内のactionパラメータにwp_ajax_より後ろに記載した文字列を指定する必要があります。(今回の場合はwpmra_fetch_site_info

3. データ取得するJavaScriptの作成

custom.jsというファイルを作成し、読み込みます。

add_action('admin_enqueue_scripts', 'enqueue_wpmra_script');
function enqueue_wpmra_script(){
    wp_enqueue_script('wpmra_js', '/path/to/custom.js', array('jquery'), '0.1');
}

このjsファイルにデータ取得する処理を書いていきますが、ここで一つ問題が。
先ほどwp_ajax_のエンドポイントはサイトURL/wp-admin/admin-ajax.phpだと説明しましたが、サイトURLは開発環境、テスト環境、本番環境で変わっていきます。
また、この処理をプラグインに実装するとなると、余計に変わります。
JavaScriptにサイトURLの判定処理を書くのも何なので、wp_localize_scriptという関数でPHPからjsに渡すようにします。

PHPファイルにscriptタグで直接書けば良いのでは?という意見もあると思いますが、横着せずPHPはphpファイルに、JavaScriptはjsファイルで管理するよう心がけましょう。

add_action('admin_enqueue_scripts', 'enqueue_wpmra_script');
function enqueue_wpmra_script(){
    wp_enqueue_script('wpmra_js', '/path/to/custom.js', array('jquery'), '0.1');
    wp_localize_script('wpmra_js', 'WPMRAJS', array('endpint' => admin_url('admin-ajax.php')));
}

wp_localize_scriptの第2引数の文字列がcustom.jsでのグローバルオブジェクトになります。
第3引数に渡している配列でWPMRAJSというグローバルオブジェクトに値がアサインされます。

これでJavaScriptを書ける準備が整いましたので、書いていきます。

jQuery(function(){
    // URL情報を取得するボタンを押したらサイト情報を設置する
    jQuery("#wpmra_fetch_site_info").on('click', function(){
            // 記事タイトルに入力されたRSS Feed
        var post_title = jQuery('input[name="post_title"]').val();
        jQuery.ajax({
            url : WPMRAJS.endpoint,
            type : "POST",
            // actionパラメータに、実行したいアクションの「wp_ajax_」より後ろの文字列を指定
            data : {action : 'wpmra_fetch_site_info', post_title : post_title },
            success : function(res){
                if(res.status === 'OK') {
                    jQuery('input[name="mra_rss_title"]').val(res.data.title);
                    jQuery('input[name="mra_rss_feed_url"]').val(res.data.url);
                }
                if(res.status === 'NG') {
                    alert("取得に失敗しました。");
                }
                return false;
            }
        });
    });
});

WordPressでのサイト制作にはVCCWがおすすめ

タグ: , | 投稿日: 投稿者:

新年あけましておめでとうございます。ニタです。

年末年始、いかがお過ごしでしたか?

私はWordPressのプラグインの改修を進めたかったのですが、何かと慌ただしく過ぎてしまいました。
機能追加を計画していますので、もうしばらくお待ちください。

さて、そんなWordPressでのサイト(テーマ)、プラグイン開発で非常に便利なのが今回ご紹介する「VCCW」です。

VCCWって何?

VCCWは、VagrantとChefによるWordPress開発環境ツールです。

ローカル開発環境にインストールするのは、VirtualHostの設定、MySQLのDB登録などの作業だけで、すぐ済むのですが、そういった作業が苦手なデザイナーやHTMLのコーダー、いちいち設定するのが面倒と感じる方もいると思います。

VCCWでは、WordPress単体だけでなく、テーマ・プラグイン制作に役立つツール類もインストールされます。

Vagrantとchefにより、centos上にApache、PHP、MySQL、WordPressなどがインストールされます。

opensslもインストールされるので、フォームなどのSSL環境が必要な状況にも対応しています。

初回起動時にインストールされるツール、プラグイン

  • openssl
  • Grunt
  • Composer
  • rbenv
  • bundler
  • node.js
  • grunt-cli
  • WordPress Unit Tests(PHPUnit)
  • WordPress i18n Tools
  • WP-CLI
  • theme-check (WordPress plugin)
  • dynamic-hostname (WordPress plugin)
  • plugin-check (WordPress plugin)
  • wp-multibyte-patch (WordPress plugin)

利用には、VagrantとVirtualBoxが利用できることが前提となるので、予めインストールしておいてください。

また、Vagrantのプラグインvagrant-hostsupdaterが必要となります。

Vagrantインストール後、以下にてプラグインをインストールしてください。

※今回はmacでのインストール方法のみになります。予めご了承ください。

vagrant plugin install vagrant-hostsupdater

インストール、設定

パッケージのダウンロード

VCCWのサイトにあるzipかtar.gzをダウンロードし、適当なディレクトリに解凍します。

この記事の執筆時のVCCWのバージョンは1.9.6です。

解答すると、「vccw-1.9.6」というディレクトリが作成されます。

Vagrantfileの編集

解凍してできた「vccw-1.9.6」というディレクトリ内にあるVagrantfileがあるので、ターミナルなどでvccwディレクトリに移動し、vagrant upコマンドで開発環境は立ち上がります。
その前に日本向けにVagrantfileを編集します。

  • 15行目、WordPress内のlocaleをjaに。
WP_LANG = ENV["wp_lang"] || "ja" # WordPress locale (e.g. ja) 
  • 70行目、cent os側のWordPressのディレクトリをローカルマシンのディレクトリとsyncさせる。
config.vm.synced_folder "www/wordpress/", "/var/www/wordpress", :create => "true"

上記の"www/wordpress/"をローカルマシンでWordPressを格納するディレクトリパスに書き換える。

パスが、/Users/nita/workspace/wp-developの場合、

config.vm.synced_folder "/Users/nita/workspace/wp-develop", "/var/www/wordpress", :create => "true"
  • 113行目、 cent osにインストールされるPHPのタイムゾーンを変更。
"date.timezone" => "Asia/Tokyo",

起動 確認

Vagrantfileの編集が終わったら、ターミナルなどでVagrantfileがあるディレクトリに移動し、vagrant upコマンドで起動します。

初回起動時は、centosのboxファイルのダウンロードや、apache、PHP、MySQL、WordPressのインストールや設定が行われるので、多少時間がかかります。

また、途中でhostsファイルにVagrantで利用するホストとURLを書き込むため、ローカルマシンのユーザーパスワードを求められます。

無事、起動が成功しますと、以下のURLにてWordPressサイトが表示されます。

http://wordpress.local

また、管理画面は以下のID/パスワードでログインできます。

http://wordpress.local/wp-admin

ID パスワード
admin admin

といった感じです。

WordPressを利用したサイト制作では、WordPressの設定やデータベースの設定など何かと準備が細々とあります。

VCCWを使えば、そんな準備に時間をかけることなく開発作業に臨めると思います。

VCCWには今回紹介した他にも、WordPressでの様々な操作をコマンドラインで実行できる「WP-CLI」やtheme-check、plugin-checkなど便利なツールが使えます。

おまけ

VCCWがデフォルトでインストールしているプラグインやWP-CLIについて説明します。

theme-check

ダウンロードしたテーマや、制作したテーマが、WordPressが設けている品質ガイドラインに準拠しているか、セキュリティホールが開いていないかどうかチェックしてくれます。

plugin-check

制作したプラグイン、インストールしたプラグインが、WordPressの品質ガイドラインに準拠しているかどうか、セキュリティホールが開いていないかどうかをチェックしてくれます。

互換性に問題のある関数が使われていないか、システムコマンドが実行されていないか、プラグイン内でini_set()が使われていないかなど、細々とチェックしてくれます。

WP-CLI

WP-CLIで出来ることをちょっとだけ。

まずは、VCCWの仮想環境にSSH接続しWordPressのディレクトリに移動ます。

vagrant up
vagrant ssh
cd /var/www/wordpress

WordPressのDBのエクスポート

例:mysqldump_wordpress.sqlにエクスポート

wp db export mysqldump_wordpress.sql

WordPressプラグインのアップデート

例:プラグインakismetをアップデート

wp plugin update akismet

また、rbenv、node.js、Grunt、bundlerなどはjQueryのプラグインのインストールやSassのインストールなど、テーマ制作時に利用すれば、色々捗ると思います。

その辺については、また改めて紹介したいと思います。


WordPressプラグインの申請公開方法

タグ: , | 投稿日: 投稿者:

こんにちは、ニタです。

またしてもWordPressネタですが、プラグインを作ったのなら公開してみるのも良いと思います。WordPressをお使いの方々に多少貢献出来るかもしれません。
そこで、今回はWordPressプラグインの申請、公開方法をまとめした。

事前準備・用意するもの

wordpress.orgのアカウント

アカウント登録はこちらからできます。最低でもusernameとemailが入力していれば登録できます。
登録すると、入力したメールアドレスにwordpress.orgからusernameとpasswordが記載されたメールが送られてきます。
こちらでログインすると、プラグインとテーマの申請、WordPressのフォーラムへの参加ができるようになります。

プラグインファイル一式

当然ですが、動作テストし問題ない状態でリリースしましょう。
※今回は割愛しますが、管理画面などに項目を追加するようなプラグインの場合、表示項目の国際化処理をするのをおすすめします。

readme.txtを書く

プラグインには、readme.txtを追加する必要があります。
このtxtファイルを基に、WordPressプラグインページが作成されます。
表記内容は、WordPressのreadmeファイルの標準に沿ったものになり、MarkDown記法で記載していきます。
readme.txtは、プラグインディレクトリの直下に置きます。
表記例はこんな感じ。

=== Rucy ===
Contributors: gips-nita
Tags: post, update content, update post, update page, schedule update, reserve update, reservation update, rucy, Rucy
Requires at least: 3.5+
Tested up to: 3.9
Stable tag: 0.2.0
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html

Add reservation update published content.

== Description ==

You can automatically update the DateTime specified posts published by this plugin.

Post and Page, specify custom post type is also possible.

But in your WordPress, this plugin is a prerequisite is that the reservation can be posted (can use WP_CRON is required).

== Installation ==

You can install this plugin directly from your WordPress dashboard:

 1. Go to the *Plugins* menu and click *Add New*.
 2. Search for *rucy*.
 3. Click *Install Now* next to the *rucy* plugin.
 4. Activate the plugin.
 5. Configure reservation post type in *rucy* in *Setting* menu.

== Screenshots ==

1. Added Reservation Content Editor in Editor.
2. Reservation Content Type Setting Page.

== Frequently Asked Questions ==

== Changelog ==

= 0.2.0 =
* 2014-06-13
* fixed Bugs.
* change input type reservation datetime.
* add check validation reservation datetime is past.

= 0.1.2 =
* 2014-05-04
* add reservation datetime post updated messages.
* add "revision" and "attachment" in invalid custom post type Setting
* refactoring

= 0.1.1 =
* 2014-04-25
* if accept checkbox unchecked , clean schedule update content.
* modified revision post_type do not add schedule update.
* add donation link.

= 0.1.0 =
* 2014-04-18 First release

表記する項目は、以下のとおり。MarkDown記法で記載していきます。
=== [プラグイン名] ===

Contributors: [WordPress.orgで登録したusername]
Tags: [プラグインを検索した時にヒットされやすいタグをカンマ区切りで記載]
Requires at least: [このプラグインが動作保証出来るWordPressの最低バージョン]
Tested up to: [プラグインの動作テストで使用したWordPressのバージョン]
Stable tag: [動作保証出来るプラグインのバージョン]
License: GPLv2 or later (ライセンス)
License URI: http://www.gnu.org/licenses/gpl-2.0.html (ライセンスのURL)

== Description == 詳細説明
== Installation == インストール方法
== Screenshots == スクリーンショットの説明。
1.一番目のスクリーンショットの画像の説明。
スクリーンショット画像は、上記の番号に対応するスクリーンショット画像を用意します。
ファイル名は、screenshot-[番号].[拡張子]
拡張子は、png/jpg/jpeg/gifのいずれかです。
画像ファイルは、readme.txtと同じ階層に配置しておきます。
== Frequently Asked Questions == よくある質問。初回は項目があるだけでも構いませんが、想定される質問を記述するのもいいでしょう。
== Changelog == 更新履歴。更新する度に追記していきます。

wp-plugin_dir

説明用コメントアウトの更新

プラグインのphpファイルに、コメントアウトでプラグインの説明を記述していると思います。
以前、最低でもPlugin NameだけでOKと説明しましたが、こちらも更新しておきましょう。

/*
Plugin Name: (プラグインの名前)
Plugin URI: (プラグインの説明と更新を示すページの URI)
Description: (プラグインの短い説明)
Version: (プラグインのバージョン番号。例: 1.0)
Author: (プラグイン作者の名前)
Author URI: (プラグイン作者の URI)
License: (ライセンス名の「スラッグ」 例: GPL2)
*/

申請作業

wordpress.orgにアップロード

さて、色々準備をしてきましたが、ようやく申請です。
プラグインファイルとreadme.txt、スクリーンショット画像をまとめたzipファイルを作成し、外部からアクセス可能なサーバにアップロードしておきます。

そして、WordPressのプラグイン申請ページで、各入力内容を記入し申請します。

WordPress_›_Requests_«_WordPress_Plugins

これで申請完了です。
審査が通過し承認されると、WordPress.orgからその旨のメールが届きます。

申請ページにもありますが、現在申請している数と審査中の数が出ていますので、タイミングによっては結構待たされる場合もあるようです。
僕が以前申請した際は、2、3日程度でした。
もし、審査に引っかかた場合、その理由などが書かれたメールが届くそうなので、そちらを基に修正するなり、WordPress.orgとやり取りし、再申請となります。

審査が通ったら

審査を無事通過し公開可能となりますと、そのプラグイン用のsvnのリポジトリが与えられます。
前述の、承認されたという連絡のメールにリポジトリのURLが記載されているので、ローカル環境にリポジトリをチェックアウトし、プラグインファイルなどを追加し、コミットします。

// 作業ディレクトリを作成
mkdir ~/workspace/wordpress-plugin/
// チェックアウト
svn co [wordpress.orgから届いたリポジトリURL] ~/workspace/wordpress-plugin/

// プラグインなどファイルコピー
cp file/to/path/my-plugin.php ~/workspace/wordpress-plugin/trunk/my-plugin.php
cp file/to/path/readme.txt ~/workspace/wordpress-plugin/trunk/readme.txt

// svnに追加
svn add trunk/*

// コミット
svn ci -m 'コミットメッセージ'

参照:http://wordpress.org/plugins/about/svn/

コミットが完了すると、15分程度でWordPress.orgに反映され、めでたく公開となります。
以後、プラグインの更新は、このsvnからコミットし更新して反映していきます。

また、コミットする際、svnのtrunkやtagsと同階層にassetsディレクトリを作成し画像を追加すると、WordPress.orgのプラグインページのアイキャッチ的な部分に画像が反映されます。

画像ファイルの仕様は以下になります。
ファイル名:banner-772×250.png
幅:772px
高さ:250pxになります。
画像の種類は、jpg,pngのどちらかです。

また高解像度ディスプレイ向けに、以下の仕様の画像を用意すると、サイト側で動的に切り替えてくれます。
ファイル名:banner-1544×500.png
幅:1544px
高さ:500px

WordPress_›_Rucy_«_WordPress_Plugins


WordPressデータのXMLインポート

タグ: , , | 投稿日: 投稿者:

こんにちは、モリです。

暑がりなので夏が近くなるにつれて、嫌になってきます。。。。

早く夏過ぎないかなぁ~~~(笑

WordPressのインポート機能を使用した際の備忘録です。

ちなみにXMLでインポートで移行しても設定変更しないといけない設定があるんですね~

  • 一般設定
  • 投稿設定
  • 表示設定
  • ディスカッション
  • メディア
  • パーマリンク設定
  • プラグインの新規インストール&設定

ブログ1

サーバ移転等の場合、テーマ情報などはFTPでそのままテーマ配下に配置しないといけません。

    • テーマ

/wp-content/themes/テーマ名/

    • 画像

/wp-content/uploads/

でわ!


WordPressプラグイン開発のポイント

タグ: , , | 投稿日: 投稿者:

こんにちは。ニタです。

前回、WordPressプラグインのリリース報告後、まともに開発する時間が取れなくて、プラグインの更新が出来ずにおります。
今回は、WordPressプラグインを開発する際の要点、ポイントをまとめてみます。

ディレクトリ、ファイル構成

プラグインは、WordPressのwp-content/plugins/内に格納されます。
プラグインファイルのみを格納するだけでも、WordPressは認識しますが、管理面も考慮して個別のディレクトリに格納しておくのが良いでしょう。
ディレクトリ名は、管理面も考慮して、プラグイン名と同じにするのが一般的です。
他のプラグインと重複しないよう予め調査するか、プレフィックスなどで唯一性を持たせるのもひとつの手です。
もし、開発したプラグインを、一般公開する場合、プラグイン名は特に考慮しておくべきでしょう。

rc_directory

また、プラグインのメインとなるファイル名(そのプラグインのメインとなる処理などが書かれたPHPファイル)は、プラグイン名にするのがWordPress界隈の慣例のようです。
ですが、ファイルの先頭に、プラグインの説明文をコメントアウトで記述していると、WordPressが勝手にメインとなるファイルとして判断するようです。

コメントアウトでプラグインの説明を記述

前述した、プラグインの説明文についてです。WordPressのプラグイン、テーマファイルは、コメントアウトでプラグインやテーマファイルの名称、バージョン、作者名、ライセンスなどを記述する必要があります。

/*
Plugin Name: (プラグインの名前)
Plugin URI: (プラグインの説明と更新を示すページの URI)
Description: (プラグインの短い説明)
Version: (プラグインのバージョン番号。例: 1.0)
Author: (プラグイン作者の名前)
Author URI: (プラグイン作者の URI)
License: (ライセンス名の「スラッグ」 例: GPL2)
*/

特に、プラグインに関しては、このような説明がないと、いくらpluginsディレクトリに格納しても、管理画面のプラグインページで表示されず、プラグインの有効化ができません。
最低でも、プラグイン名「Plugin Name」の項目だけは記述する必要があります。

フックについて。アクションとフィルタ

プラグインを開発すると言いましても、ざっくり言いますと「WordPressのコアファイル群で走っている処理の間に、自作の処理を挟ませて、処理結果を変える。その処理を作る」のが、WordPressプラグインの主な仕事です。
その自作の処理を挟ませることを、WordPressではフック(hook)と呼びます。

フックは、アクションとフィルタに分けられます。

アクションは、投稿を追加した時、テーマを切り替えた時などに走ります。

add_action('publish_post','hoge');

上記の場合、publish_postというアクションをフックに、hogeというfunctionを実行させています。
publish_postアクションは、投稿が公開された時のアクションですので、投稿が公開されたタイミングで、管理者にメールを送信する、ということも可能です。

フィルタは、WordPressのデータベースからデータをブラウザへ表示させる際、ブラウザからのデータをデータベースへ追加するタイミングなどに通る関数を指します。
僕が開発したプラグイン「Rucy」では、以下の様な使い方をしています。

add_filter('post_updated_messages','addRcMessage');

コアファイル群がpost_updated_messagesという、投稿内容を追加・更新した際に編集画面にメッセージを表示する関数に、addRcMessageという自作の関数を通しています。
addRcMessageでは、予約更新日時に関するメッセージを追加させています。
その結果、編集画面では、以下の様なメッセージが表示されるようになります。

rc_addmessage

アクションとフィルタの一覧はWordPress公式のWikiに掲載されていますので、参考にしてみてください。

アクションフック一覧
フィルターフック一覧

プラグインのインストール、アンインストール時のフック

プラグインを、管理画面で有効にした際、プラグイン独自の設定項目などをデータベースに登録したい場合があると思います。
その場合、以下のコードによってプラグインを有効にした際に、関数fugaが実行されます。

// fugaという独自関数を有効化時にフックさせる。
register_activation_hook( __FILE__, 'fuga' );

同様に、アンインストール、無効にした場合に実行させたい処理は以下のようにフックします。

// goodbyeRucyという独自関数をアンインストール時にフックさせる。
register_uninstall_hook(__FILE__, 'goodbyeRucy');

「Rucy」によってデータベースに追加された、予約更新内容や、設定内容を削除しています。
飛ぶ鳥跡を濁さずと言いますか、データベースなどに残したデータによって、アンインストール後のシステムに影響を与えないようにしています。

ざっと書きましたので、まとめますと、

  • プラグインはディレクトリ名、ファイル名は合わせる。
  • プラグイン名は唯一性を持たせる。
  • ファイルの先頭に、プラグインの説明文をコメントアウトで記述する。
  • プラグイン開発の基本はアクションとフィルターのフックを活用する。

こんな感じでしょうか。

このエントリーが、皆様のプラグイン開発の一助になれれば幸いです。
Enjoy, WordPressLife!


[WordPress]公開済みの記事を時限更新するプラグインを公開しました

タグ: , | 投稿日: 投稿者:

こんにちは、ニタです。
CMS、ブログのプラットフォームとしてWordPressは取っ付き易く、WordPressで管理している企業サイトも多いと思います。
「WordPress カスタマイズ」などで検索すると、結構な数の紹介記事などがヒットしますし。

そんなWordPressで、新規作成した投稿には日時指定での公開設定が可能ですが、公開済みの投稿への日時指定更新は、標準機能として備わっていません。
商品ページの価格や、キャンペーンページの時間指定更新がある場合、時間に合わせて更新する必要があります。
これが深夜0時更新だったり、複数ページの更新だとしたら…。ちょっと面倒ですよね。

そんな公開済みの投稿に対して、自動更新してくれるWordPressのプラグインが、既にあるのかと思ったのですが、なかなか見つからなかったので、自分で作ってみました。
WordPressの公式サイトからダウンロード、インストールできます。

img_plugin_rucy
WordPress › Rucy « WordPress Plugins

概要

「Rucy」というプラグインです。当初は「Reservation Update Content」という名前だったのですが、安直だし長いなと思い、頭文字から「Rucy」としました。
「るーしー」と読みます。

管理画面の投稿、固定ページ編集画面で予約更新分の記事内容、更新日時を登録できるようになります。
予約更新すると、指定された日時に記事内容が更新されます。…そのままですね。

利用環境

    • WordPress3.5以上
    • wp_cron()が実行できること(新規投稿で予約公開が正常動作できること)

インストール方法

方法は2つあります。
1. 直接ダウンロード

      • プラグインをこちらのダウンロードボタンからダウンロード
      • ダウンロードしたzipファイルを解凍し作成されたディレクトリを、お使いのWordPressのwp-content/pluginsディレクトリにコピー
      • WordPress管理画面「プラグイン」で「Rucy」を有効化

2. 管理画面から

      • WordPress管理画面「プラグイン」 > 「新規追加」に移動
      • 検索のテキストフォームから「Rucy」で検索
      • Rucyが表示されるので、インストール
      • インストールが成功したら、有効化

使用方法

有効化すると、編集画面に以下のような項目が追加されます。

rucy_sc003

「予約更新を行う」のチェックボックスをチェックすると、チェックボックス横の日時に、更新されます。
更新日時は、更新日時横の「編集」リンクから編集できます。
更新する記事内容は、WordPress標準のテキストエリアで編集できます。
更新日時、予約更新記事内容を編集し、「予約更新を行う」のチェックボックスをチェックして、公開項目の「更新」ボタンから記事を更新すると、指定日時に更新されるようになります。

設定

Rucyには、予約更新を実行する投稿タイプを設定できる設定画面があります。
有効化すると、管理画面の「設定」に Rucyというサブメニューが追加されます。
ここで投稿タイプ別に予約更新項目の追加設定ができます。

rucy_sc001

WordPress標準の、投稿、固定ページのほか、カスタマイズして追加したカスタム投稿タイプも、追加できます。

随時更新していきます

この記事を書いている今日現在(2014/05/06)、Rucyのバージョンは0.1.2です。
今後、アイキャッチ画像を更新可能にしたり、更新日時のUIの変更などの更新を予定しています。
また、Githubでもソースを公開しています。
ご意見、不具合などありましたら、ご連絡ください。可能な限り対応していきたいと思います。

※さくらクラウドにて期待通りの動作をしないという報告をいただいています。
同環境での動作検証ができておりませんが、同環境でご使用予定の方は、予めご考慮いただきインストールしてください。
(2014/09/11追記)

※バージョン0.4.0にアップデートし、ロールバック機能を追加しました。
指定日時に予約更新前の投稿内容に再更新(ロールバック)します。
(2015/10/22追記)