WordPressでカスタム投稿タイプごとにアーカイブの表示件数を変更する

どうも、ホワイトです。

WordPressでカスタム投稿タイプの使用頻度はめっちゃ高いです。

カスタム投稿タイプを使うということは、投稿タイプごとの特徴が分かれていることも多く、内容やレイアウトも異なってくることがあります。

内容のボリュームやレイアウトの違いでアーカイブ(記事一覧)ページに表示する件数もそれぞれ異なってくることがあるかと思います。

そこでカスタム投稿タイプごとのアーカイブページにおける表示件数の設定方法をまとめてみました。

投稿全般におけるアーカイブページの表示件数の設定

WordPress全体の記事一覧ページの表示件数については「設定」→「表示設定」→「1ページに表示する最大投稿数」で設定することが可能です。 ただ、ここは全体での最大投稿数を制御するためのものであって、特定のカスタム投稿タイプの表示件数を設定することはできません。

ここが「10件」となっていれば、カスタム投稿タイプだろうが通常投稿だろうが、どのアーカイブページでも最大10件までしか表示されないことになります。

特定のカスタム投稿タイプでの表示件数を設定する

全体のアーカイブページでの最大投稿数が10件だとして、例えば”activity”というカスタム投稿タイプのアーカイブページだけを最大30件表示できるようにします。 そうしたときのコードが以下となります。

function change_posts_per_page($query) {
    if ( is_admin() || ! $query->is_main_query() )
        return;
    if ( $query->is_post_type_archive('activity') ) { //activityというカスタム投稿タイプを指定する
        $query->set( 'posts_per_page', '30' ); //カスタム投稿タイプの最大投稿件数30を指定する
    }
}
add_action( 'pre_get_posts', 'change_posts_per_page' );

これで指定したカスタム投稿タイプのアーカイブページの表示件数を設定することができます。

さらに分岐させるときは以下のように記述します。

function change_posts_per_page($query) {
    if ( is_admin() || ! $query->is_main_query() )
        return;
    if ( $query->is_post_type_archive('activity') ) { //activityというカスタム投稿タイプを指定する
        $query->set( 'posts_per_page', '30' ); //カスタム投稿タイプの最大投稿件数30を指定する
    }
    if ( $query->is_post_type_archive('event') ) { //eventというカスタム投稿タイプを指定する
        $query->set( 'posts_per_page', '10' ); //カスタム投稿タイプの最大投稿件数10を指定する }
}
add_action( 'pre_get_posts', 'change_posts_per_page' );

この条件分岐も必ず使うケースが出てくると思います。

丸々覚えているというのはなかなか難しいので、こういう条件分岐が使えるということは必ず覚えておいて損はないでしょう。

is_post_type_archiveの他にも、is_archive、is_searchといった感じで使い分けができるので重宝させてもらっています。

WordPressのカスタム投稿タイプで特定のタームごとの記事一覧を表示させる

どうも、ホワイトです。

WordPressでカスタム投稿タイプを使用していると、ある特定タームの記事を何件か表示させることはできますか?ということがありました。

通常の投稿のカテゴリーだったら、すぐできるんですが、少し考えてしまったことがあったので、備忘録とともに設定方法を残しておきます。

tax_queryを使って記事を読み込む

今回ポイントとなるのはtax_queryじゃないかと思います。

<ul>
  <?php $query = new WP_Query( array( 'post_type' => 'column', //カスタム投稿タイプの指定
          'posts_per_page' => 4, //表示件数
          'tax_query' => array(
              array(
                  'taxonomy' => 'column-cat', //タクソノミーの指定
                  'field' => 'slug',
                  'terms' => array(
                      'books', //column-catのタームであるbooksの記事を指定
                  ),
              ),
          ),
      )
  );
  ?>
  <?php if($query -> have_posts()): ?>
  <?php while($query -> have_posts()): $query->the_post();?>
  <li>
    <a href="<?php the_permalink(); ?>">
      <?php the_post_thumbnail('pagePost'); ?>
      <?php echo get_the_date('Y.m.d'); ?>
      <?php the_title();?>
    </a>
  </li>
  <?php endwhile; ?>
  <?php endif; wp_reset_postdata(); ?>
</ul>

これでカスタム投稿タイプ”column”のカスタムタクソノミーである”column-cat”に属する”books”の記事が表示されることになります。

htmlの部分は任意なので、使用する状況に応じて適宜変更してください。

通常投稿だけじゃなく、カスタム投稿でもカテゴリー分け、タグ分けのような形で細かく指定されることは結構あると思うので、この書き方を知っておくと便利だと思います。

 

WordPressの条件分岐”in_category”で特定のカテゴリーページにのみ表示させる方法

どうも、ホワイトです。

WordPressを使っていれば条件よって分岐する記述を行わざるを得ないことが幾度となくあります。

 

「特定の〇〇にだけ〇〇を表示させたい」なんてことは日常茶飯事のように起きてきます。

今回は特定のカテゴリーに属するページだけに表示させる条件分岐の方法です。

特定カテゴリーの表示を切り替える

今回使う条件分岐のタグは”in_category”です。

“is_category”もありますが、間違えないように注意してください。

“is_category”はアーカイブページの条件分岐に使用するので、そちらはまた別にまとめたいと思います。

例1)newsというカテゴリーだけに表示させる方法

