WordPress

【WP REST API】PHPを一切使わずに投稿一覧を作ってみる


エンジニアの関です。
4月でいよいよ社会人3年目です。最近、時代の流れの速さに怯えています。
私は普段WordPressで開発をしているのですが、よくこんな言葉を耳にします。

「PHPの知識がないからカスタムができない」

WordPressには初心者でも使いやすいようにプラグインやテーマなどを数多く取り揃えているのですが、自由にカスタムしたいとなると、やはりPHPの知識が必要になってきます。
そこで今回は、PHPを一切使わずにWordPressから動的にデータを取得・表示する方法をご紹介したいと思います。

続きを読む


【WordPress】投稿を集計するただひとつのプラグイン「Site Posts Stats」


社会人2年目エンジニアの関です。

WordPressの開発で、テーマとかプラグインを自作しているとなんだか上級者っぽい感じしませんか?かっこよくないですか?
ということで、私もかっこいい上級者に一歩でも近づきたいのでプラグインを自作してみました。

今回の制作物は以下で公開しています。
概要や画面説明などはREADME.mdを見てください。
https://github.com/hseki-luckey/site-posts-stats

1. 開発に必要なもの
テーマユニットデータ
集計するにはそこそこの投稿数が必要。でも、ちまちま1記事ずつ準備するのもなぁ・・・。と思っていたらちょうどいいのがありました。
簡単なインポートだけで投稿だけでなくカテゴリやタグ、ユーザなども追加できます。超助かります。

Chart.js
グラフを表示するためのライブラリ。今回の主役と言っても過言ではない。
このプラグインでは円グラフ、棒グラフ、折れ線グラフの3種類しか使っていませんが、他にもレーダーチャートやドーナツグラフなど、グラフの種類が充実している地味な優れものです。
ダウンロードしてもよかったのですが、めんどくさかった諸々の事情により外部リンクで読み込んでいます。個人的にアニメーションが好き。

2. 導入方法
① githubからソースをダウンロードし、/wp-content/plugins内にフォルダを設置する

② wp-admin内「インストール済みプラグイン」から「Site Posts Stats」を有効化する

③有効化すると左枠メニューバーに「投稿集計」というメニューが表示される

3. 画面デモ
以下、実際に表示されるグラフです。
女子っぽくグラフの色はピンクで統一してみました。

① 年別投稿数

初期値には「post_date_gmt」が「0000-00-00 00:00:00」になっている投稿が設定されます。(ステータスはおそらく「draft」「 auto-draft」だと思います。)
地味に投稿数0件の表示が大変でした。

②ステータス別投稿数

集計対象となる投稿のpost_typeを「post」と「page」に区切っているため、対象ステータスは「inherit」以外です。
③もなのが9種以上サイト内に投稿ステータスが存在すると対応する色が存在しないのでエラーが起きます。WordPressデフォルトは8種類なので、普通に使う分には問題ないかと。

③投稿タイプ別投稿数

②でも説明しましたが、対象の投稿タイプを9種類以上にするとエラーが起きます。
現在は「post」と「page」に絞っていますが、集計範囲を広げる場合には十分注意してください。

④著者別投稿数

10件以上グラフに表示させるとラベルの文字が小さくなりすぎて何が何だか分からなくなるので、グラフの表示数だけは10件に絞っています。

⑤カテゴリ別投稿数

④と同じくグラフの表示を10件に絞っています。

4. おわりに
今回のプラグイン制作期間はおよそ10時間。
phpやsqlというよりもjsやcssに手間取ってしまいました。行き当たりばったりで画面構成を決めてしまったのと、関数の作り方が雑だったのが反省点です。
まだまだWordPress上級者にはほど遠いので、また違うプラグインを作ってみたいと思います。

☆.。:・★.。:・☆.。:☆.。:・★.。:・☆.。:・★.。:・☆☆.。:・★.。:・☆.。:☆.。:・★.。:*・☆☆

株式会社リンクバルでは一緒に働くエンジニアを募集中です!
気になった方はコチラまで!

☆.。:・★.。:・☆.。:☆.。:・★.。:・☆.。:・★.。:・☆☆.。:・★.。:・☆.。:☆.。:・★.。:*・☆☆


