ピンバックとは、記事に中に参考にしたページのURLを記載することによって、WordPressが自動的に記事中にURLが無いか探し、見つけた場合に参考にしたURLに知らせるシステムです。
トラックバックととてもよく似たシステムです。
トラックバックは参考にしたURLに自分で手動で通知しますがしますが、ピンバックは自動でURLを発見し通知する点に違いがあります。
また、ピンバックはXML-RPCとトラックバックはHTTP POSTとプロトコルを採用しています。トラックバックでセキュリティホールが有ったってことも有りましたよね。
ピンバックを有効にするか無効するかは、ダッシュボード＞設定＞ディスカッションの中の投稿のデフォルト設定で設定が出来ます。
設定箇所を読めば設定はわかりますよね？
ちなみに私はどちらも有効にしています。
でも、Akismetはしっかり入れてます。皆さんもスパム対策しっかりとしてくださいね。
WordPress を始めると「どのテーマを使おうか」って少し悩みますよね。
WordPressにはテーマというものが有りますがどんなものなのでしょう？
外観に特化したプラグインのようなものなのかな？
機能的には、テーマを選択することで、作成したWebサイトの見た目のデザインをテーマに沿って簡単に変えることができます。
また、固定ページにマッチしたテーマを使うことで、一般的なブログ形式ではなくホームページ形式外観にすることもできるようです。
テーマってなかなか奥が深そうですね。もう少し掘り下げてテーマをみたいと思います。
テーマとは、作成したサイトの見た目のデザインを決めるファイルの集まりです。
小難しく言うと、「テーマはWordPressで構築されたWebサイトの外観を制御するモジュールです」です。
一般的なブログで「スキン」や「テンプレート」と呼ばれるものにプログラムによる振る舞いを追加した機能のこととも言えます。
テーマは、サイトのレイアウトを作るテンプレートファイルや表示内容を動的に作り出す処理ファイルで構成されています。それらのファイルによってテーマは独自のデザインと振る舞いで個性を出しています。
テーマは、WordPressの他のデータから分離された表示用のプログラムとリソースの集合体で、WordPressの管理画面から使用するテーマを簡単にインストールしたり、更新したり、削除したり、切り替えたりすることができます。
WordPressのテーマは、多くの個人や企業から提供されています。テーマを選ぶ重要な指標はデザイン性です。しかし一方、誰が作ったのか？安心して使えるのか？などセキュリティ面も考慮する必要が有ります。
また、如何にテーマの数が多いとは言え、作成したサイトのイメージに100％合致するテーマは無いと思った方が良いです。テーマは手を加え自分の好みや必要な機能を追加して作りこんでいく「カスタマイズ」するものと考える必要も有ります。
テーマは進んだシステムです。
(※プライバシー・ポリシーWordPress Codex 日本語版から)
こんなに進んだテーマなら、そのまま使っても問題がなさそうですが、、、どうでしょうか？
もちろん素テーマのまま使っても良いのですが、使ってくるうちに装飾が物足りなくなったと言う話も聞きますし、検索順位を上げたいので手を加えたいとか、だんだんと自分の思い浮かべたイメージに沿ったWebサイト（ブログサイト）を作りたくなります。
その結果テーマを少しカスタマイズしたいと思い始めることが多いです。
テーマはあくまでもテンプレートとしての位置づけですので、自分のイメージ沿ったWebサイト（ブログサイト）にするために、そして他のWebサイト（ブログサイト）との差別化のために、プラグインをインストールして手を加えたりする他、CSSやプログラムに手を加えて行くことになります。
今回はテーマについて概要を調査し纏めただけですが、テーマはカスタマイズできるので、いろいろ試して行きたいと思っています。
試したらまた記事にして報告したいと思います。
Webサイト（ブログサイト）を始めると、検索順位が上がるにつれてスパムコメントが増えてくるそうです。（上がらなくても増える？）そんな時に役に立つのがプラグイン「Akismet」です。
Akismetとは、コメントやトラックバックの内容をサーバーでチェックして、スパムコメントだったら除外してくれるサービスです。私のWordPress4.2.2では標準でついてきていました。標準で付いてくるほどですから、使っておいた方が良いと思います。
先ほど見たら、「新しいバージョンの Akismet が利用可能です。バージョン 3.1.2 の詳細を見るか今すぐ更新します。」と出ていたので早速、更新しました。
Akismetを使うには、
1) Akismetの「有効化」リンクをクリック
2) サインアップして Akismet API キーを取得
3) Akismet の設定ページに移動して API キーを保存
の3つを行います。
ダッシュボード＞プラグイン＞インストール済のプラグイン
「有効化」をクリック
ちょっとだけ。と言っても２分もかからないくらいで取得できます。
「サインアップして Akismet API キーを取得」をクリック
下の画面（そのうち変わると思いますが。。。）が立ち上がります。
「GET AN AKISMET API KEY」をクリック
下の画面（そのうち変わると思いますが。。。）が立ち上がります。
これはどうやら、WordPress.comへのサインアップも兼ねているようです。
それぞれを入力して「Sign up」をクリック
Sign upすると、すぐにメールでアカウントを有効化しろと案内が来るのですが、しなくても大丈夫そうです。WordPress.comに興味のある方は。。。有効化すると、どうなるんだろう？
「I already have a WordPress.com account」をクリックするとどうなるんだろう？やって無いのでわかりません。
「Sign up」をクリックすると、下の画面（そのうち変わると思いますが。。。）が立ち上がります。
要件が有るようです。月に50,000件もチェックは要らないので、Basicで。
SIGN UPをクリックすると、下の画面（そのうち変わると思いますが。。。）が立ち上がります。
赤丸で囲ったスライドバーを左へ移動して、$0.00/yrにする。
あっ、もちろん気持ちですから援助は大歓迎だと思います。
スライドして0にすると、下の画面（そのうち変わると思いますが。。。）になります。
それぞれ記入して「CONTINUE」をクリック
CONTINUEをクリックすると、下の画面（そのうち変わると思いますが。。。）になります。
Akismet API キーが表示されます。
メールも合わせてくるので、とりあえずコピペするために、コピーだけしておきましょう。
Akismet API キーが貰えたので、再度自分のWordPressに戻ります。
あっ、Akismetの設定をクリックする画像を取り忘れました。。。わかりますよね？
先ほどの有効化したのと同じところに、設定と停止が有ると思います。その設定をクリックします。
下のような画面になります。
先ほど取得したAkismet APIキーを入力してください。
もし忘れたりしてたら、メールが来ているのでそこからもらってきてください。
「変更を保存」をクリックします。
下のような画面が表示されて設定終了です。
これであなたのWebサイト（ブログサイト）はスパムから守られました。もし、超人気が出て一月に50,000件を超えるようになったら、Basicから上にアップグレードしましょう。
そうなると良いですね＾＾
googleにインデックスして貰えてますか？
一番簡単で確実な方法は「Fetch as google」でGoogleにWebサイトを読込ませインデックスにURLを送信する事ですが、サイトマップをGoogleに送って、漏れなくインデックスして貰うように依頼する方法も有ります。
今回はサイトマップを自動で作成してくれるプラグインをインストールしてみましたので、その報告です。
「サイトマップとは、サイトのウェブページを指定して、Google や他の検索エンジンにサイトのコンテンツの構成を伝えるファイルです。 Googlebot などの検索エンジンのウェブクローラは、このファイルを読み込んで、より高度なクロールを行います。 サイトのページが適切にリンクされていれば、通常 Google のウェブクローラはサイトのほとんどのページを検出できます。 それでも、特にサイトが次のいずれかの条件に該当する場合には、サイトのクロールを改善する手段としてサイトマップが役立ちます。」
とSearch Console ヘルプに書かれていますので、引用します。
今回はこのサイトマップを自動作成してくれる「Google XML Sitemaps」というプラグインを試しにインストールして使ってみました。
Google XML Sitemapsとは、xml形式のサイトマップを自動作成するプラグインで、記事を公開または更新するたびに、自動的にgoogleにサイトマップ更新を通知してくれます。
Google XML Sitemapsは100万以上件のインストールおよび有効化済みのプラグインでWordPress4.2.2と互換性がありまますので、安心して使用できると思います。
ただ、２０１５年６月４日現在で不具合が残っている可能性が有ります。記事の投稿や更新をしてGoogleに通知をしても保留となり反映されないそうです。これが必ず発生するのか少し時間を置けば処理されるのか詳しい情報は探せませんでしたが、そのうち修正版が出るだろう的に楽観視して導入します。
ダッシュボード＞プラグイン＞新規追加から「プラグインを追加」画面を表示する。
その後、検索文字列に「Google XML Sitemaps」と入力し検索を行う。
「今すぐインストール」をクリックする。
しばらくすると以下の画面に変わる。
「プラグインを有効化」をクリックする。
上の「プラグインを有効化」をクリックするとインストール済のプラグイン一覧画面に切り替わる。
Google XML Sitemapsの設定を行うために真ん中あたりに有る「設定」をクリックする。
もしくはダッシュボード＞設定＞XML-Sitemapsをクリックする。
XML Sitemap Generator for WordPress 4.0.8の設定画面が表示される。（バージョンは今後は変わると思うので、あくまでも参考まで。。。）
この段階ではまだ検索エンジンに通知していないようです。
尚、サイトマップのURLは下のとおり。覚えておきましょう。
http://貴方のWebサイト（ブログサイト）URL/index.php?xml_sitemap=params=
設定ですが私は投稿の優先順位のみ変更しました。デフォルトは「コメント数」だったのですがそんなにコメントが発生しないと思い、「優先順位を自動的に計算しない」に変更しました。
後はデフォルトのままです。より詳しく解説してくれるWebサイト（ブログサイト）も有ると思いますのでググってみてください。ただ、それ程神経質になることはないと私は考えています。
設定を変えたら一番下の「設定を更新」ボタンをクリックします。
これでGoogle XML Sitemapsの設定は終了です。
後は記事を新規で追加するか更新するかでGoogleに通知されます。
とりあえず、この記事を投稿してみます。
Google XML Sitemapsに変化が有りました。
正しく通知されたようです。
ウェブマスターツールでサイトマップの確認をしてみます。
通知するだけではダメなようですね。
先ほどのXMLサイトマップのURLをGoogleに「サイトマップの追加／テスト」ボタンをクリックして送り込んでみます。URLは「index.php?xml_sitemap=params=」の部分をコピーして貼り付ければOKのようです。
「サイトマップを送信」をクリックすると、以下の表示に変わりました。
「ページを更新する」をクリックすると、
上手くサイトマップが送れたようです。
サイトマップが保留のまま放置されるという現象は未確認なので、発生したらまた書きたいと思います。
サイトマップが保留のまま放置されるという現象はどうやら、3.0系から4.0系に変わった人達の旧サイトマップの設定がそのまま残っていたり、勘違いだと思います。
Google側は単にサイトマップが更新されたと通知を受けて処理するだけなので、どんな仕組みを使用していようが処理的には同じはずなので。ちなみに確かに一時保留になりますが、しばらくすると処理されていることを何回も確認できました。
もしろ、今回発生している不具合の方が厄介です。
記事を投稿したり更新しても、サイトマップ自体に反映されない。反映されないので、Google側は以前のままのサイトマップを見て処理をしてしまっています。
最悪です。
この不具合の確認は「Google XML Sitemapsでサイトマップが更新されない」で。
WordPressにおけるプラグインとは、WordPressの機能を拡張するためのツールです。プラグインを利用することでWordPressを自分の思うようなWebサイト（ブログサイト）に仕上げることが可能です。
プラグインは多岐に渡ってWordPressを支えてくれています。例えば、WordPressを使っているといろいろな問題に直面します。スパムコメントをどうにかしてほしい。HTMLやCSSのコードを書きたい。サイトマップを自動で作って欲しい。。。etcetc…また、Webサイト（ブログサイト）の外観やイメージを決めるテーマもプラグインの一つです。
プラグインとは、サクッとプログラム出来る人達や企業が一般の人たちの為に、いろいろな機能を提供してくれる素晴らしい機能もしくはそのプログラムのことです。
プラグインはWordPressの設計思想が形となったものです。WordPress のコアは堅牢性と保全性を保つために、どうしても必要なコア機能以外は外付けで組み込むようにしているようです。そのために簡単に機能拡張ができるように設計されています。
ユーザーはそれぞれのニーズに合ったプラグインを利用してカスタム機能を取り入れることで、WordPressをより使いやすものとして利用できるようになります。
ここでは、プラグインの検索方法とインストール方法を取り扱いません。プラグインの検索方法やインストール方法はいろいろなWebサイトで紹介されているのでググって検索してください。
プラグインを使う際は少なくとも２つの注意点が有ります。
・単純に「ヤバいプラグイン」かもしれないこと。
・このプラグインって「古い（新しい）プラグイン」だけど大丈夫？
の２つです。
これはもう説明の必要もない注意点ですよね。
プラグインをインストールする際は、全て自己責任です。全く知らない他人の作ったプラグインです。公式サイトで配布されているのならまだしも、野良プラグインはなにが潜んでいるかわかりませんから気を付けましょう。
また、公式で配布されていても内部エラーが発生したり、その機能が動くと極端に重くなったりするケースも考えられます。インストール件数が極端に少ないなど実績の少ないプラグイン場合などは、テストWebサイト（ブログサイト）でテストしてから本番へ適用するなどしましょう。
どんなコードが書き込まれてるかわからない。犯罪の土台にされるかも。データが改ざん・消去されるかも。。。怖くて使えません。
⇒インストールするのを諦めましょう。
よさそうなテーマだったので入れてみたら、内部エラー「500」が発生しWebサイト（ブログサイト）自体が動かなくなった！どうやったら、プラグインを削除できるの？？
⇒テストWebサイト（ブログサイト）でテストしてから本番へ
プラグイン入れたらあるページだけ途端に重たくなって動きが悪いんだけど。。。なにが悪いの？
⇒テストWebサイト（ブログサイト）でテストしてから本番へ
プラグインにも要件が有ります。PHPやMySQLの対応バージョンに注意が必要です。また、セキュリティ面でも注意が必要です。
逆に新しすぎてレンタルサーバのPHPやMySQLが対応バージョン未満ってケースもままあります。
古いプラグインの場合、昔見つかったセキュリティホールがそのまま放置されたまま提供されている可能性が有ります。
数年まえから更新されていないようなプラグインにこの危険性が有ります。
⇒何年も更新されていないようなら、同機能の新しいものを探しましょう
現在使用しているレンタルサーバのPHPやMySQLのバージョンが使用しようとしているプラグインに合致しているかが問題になります。PHPやMySQLは下位互換が高いと言えますが、それでも下位互換性のない変更点が幾つか有ります。
レンタルサーバのPHPやMySQLのバージョンが高い場合、下位互換性のない機能や関数等が使われていると動かない可能性が高いです。
逆に新しすぎるプラグインの場合、現バージョンでサポートしていない機能や関数が使われていると動かないです。
⇒バージョンの要件が合うか事前に確認しましょう
プラグインはとても使い勝手の良い機能ですが、全てOKと言うわけではないので注意しましょう。特に入れたけどWebサイト（ブログサイト）が立ち上がらないなどとならないように細心の注意が必要です。
「WordPressでブログ」の運用レンタルサーバをInfinitoPlusからExpressWebへ移行中です。先回は「wp_config.phpのプレフィックスとデータベース接続情報を変更」作業を実施して、新しい稼働先レンタルサーバExpressWebのデータベースへ接続できるようにwp_config.phpファイルのデータベースへ接続情報の編集を実施しました。
今回は次の3つの作業「新レンタルサーバにFTPで全ファイルアップロード」「稼働テスト」「DNSの切り替え」をまとめて実施します。
今回、稼働テストに関して考慮が足らず、テストができませんでした。この作業は反省点について書きたいと思っています。
各々の具体的な作業は、ほぼタイトル通りで余り説明しなくても大丈夫かと思います。ただ注意点も有るため個別の作業内容の説明の中で報告していきたいと思います。
まずは新レンタルサーバのExpressWebにWebサイト（ブログサイト）「wordpress.bia.jp」を作ります。
次に「wordpress.bia.jp」のホームフォルダにFTPを使ってバックアップしたWordPressのファイルを全ファイルアップロードします。
この作業は「現レンタルサーバからFTPで関係ファイルを全部ダウンロード」の逆の作業です。WordPressのファイルのアップロード先のフォルダを間違えないようにしてください。
各レンタルサーバによって異なるので、実際は各レンタルサーバのマニュアルを見てください。
ExpressWebの場合は、Webサイトの作成方法を参照してください。
その際、DNSの管理を有効にするかしないかという問題が発生します。DNSの管理をExpressWebに任せる場合は有効にして、その後、ドメイン管理会社でネームサーバの変更手続き等をする必要が有ります。
DNSの管理をよそのサーバで行う場合は、有効にしないを設定しWebサイトの登録はそのよそのDNS管理サーバで行います。
この辺りはDNSの切り替えに関係してきますので、良く理解しておく必要が有ります。
①FTPクライアントを立ち上げ、新サーバに接続します。
②FTPクライアントのローカルフォルダをバックアップをコピーしてwp_config.phpファイルを修正したフォルダに変更します。
③FTPクライアントのサーバフォルダをホームフォルダに変更します。
④全ファイルアップロードします。
ここで注意点が有ります。
必要に応じてファイルやフォルダにWordPressから変更・追加・削除が可能なようにアクセス権の付与を与えることです。例えば、「メディアを追加」をした時に、保存されるフォルダにアクセス権を付与していないとイメージファイルをフォルダに追加できないのでメディア追加を失敗することになります。また、外観の変更などでstyle.cssに対するアクセス権を与えていないとWordPress上から編集できません。
私の場合は、とりあえずイメージファイルを張ることも有るので、メディアを追加できないと困るので、保存されるフォルダにアクセス権を与えておきました。メディアを追加で使用するフォルダは「/wp-content/uploads」です。このフォルダの下に年、月が追加されて保存されていました。2015年6月に保存すると「/wp-content/uploads/2015/06」に保存されます。
なので、「/wp-content/uploads」フォルダの配下のフォルダも含め、変更可というアクセス権を付与しました。
アクセス権の付与方法はレンタルサーバのマニュアルで確認してください。
その他、style.cssを始めとしてWordPress上から編集する場合も有ります。その場合はそのファイルのアクセス権も付与しておくことが必要です。この場合は、WordPressの外観＞テーマの編集でファイルを選択すると、下の方に保存ボタンが有るか、編集するアクセス権が無いとのメッセージが出ているので確認できます。
必要ならファイルにアクセス権を付与してください。
この辺りは、運用中におや？変？となった時にアクセス権大丈夫かな？と思い出してください。今の私の環境では問題が出ていませんが、個々のレンタルサーバで違ったりもするので、たとえばプラグインが上手く入らないとかも有るかもしれません。
今までの経験を生かして、問題が発生した時に慌てず環境を見直しましょう。
今回、稼働テストの環境を考えていなかったため、稼働テストができませんでした。
今まで使ってきたレンタルサーバにはWebサイトURLとWebスペースURLの2つのURLが付いている場合が多く、DNSの設定をしていなくても構築中のWebサイトにWebスペースURLを使うことでアクセス出来るようになっていたのですが、ExpressWebではそのようなサービスが有りませんでした。
今回は、運用開始して間もないことから、DNSを先に切り替えて本番環境で稼働チェックをことをしましたが、良い方法ではないのでちょっと反省しています。
そこで対策なのですが、DNSの設定をしていなくても構築中のWebサイトにWebスペースURLを使うことでアクセス出来る環境にない人は、テスト用のサブドメインを作りましょう。
テスト用のサブドメインでテストWebサイトを構築してそこでちゃんと動くか確かめた上で、改めてテスト用のサブWebサイトから本番Webサイトへ全ファイルをコピーすれば、OKかと。
今回は失敗してしまいました。。。
DNSを先に切り替えて本番環境で稼働チェックですが、単純にアクセスすると今まで通りに表示されればOKです。
もし、データベースと接続できなければ、具体的にはわかりませんが「データベース接続確立エラー」表示されるそうです。この場合は、wp_configの設定情報にミスが有ると思いますので見直してください。
また、データベースに接続できたけどプレフィックスの情報が間違っていた場合は、「ようこそ」と書かれた新規のインストール画面が表示され、ユーザー名等々の入力が促されます。この場合は、wp_configのプレフィックスの情報と実際のデータベース内のテーブル名のプレフィックスが異なっていると思われますので見直してください。
DNSの切り替えはDNSを管理しているサーバで行うことになるので、個々で方法が変わってきます。自分のDNSの設定環境を確かめて、新しいサーバに切り替えてください。
私の場合は、DNSをInfinitoPlusで管理していたのですが、DNSのレコードはWebサイトと紐づいていたたため単独で消すことが出来ませんでした。そこで仕方なくInfinitoPlusからWebサイトを削除しました。削除した時点でDNSのレコードも一緒に削除されました。
その後、InfinitoPlusで新レンタルサーバのホストを登録しDNSの切り替えを完了しました。
DNSの切り替えが済んだら、これで移行は一応完了です。
アクセス権の問題も有るので、完全に完了とは言えませんが一通りの運用は出来るようになっているはずです。
ここまで長い間「WordPress レンタルサーバ移動 引っ越し」を読んでいただきありがとうございました。やはり「稼働テスト」と「DNS切り替え」が不完全燃焼ですね。
それにDNS周りは知識と経験が無いと難しいかもしれません。
DNSに関しては後から少し情報を足すようにしたいと思います。
以上、最後までお読みくださり、ありがとうございました。
「WordPressでブログ」の運用レンタルサーバを InfinitoPlus から ExpressWeb へ移行中です。
先回は「新データベースのテーブル名（プレフィックス）を変更」作業を実施して、新しい稼働先レンタルサーバ ExpressWeb の WordPress のデータベースのテーブル名（プレフィックス）をphpMyAdminのSQL実行機能を使い変更しました。
今回は次の作業「wp_config.php のプレフィックスとデータベース接続情報を変更」を実施します。wp-config.php は、データベースへの接続情報などを記述する重要なファイルです。接続情報が間違えているとデータベースに接続できないケースとか、新しくデータベースを作りに行ったりとかしてしまいますので、編集には細心の注意を払う必要が有ります。
今回の具体的な作業は、wp_config.php を新しいデータベース接続情報に変更することと、データベースのテーブル名のプレフィックス定義の変更です。難しくはないですが、確実に実行していきましょう。
注意点が一つ。
wp-config.phpファイルはUTF-8 の BOM なし (UTF-8N) で保存する必要が有ります。絶対にWindowsのメモ帳で編集・保存しないでください。Windowsのメモ帳はUTF8をBOM付きで保存してしまいます。UTF-8 の BOM なしで保存できればどんなテキストエディタでも構いませんが手元にないようなら、「秀丸」をお勧めします。
まずは、wp_config.phpファイルがどこにあるかですが、WordPress4.2.2ではトップフォルダーに入っています。他のバージョンでも同じだと思います。今回はバックアップしているのでトップフォルダーに有りますが、もすWordPressの最新版等をダウンロードして解凍したばかりだとwp_config.phpファイルが存在しておらず、wp_config_sample.phpファイルがそのひな形ファイルとして有るはずです。
wp_config.phpファイルは見つかりましたか？
ちなみにwp_config.phpファイルは、WordPressの環境設定を行なう重要なファイルです。WordPressがMySQLデータベースに接続するために必要な情報のほか、任意でその他の高度な設定を定義できます。
今回は新しくExpressWebに作ったデータベースの接続情報をwp-config.phpの該当箇所を探し出し更新します。更新情報は４つです。
・データベースサーバ名（ホスト名）
・データベース名
・データベースユーザ名
・データベースユーザパスワード
wp-config.phpはそれほど長いファイルでは有りませんのですぐに下のように箇所が見つかると思います。該当４箇所の修正と更新情報はわかりますよね？
保存はしてもかまいませんが、引き続きプレフィックスの変更を行います。
// ** MySQL 設定 – この情報はホスティング先から入手してください。 ** // /** WordPress のためのデータベース名 */ define(‘DB_NAME’, ‘database_name_here’); /** MySQL データベースのユーザー名 */ define(‘DB_USER’, ‘username_here’); /** MySQL データベースのパスワード */ define(‘DB_PASSWORD’, ‘password_here’); /** MySQL のホスト名 */ define(‘DB_HOST’, ‘localhost’);
次はテーブル名のプレフィックスの変更です。
データベース接続情報の少し下に次のような箇所が有るので探して編集してください。
/** * WordPress データベーステーブルの接頭辞 * * それぞれにユニーク (一意) な接頭辞を与えることで一つのデータベースに複数の WordPress を * インストールすることができます。半角英数字と下線のみを使用してください。 */ $table_prefix = 'wp_';
編集し終えたら保存してください。
もう一度改めて書きますが、Windowsのメモ帳で編集・保存しないでくださいね。
以上でwp_config.phpのプレフィックスとデータベース接続情報を変更の作業は終了です。ここまでこれば終了間近です。
「WordPressでブログ」の運用レンタルサーバを InfinitoPlus から ExpressWe bへ移行中です。
先回は「新データベースにデータをリストア」作業を実施して、新しい稼働先レンタルサーバ ExpressWeb へ現在使用中のWordPressのデータベースのバックアップデータをphpMyAdminの機能を使いリストアしました。
今回は次の作業「新データベースのテーブル名（プレフィックス）を変更」を実施します。
これは１つのデータベースの中で複数の WordPress ブログを稼働させるためにテーブル名が重ならないようにするためです。その他、テーブル名を変えることはセキュリティ面からも良いと言われているそうです。
テーブル名を変えると言ってもテーブル名をガラリと変えるわけではなくて、プレフィックスと呼ばれる部分だけ変更します。
元々のプレフィックスは「wp_」です。今回は「wp_****_」としました。****の部分はセキュリティ面から非公開とさせてください。
プレフィックスは wp_config.php の中で指定してあります。ですから、例えばデータベース内のテーブル名が「wp_commentmeta」→「wp_****_commentmeta」と変えるような作業をします。またデータ中にそのテーブル名を持っているデータが有りますので、その情報のプレシックスも変更します。私もこの作業は初めてですが、難しい作業では有りませんので確実に一つ一つ進めていけば問題ないはずです。
まずはプレフィックスを何という名前にするか決めます。私は適当にWP_の後ろに4文字の単語を追加する形にしましたが、わかり易い名前でそんなに長くなければ何でも良いと思います。それからwp_に拘らなくても良いそうです。
WordPressのデフォルト環境で使用しているテーブルはWordPress4.2.2では以下の11テーブルです。
・wp_commentmeta
・wp_comments
・wp_links
・wp_options
・wp_postmeta
・wp_posts
・wp_terms
・wp_term_relationships
・wp_term_taxonomy
・wp_usermeta
・wp_users
これら１１個のテーブルに対し、リネームを行います。
ALTER TABLE wp_commentmeta RENAME TO wp_****_commentmeta; ALTER TABLE wp_comments RENAME TO wp_****_comments; ALTER TABLE wp_links RENAME TO wp_****_links; ALTER TABLE wp_options RENAME TO wp_****_options; ALTER TABLE wp_postmeta RENAME TO wp_****_postmeta; ALTER TABLE wp_posts RENAME TO wp_****_posts; ALTER TABLE wp_terms RENAME TO wp_****_terms; ALTER TABLE wp_term_relationships RENAME TO wp_****_term_relationships; ALTER TABLE wp_term_taxonomy RENAME TO wp_****_term_taxonomy; ALTER TABLE wp_usermeta RENAME TO wp_****_usermeta; ALTER TABLE wp_users RENAME TO wp_****_users;
また、wp_optionsテーブルのoption_nameのデータに「wp_user_roles」テーブル名情報が格納されているので、これも「wp_****_user_roles」と更新します。
その他には、wp_usermetaテーブルのmeta_keyのデータの中にもテーブル名情報が含まれていますので更新します。
UPDATE wp_****_options SET option_name = 'wp_****_user_roles' WHERE option_name = 'wp_user_roles'; UPDATE wp_****_usermeta SET meta_key = 'wp_****_capabilities' WHERE meta_key = 'wp_capabilities'; UPDATE wp_****_usermeta SET meta_key = 'wp_****_user_level' WHERE meta_key = 'wp_user_level';
プレフィックスを決めたら先回と同様に、ｐｈｐMyAdminを立ち上げ新しく作成したデータベースへ接続します。
私の環境では ExpressWeb の管理画面からMySQLを操作する phpMyAdmin を立ち上げます。
①データベースをクリック
新しく作成したデータベースをクリックします。
②SQLタグをクリック
SQLタグをクリックしてSQLを実行できるようにします。
③SQL文を張り付ける
上のテーブル名を更新するSQLのプレフィックス名を変更したものをコピーして貼り付けます。
④実行する
「実行する」ボタンをクリックしテーブル名変更を実行します。
①成功メッセージを確認する
「SQLは正常に実行されました」とメッセージが出ているか確認する。もし、失敗していたら、SQLを正しく修正して失敗したテーブル以降を分を再度実行する。
②テーブル名が正常に更新されたことを確認する
プレフィックスが正常に反映されているか確認する。
次にテーブル名が既に格納されている情報（データ）を更新する。 WordPress4.2.2 のデフォルトのままだと上に挙げた3か所が該当するので更新を行ないます。
尚、ググってみると wp_dashboard_quick_press_last_post_id、 wp_user-settings、 wp_user-settings-time についても更新するの対象かのように書かれた情報も有ったが、変更しなくてOKそうである。今のところ不具合は出ていない。もし、なにかしら不具合が出たら別途報告します。
①データベース名をクリックする
②SQLタグをクリックする
③Update文を張り付ける
上のテーブル名データを更新するupdate文のプレフィックスを変更したテーブル名に変更後張り付けます。
④実行する
①成功メッセージを確認する
「SQLは正常に実行されました」とメッセージが出ているか確認する。もし、失敗していたら、SQLを正しく修正して失敗した更新以降を分を再度実行する。
以上でテーブル名（プレフィックス）の変更が実施できました。SQL文を実行するなど初めての人は少し難しかったところも有ると思いますが、確実に一つ一つこなすことで先に進めたと思います。
次は、wp_config.phpのプレフィックスとデータベース接続情報を変更する作業「WordPress レンタルサーバ移動 引っ越し wp_config.phpを変更（７）」に進みます。
「WordPressでブログ」の運用レンタルサーバを InfinitoPlus から ExpressWeb へ移行中です。
先回は「新データベースを作る」作業を実施して、新しい稼働先の ExpressWeb へ WordPress 用のデータベースを ExpressWeb の機能を使い作成しました。
今回は次の作業「新データベースにデータをリストア」を実施します。
リストアとはバックアップしたデータベースを復旧させることを言います。今回の場合だと InfinitoPlus の MySQL のデータベースをバックアップから、ExpressWebの MySQL へデータベースを復旧する作業のことになります。
今回はデータベースのバックアップを SQL 文で取得したので、SQL文をそのまま新データベース上で実行すれば、WordPress のデータベースが復旧されます。
まずは、ｐｈｐMyAdminを立ち上げ新しく作成したデータベースへ接続します。
私の環境では ExpressWeb の管理画面からMySQLを操作する PHPMyAdmin を立ち上げます。
PHPMyAdmin でSQL文からデータベースをリストします。
①データベースを選ぶ
今回作成したデータベースを選び（クリック）ます。
②インポートタグをクリック
操作タグの中からインポートタグ探しクリックします。
③先ほどバックアップしたファイルを選択
インポートするファイルの中の「ファイルを選択」ボタンをクリックし、「２．現データベースのデータのバックアップ」でバックアップしたSQLファイルを選択します。
④実行する
右下の「実行する」ボタンをクリックし、インポートを実行します。
実行結果を確認します。
それ程大きなWebサイトの引っ越しでない限り、数秒で終了すると思います。尚、プラグイン等で非常に大きなデータを扱っているケースも有るらしく、その際はある程度時間が掛かると思います。
実行が終了するインポート結果画面表示に変わります。
①成功のメッセージが出ているか確認
「インポートが正常終了しました。＊＊＊個のクエリを実行しました」と表示されます。ｐｈｐMyAdminのバージョンによって多少変わるかもしれませんが、成功した旨のメッセージ出ているか確認します。
もし、インポートが正常にできない旨のメッセージなら、異常を調査し対応します。
②11個のテーブルが出来ているか確認
WordPress4.2.2のデフォルトのテーブル数は11個です。今後のバージョン次第でテーブル数が増えるかもしれませんし、プラグインでプラグイン固有のテーブルを使用している場合は増えている可能性が有ります。
これを機会にテーブルの中を覗いてみるのも良いです。wp_postsなどをデータを見ると、見覚えのある投稿記事がデータの中に見えるはずです。
これで新データベースにデータをリストアは終了です。
思っていたより簡単にデータ移行ができたのではないですか？データのバックアップを行うとき圧縮をしてZip形式ファイルにもできるそうです。インポートできる最長のファイルは75MiBだそうです。ちょっとMiBの単位が良く分かりませんが、限界の大きさはちょっと調べていないのでわかりませんが、いざって時の為に違う形式、違う方法で試しに練習しておくことも不具合対応練習として良いかもしれません。
新データベースにデータをリストアでした。
次回は、WordPress レンタルサーバ移動 引っ越し テーブル名（プレフィックス）を変更（６）です。