Bridgeテーマのデモインポート時のPHP環境設定に関する警告を解決

20万以上の販売実績を誇る超人気のWordPressテーマ「Bridge」をエックスサーバで使用する際に、デモサイトのインポートで警告が表示された場合の解決方法をご紹介します。

『Bridge』の詳細はこちら(ThemeForest)

Bridgeテーマのデモインポート方法

Bridgeテーマには、630種類以上のデモサイトが用意されています。これらのデモは、「Bridge Dashboard」の「Import」からインポートできます。

サムネイルの上にマウスを載せ「IMPORT DEMO」テキストをクリックすると、詳細ポップアップが開きます。

ポップアップでは、必要なプラグインやインポートタイプ（すべて、コンテンツ、ウィジェット、オプション情報）、添付ファイルの有無などを選択できます。

デモインポート時の警告とその原因

ポップアップの上部に、次の警告が表示されることがあります。
Please note that your server resources are not configured properly so you might run into an issue during the demo import process. Please adjust your server configuration values.

これは「サーバーリソースが適切に設定されていないため、デモのインポート処理中に問題が発生する可能性があります。サーバーの設定値を調整してください。」のような警告です。

この警告は、「Bridge Dashboard」の下部「System Information」に記載されている「PHP Time Limit」と「PHP Max Input Vars」の数値が低いことが原因です。
なんとなく、180を300に、1000を3000にすれば良い、ということがわかります。

PHP Time Limit
180 While the current value should be sufficient to support the theme, please consider adjusting this value to 300 in order to ensure proper theme functioning and meet the requirements.

PHP Max Input Vars
1000 While the current value should be sufficient to support the theme, please consider adjusting this value to 3000 in order to ensure proper theme functioning and meet the requirements.

PHP Time Limit：スクリプトの実行時間の上限を設定する値です。
PHP Max Input Vars：1リクエストあたりに受け入れる変数の最大数を設定する値です。

警告を解決するための設定方法

警告を解決するには、エックスサーバの管理画面で以下の設定を行います。

該当するドメインを選択後、「PHP」の「php.ini設定」をクリックします。「php.ini設定変更」「php.ini直接編集」「php.ini設定初期化」のタブが並びます

「php.ini設定変更」タブで、「その他の設定」の「max_execution_time」を180から300に変更します。

「確認画面へ進む」→「変更する」で確定します。

次に「php.ini直接編集」タブをクリックし、「php.ini設定内容」に max_input_vars = 3000 を追加します。似たような設定が集まる max_execution_time、max_input_time、memory_limit の下に記入すると良いでしょう。
※ちなみに「PHP Time Limit」もここで変更可能です。その場合はmax_execution_time = 180をmax_execution_time = 300に修正します。

「確認画面へ進む」→「確定する」で変更を確定します。
※問題が発生した場合は、「php.ini設定初期化」→「初期化する」でデフォルトの状態に戻しましょう。

設定変更後の確認

設定変更後、「Bridge Dashboard」の下部「System Information」を確認します。警告がすべて消えていれば、設定は成功です。

また、「Bridge Dashboard」の「Import」からデモのポップアップを開いても、警告が消えているはずです。

これで、Bridgeテーマのデモをインポートする準備が整いました。下記画像はデモサイト「Fine Dining Restaurant」

まとめ

Bridgeテーマのデモインポート時に表示される警告は、サーバーの設定値が原因である場合があります。エックスサーバの管理画面から「PHP Time Limit」と「PHP Max Input Vars」の値を調整することで、警告を解決できます。

設定変更後は、必ず「Bridge Dashboard」で警告が消えているか確認しましょう。これで、お気に入りのデモサイトを問題なくインポートできるはずです。

『Bridge』の詳細はこちら(ThemeForest)

投稿 【WordPress】Bridgeテーマのデモインポート時の警告を解決【エックスサーバ】 は studioDoghands に最初に表示されました。

映画トレイラーや動画コンテンツを魅力的なデザインで。YouTubeやVimeoなどの外部サービスや自社サーバでの動画配信に。動画以外にも、スタッフ紹介やブログ、各種固定ページやカミングスーンなど、様々な要素が用意されています。

をワンクリックでインポートし、コンテンツを直接編集するか、自分のコンセプトを思いのままに創造できます。

投稿 Superflick – 映画スタジオ、ビデオアーティスト、映画製作者に最適な洗練されたワードプレステーマ は studioDoghands に最初に表示されました。

Figma用のドラッグ・アンド・ドロップ・ダッシュボードビルダー。デザインから開発までのプロセスのスピードアップに、Vuexy Figma Dashboard UI Kitは強力な味方になるでしょう。

『Vuexy – Figma Admin Dashboard Builder & UI Kit Template with Atomic Design System』の詳細はこちら(テーマフォレスト)

Figma上でのライブプレビューはこちらから

基本的なUIテンプレート

ダッシュボードアプリによく使用される10種類のテンプレートが最初から用意されています。
メール確認画面（Email）、チャット画面（Chat）、カレンダー画面（Calendar）、カンバン監視画面（Kanban）、電子商取引管理画面（eCommerce）、教育プラットフォーム画面（Academy）、物流管理画面（Logistics）、請求書処理画面（Invoice）、ユーザー管理画面（User Management）、役割と権限設定画面（Role & Permissions）

15種類以上の基本レイアウト
ランディングページ（Landing Page）、ヘルプセンター（Help Center）、価格設定画面（Pricing）、チェックアウト画面（Checkout）、登録画面（Register）、支払い画面（Payment）、近日公開（Launching Soon）など