スラッグを使う場合。

<?php if ( in_category( 'news' ) ): ?>
newsカテゴリーに属したページだけに表示
<?php endif; ?>

 

スラッグだけでなくIDを使うことも可能です。

その場合はシングルクオーテーションを外します。
※例として10と入れていますが、実際に該当するIDを入れてください。

<?php if ( in_category( '10' ) ): ?>
newsカテゴリーに属したページだけに表示
<?php endif; ?>

 

例2)newsというカテゴリーと、それ以外に表示させる方法

上記の二例はnewのときだけに表示する方法ですが、newカテゴリーのページとそれ以外のページに表示したいという場合は以下のようになります。

<?php if ( in_category( 'news' ) ): ?>
newsカテゴリーに属したページにはこちらを表示
<?php else: ?>
newsカテゴリー以外のページにはこちらを表示
<?php endif; ?>

例3)三つ以上の選択肢が必要な場合に表示させる方法

もちろん二つより多い選択肢で表示を出し分けることもあります。

むしろそんなケースも多くあるのではないかと思います。

そういったときは以下のような記述となります。

<?php if ( in_category( 'news' ) ): ?>
newsカテゴリーに属したページにはこちらを表示
<?php elseif ( in_category( 'schedule' ) ): ?>
scheduleカテゴリーに属したページにはこちらを表示
<?php elseif ( in_category( 'gallery' ) ): ?>
galleryカテゴリーに属したページにはこちらを表示
<?php else: ?>
上記三つ以外のカテゴリーのページにはこちらを表示
<?php endif; ?>

 

カテゴリーを複数指定する場合

特定のカテゴリーを一つだけでなく複数指定したい場合も当然出てくると思います。

そういうときは以下のコードを使います。

<?php if ( in_category( array( 'schedule', 'gallery' ) ) ): ?>
scheduleとgalleryのカテゴリーに属したページだけに表示
<?php endif; ?>

カンマで区切ってカテゴリーを複数記述していけば大丈夫です。

 

逆に特定のカテゴリーにのみ表示させない

これまでとは逆に特定のカテゴリーだけに表示させたくないという場合も当然出てくるでしょう。

そういった場合は以下の記述をします。

<?php if (!in_category( 'schedule' ) ): ?>
scheduleカテゴリーに属したページだけに表示しない
<?php endif; ?>

 

色々な場面で使うケースがあると思いますが、個人的にも使用頻度は高く、WordPressを使う上で必須となる条件分岐のタグでしょう。

WordPressの個別ページをカテゴリーごとにデザインを変えるsingle.phpの設定方法

どうも、ホワイトです。

WordPressで個別投稿ページをカテゴリーごとにデザイン変更することがよくあります。

同じ投稿形式でも、newsカテゴリーに属する個別ページと、blogカテゴリーに属する個別ページでデザインを変更したいなんてことが出てくると思います。

タグの出し分けなら条件分岐のifを使ったりしてできることもあるだろうけど、デザインを変更するとなるとカテゴリーごとのsingle.phpがあった方が便利。

その設定方法です。

カテゴリーごとに分岐するためのsingle.phpの記述

カテゴリーごとの記事一覧ページを作る場合はcategory-カテゴリーのスラッグ.phpというファイルをそれぞれ作ってあげれば記事一覧は表示されるのですが、個別ページは単にsingle-カテゴリーのスラッグ.phpというファイルを作っても、記事一覧のように勝手に分岐されて表示はされません。

 

