Google Analytics トラッキング コードの設定 方法

Google Analytics トラッキング コードの設定 方法

今回は子テーマをせっかく作ったのでそれを利用してGoogle Analytics トラッキング コードの設定 をします。

ちなみに良く見かける方法は、親テーマの「header.php」へ直接書き込んだりする方法です。
もちろん手軽ではありますが、親テーマのアップデートでコードが無くなってしまいます。

それから、プラグインでGoogle Analytics トラッキング コードを設定する方法もありますが、プラグインって何かと問題を起こすし重くなるので、ほんとうに使いたい機能以外は極力避けたいと思っています。
これは好みの話なので、プラグインを使ってももちろんOKだと思います。
検索してみると下の2つが良く使われているプラグインみたいです。
・Google Analytics by Yoast
・All in One SEO Pack

子テーマを使った Google Analytics トラッキング コードの設定

では、初心者にもわかる「子テーマを使ったトラッキング コードの設定」を紹介します。
子テーマに便利な「functions.php」ファイルがあります。
このファイルには自分で関数を定義追加することができます。
なので、自分でGoogle Analytics トラッキング コードをheadに貼り付ける関数を登録してしまおうという方法です。

『twentyelevenの子テーマの作り方』『twentyseventeenの子テーマの作り方』の方法で子テーマを作ってあると「functions.php」が作ってあるはずです。
親テーマのスタイルシートを読み込む際に以前は @import: を使用して親テーマのスタイルシートをインポートしていましたが、これはもはや良い方法ではありませんと言われています。
親テーマのスタイルシートを読み込む正しい方法は、子テーマの 「functions.php」 で wp_enqueue_script()を使用する方法です。したがって子テーマには 「functions.php」 を作成する必要があります。

で、その「functions.php」にしたのコードのようにコピペするだけです。

//Gole Analytics Code設定
function set_gac() { ?>
    <script>
        (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
        (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
        m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
        })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

        ga('create', 'UA-XXXXXXXX-X', 'auto');
        ga('send', 'pageview');

    </script> 
<?php }
add_action('wp_head', 'set_gac');

これで親テーマがアップデートされても上書きされないのでメンテナンスが楽になります。

以上、子テーマを使ったGoogle Analytics トラッキング コードの設定方法でした。

twentyseventeenの子テーマの作り方

twentyseventeenの子テーマの作り方

今回は、twentyseventeenの子テーマの作り方 を紹介します。
「twentyelevenの子テーマの作り方」はこちらまで

今回はサクッと一番簡単な作り方を紹介します。

子テーマ設置方法

子テーマ設置場所

子テーマを作成する最初の行程は、子テーマディレクトリの作成です。
wp-content/themes ディレクトリ下に作成します。
子テーマディレクトリの名前には最後に ‘-child’ を付けることが推奨されます。

今回は、「twentyseventeen-child」という名前のディレクトリを「wp-content/themes」ディレクトリに作ります。
作り方は、FTPアプリやレンタルサーバのファイル管理アプリで作ります。
※子テーマディレクトリの名前には空白を含めないでください。エラーが発生します。

子テーマ設置必須ファイル

子テーマは、2つのファイル「style.css」と「functions.php」を作成する必要があります。

まずは、「style.css」から作ります。

/*
 Theme Name:   Twenty SeventeenChild
 Template:     twentyseventeen
*/

Theme Name:Twenty SeventeenChild
テーマの名称。全角可。ここに書いた名称が管理画面のテーマ選択画面に表示される。
Template:twentyseventeen
親テーマのディレクトリ名。大文字小文字を区別するのできっち書くこと。
※全角文字を入れたときにはエディタの文字コードを UTF-8 にする必要があります。

次に、「functions.php」を作ります。
以前は「style.css」の中で @import: を使用して親テーマのスタイルシートをインポートしていましたが、これはもはや良い方法ではないそうです。
親テーマのスタイルシートを反映させる正しい方法は、子テーマの functions.php で wp_enqueue_script()を使用する方法です。
したがって子テーマには functions.php を作成する必要があります。