すぐに仕える基本デザイン
ユーザープロフィール画面（User Profile）、アカウント設定画面（Account Settings）、よくある質問画面（FAQ）、価格設定画面（Pricing）、メンテナンス中画面（Under Maintenance）、カードアドバンス画面（Card Advance）など

各種チャート、グラフ、数値表示などの充実したウィジェットパーツ

ドラッグ・アンド・ドロップでの直感的なレイアウト

投稿 管理ダッシュボードとUIキットの人気Figmaテンプレート【Vuexy】 は studioDoghands に最初に表示されました。

ヘアモデルやパーツモデル（手や足モデルなど）のスタジオ/事務所のホームページ構成です。

想定されるサイトの目的

1. 主に広告代理店からのお問い合わせ
2. 事業の認知
3. ヘアパーツモデル希望者からのお問い合わせ

想定されるコンテンツ構成

HOME
サービス（カスタム投稿タイプ）
システム（料金表や契約の流れ。固定ページ）
MEDIA掲載履歴等（カスタム投稿タイプ）
ウェブ広告、CM、雑誌、インフォマーシャル等のカテゴリーをカスタムタクソノミーにて設定
モデル紹介
カスタムタクソノミー/カスタムフィールドにて詳細データ入力を簡易化
ギャラリー
リクルート/採用情報→頻繁に更新する場合はカスタム投稿タイプ/随時同一の内容であれば固定ページ
会社概要
お問い合わせ

モデル-登録画面の例

投稿 業種別サイト設計-ヘアモデル・パーツモデルスタジオホームページ は studioDoghands に最初に表示されました。

大量の記事のカスタムフィールドの内容を、新規で作成したカスタムタクソノミーに移動したい。
リニューアルや引き継ぎ案件でたまーに発生する作業です。

まず、サイトに掲載するデータをカスタムフィールドにするか、カスタムタクソノミーにするか、これは明確な場合もあれば、迷う場合もあります。
データが一意であればカスタムフィールドにしておけば良いのですが、サイトを長らく運用しているうちに「あれ？これ結構何回も使うぞ？カスタムタクソノミーにして選択式の方が良かったかも。」という状況が発生することもあります。

例えば、
毎回異なる調味料を紹介するサイト。カスタムフィールド「今日の調味料」を作成。
数年経つうちにレシピサイト寄りに路線変更。また、最初は単発の扱いであった「ハリッサ」のレシピが好評で、カスタムフィールド「今日の調味料」に「ハリッサ」が登録されている記事だけでも数十に。

こんな場合、明らかに「今日の調味料」はカスタム投稿タイプにしておいた方が運用が楽で、また「ハリッサを使ったレシピ一覧」の表示も簡単です。

弊社では「後々面倒にならない。運用が楽」であることを最も重視しているので、上記のようなことはめったに起こりませんが、既存のサイトではたまにみる設計です。

今回は、「カスタムフィールド」を利用して多くの記事を書いてしまったが、この「カスタムフィールド」に登録した単語を「カスタムタクソノミー」に移動、記事の他の部分には手を加えない。という作業をしてみます。

作業の順序

作業の順序はこのような感じになります。
1.カスタムフィールドを含んだ投稿をCSVでエクスポート
2.タクソノミー登録用にCSVを加工する。
3.タクソノミーを一気に登録する。
4.タクソノミーと関連付けた投稿CSVをインポートして投稿を上書き
5.カスタムフィールドの削除等の仕上げ

それでは実際に作業してみます。

1.カスタムフィールドを含んだ投稿をCSVでエクスポート

これはプラグインを利用します。
今回は「WP All Export」を使ってみましょう。

投稿タイプを選択してから、エクスポートするデータの項目の設定に進みます。

エクスポートするデータを選択します。
プラグイン「Advanced Custom Fields」（ACF）を利用したカスタムフィールドのラベルは「ACF」に表示されています。
該当のラベルを中央にドラッグします。

インポート時はIDで上書きする投稿を判別するので、「Title」や「Content」は枠外にドラッグしてクリアしても良いでしょう。

設定完了後、CSV形式でローカルに保存します。

2.タクソノミー登録用にCSVを加工する。

ローカルに保存したCSVは
・タクソノミー登録用
・投稿上書き用
の2種類に分けることになります。
まずは「タクソノミー登録用」にCSVを加工しましょう。

GoogleスプレッドシートにCSVをアップする

エクセルでもLibreOfficeでも何でも良いと思いますが、今回はGoogleスプレッドシートで加工してみます。
空のスプレッドシートを作成し、ローカルのCSVをインポートします。

「現在のシートを置換する」をチェックしてインポートします。

こんな感じでずらっと表が作成されます。

タクソノミー作成用の表を作るので、まずはシートをコピーして「タクソノミー抽出作業」のような名前を付けておきましょう。

Googleスプレッドシートで加工

加工に入ります。
この作業では、カスタムフィールド以外の情報は必要が無いので削除しておきます。
下の場合、「Id」と「Title」列は必要ありません。

下はカスタムフィールドのみ残した列のイメージです。
fruitsというフィールドに、みかんやいちご等の単語が並びます。
これらをタクソノミーとしてサイトに登録するために、まずは「重複」を消していきます。

単語の重複を排除する

重複の削除は簡単です。

列を選択して、上部の「データ」から「重複を削除」をクリックして完了です。

重複が削除されました。