【WordPress】プラグインがサイトを危険に晒す4つの方法


こんにちは!社会人2年目エンジニアの関です!

WordPressを利用する上で、プラグインはなくてはならないものです。
しかし間違った運用を続けていると、時にサイトを大破させる凶器にもなります。
今回は、突然の大事故を避けるためのプラグインの正しい導入・運用方法について紹介していきたいと思います。

1. 実績のないプラグインを導入する
WordPressには実に多くのプラグインが用意されています。そのため、中には粗悪なプラグインも紛れ込んでしまっているのも確かです。
プラグインの導入は良くも悪くもサイトに大きな影響を与えるため、慎重に選んでいきたいところです。

とりあえず「/)( ◕ ‿‿ ◕ )(\ わけがわからないよ」という方は、プラグインのダウンロードページで以下の3点に注意して選んでみてはいかがでしょうか。

  1. 最終更新日
    個人が作られているものも多いので、気づいたら1年以上前に更新が止まっていた、なんてことも。
  2. 有効化済みインストール数・評価
    何かしらの理由がない限りより多くのインストール数、より良い評価を集めているプラグインを選ぶべきだと思います。
    またインストール数が多いということは使っている人も多いため、ggるときに情報を集めやすくなる利点もあります。
  3. WordPressとの互換性
    あのバージョンでは動くけど、このバージョンでは動かないということがあります。
    プラグインの最新版が自分の環境のWordPressと互換性があるか、導入後に後悔しないためにもきちんと確認しましょう。

banners_and_alerts_%e3%81%a8_custom_post_type_ui_-_wordpress_plugins

とにかく言えるのは「とりあえずggれ」ということだけです。

2. 不用意にプラグインをインストールする
いくら便利なものでも使わないなら不要なものです。
プラグインの入れ過ぎは、サイトが異常に遅くなったり、セキュリティホールを作ってしまったりする原因になります。

インストールしているプラグインを定期的に見直し、必要に応じて削除するなり、入れ替えをするなりすることをオススメします。
また、プラグインを入れずに独自で実装できないかについても検討してみましょう。

3. バージョンが古いプラグインを使い続ける
「アップデートしたら動かなくなるかもしれない。」
「今正常に動いているからいいじゃん。」
気持ちは分かりますが、それを長く続けていくとどこかで事故る可能性が大いに出てきます。

WordPressを最新版にアップデートしたらプラグインが動かなくなり、慌てて最新のバージョンにプラグインをアップデートしたらサイトが壊れたorz
・・・なんてことになったら、まさに地獄の始まりです。

また、プラグインのリリースノートを見るとセキュリティfixのものも散見されるので、セキュリティ的にも小まめなアップデートをオススメします。

プラグインが最新か確認する方法

  1. プラグイン>インストール済みのプラグイン(/wp-admin/plugins.php)にアクセス
  2. 全プラグインが最新版になっているか確認

※最新でない場合下記のように「新バージョンの○○が利用できます」という黄色い表記が出てきます。その場合は「更新」を押して該当プラグインを最新版にアップデートしてください。

%e3%83%95%e3%82%9a%e3%83%a9%e3%82%af%e3%82%99%e3%82%a4%e3%83%b3__test01_-_wordpress_%f0%9f%94%8a

4. プラグイン自体に手を入れる
上記の「3.バージョンが古いプラグインを使い続ける」をついつい行ってしまう主な理由だと思います。
WordPressには様々なプラグインが用意されていますが、自分の求めている仕様に合致するプラグインが無く、似た仕様のプラグインをカスタムしなければならないときが出てくるかもしれません。
しかし、だからといってプラグインのソースコード自体に手を入れてしまうのはNGです。

プラグインはアップデートするとファイルの中身がごっそり入れ替わってしまうため、それに伴い、いくらソースコードを頑張ってカスタムしていたとしても容赦無く全部消えてしまいます
(同じ理由でWordPressのコアファイル(/wp-content以外のファイル)に手を入れるのはオススメしません。)

どうしてもプラグイン(コアファイル)をカスタムしたい場合は、WordPressデフォルトで用意されている「add_filter」などの関数を使ってカスタムしていきましょう。
この関数を使えば、プラグイン(コアファイル)内の該当関数にフックをかけて自由に動かすことができます。

おわりに
ここまでプラグインの安全な導入・運用方法をご紹介してきましたが、結局のところ日頃の小さな積み重ねが突然の大事故を防いでくれると思います。
そのためにも定期的な情報収集、運用方法の見直しを行うことをオススメします。

それでは、よいWordPressライフを!

☆.。:・★.。:*・☆.。:*☆.。:*・★.。:*・☆.。:・★.。:*・☆☆.。:・★.。:*・☆.。:*☆.。:*・★.。:*・☆☆

株式会社リンクバルでは一緒に働くエンジニアを募集中です!
気になった方はコチラまで!

☆.。:・★.。:*・☆.。:*☆.。:*・★.。:*・☆.。:・★.。:*・☆☆.。:・★.。:*・☆.。:*☆.。:*・★.。:*・☆☆


【WordPress】固定ページで親子関係を探る


こんにちは!社会人2年目エンジニアの関です!
先日WordPressの開発を行っていたとき、私はあることに気づきました。

「固定ページには親子関係を判定するための関数がない・・・だと・・・!」

そう。私の大好きな「cat_is_ancestor_of」のような関数が、固定ページの場合だとWordPressデフォルトで備わっていなかったのです。
そこで今回は、固定ページの親子関係を判定するための関数を作っていきたいと思います。

固定ページでの親子関係の作り方
WordPressデフォルトの機能として、以前ご紹介したカテゴリー同士での親子関係付けの他に、固定ページでの親子関係付けを行う機能も備わっています。
設定方法はカテゴリのときと同じく、とっても簡単な2ステップのみです。

①子にしたい固定ページの編集画面にアクセスする
②ページ属性>親の入力欄で親にしたい固定ページのタイトルを指定、保存して完了!
※親として選択できる固定ページは「公開中」のもののみです。親子関係付けを行う前に必ず親ページの公開を行ってください。
※カテゴリーのときと同じく、固定ページのURLも階層関係に応じて「親/子/孫/ひ孫/・・・」の形式に変化します。

%e5%9b%ba%e5%ae%9a%e3%83%98%e3%82%9a%e3%83%bc%e3%82%b7%e3%82%99%e3%82%92%e7%b7%a8%e9%9b%86__test01_-_wordpress

親子関係に応じて入力欄の表示や一覧ページの表示が変化するのもなかなか憎いです。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88_2016-11-25_9_39_44  

%e5%9b%ba%e5%ae%9a%e3%83%98%e3%82%9a%e3%83%bc%e3%82%b7%e3%82%99__test01_-_wordpress

詳しくは以下の記事をご参照ください。
固定ページの階層化/AdminWeb

親子関係を判定してみる
固定ページに親子関係を付けたところで、実際に親子関係を判定するための関数を実装してみます。

今回目指す仕様は以下の3点です。
①現在表示している固定ページは、指定した固定ページの子孫か否かを判定
②「cat_is_ancestor_of」のようにどんなに関係が離れた子孫(親とひ孫など)でも判定させる
③ページID指定だと開発している環境によって変わってしまう可能性があるのでslug指定

function page_is_ancestor_of($slug){
  // 現在表示しているページ情報を取得
  // get_the_ID()で紹介しているところも多いですが、これでも取得できます
  global $post;
  // 親か判別したい固定ページのslugからページ情報を取得
  $page = get_page_by_path($slug);
  $result = false;
  if(isset($page)){
    // $post->ancestorsで先祖を全て取得した配列(ID配列)を繰り返し処理
    foreach ($post->ancestors as $ancestor) {
      // 表示しているページのIDが含まれていればtrueを返す
      if($ancestor == $page->ID){ $result = true; }
    }
  }
  return $result;
}

これを使って、固定ページ「parent」を先祖に持つか否かを判定させてみると、

// 「parent/children/grandson/great_grandson」のページ
page_is_ancestor_of('parent');
#=> true

// 「sample/other」のページ
page_is_ancestor_of('parent');
#=> false

slug指定するなら親ページのslugと子ページのslugの前方一致でもいいんじゃあ・・・という気がしないでもないですが、とりあえずこれで固定ページの親子関係を判定するための関数ができました。
関連する固定ページの場合にのみ表示させたい項目があるときや、サイドバー・ヘッダー・フッターの出し分けなど、そこそこ必要な場面があると思います。

今回ご紹介した方法はほんの一例なので、他にいい方法をご存知でしたら教えてください。

☆.。:・★.。:*・☆.。:*☆.。:*・★.。:*・☆.。:・★.。:*・☆☆.。:・★.。:*・☆.。:*☆.。:*・★.。:*・☆☆

株式会社リンクバルでは一緒に働くエンジニアを募集中です!
気になった方はコチラまで!

☆.。:・★.。:*・☆.。:*☆.。:*・★.。:*・☆.。:・★.。:*・☆☆.。:・★.。:*・☆.。:*☆.。:*・★.。:*・☆☆


【学ぶ夜シリーズ・第2弾】徳丸浩とWordPressのセキュリティを学ぶ夜 セミナーレポート

セキュリティ

リンクバル技術部の川畑です。先日HASHコンサルティング主催の「【学ぶ夜シリーズ・第2弾】徳丸浩とWordPressのセキュリティを学ぶ夜」に参加してきました。
主な内容は、簡単な攻撃デモとセキュリティ対策についての解説と少し宣伝といった感じとなります。そのうちのセキュリティ対策の内容についてのレポートとなります。

Webサイトへの侵入経路は2パターンしかない!

  1. 管理用ツールの認証を突破される
  2. ソフトウェアの脆弱性を悪用される
    • 基盤ソフトウェアの脆弱性を悪用される(例:Apache、Nginx、PHPなどの脆弱性)
    • アプリケーションの脆弱性を悪用される(例:SQLインジェクションなどの脆弱性)

基本的にWebサイトへの侵入経路は2パターンしかないとのことで、「認証の突破」と「脆弱性の悪用」を重点として対策を打つのが有効!

攻撃受けるとどうなるか

  1. 情報漏洩
  2. データ改ざん
  3. DDos攻撃
  4. なりすまし

対策の基本的な考え方

  1. 根本的解決
    • パスワードをしっかり設定
      • 8文字以上
      • 英数字を混ぜる
      • 辞書に載っている単独文字は禁止
      • できればランダム文字列
      • 他のところで使用していないもの
      • 管理者が複数存在する場合は、管理者毎にユーザーを作成する
      • 退職・異動した管理者のアカウントは直ちに無効化する
    • 脆弱性を解消する
      • ソフトウェアバージョンアップまたはパッチ適用
        • 脆弱性対処は、バージョンアップまたはパッチ適用が基本
          • OSのパッケージを導入している場合はパッチ適用
        • バージョンアップするとサイトが動かなくなる…なんて心配しないで、とにかくバージョンアップ!
        • 自力でトラブル対処ができないソフトは導入しないこと
        • パブリッククラウドを利用している場合、イメージ形式でのバックアップをとっておくと安心

最も大切なことは「根本的解決策」を面倒くさがらずしっかりやる。パスワードもポリシーを作成し、定期的に変更するなどはセキュリティーの観点からはかなり有効とのこと。ユーザー名はデフォルトでも構わないからとにかく「パスワード!パスワード!」といっていたのが印象的でした。

  1. 保険的対策
    • PHPの機能を制限する
    • ファイルのディレクトリのパーミッション設定
    • 管理画面のログイン画面のIP制限
    • WAFの導入
    • SQLインジェクション対策
      • PHPの場合、とにかくプレースホルダを使うこと
      • 外部入力をSQL文に混ぜない

セキュリティ対策はイタチごっこ。地道な対策を続けることでシステムのセキュリティは守られるのだと再認識しました。
リンクバルではエンジニアを積極募集中です。興味のある方は、ご応募ください。もちろん、社内の人間と面識があるのでしたら、直接にご連絡いただいてもかまいません。