私も初心者なので理解できないこともありますが、言われたとおりに作っておきます。

<?php
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );

}
?>

普通はこれで親のスタイルシート(「style.css」)を読み込んだ後に、子テーマのスタイルシート(「style.css」)を読み込み上書きされることになります。
しかし、なぜかうまく子テーマのスタイルシート(「style.css」)が読み込まれないパターンがあるそうです。
その際は、下のようにすると良いらしいです。

<?php
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array('parent-style')
    );
}
?>

各々ファイルを保存したら、先ほど作った子テーマディレクトリへファイルをアップロードします。
と言うか、どんな方法でも良いので、先ほど作った子テーマディレクトリに2つのファイルを置ければOKです。
なお、エディタの文字コードを UTF-8 で保存しましょう。

子テーマの有効化

正常にアップロード出来たら、子テーマを有効化できる準備ができました。
サイトの管理画面にログインし、管理画面 > 外観 > テーマに移動してください。
子テーマが表示され、有効化できる状態になっています。

なお、 子テーマを有効化したあとは、メニュー (外観 > メニュー または 外観 > カスタマイズ > メニュー) およびテーマのオプション (背景やヘッダイメージ) を保存し直す必要があります。
今まで触って居なければそのままでもOKです。
以上でtwentyseventeenの子テーマの設定ができます。
後は、自由にカスタマイズすればOKですので学習してカスタマイズしてください。

twentyeleven の 子テーマ の作り方

twentyelevenの子テーマの作り方

今回は「twentyeleven」の子テーマの作り方を紹介します。
そもそも 子テーマ とは、親テーマ(今回はtwentyeleven)と呼ばれる別のテーマの機能とスタイルを継承して、必要な部分だけ変更するテーマです。
既存のテーマを変更する方法として、子テーマが推奨されています。

子テーマ の有用性

子テーマの有用性は、親テーマがアップデートされてもカスタマイズ(変更)が消えない点にあります。

親テーマ(twentyeleven)は頻繁にアップデートされます。
それはとてもありがたいことですが。。。しかし、、、
自分で編集したファイルも上書きされてしまい、カスタマイズも無かったことにされてしまいます。

子テーマはそれを防いでくれる良い方法なのです。
子テーマがすべてを防いでくれるわけではありませんが、初心者レベルのカスタマイズなら問題ないでしょう。

子テーマ設置方法

子テーマ設置場所

子テーマを作成する最初の行程は、子テーマディレクトリの作成です。
wp-content/themes ディレクトリ下に作成します。
子テーマディレクトリの名前には最後に ‘-child’ を付けることが推奨されます。

今回は、「twentyeleven-child」という名前のディレクトリを「wp-content/themes」ディレクトリに作ります。
作り方は、FTPアプリやレンタルサーバのファイル管理アプリで作ります。
※子テーマディレクトリの名前には空白を含めないでください。エラーが発生します。

子テーマ設置必須ファイル

子テーマは、2つのファイル「style.css」と「functions.php」を作成する必要があります。

まずは、「style.css」から作ります。

/*
 Theme Name:   Twenty ElevenChild
 Template:     twentyeleven
*/

Theme Name:Twenty ElevenChild
テーマの名称。全角可。ここに書いた名称が管理画面のテーマ選択画面に表示される。
Template:twentyeleven
親テーマのディレクトリ名。大文字小文字を区別するのできっち書くこと。
※全角文字を入れたときにはエディタの文字コードを UTF-8 にする必要があります。

次に、「functions.php」を作ります。
以前は「style.css」の中で @import: を使用して親テーマのスタイルシートをインポートしていましたが、これはもはや良い方法ではないそうです。
親テーマのスタイルシートを反映させる正しい方法は、子テーマの functions.php で wp_enqueue_script()を使用する方法です。
したがって子テーマには functions.php を作成する必要があります。

私も初心者なので理解できないこともありますが、言われたとおりに作っておきます。

<?php
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );

}
?>