基本的な加工は一旦ここまでにして、「3.タクソノミーを一気に登録する。」に進みます。

3.タクソノミーを一気に登録する。

まずは移行対象となるタクソノミーをサイトに登録しておきます。
例えば、カスタムフィールドの項目「Fruits」をタクソノミーに移動したい場合は「Fruits」や任意の名前でタクソノミーを作成します。
「Custom Post Type UI」等のプラグインを利用しても良いでしょう。

このタクソノミーに個々の単語（ターム）を一括で登録する為、プラグインを利用してみます。

今回は「WP Taxonomy Import」を使います。
※長らく更新されていない為、管理画面からのプラグイン検索結果には表示されず、ダウンロードしてインストールする必要があります。

プラグインを有効可して、「設定」→「Taxonomy Import」から設定画面を開きます。

プルダウンから登録しておいたタクソノミーを選択し、フォームにタームを記入していきます。
タームの入力方法は下記の通りです。
・デリミタで区切るとタームとスラッグを同時で登録可能（デフォルトのデリミタ: $ ）
例:りんご$ringo
・タームの親子関係は->で指定可能
例
Toyota->rav4
Toyota->ch-r

スラッグも登録しておく

ということなので、先程作成した表にスラッグも追加してみます。
コツは間に一列を追加し、セルにデリミタ（$）を入れておくことです。

こうしておけば、表をコピーして

エディタ（ATOMやSublime Text、VS Code等何でも良いです）にペースト

余計な空白を置換して削除すれば、「Taxonomy Import」に使えるテキストが完成します。

※画像では一列目（fruits$スラッグ）までコピーしてしまっていますが、ここは必要ありません。

「Taxonomy Import」にテキストをペーストして、タクソノミーをインポートします。

ここまでで、カスタムフィールドに登録されていた単語を特定のタクソノミーのタームとして登録することができました。

4.タクソノミーと関連付けた投稿CSVをインポートして投稿を上書き

後は投稿とタクソノミー（のターム）を紐付けて、既存の投稿を上書きします。

「1.カスタムフィールドを含んだ投稿をCSVでエクスポート」で作成し、スプレッドシートにアップした表を利用します。

投稿の一括登録（上書き）には、プラグイン「Really Simple CSV Importer」を利用してみます。

このプラグインも長らく更新が無く、ダウンロードしてインストールが必要になります。

「Really Simple CSV Importer」の基本的な使い方

基本的な使い方は、プラグイン製作者様のこちらの記事が一番わかり易いです。

CSVの各項目のタイトルをルールに沿ってリネームし、WordPress管理画面「ツール」→「インポート」→「CSV」からインポートを実行します。

「Really Simple CSV Importer」用に表を加工する

今回は既存の記事に、新規設定したタクソノミーを登録するだけなので、表はシンプルです。
必要なのは記事IDとタームのみです。後は、投稿タイプの指定も推奨されているので追加しておきます。

元の表。実際はTitleの列も必要ありません。
エクスポートしたカスタムフィールドの項目名を、今回登録したタクソノミー名に変更します。

「Really Simple CSV Importer」ではタクソノミーを登録する際、下記のルールがあります。
・列名は「tax_タクソノミー名」。例えばfruitsならtax_fruits
・タクソノミーとタームは登録済である必要がある※この為、「3.タクソノミーを一気に登録する。」の作業をしておく必要があります。

今回の作業で最低限必要なのは、このようなイメージの表です。※ポストタイプは必須ではありませんが、指定が推奨。

加工した表をCSVとしてローカルに保存

表の加工が完了したら、「ファイル」→「ダウンロード」からCSV形式でローカルに保存します。

WordPress管理画面からインポート画面（「ツール」→「インポート」→「CSV」）から先程のCSVを選択して、インポートを実行して完了です。

5.カスタムフィールドの削除等の仕上げ

後は、利用しないフィールドの削除、管理画面で該当するカスタムタクソノミーの表示、サイト側の表示コードの修正、等の仕上げを行います。

カスタムフィールドのデータを削除「Delete Custom Fields」

「Advanced Custom Field」から項目を削除しても、以前に入力し、記事に紐付けられているデータは残ったままなので、データベースから削除、またはプラグインを利用します。

これまた長らく更新されていないプラグインなので、下記ページからダウンロードしてインストールが必要です。
利用時には念の為サイトのバックアップを取っておきましょう。
Delete Custom Fields

「ツール」→「Delete Custom Fields」から、データを削除するカスタムフィールドを選択し、実行します。

記事に紐付けられていたカスタムフィールドのデータが削除されます。

最初の設計が肝心

如何でしたでしょうか？
ホームページの設計時に、カスタムフィールドとカスタムタクソノミーの特性を理解しておけば、このような作業は必要ありません。
・後でまとめて表示したいかも
・何回も使うかも
と思うような項目は、カスタムタクソノミーの利用を考えましょう。

引き継いだサイトの中には、繰り返されるセミナーの開催地や、採用ページの勤務地がカスタムフィールドとして設計されているサイトもありました。
つまり、管理画面から毎回毎回同じような住所を記入しなければならないのです。
このような場合は、カスタムタクソノミーで地名を選択式にしておき、連動する要素（住所、アクセス、地図）を自動で出し分ける方が運用が楽でしょう。
カスタムフィールドで選択式にしておく方法もあると思いますが、この場合「同じ会場で開催されているセミナー一覧」「同じ勤務地で募集している採用一覧」などの表示が面倒です。