カテゴリースラッグごとのsingle-〇〇〇.phpを作る前に、大元となるsingle.phpにカテゴリーを分岐するための記述をする必要があります。

最初の頃はここで引っかかって何かエラー出ちゃってるのかな?と迷うこともありました。

 

例として”news”と”blog”と”report”という三つのカテゴリーとそれ以外を分岐するためには、single.phpに以下のように記述します。

<?php $post = $wp_query->post;
if ( in_category('newsのカテゴリーID') ) {
include(TEMPLATEPATH.'/single-news.php');
} elseif ( in_category('blogのカテゴリーID') ) {
include(TEMPLATEPATH.'/single-blog.php');
} elseif ( in_category('reportのカテゴリーID') ) {
include(TEMPLATEPATH.'/single-report.php');
} else ( in_category('etcのカテゴリーID') ) {
include(TEMPLATEPATH.'/single-etc.php');
}
?>

single.phpへの記述はこれだけ。

newsカテゴリーの場合はsingle-news.php、blogカテゴリーの場合はsingle-blog.php、reportカテゴリーの場合はsingle-report.php、それ以外はsingle-etc.phpが読み込まれます。

カテゴリーIDの部分はスラッグを指定しても大丈夫です。

 

スラッグで指定する場合は以下のようになります。

<?php $post = $wp_query->post;
if ( in_category('news') ) {
include(TEMPLATEPATH.'/single-news.php');
} elseif ( in_category('blog') ) {
include(TEMPLATEPATH.'/single-blog.php');
} elseif ( in_category('report') ) {
include(TEMPLATEPATH.'/single-report.php');
} else ( in_category('etc') ) {
include(TEMPLATEPATH.'/single-etc.php');
}
?>

あとはここに記述した、カテゴリーごとのsingle.phpファイルを作成して、それぞれにデザインを分けたコーディングを行っていけば完了です。

ここでいうと、single-news.php、single-blog.php、single-report.phpというファイルを作成すれば大丈夫です。

 

意外と使う機会があるかと思うので、覚えておくと便利です。

WordPressで投稿タイプごとの検索ボックスを設置する

どうも、ホワイトです。

先日、WordPressの検索ボックス設置について、質問されることがあったので、自分のための備忘録としても残しておきたいと思います。
数年前に使ってtxtファイルに残していたけど、こうやって書き出した方が良いですね。

ここ最近では自分が関わってきたWordPress案件には何故か検索ボックス設置を行うことがなかったので久々でした。

投稿タイプを指定したコードを記述する

まぁ、当然といえば当然ですが、そういうことです。

<form method="get" id="searchColumn" action="<?php echo home_url('/'); ?>">
<input type="text" name="s" id="searchColumnInput" value="<?php the_search_query(); ?>" placeholder="カスタム投稿内を検索" />
<input type="hidden" name="post_type" value="column">
<input type="submit" value="search" accesskey="f" />
</form>

これだけ。

 

“column”というカスタム投稿タイプ内を検索するという設定例です。

 

nameでpost_type、valueで投稿タイプの”column”を指定します。

<input type="hidden" name="post_type" value="column">

こちらの行で、どの投稿タイプかの絞り込みを行います。

一行目、二行目のid、placeholderに入るのは、あくまで例なので、必要に応じて適宜変更してください。

投稿タイプごとの検索結果を表示させる

検索結果を表示させるのであれば、search.phpは最低限必要になってきますが、用意されていない場合はindex.phpが適用されて検索結果が表示されることになります。

通常の検索結果であれば、これらのファイルを用意すれば充分かと思いますが、カスタム投稿タイプに応じた検索結果を表示したいという場合はfunctions.phpへの記述と、カスタム投稿タイプごとの検索結果テンプレートファイルを作成します。

まずはfunctions.phpに以下のコードを記述します。

 

add_filter('template_include','custom_search_template');
function custom_search_template($template){
  if ( is_search() ){
    $post_types = get_query_var('post_type');
    foreach ( (array) $post_types as $post_type )
      $templates[] = "search-{$post_type}.php";
    $templates[] = 'search.php';
    $template = get_query_template('search',$templates);
  }
  return $template;
}

上記のコードをfunctions.phpに記述することで、カスタム投稿タイプごとの検索結果ファイルをsearch-xxxx.phpというような形で作ることができます。