普通はこれで親のスタイルシート(「style.css」)を読み込んだ後に、子テーマのスタイルシート(「style.css」)を読み込み上書きされることになります。
しかし、なぜかうまく子テーマのスタイルシート(「style.css」)が読み込まれないパターンがあるそうです。
その際は、下のようにすると良いらしいです。

<?php
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array('parent-style')
    );
}
?>

各々ファイルを保存したら、先ほど作った子テーマディレクトリへファイルをアップロードします。
と言うか、どんな方法でも良いので、先ほど作った子テーマディレクトリに2つのファイルを置ければOKです。
なお、エディタの文字コードを UTF-8 で保存しましょう。

子テーマの有効化

正常にアップロード出来たら、子テーマを有効化できる準備ができました。
サイトの管理画面にログインし、管理画面 > 外観 > テーマに移動してください。
子テーマが表示され、有効化できる状態になっています。

なお、 子テーマを有効化したあとは、メニュー (外観 > メニュー または 外観 > カスタマイズ > メニュー) およびテーマのオプション (背景やヘッダイメージ) を保存し直す必要があります。
今まで触って居なければそのままでもOKです。

WordPress 4.7.3 セキュリティリリース

WordPress 4.7.3 セキュリティリリース

2017年3月6日、WordPress 4.7.3 が公開されました。

主な変更点

WordPress 4.7.2 およびそれ以前のバージョンは6件のセキュリティ問題の影響を受けます。
これは過去のすべてのバージョンのためのセキュリティリリースですので今すぐサイトを更新するようにしましょう。

参照先:『WordPress Codex 日本語版』

WordPress リビジョン管理 プラグイン

WordPress リビジョン管理

今回はWordPressの便利情報、 WordPress リビジョン管理 プラグインを紹介します。
WordPressにはデフォルトで過去の記事を履歴として残す リビジョン管理 機能があります。
2017/8/10 追記しました。追記にあるように 簡易な管理 なら追記の方法で十分でした。
修正前のものをきちんと残しておきたい場合は、追記の方法ではできません。プラグインで管理してあげる必要があります。

リビジョンとは

WordPress の記事を書いていると、下の方にリビジョンが表示されていることに気付きますよね?
記事をある タイミング で保存し、後から見たときにいつの時点でどのような 変更 や修正 を掛けたかを 確認する機能 です。

WordPress リビジョン管理

WordPress リビジョン管理


上のように、いつも知らないうちに溜まってます。
30個くらい溜まってたこともありました^^;

そもそもリビジョンとは、修正作業等の変更を表す改訂番号のことです。例えば誤字脱字の修正を行ったときにリビジョンの値を上げて記事をリリースします、でリリースした記事がいつリリースされたか? どのように修正されたか?などを(古い記事を保存じて)確認できるようにしているデータです。
先ほども書きましたが、 WordPress も デフォルト でリビジョン管理機能を持っています。

WordPressのリビジョン管理とは

WordPressのリビジョン管理は、以下のような時にリビジョンを作るようです。
・下書き保存をした時
・下書き中の記事を変更してプレビューした時
・記事を公開した時
・公開した記事を変更し、最初に「自動下書き保存」した時
・公開した記事の変更をプレビューした時
・公開した記事を更新した時
・ゴミ箱に記事を移動した時
・ゴミ箱から記事を戻した時

これらの操作でほぼ自動でリビジョンが作成され管理されています。
ちなみに、 WordPress には リビジョン を 比較する機能 や 復元する機能 も付いています。
私はこの機能を「へぇ~」って思って見たいただけで、実はほぼなにも使っていません。

これだけ細かく管理する必要があるのかは個人の見解に依るでしょうが、個人的なブログであれば必要ないと思います。
商売でやってる人には履歴はあった方が良いのでしょうが。
私のような人も多いのでは。。。と。

リビジョン管理の問題点

問題点と言うほどの問題点も実は無いのですが。。。
・データベースのデータ量が少し増える、それに合わせて少し重くなる。
・パーマリンクの番号が増える。
・下にだらだらリビジョンが有ってなにこれ?ってなる。