これからサイトを作る場合は後々運用が面倒にならないように、慎重に設計しましょう。

投稿 カスタムフィールドで登録した情報をやっぱりカスタムタクソノミーに移行してみる は studioDoghands に最初に表示されました。

サイトの多言語化プラグインの定番「WPML」で、お問合せフォームプラグインの定番「コンタクトフォーム7」の各項目の翻訳をしてみましょう。

考えられる翻訳方法

コンタクトフォームの翻訳は次の方法が考えられます。
A:言語ごとにコンタクトフォームを作成し、各言語の固定ページにそれぞれのショートコードを反映。
B:専用のプラグイン、「Contact Form 7 Multilingual add-on」を利用して、ひとつのショートコードから生成されるフォームを言語で分岐。
今回はBの方法を試してみます。

必要な環境、プラグインなど

WPMLの初期設定は終了している前提です。
また、日本語でのコンタクトフォーム7の作成も完了しておきます。
その他必要なプラグインは下記の通りです。WPMLにログイン後、ダウンロードページからダウンロード、アップロード後有効化しておきましょう。
「String Translation」
「Translation Management add-on」
「Contact Form 7 Multilingual add-on」

コンタクトフォーム7の翻訳

それではフォームを翻訳していきましょう。

WPML→翻訳管理から、コンタクトフォームを絞り込み検索します。

今回は「base」と名前を付けたコンタクトフォームを多言語化してみます。
該当のフォームを選択して言語を選び、「翻訳バスケットに選択したコンテンツを追加」をクリックします。

翻訳バスケットに移動し、トランスレーターを選び（もちろん自分で構いません）、「全てのアイテムを翻訳に送信する」をクリックします。

WPML→翻訳をクリックします。

「翻訳する」をクリックします。

とりあえず今回は青の「自分で翻訳する」を選択してみます。

各項目を選択し、翻訳していきます。

雷マークは自動翻訳なので、使ってみましょう。

返信メールも同様に修正します。

編集が完了したら、「Finish」を押して完了します。

これで、ひとつのお問合せフォームショートコードで複数の言語への対応が可能になりました。

フォームは、「お問合せ」からも多言語編集することができます。
項目をがっちりと変更（フリガナを削除したり、郵便番号からの自動住所反映コードを変更したり、等）する場合はここから修正した方が早いかもしれません。

後は微調整

後は設計による誤差の微調整を行います。このフォームの場合、「必須」テキストがCSS（SCSS）の疑似要素で設定されている様子で、英語版でも「必須」のままです。

修正にはいろいろな方法（英語フォームでは読み込むCSSを変更したり、英語フォームにIDを付けてCSSを分岐等）がありそうですが、今回は「:lang擬似クラス」を使ってみます。
使い方は「要素名:lang(言語コード) {プロパティ名:値;}」で、言語コードはこちらを参照してください。ja（日本語）、en（英語）、es（スペイン語）、fr（フランス語）、zh（中国語）のような感じです。

CSS(SCSS)に追加してみます。

修正されました！

投稿 WPMLでコンタクトフォーム7の翻訳をしてみよう は studioDoghands に最初に表示されました。

先日、当サイトで全てのタクソノミーの表示が消えました。
エラーでは無く、カテゴリーやカスタムタクソノミーのタームが全く登録されていないのと同じ状況です。

例えば、下のようなデフォルト投稿タイプのカテゴリー表示コードが全く動作しない状態です。

[php]
<?php if ( get_post_type() === ‘post’ ): //デフォルト投稿タイプ ?>
<?php
$category = get_the_category(); //カテゴリーは配列で取得
if ( isset( $category[0] ) ) { //カテゴリーの最初のひとつだけ表示
$category_link = get_category_link( $category[0]->term_id );
$category_name = $category[0]->cat_name;
$category_slag = $category[0]->category_nicename;

$link = ‘<a href="’ . $category_link . ‘" class="cat ‘ . $category_slag . ‘">’ . $category_name . ‘</a>’;
esc_html( $link );
}
?>
<?php endif; ?>
[/php]

こういったカテゴリーの表示も消えました。

まず一通り確認