“column”というカスタム投稿タイプの場合は、search-column.phpとなります。

 

これでカスタム投稿タイプごとの検索結果ページのデザインを変えていくことができます。

 

今回教えた方もすぐに使えたようなので、恐らく間違いはないでしょう。

 

そんなに頻度は高くないと思いますが、知っていると便利ですね。

WordPressのセキュリティ向上に「SiteGuard WP Plugin」を導入する

どうも、ホワイトです。

WordPressの初歩的な部分を振り返っているつもりで書いているプラグインシリーズですが、結構出てくるもんですね。

今回はログインページと管理画面のセキュリティ向上のために使用する「SiteGuard WP Plugin」の設定と使用方法について。

SiteGuard WP Pluginをインストール&有効化する

いつものごとく、プラグインをインストール&有効化します。

有効化すると管理画面上部に「ログインページURLが変更されました。」が表示されます。

「新しいログインページURL」をクリックするとプラグインをインストールすることで設定された新しいログインページに遷移します。

その際、ユーザー名、パスワードのほかに表示された文字を入力する項目も表示されます。
ユーザー名とパスワードに変更はないので、表示されている文字を入力してログインします。

SiteGuard WP Pluginを設定する

管理画面のSiteGuard→ダッシュボードで設定状況を確認します。

一つずつ設定を見ていきます。

管理ページアクセス制限

文字通り、外部から管理ページへのアクセスを制限します。

ログインページ以外の下層ページに直接アクセスされて入り込まれてしまうことがないよう、ログインを行っていない悪意の第三者からの攻撃に対し404を返します。

設定に関する説明も記載されているので、これをよく読んでからONにします。
必ずONにしておきましょう。

ログインページ変更

上記はテスト用に変更したログインページ名なので、実際にアクセスしても表示されません。

プラグイン有効化と同時に変更されたログインページのURLをこちらで変更することができます。

ランダムに変更されたものよりも自分で決めた方が良いという場合はこちらから変更してください。

WordPressのログイン画面URLは誰でもすぐにわかってしまうので、これは必ず設定した方が良いです。

画像認証

先ほどログインページで出てきた認証用の文字の設定などを変更できます。

これもしっかりと設定しておきましょう。

ログイン詳細エラーメッセージの無効化

ログインエラー時に出されるエラーメッセージによって何が間違っているかを教えてしまうため、失敗したと同時にログインするためのヒントを与えてしまうことにもなります。

このエラーメッセージを同一のものを返すことで、侵入を試みようとする者にヒントを与えず管理画面を守ります。

ログインロック

何回かログインを試みて失敗したときに同一IPからのアクセスを一定時間ブロックします。

これを設定して自分でその設定のとおりに間違えたりしないように注意してください。

ログインアラート

管理画面にログインがあるとメールで通知してくれます。

もちろん自分自身でログインした場合にも通知があるので、多少鬱陶しいこともありますが、何が起きるか分からないので一応これもONにしておきます。

フェールワンス

これは便利なのかどうか微妙なところではありますが、正しいユーザー名とパスワードを入力しても一度はログインが失敗するという機能です。

正しく入力しても、それを弾くので相当セキュリティとしては良いと思うのですが、自分がログインの度にそれやられてもなぁ…と思うので、これはOFFのままにしてますが、必要に応じてONにしてください。

XMLRPC防御

う~ん、これも微妙なところですね。

説明に書いてあるとおりXMLRPCを無効化して他のプラグインに影響が出るといけないので、ピンバック無効化は行っても良いと思いますね。

ピンバックによる攻撃もあるのでピンバック無効化を選択してONを設定します。

更新通知

これは設定画面のとおり、それぞれに更新があったときに通知してくれる機能です。

これも一応ONにしていますが、ログインすれば管理画面上に現れることなのでログイン頻度が多い人はOFFでも構わないと思います。

WAFチューニングサポート

契約しているレンタルサーバーのサービスでWAFがある場合、WordPress内での誤検知を回避する機能です。

サーバーにWAFが設定されていればON、設定されていなければOFFにします。

詳細設定

説明どおりIPアドレスの取得方法が設定できます。

これは初期設定のまま「リモートアドレス」にしておいて大丈夫です。

ログイン履歴

ログイン履歴が見られるので重宝しています。

時折、同IPから凄い数のアクセスがあり、結果のところに全て失敗と表示されていて、いかにも攻撃されてたんだなとわかるようなときもあります。