私はリビジョン管理を見るたびに、不要なデータは要らないから作らない方が良いのではと思ったり、まぁ、作っても良いけどだらだら表示しない程度にデータ量を少なくしてって感じたり、そんな感じで少しだけ気を取られてその後は忘れてしまってます。

最初に気になったころ、phpに手を入れてリビジョンそのものを作らないようにすることも可能だと思い、その方法もググってみたりしました。結局は、php改修は大変そうだし、そこまでやらなくても良いかなって思い放置していました。

追記:2017/8/10
難しい改修をしなくても wp-config.php のみで少し制御できることがわかりました。

■ そもそも保存しない
そもそも保存をしないようにするには、下の一文
define(‘WP_POST_REVISIONS’, false);
を、最下行の require_once(ABSPATH . ‘wp-settings.php’); より前に入れてあげればOKです。
下のように記述すればOKです。

if ( !defined(‘ABSPATH’) )
define(‘ABSPATH’, dirname(__FILE__) . ‘/’);

define(‘WP_POST_REVISIONS’, false);

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . ‘wp-settings.php’);

■ 保存数を制限
作成されるリビジョンの数を制限するには、下の一文
define( ‘WP_POST_REVISIONS’, X );
を、最下行の require_once(ABSPATH . ‘wp-settings.php’); より前に入れてあげれば OK です。
X は数字で保存数を指定します。3 つ分保存ならを 3 指定します。
指定した数だけ保存され、古いものは自動的に削除されていきます。
下のように記述すれば 3 つ分保存されます。

if ( !defined(‘ABSPATH’) )
define(‘ABSPATH’, dirname(__FILE__) . ‘/’);

define(‘WP_POST_REVISIONS’, 3);

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . ‘wp-settings.php’);

このやり方だと、直近 3 つ分しか残りませんが、私個人はプラグインを利用しても細かな制御をしないのでそんなに変わらないかと思います。このやり方でいいかな^^;
とりあえず試しに直近 3 つ分しか残こらないように実行してみますね。
(結果)
いとも簡単にできてしまいました。
プラグインよりお手軽便利です^^
プラグインアンインストールしちゃおうかな^^
そうしますね^^;
–追記終わり

有るとき不意に、プラグイン の存在を思い出し、ググってみました。

リビジョン管理 プラグイン を導入する

で、やっと本題の WordPress リビジョン管理 プラグイン です。

リビジョン管理を全くしないわけでなく、今まで通り自動で作くり、古いリビジョンから消していくという折衷案で、プラグインを導入してしまうのが良いのかと。
サクッと調べてみると下の3つが有名な プラグイン でした。私も一部使ってみました。

Optimize Database after Deleting Revisions 設定英語、リビジョンの保存数を自由に設定できる。
Revision Control 日本語設定、リビジョンの保存数を自由に設定できる。
Better Delete Revision 英語設定、記事の古いリビジョンを一括削除してデータベース容量を減らせる。

個人的に「Optimize Database after Deleting Revisions」と「Revision Control」を別々の二つのサイトで使っていますが、どっちもどっちの感想です。特にこちらが使いやすいとかもなく。
日本語の設定で簡単にできる「Revision Control」の方が楽なような気もしますが、「Optimize Database after Deleting Revisions」の方が細かく設定出来るので良いと思い人もいるかも。

インストール方法 や 管理の仕方 を細かく教えてくれているサイトもあるので、「Optimize Database after Deleting Revisions」と「Revision Control」を検索して好みの方を利用してみてください。

参照先:『WordPress Codex 日本語版 リビジョン管理』
以上、「 WordPress リビジョン管理 」プラグインの紹介でした。

WordPress メンテナンスモードを解除する

WordPress メンテナンス 困ったとき

WordPress メンテナンスモードを解除する 方法の紹介です。
更新が上手く行かずにこの画面が出ると焦りますね^^;

WordPress メンテナンスモードを解除する

WordPress 本体やテーマやプラグインをアップデートしている間、WordPress はメンテナンスモードになり、普通にサイトにアクセスできなくなります。
アクセスしてきた人は、メンテナンス画面を見ることになります。
普通は各アップデートが完了すればメンテナンスモードが自動的に解除され、すぐにサイトにアクセスできるようになります。