get_the_category()やget_the_terms()を使ったコードが全て表示されず、エラーも吐き出さない状態。
コードは全て
[php]if ( isset( $category[0] ) ) {[/php]
のように、該当するタームがある場合のみ表示する条件なので、ターム自体が認識されていない状況です。

この場合考えられるのは
・PHPアップデートによる関数の制限またはバグ
・タクソノミーまたはタームが消えた
・WordPressアップデートによるエラー
・プラグインの干渉
諸々です。
サイト内の一部の不具合なので、サーバメンテナンス等の可能性はとりあえず除外して良いでしょう。

管理画面では、カテゴリーやカスタムタクソノミーのタームは問題無く存在していた為、次に
カスタム投稿タイプ操作プラグイン「Custom Post Type UI」を一旦停止して様子を見てみましたが、状況は変わらず。
そもそもデフォルトのタクソノミーである「カテゴリー」も「タグ」も取得できないので、カスタム投稿タイプやカスタムタクソノミーを操作する上記プラグインは関係無さそうです。

プラグインを疑う

簡易的なテストコードを作成し、タクソノミーの中身が入っているかどうかだけの判別をしても、「タームは無し」の状態なので、これは根本的に、WordPressがタクソノミーまたはタームを参照している場所が間違っている感じです。
つまり、get_the_category()を実行しても「カテゴリーとか全然無かったよ！」と、WordPress的にはきちんと答えを返している状況です。

なんとなく、タクソノミーの順番入れ替えプラグインが怪しいです。

『Simple Custom Post Order』というそのものズバリのプラグインを停止してみたところ、不具合が直りました。

普段は『Intuitive Custom Post Order』という同様のプラグインを利用していたのですが、テストで入れ替えていました。

さっそくサポートを確認したところ、似たような状況の質問がりました。
https://wordpress.org/support/topic/last-update-cause-dissapear-custom-taxonomies/

前回のアップデート後にタクソノミーの表示が消えたとのことです。
他に似たような報告は無さそうなので、複数の要因が重なった可能性があります。

対応方法

『Simple Custom Post Order』を削除して、再度インストールすることで問題が解決しました。

まとめ

・カスタム含めたタクソノミーのタームが存在しているのに
・get_the_category()もget_the_terms()も値を返さない時は
・記事やタームの順番入れ替え系のプラグインを確認

投稿 get_the_category()やget_the_terms()が効かない！そんな時はタームの順番入れ替えプラグインが原因かも は studioDoghands に最初に表示されました。

baserCMSからwordpressへサイトを移行する工程の覚書です。
弊社がbaserCMSでサイトを作成することはありませんが、既存サイトのリニューアルでbaserCMSからWordPressに移行することが偶にあります。
今回は固定ページの移動を行ってみます。カスタム投稿タイプと違い、カスタムフィールドやカスタムタクソノミー、スラッグ被り等の考慮をしなくて良いので楽です。

baserCMSからwordpressへ固定ページ移動の流れ

1. baserCMSから固定ページのデータをCSVでエクスポート
2. CSVのデータをWordPressでインポートできるように加工
3. WordPressでCSVをインポート

の流れで作業します。
データのエクスポートにはphpMyAdminを利用。
今回、CSVの加工全般はGoogleスプレッドシート、WordPressでCSVデータを読み込むのは、プラグイン『Really Simple CSV Importer』を利用します。

固定ページをエクスポート

phpMyAdminにログインします。
MySQLからCSV形式でテーブル「mysite_pages」をダウンロードします。

この際、詳細オプションで「1行目にカラム名を追加する」にチェックをしておきます。

CSVを加工する

Googleスプレッドシートで適当なファイルを作成し、ファイル→インポート。

CSVをアップロードします。

大量の項目が並び、見ずらいので列、行とも幅を適当に狭くします。
※全選択で、適当な列や行の幅を狭めます。

投稿タイプの移動と違い、固定ページはシンプルです。
付随するカスタムフィールド、タクソノミー、公開日など、気にしなくても良い項目は多いです。
いらなそうな項目はどんどん消していきましょう。

フィルタも使い、非表示状態（statusが0）のページも消しておきます。

このあたりも固定ページの移動の場合は必要なさそうです。

最終的に、下記の項目のみ残しました。
カスタム投稿タイプに比べてかなり楽です。
親子関係があったりする場合はもう少し項目は必要になるでしょう。
name
title
description
contents
status
created

『Really Simple CSV Importer』を参考に、カラムの名前を変更します。

このような感じで項目名を変更します。
post_status（公開状態）はpublishにしておきます。

また、投稿タイプの指定も忘れてはいけません。
post_typeの項目を追加し、pageを指定します。

コンテンツの加工

この時点で、コンテンツ内の画像リンク等は正規表現を使った置換で修正しておくと、後々楽でしょう。
詳細は割愛しますが、例えば画像リンクや、Baser特有のページ内のPHPコード等です。

[code]
<?php $this->BcBaser->img(‘/img/common/○○/○○.png’,array(‘alt’=>”)); ?>
[/code]

また、画像をクリックすると「同じサイズの画像」がポップアップ、等の意味のないコードも削除しておきます。

正規表現を使った置換を数多く行うので、一旦何らかのエディタ（PhpStormやVisual Studio Code）で作業しても良いかもしれません。

CSVをWordPressにエクスポート

ある程度コンテンツの置換も済んだところで、CSV形式でローカルにダウンロードします。

プラグイン『Really Simple CSV Importer』をインストールします。
WordPress管理画面のツール→インポーターからCSVインポーターを実行します。

無事固定ページがインポートされました。

後はWordPress側で細かい修正を行い（これが大変な部分なのですが）、完了です。

投稿 baserCMSの固定ページをWordPressへ移動してみる は studioDoghands に最初に表示されました。

baserCMSからwordpressへ移行の際の覚書です。
弊社が自らbaserCMSを選択することは無いのですが、既存サイトのリニューアルでbaserCMSからWordPressに移行する依頼がたまにあります。

大抵の場合
・テーマ自体の設計（古い）
・baserCMSのバージョン（古い）
・PHPのバージョン（古い）
が絡み合い、どの要素をアップデートしてもサイトが止まる状況です。
当記事もこの状況を前提にしています。

具体的には
baserCMSバージョン： 3.0.1（古い）
CakePHPバージョン： 2.4.3（古い）
PHPバージョン： 5.4.16（古い）
テーマ、サイトを作成した人: 知らない
構造:控えめに言ってめちゃくちゃ。簡単そうなひとつの変更（例えば商品のカテゴリーを変える）で5~10個のPHPを触る必要有り（つまり、作られた年代は関係無く、全く現場での運用を考えていない設計）。
という状況で引き継いだ場合です。

baserCMSから記事情報をエクスポートしてみる

なにかプラグインが有りそうですが、上記の状況で動くことはまず有りません。
また、WordPressも同様ですが、バージョンが最新版と大きく異る場合、いきなりアップデートすることは不可能で、細かく刻んでアップデートすることになります。
今後baserCMSを使わない以上、それは面倒なので、他の方法で既存の記事をエクスポートしてみます。

phpMyAdminでデータベースを確認

とりあえずphpMyAdminでデータベースを確認してみます。

mysite_pagesテーブルがWordPressで言う固定ページ

mysite_pg_blog_postsテーブルがWordPressで言う「投稿」と「カスタム投稿タイプ」のコンテンツっぽいですね。

MySQLからCSVでダウンロード

コンテンツをCSVでダウンロードできれば、WordPress側でなんとかインポートできそうです。

エクスポートから、フォーマットをCSV、「1行目にカラム名を追加する」にチェックを入れてダウンロードしてみます。

CSVを開いてみると（画像はLibreOffice）、WordPressで使えそうな項目が並んでいます。

例えばblog_content_idはカスタム投稿タイプっぽいので「mysite_pg_blog_contents」のidとnameで置換。

blog_category_idはカスタムタクソノミーっぽいので「mysite_pg_blog_categories」のidとnameで置換。

他にも置換出来る部分は置換して、コンテンツ内容も一括で編集できる部分は編集、CSVインポーター系のプラグインを利用してWordPressに取り込めそうです。

続きはまたアップします。

投稿 baserCMSからWordPressへ引っ越ししてみる は studioDoghands に最初に表示されました。

WordPressの新機能「サイトヘルスチェック」でデータベースが古いことを指摘されてしまったので、MySQLのバージョンアップをしてみました。
※「サイトヘルスチェック」記事は下記を参照ください。
WordPressの新機能「サイトヘルスチェック」でトラブルを未然に防ごう

環境はエックスサーバで、当サイト自体が古い（8年程度）こともあり、データベースのバージョンも最新の物では無いことに気が付きつつ、移行が面倒そうで放置していました。
PHPのバージョンアップは簡単ですが、データベースの場合はホスト間を移動するので、後回しになっていたのです。

今回、「サイトヘルスチェック」でアラート（レコメンド、なので軽い方ですが）が表示されたのを機に、エックスサーバの「MySQL移行ツール」を使い、現在のMySQL5.0から最新バージョンMySQL5.7へバージョンを移行したので、手順を紹介致します。

エックスサーバ「MySQL移行ツール」の概要

公式マニュアルはこちら

『MySQL移行ツール』は、旧バージョンのMySQLデータベースについて、最新バージョンのMySQLへの移行を補助するツールです。

本ツールでは、旧バージョンのMySQLと同じ内容のデータベースとMySQLユーザを、最新バージョンに作成します。
ご利用のプログラムにて設定のMySQLホスト名を移行先MySQLのホスト名に変更するのみで、最新バージョンのMySQLデータベースを利用することが可能になります。
エックスサーバ「MySQL移行ツール」

MySQL5.0や5.5を利用している古いユーザー向けで、現行のMySQL5.7データベースを利用しているユーザーには無関係の機能です。
4年くらい前にエックスサーバで他に新規アカウントを作成した時は最初からMySQL5.7が利用できたので、少なくともそれ以前のユーザーはMySQLのバージョンを確認してみましょう。

移行とは言っても、新規データベース用の別のホスト(サーバ)に旧データベースのデータベース名、ユーザー名、パスワードをそのままコピーするので、移行を実行しても現行サイトがいきなり閲覧できなくなるようなことはありません。
※完全に移行を確認した後は旧DBの削除が必要です。

バージョン移行できないケース

いくつか注意点がある様子です。
1・MariaDB5.5(旧MySQL5.0)、MariaDB5.5(旧MySQL5.5)、MySQL5.7のいずれか2つ以上に同名のユーザ・データベースが存在する場合
2・移行するデータベースの容量が、1GBを超えている場合
3・MySQLユーザのパスワード保存形式が移行できない形式の場合

どれも大きな問題では無いか、もし当てはまるケースがあっても修正できそうです。
1は古いデータベース情報(MySQL5.0/5.5)を現行データベース(MySQL5.7)にコピーするので、上書き防止の為でしょう。

2については、WordPressサイトの場合、ファイルを含めたサイト全体で1GBを超えることはあってもデータベースが1GBを超えることはほぼ無いでしょう。
また、エックスサーバ自体のデータベース容量が(1データベース毎に)1GBなので、サイトが運用できている状態なら問題ありません。

3が額面どおりに保存形式（エックスサーバ側のパスワードハッシュ化/暗号化方法の変更含めた内部仕様）の事か、パスワードに許可された文字列が旧DBと新DBで異なる、という意味なのか（この時点では）分かりません。
前者の場合は、今までと同じパスワードを保存し直せば良いだけ、というケースが多いです。
※移行作業にて、前者であることを確認しました。

「MySQL移行ツール」利用中の注意点

ツール利用中は、データベースとMySQLユーザの作成が行えなくなります。
DBのテーブル操作等は問題無く行えるので、既存のワードプレスの運用に影響はありませんが、可能な限り一気に作業する方が良いでしょう。
例えば、MySQL5.0（旧バージョン）に10個データベースがある場合、1日一個ずつ作業、というよりは、2時間程度の時間を作り、全部片付ける感じです。

移行完了時に必要な作業

エックスサーバのサーバパネルにログイン後、「MySQL移行ツール」をクリックします。

「MySQL移行ツール」初期画面

下部に、「移行時に必要な作業について」の記述があります。

MariaDB5.5(旧MySQL5.0)から移行した場合
MariaDB5.5(旧MySQL5.0)ホスト名 【mysql○○.xserver.jp】から、MySQL5.7ホスト名 【mysql△△.xserver.jp】に変更

MariaDB5.5(旧MySQL5.5)から移行した場合
MariaDB5.5(旧MySQL5.5)ホスト名 【mysql○○.xserver.jp】から、MySQL5.7ホスト名 【mysql△△.xserver.jp】に変更

○○、△△等のホスト名は環境により変わります。

WordPressサイトの場合は、「wp-config.php」を書き換えることになります。

「MySQL移行ツール」を使ってみる

とりあえず移行ツールボタンを押して、移行を開始します。

いきなりアラートです。
【下記のMySQLユーザのパスワード情報は、MySQL5.7に移行することができない形式で保存されており、MySQL移行ツールを開始することができません。】

利用中の多くのMySQLユーザのパスワードが、移行できない形式で保存されているとの事です。

ここで表示されているMySQLユーザのリストの中には、今回バージョン移行したいデータベースで利用しているユーザーは無かったので、構わず続けようとしますが、「続ける」的なボタンが見当たりません。
 
「これ全部なおさんと進められないんか〜い！」
 
というわけで、地道にパスワードの保存形式とやらを直すことにします。

SQL設定画面に移動。

まず、先程のアラートのリストにあったユーザーを適当に選び、パスワードの変更を押します。

ここで試しに、今までと同じパスワードを入力し、保存します。

もう一度、「MySQL移行ツールの利用を開始する」ボタンを押します。

先程パスワードを変更（以前と同じものを入力）したユーザーがアラートのリストから消えていました。
※例えば10個のリストが9個になっている、という事です。

つまり、「パスワード自体は変える必要は無く、もう一度同じものを使っても良い」という事です。

リストに上がっていたユーザーはかなり昔に作ったので、MD5やSHA1等のハッシュ化関連のセキュリティがより強固になった、ということでしょう。
パスワード自体は変えなくても良いので、その場合はwp-config.phpのデータベースユーザー部分は変える必要はありませんね。

使っていないユーザーもかなりあったので、地道に削除したり、パスワードを変更したりして進めます。

さくさくと削除し、アラートに表示された全てのユーザーを処理したところでもう一度
「MySQL移行ツールの利用を開始する」ボタンをクリックします。

やっとあるべき画面が表示されました。

該当のデータベースの「移行（確認）」をクリックします。

「MySQL5.7データベースを追加しますか？」の確認画面が表示されるので、
「MySQL5.7へデータベースの追加（確定）」ボタンをクリックします。

「データベースの移行を完了しました。」メッセージが表示されます。

「MySQL設定」から確認します。
無事、同名のデータベースとユーザーがMySQL5.7に追加されています。

データベース移行後の処理

後は参照するデータベースを変更したいタイミングでWordPressの「wp-config.php」のMySQLのホスト名部分を書き換えれば完了です。
wp-config.phpはWordPressをインストールしたルートフォルダにあります。

wp-config.phpを書き換え、FTPで上書き。

WordPressの「サイトヘルス」のRecommended improvementから「古いデータベースサーバー」の表記も消えました！

※「PHPの更新をおすすめします」については、WordPressのレコメンドがPHP7.3、エックスサーバが現時点で対応しているのがPHP7.2~なので対応待ちです。
詳しくは下の記事の「WordPressの新機能「サイトヘルスチェック」を使ってみる」を参照ください。
WordPressの新機能「サイトヘルスチェック」でトラブルを未然に防ごう

注意！旧データベースは自分で消さなくても大丈夫です

WordPressの表示を確認しても、旧データベースはそのままにしておきましょう。
※最終的な工程で削除されます。

私は「MySQL移行ツール」の、該当のデータベースの「DB削除（確認）」ボタンをクリックして旧データベースを削除しようとしましたが

移行したばかりの「MySQL5.7」を消すよ！！という意味であったことに気が付き思いとどまりました。

「MySQL移行ツール」の完了

「MySQL移行ツール」ページ内にある全てのデータベースの移行（使わないのであれば、削除した方が楽です）と、そのDBを利用したサービス（ワードプレス等）の表示の確認が完了したら、「移行完了手続き」の「バージョンをMySQL5.7に移行する(確認)」をクリックして、ツールを終了しましょう。

「MySQL移行ツール」の利用中は、データベースとMySQLユーザの作成が行えなくなるので、可能な限り完了させておく必要があります。

投稿 エックスサーバ「MySQL移行ツール」でMySQL5.0からMySQL5.7へバージョン移行してみた は studioDoghands に最初に表示されました。

ワードプレスにアップロードした画像が特定の閲覧環境、例えばスマホなどで横向きになってしまうことがあります。
この原因は多くの場合、JPEG画像に含まれるExif情報が関連しています。
Exif情報には、撮影日時、場所、デジカメの機種や各種設定が含まれていて、このなかに「カメラを横に構えているか、縦に構えているか等、カメラの向き（Orientation属性）」※の情報も保存されています。
※Orientation属性は8種類に分かれていて、少し分かりづらいのですが、「写真が横向きになってしまう」ことの解決方法として理解する必要は無いので割愛します。

要は、WordPressにアップする画像から「Exif情報」を削除してしまえば画像の向きが勝手に変更される問題は無くなります。

方法その１、ローカルでExif情報を削除

社内、または自分で画像加工する際にExif情報を削除しておきましょう。
利用しているアプリ名と「Exif」「削除」でググれば大体出てくると思います。
例えばPhotoshopであれば、「WEB用に書き出し」を行うと同時にExif情報も削除されます。

多くの画像一括処理ソフトはデフォルトでExif情報は削除されます。
例えば私が愛用しているMacの画像サイズ一括変更アプリ「Th-MakerX」でも、Exif情報の保持にチェックを入れない限りは削除されます。

方法その2、プラグインでExif情報を削除

EWWW Image Optimizerプラグインが定番です。本来は画像のサイズ（容量）を圧縮するプラグインですが、Exif情報削除のみの目的でも利用できます。
プラグイン→新規追加で「EWWW Image Optimizer」を検索、インストールします。

設定→EWWW Image Optimizerを開き、「Basic」タブの「Remove Metadata」にチェックを入れます。
これで、今後WordPressにアップロードする画像からはExif情報が削除されます。

今までアップロードした画像も処理する場合は、
メディア→一括最適化から、「最適化されていてない画像をスキャンする」をクリックし、処理を進めます。

ローカルで処理するのが確実ですが、スタッフが複数に渡る場合は「最後の関所」で例外を省くこの方法が有効でしょう。

オンラインでExif情報を削除

数枚の画像から手っ取り早くExif情報を消したい場合はオンラインサービスを使う選択肢もあります。
「remove Exif online」あたりで検索すると複数のサービスが見つかります。
例:VIEW AND REMOVE EXIF ONLINE
当然「他人のサービスに画像をアップロードして処理する」リスクはありますが、WEBに掲載する目的の画像であればリスクは若干さがります。

まとめ。プロジェクトで自分が提出しているファイルで無駄なワークフローを生み出していないか確認しよう。

個人のサイトで「画像が稀にに横になってしまう」程度であれば問題はありませんが、複数のスタッフからなるプロジェクトで、「この人からの画像ファイルは気をつけないと横になる」というのは非常に大きなムダを生みます。「珠にある事柄」のためにチェック項目が増えてしまうからです。

これは、チーム内の１人のみがWindowsで「シフトJIS/JIS」でファイルを編集、しかも①②③などの機種依存文字を多様、Macで受け取ったメンバーが毎回「㈰㈪㈫」の謎文字を探し、修正する、というあるあるにも似ています。

プロジェクトで自分が提出するファイルが無駄なワークフローを生み出していないか常にチェックしてみましょう。

投稿 ワードプレスにアップした画像が横向きになる時は「Exif情報」を削除で解決 は studioDoghands に最初に表示されました。

WordPressに限らず、サイトは突然落ちます。
真っ白になったり、PHPのエラーコードが吐き出されたりと様々です。
その中で、少なくとも弊社が経験したクライアントサイトの「403 Forbidden」エラーで一番多い原因を紹介します。

そもそも「403 Forbidden」エラーとは？

HTTP 403、またはエラーメッセージ Forbidden（「閲覧禁止」「禁止されています」の意）は、HTTPステータスコードの一つ。ページが存在するものの、特定のアクセス者にページを表示する権限が付与されず、アクセスが拒否されたことを示すもの。また、サイトの制作者側の設計ミスによる障害やサイトが非常に混雑している時、URLが間違っている場合にも表示される事がある。

出典: フリー百科事典『ウィキペディア（Wikipedia）』

つまり、有名な「404エラー」（ページが存在しない）と違い、「ページはあるけどあなたは見ることが出来ません」というエラーメッセージです。

「昨日まで問題なかったサイト」が突然「403 Forbidden」エラーで見えなくなったら

「403 Forbidden」の原因は主に
・サーバのWAF（ウェブアプリケーションファイアウォール）設定によるセキュリティで弾かれている※最近はあまりありません
・「.htaccess」ファイルの誤設定
・各種ファイルのパーミッションを書き換えてしまった
・新規ドメインやサーバ移動などで諸々の設定が反映されていない
等があります。

但し、これらはホームページ制作者であれば触ることもあるかもしれませんが、お客様サイトで、何も触っていないのに「403 Forbidden」エラーが出た場合の原因は、殆どが
サーバの更新手続きや支払いを行っておらず、サービスが停止された
が原因です。
意外と大きな会社に多く、「サーバの取得は別の部署」「サーバアカウントの連絡先の社員が退社」「クレジットカードの利用が禁止されており、銀行振り込み。督促メールも未確認。」「取り急ぎクレジットカードは社長のものを使ったが、カード番号更新の際にサーバ側が決済できず（いわゆる「洗い替え」を行なっていない）、社長も当然の如くサーバ会社からの未決済メールは未確認。」などの事情が重なり、サービス停止に至ります。

WordPressサイトで突然の「403 Forbidden」エラー、まとめ

すぐにサーバの管理画面にログイン、支払い状況を確認しましょう。
ほとんどのサーバは支払い後復旧可能です。
その後、アカウントの連絡先アドレスを確認、特定の個人スタッフの場合は、会社のメインメール（info@・・・等）に変更しておきましょう。
また、同時に「ドメイン管理サービス」の支払い状況もチェックしておきましょう。（ドメインのほうが停止された場合深刻です）

投稿 WordPressサイトで「403 Forbidden」エラーが表示された場合の意外な原因No1はこれ は studioDoghands に最初に表示されました。