特にON・OFFないですが、デフォルトで履歴残してくれて助かりますね。

 

意外と設定項目が多いけど、難しいことはないので、WordPressを使うならこのプラグインはインストールしておいた方が良いと思います。

WordPressの記事内にソースコードを表示するなら「SyntaxHighlighter Evolved」プラグイン

どうも、ホワイトです。

さて、ちょっと間が空いてしまってWordPress関連です。

記事内にhtmlなどのソースコードを載せたいなと思ったので、まずはプラグインの使い方を振り返る意味でのアウトプット。

久々に使おうとしても意外と覚えているもんですね。

SyntaxHighlighter Evolvedをインストールする

ソースコードを記事内で表示するには「SyntaxHighlighter Evolved」というプラグインを使います。

まずは管理画面からインストールしましょう。

インストール&有効化が済んだら設定に入ります。

SyntaxHighlighter Evolvedの設定

最低限、必要と思われる項目を説明します。

SyntaxHighlighterのバージョン

3.xで良いでしょう。

設定画面の下部にあるプレビュー表示でも確認できますが、2.xにするとコード内にマウスオーバーすると右上にコピーするためのツールが出たり、折り返し表示がされます。

3.xはそのままドラッグでコピーしても行番号がコピーされないことと、ダブルクリックするとコード全てが選択できるので、自分はこちらの方が便利だと思うので使います。

テーマの選択

テーマもいくつか選択ができます。

選択して「変更を保存」をクリックすると、下部のプレビューで選択したテーマの表示がされるので、そちらを見て選択してみてください。

Fade to Greyを選択すると↑このような表示になります。

次の「すべてのブラシを読み込む」は特にチェックを付けなくても大丈夫です。
そもそもここを調べたことないけど問題なく使えてるので、特には必要ないでしょう。

規定の設定

こちらはもう見たまんまというか、自分は基本的にここもいじりません。

追加のCSSのclass名(複数可能)というのは、コードの中にあるdivにclass指定することができます。

タイトルはコードブロック上部にタイトルテキストが表示されます。

記事への投稿の方法

使い方は非常に簡単。

記載したいソースコードを言語タグで囲むだけ。必ず「ビジュアルモード」ではなく「テキストモード」で行ってください。
htmlの場合は以下のような形です。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>PHP Code Example</title>
</head>
<body>
<h1>PHP コードサンプル</h1>
<?php echo 'Hello World!'; ?>
<div class="foobar">
        This    is  an
        example of  smart
        tabs.
</div>
<a href="http://wordpress.org/">WordPress</a>
</body>
</html>

もしくは

[code lang=”言語名”][/code]

で囲んでも同じように表示されます。

設定画面下部に「引数指定の例」という箇所があるので、ここを参照にするとすぐわかると思います。

SyntaxHighlighterで使える言語

SyntaxHighlighterで使える言語は以下のとおりです。

XML xml, xhtml, xslt, html, xhtml
Plain Text plain, text
CSS css
PHP php
JavaScript js, jscript, javascript
ActionScript3 as3, actionscript3
Bash/shell bash, shell
ColdFusion cf, coldfusion
C# c-sharp, csharp
C++ cpp, c
Delphi delphi, pas, pascal
Diff diff, patch
Erlang erl, erlang
Groovy groovy
Java java
JavaFX jfx, javafx
Perl perl, pl
PowerShell ps, powershell
Python py, python
Ruby rails, ror, ruby
Scala scala
SQL sql
Visual Basic vb, vbnet

パラメーターの設定

パラメーターも設定画面の下部に全て書いてあるので、そちらを参照に使ってみてください。

プレビューでも使用されているハイライトの使い方は以下の通りです。
htmlの5行目をハイライトする場合。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>PHP Code Example</title>
</head>
<body>
<h1>PHP コードサンプル</h1>
<?php echo 'Hello World!'; ?>
<a href="http://wordpress.org/">WordPress</a>
</body>
</html>

5行目がハイライトされます。

 

使い方は非常に簡単で、個人的には記事の中でソースコードを記載するプラグインとしては一番優れていると思ってます。

来るべき日に備えてプラグインでGutenbergを無効化する方法

Disable Gutenberg

どうも、ホワイトです。

近々行われるアップデートでWordPress5.0から新エディターの「Gutenberg」が導入されることとなります。