ただ、アップデート中にアップデートが失敗するとメンテンナンスモードが解除されず、WordPressサイトにアクセスできなくなってしまいます。
もちろん、アップデートの指示までもできなくなっていまいます。
そのような場合 メンテナンスモード 状態を解除する必要があります。
解除後、原因を取り除き、アップデートを完了させることになります。

メンテナンスモードとは

WordPress 本体のアップグレードやプラグインの更新を行っている時、WordPress は自動的にメンテナンスモードに切り替わり、アクセスしてきた人は、メンテナンス画面を見ることになります。
表示に必要なプログラムやデータを修正している最中にアクセスされてもエラーを返すことになるので、更新中はメンテナンス画面を見せる仕組みになっています。
この状態のことをメンテナンスモードと呼んでいます。

WordPress メンテナンスモードを解除する 現在メンテナンス中

現在メンテナンス中

その他、プラグインを使ったり、phpを書き換えてメンテナンスモード風にする方法も有りますが、ここではWordPress 本来のメンテナンスの挙動のみを考えています。

メンテナンスモードを解除するとは?

本来メンテナンスモードは、WordPressの機能の一つで自動化されています。
自らメンテナンスモードになり、完了するとメンテナンスモードを解除しています。
なので手動で解除する必要は本来はないのですが、たまにメンテナンスモードになりっぱなしの時が有るようです。

メンテナンスモードになるには、いくつかの条件があるとも聞きますが、確かなのは「.maintenance」ファイルが存在しているということです。
なので正常にアップデートが終了したにも関わらず、メンテナンス画面が表示されるときは、「.maintenance」ファイルを削除することで解除されます。

メンテナンスモードを解除する方法

「.maintenance」ファイルを削除することで解除されます。
「.maintenance」ファイルはWordPress のインストールディレクトリ直下にあります。
FTPでアクセスして削除してもいいですし、レンタルサーバのファイル管理機能で削除しても構いません。
何らかの方法で削除してあげれば、メンテナンスモードも解除されます。

プラグインをいくつも同時に(違う画面で同時にとか)アップデートしたりするとメンテナンスモードになってしまうことが多いそうです。
私はプラグインの更新ではなったことがないので、話を聞いただけですが。
そのような場合は、プラグインごと削除しないとダメな時があるようです。
やり方は、該当のプラグイン フォルダ( wp-content/plugins/xxxxx)探して削除します。
アクセス方法はFTPでアクセスして削除してもいいですし、レンタルサーバのファイル管理機能で削除しても構いません。
その後、もう一度削除したプラグインを新規でインストールします。

以上、「WordPress メンテナンスモードを解除する」でした。

WordPress 「現在メンテナンス中のため、しばらくの間ご利用いただけません」が出たら?

WordPress メンテナンス 困ったとき

「現在メンテナンス中のため、しばらくの間ご利用いただけません」が出たら?

WordPressの本体やプラグインの新しいバージョンへのアップグレードの時にこのメッセージが表示されるようになっています。

WordPressの更新は、だいたい以下の手順になっています。
1)目的のファイルのダウンロード(Zip形式)
2)ファイルの展開
3)古いファイルと新しいファイルを置き換える。「.maintenance」ファイルを作成し、メンテナンス中のアナウンスをする。

で、3)番の古いファイルと新しいファイルを置き換える作業の時にアクセスされるとエラーで落ちる可能性があるため、この「現在メンテナンス中のため、しばらくの間ご利用いただけません」を無条件で表示するようになっています。

どういうときに表示される?

まずは、更新中にアクセスされると表示されます。でも、この場合は表示されるのが正常で、問題ないですね。

次に、何らかの原因で更新途中に失敗した場合。これはファイルが新旧混ざっている場合や失われている場合、壊れてしまっている場合とかいろいろ想定出来て、アクセスされるとエラーで落ちる可能性があるため、表示された方が助かります。早急にケースバイケースで対応してあげる必要があります。