Gutenberg(グーテンベルク)は、WordPress 5.0 で搭載される予定のビジュアルエディターです。 2018年8月現在、WordPress 4.9.8 のダッシュボードからプラグインとしてインストールし、「Gutenberg を試す」ことができます。

Gutenbergでは、「ブロック」という機能によって、見出し、文章、画像などの要素を組み合わせて作成することができます。 HTMLを記述しなくても、リッチなページを簡単に作成できるようになります。

Gutenbergの名前の由来は、活版印刷を発明した、ヨハネス・グーテンベルク(Johannes Gensfleisch zur Laden zum Gutenberg)です。

https://lqd.jp/wp/manual/gutenberg.html

通常のエディターで、よりリッチなコンテンツが簡単に作れるようになるというもので、話だけを聞くと便利そうに思いますが、この大幅なアップデートについていく準備が整っていないユーザーがいることも確か。

そこでWordPress5.0がリリースされアップデートしてからも当分は現在のエディターを使いたいという方は、これから紹介する2つのプラグインの導入をオススメします。

ただし、あくまでもこの方法は「準備が整うまで」という一時的なオススメであり、将来的にはGutenbergを使用するという前提で導入してもらえればと思ってます。

「Disable Gutenberg」をインストールする

管理画面メニュー「プラグイン」→「新規追加」から「Disable Gutenberg」と入力して出てきたこちらのプラグインをインストールします。

Disable Gutenberg

「今すぐインストール」→「有効化」で設定は完了です。

念のため「設定」→「Disable Gutenberg」から設定を確認します。

Disable Gutenberg

一番上の「Complete Disable」にチェックが付いていれば、全てのGutenbergの全ての機能が無効化されたことになるのでOKです。

「Classic Editor」をインストールして現エディターを使う

次に紹介するプラグインが「Classic Editor」です。

こちらもさきほどの「Disable Gutenberg」同様、新エディターのGutenbergが導入された後も今まで通り従来のエディターを使用できるようにするプラグインです。

Classic Editor

早速、プラグインの新規追加画面で「Classic Editor」を検索して、インストール&有効化します。

管理画面メニューの「設定」→「投稿設定」の画面へいくと「旧エディター設定」という表示がされているので、こちらの「Replace the Block editor with the Classic editor.」にチェックが付いていることを確認。

Classic Editor

逆に「Use the Block editor by default and include optional links back to the Classic editor.」を選択した場合は、投稿一覧の画面において、以下の箇所から旧エディターを選択して編集ができるようになります。

Classic Editor

こちらの「Classic Editor」は現時点(2018年11月)では公式サポートが2021年12月31日までとなっています。

 

まだまだこれから整備されてくる部分もあるので、今は使用しなくても知識だけは確実に抑えておき、いつでも移行できる準備だけは始めておいても良いと思います。

ドラッグ&ドロップでアイキャッチ設定できる「Drag & Drop Featured Image」

Drag & Drop Featured Image

どうも、ホワイトです。

無くても良いかもしれないけど、あると便利なプラグインとして重宝させてもらっているのが「Drag & Drop Featured Image」です。

重宝させてもらってるんだから、自分にとってはあった方が良いプラグインですね。

通常はこのように投稿画面の右側にある「アイキャッチ画像」のところから「アイキャッチ画像を設定」をクリックしてメディアライブラリから選択してアイキャッチを設定することになります。

Drag & Drop Featured Image

これをメディアライブラリに登録していない画像でもドラッグ&ドロップで簡単にアイキャッチとして設定することができるようにするのが「Drag & Drop Featured Image」です。

まずは例によって「Drag & Drop Featured Image」のインストール

管理画面メニュー「プラグイン」→「新規追加」からキーワードに「Drag & Drop Featured Image」を入力。

Drag & Drop Featured Image

「今すぐインストール」、そしてそのまま「有効化」を!

プラグインを有効化すると、投稿画面の「アイキャッチ画像」のところが「Featured Image」となり、すぐに画像をドラッグ&ドロップで設定できるようになります。

Drag & Drop Featured Image

これでメディアライブラリに登録されていない画像でも簡単にアイキャッチ画像として設定することができるようになりました。

基本的には投稿と個別ページの両方にアイキャッチ画像がドラッグ&ドロップで設定できるようになります。

プラグインの管理は、管理画面メニューの「設定」→「Featured Image」から設定します。