次に、正常に更新が終わってるのに、この「現在メンテナンス中のため、しばらくの間ご利用いただけません」が表示される場合。これは、何らかの原因で「.maintenance」ファイルが削除できなかった場合に表示されます。

対処法は?

上の更新そのものに失敗した場合は、更新を正常に終了させるか、プラグインならプラグインを削除してしまうか、何らかの対応を行う必要があります。その後に次の作業を行います。

で、正常に更新が終わってるのに表示される場合は、先ほどの「.maintenance」ファイルを手動で削除してあげる必要があります。
「.maintenance」ファイルはWordPress のインストールディレクトリ直下にあります。
FTPでアクセスして削除してもいいですし、レンタルサーバのファイル管理機能で削除しても構いません。
何らかの方法で削除してあげれば、WordPressが普通に動作します。

なぜ起こる?

正常に更新が終了したら自動で削除されるはずなのになぜ起きる?
不思議ですが、起きているケースがあるそうです。
傾向として複数のプラグインを一気にアップデートする時によく起こるようですので、一つ一つ確認しながら更新するのが良いと思われます。

以上、WordPress 「現在メンテナンス中のため、しばらくの間ご利用いただけません」が出たら?でした。

「WordPressを更新中です 別の更新が現在進行中です。」の表示が出たら?

WordPress

WordPressを更新中です 別の更新が現在進行中です

WordPress別の更新が現在進行中です


更新ボタンを押したら「WordPressを更新中です 別の更新が現在進行中です。」の表示が?なんで?

WordPressを更新するとインストールディレクトリに「.maintenance」ファイルが自動生成され、正常に完了するとは自動で削除されます。
何らかの形で失敗すると、「.maintenance」ファイルが残されたままになり、「現在メンテナンス中のため、しばらくの間ご利用いただけません」などの画面が表示されます。
それは、WordPressを更新中にサイトへアクセスした方へのメッセージとして表示されるものです。

今回はそうではなく、「WordPressを更新中です 別の更新が現在進行中です。」が表示されるケースです。

どんな時に表示されるの?

これはどうやら、メンテナンスモードに入る前の処理で止まってしまった時に発生するようです。

WordPressの更新は最初にzip形式の新しいバージョンのファイルをダウンロードします。
それを展開して古いファイルと新しいファイルの置き換える処理をします。
通常のメンテナンスモードは、古いファイルと新しいファイルの置き換え中にアクセスされるエラーで落ちてしまうため、メンテナンス作業中であることをアクセスしてきたユーザに知らせるように「.maintenance」ファイル作成し「現在メンテナンス中のため、しばらくの間ご利用いただけません」画面を表示します。

今回は、
・ダウンロードに失敗した
・展開に時間が掛かった
・展開に失敗した
場合に発生するようです。
この表示が出る前に、エラー表示出るか、妙に時間が掛かるなどの兆候があったはずです。

私の場合は、止まって動かなくなってしまいました。

WordPress別の更新が展開中に止まってる?

WordPress別の更新が展開中に止まってる?


2回も止まって、3回目に更新成功しました。。。サーバーが混んでたのかな?
海外の IX Web Hosting を使ってます。

対象方法は?

対処方法は2つあるようです。
1つは、15分以上放置すれば、解除されるそうです。

もう1つは、MySQLのwp_options テーブルに格納されているoption_name が 「core_updater.lock」のレコードを削除することらしいです。
SQLは、「delete from wp_options where option_name = ‘core_updater.lock’;」です。

特に急ぎでなければ、15分までは解除されるようなので15分待ちましょう。
以上、「WordPressを更新中です 別の更新が現在進行中です。」の表示が出たら?でした。

WordPressに必須のデータベースとは?

WordPressのデータベースとは?

WordPressはデータベースにデータを保存しています。そしてWebサイトに表示する際は、データベースに保存したデータを取り出し、適宜加工してホームや記事、記事一覧を表示しています。
ちなみに、管理画面で設定した項目や作成した記事内容などの入力データは、全て「データベース」に保存されます。この記事では、WordPressのデータベースについて少しご紹介します。

WordPressを使うにはデータベースが必要

WordPressを使うにはデータベースが必要です。そしてデータベースは、サイト管理者自身が用意・管理しなければなりません。
しかし、心配する必要は有りません。
なぜなら、ほとんどのレンタルサーバに既に用意されていますから。

データベースを用意する

ここをお読みの方は「レンタルサーバー」や「ホスティングサーバー」を借りているかもしくは借りる予定の方だと思います。
WordPressの自動インストールを行ってもらえるサービスが提供されているところも多いですし、データベースを設定することも難しくありません。

WordPressのデータベースはMySQL

WordPressのデータベースは基本的に「MySQL」と言う名称のデータベースです。
他に「MariaDB」と言うデータベースも使えるようですが、私はまだ見たことが有りません。

WordPress 日本語版の推奨動作環境

MySQL バージョン 5.6 以上 または MariaDB バージョン 10.0 以上です。
「古い PHP や MySQL しか利用できないレガシーな環境でも、PHP 5.2.4 以上、かつ MySQL 5.0 以上であれば WordPress は動作しますが、公式サポートは終了しており、サイトがセキュリティの脆弱性にさらされる危険があります。」と有りますので、可能な限り上の推奨動作環境をクリアしているレンタルサーバを選びましょう。
また、使用するプラグインにも推奨動作環境が有るかもしれませんので、インストールする前に利用予定のプラグインやテーマの動作要件をご確認しておきましょう。
ちなみに、私の利用している「IX Web Hosting」レンタルサーバは5.1.68なので、推奨動作対象外です( ノД`)シクシク…

データベースの管理とは?

特に何かをする必要は有りません。
WordPressのバージョンアップに伴うデータベースの更新も自動で行ってもらえるので、あまり心配する必要は有りません。
「WordPress データベースの更新が必要です」のようにデータベースの更新を行う旨の表示がされ、更新が実行されます。
インストールしているプラグインによって、データベースの更新に失敗することも有るようですので、注意するか対応できるようにスキルを上げるようにしましょう。
その他、高度なカスタマイズをしたりする場合は、データベースにも手を加えることも有るようですが先の話ですね。

データベースに保存されるものは?

WordPressをインストールすると、データベースにはデータを保存するための「テーブル」が自動的に作成されます。
そのテーブル内に管理画面で設定した項目や作成した記事内容などの入力データが全て「データベース」に保存されます。

テーブルとその保存対象

WordPress をインストールしたときに作成されるテーブルと、そのテーブルに保管される内容は以下の通りです。

テーブル名 説明
wp_commentmeta コメントにはメタデータと呼ばれる情報があり、wp_commentmetaに格納されている。
wp_comments WordPress へのコメント・トラックバック・ピンバックデータを格納
wp_links リンク作成で入力されたリンク情報を格納。(この機能は非推奨になりましたが、Links Manager プラグインで有効化できます)
wp_options 管理 > 設定で設定されたオプション設定情報を格納(オプション設定リファレンス参照)。プラグインの設定情報が格納されることも多い。
wp_postmeta メタデータという各投稿記事特有の情報を格納。カスタムフィールドとして使用するほか、各投稿に情報や設定を付加するようなプラグインが、その情報を当テーブルに追加することがある。
wp_posts WordPress データの核である投稿記事のほか、ページ、ナビゲーションメニューのデータを格納
wp_terms 投稿およびリンクの分類(カテゴリ・タグ)に使われる語句の基本情報を格納
wp_term_relationships オブジェクト(wp_posts テーブルの各投稿記事wp_links テーブル内の各リンク)と wp_term_taxonomy の(少なくとも 1)カテゴリ・タグとの関連付け情報を格納
wp_term_taxonomy 投稿およびリンクの分類上の語句(カテゴリ・タグ)データを格納
wp_usermeta 各ユーザ特有のユーザ・メタデータを格納
wp_users 登録ユーザ情報を格納

詳しく知りたい場合は、「WordPress Codex 日本語版」のデータベース構造を参照してください。