Drag & Drop Featured Image

こちらで設定のON、OFF切替を行います。

通常投稿だけでなくカスタム投稿やお問い合わせフォームなどを設定している場合は、以下のようにそれぞれの項目にON、OFF切替設定を行うことが可能となります。

Drag & Drop Featured Image

入れておいて損はないと思いますので、是非一度お試しください。

「Drag & Drop Featured Image」をインストールする際の注意点

「Drag & Drop Featured Image」をインストールして使う際に一つ注意してもらうことがあります。

一部のレンタルサーバーでは、インストールして有効化したときに画面が403エラーとなる場合があります。

自分が経験したのはロリポップ!では、ユーザー管理画面からWAFの設定を無効化することでインストールと有効化を行うことができました。

一度プラグインを有効化したあとは、WAFの方も元通り有効化しても問題無くプラグインは動作します。

他のサーバーでも403エラーが出る可能性も考えられるので、もし遭遇した場合はWAFの設定を確認してみましょう。

 

WordPressプラグイン「Better Delete Revision」で不要なリビジョン削除とデータベースを最適化しよう

Better Delete Revision

どうも、ホワイトです。

WordPressでサイト制作を行う際に自分が必ず入れるプラグインとして今回は「Better Delete Revision」を紹介します。

Better Delete Revision

WordPressでは記事を作成中に誤ってブラウザを閉じてしまったり、急にPCが落ちてしまったなどのアクシデントがあったとしても、記事を簡単に復元できるように、記事の編集や保存の履歴を自動的にデータ保存してくれる機能があります。

この機能がリビジョンです。

Better Delete Revision

こんな感じで投稿画面に表示されてるやつです。

このリビジョンはWordPressをインストールして記事を書き始めたときから自動的に溜まり続けていくので、これが多くなってくるとデータベースの使用量も増えていき、データベースを圧迫することとなります。

もしもの場合には非常に便利な機能ですが、記事が完成した後は使うことの無いゴミ同然のものが残り続けることになります。
そんなんでデータベースを圧迫されたんじゃたまったもんじゃないので、それを削除しようというプラグインが「Better Delete Revision」です。

Better Delete Revisionをインストールする

何はともあれインストールから。

Better Delete Revision

管理画面メニューの「プラグイン」→「新規追加」でキーワードにBetter Delete Revisionを入力して、こちらをインストール。

インストールしたらすぐに有効化。

Better Delete Revision

他のプラグインと同様、これでインストールできました。

もちろん、サイトからダウンロードしてインストールしても大丈夫ですが、面倒なのでこちらで一気に済ませましょう。

Better Delete Revision使って早速リビジョンを削除してみる

プラグインを有効化したら、早速リビジョンを削除してみましょう。

管理画面メニューの「設定」→「Better Delete Revision」で設定画面の入ります。

Better Delete Revision

ボタンが2つ出てくるので「Check Revision Posts」をクリック。

そうすると溜まったリビジョンの一覧が表示されます。

Better Delete Revision

リビジョン一覧の最下部にある青いボタンの「Yes, I would like to delete them!(A Total Of 5)」をクリックします。
※最後の数字はリビジョンの数によって変動します。

ボタンをクリックしたらリビジョンは全て削除完了です。

Better Delete Revision

データベースを最適化してみよう

不要なリビジョンの削除とともに「Better Delete Revision」ではデータベースの最適化も行うことができます。

Better Delete Revision

設定画面で「Optimize Your Database」をクリック。

データベースの一覧が表示されます。

Better Delete Revision

↑のサンプル画面では右側に緑の文字で全て「OK」と出ています。

この状態であれば問題ないのでデータベースを最適化しなくても大丈夫です。

一覧の下の方へ行くと、「ステータスがOKであれば、データベースを最適化する必要はありません。もし赤い場合はボタンをクリックしてWordpressデータベースを最適化しましょう」というような英文が書いてあります。
※英語できないので大体の単語から推測…恐らく合ってます。

Better Delete Revision

指示通り、ステータスに赤く表示されているテキストがある場合は「Opitimize WordPress Database」をクリックしてデータベースを最適化します。

 

かなり簡単に使えて便利だと思ってます。

ブログ更新頻度が高かったりすると保存したり修正したりも多くなってくるのでリビジョンがどんどんと溜まっていく一方になるので、不要なリビジョンは削除しておくようにしましょう。