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 に最初に表示されました。

先日より、下記のようなタイトルで、ワードプレスのバックアッププラグイン「BackWPup」のバックアップが失敗したとメールが届くようになりました。
[エラー] BackWPup ログ 11-5月-2019 03:00: database
同時期にWordPress5.2にアップデート、PHPバージョンも7.2xにアップデートしていたので、「まあ、どちらかが原因で、その内プラグインも対処するだろう」と特に対策もしていなかったのですが、数日経ってもエラーメールが届くので、なんとかすることにしました。

とりあえず解決方法は記事下部の「解決方法の解説」に掲載しています。Dropboxとの連携をやり直せば直ります。

解決方法の確認

メール内容を確認

エラー: ステップを中止: 回数が多すぎます！
エラー: ジョブは9秒でエラー終了しました。エラーを解決する必要があります。
のメッセージが表示されています。なんとなくDropboxとの連携がうまく行えていない雰囲気です。

BackWPupのログを確認。
WordPress管理画面、「BackWPup」→「ログ」を確認します。

「たまにきちんとできているときもあるんかーい！」
全てエラーなら分かりやすいのですが、バックアップが出来ている時もある、というのがまた面倒そうな予感がします。

出来ているときと出来ていない時の違いを確認。

バックアップが正常に完了している時のログ。

バックアップが出来ていない時のログ。

正常時にあった、「Dropbox で認証されました。」のメッセージがありません。
ドロップボックスの認証が原因っぽいです。

該当部分のエラーメッセージを確認します。

Dropbox API: (400) Bad input parameter: Error in call to API function "users/get_current_account": This app is currently disabled.
です。というか、メールの文中にあった内容ですね。

上記のエラーメッセージでグーグルで検索してみます。

そのものズバリのスレッドがワードプレス公式サイトにありました。
Dropbox API: (400) Bad input parameter | WordPress.org

製作者より修正方法へのリンクが記載されていたので、移動します。

この重要なお知らせです。
5月7日に、Dropboxのセキュリティ対策の一環としてBackWPup（3.6.9）のアップデートをリリースしました。
5月10日までに、BackWPup設定でプラグインを更新してDropboxアカウントを再度認証してください。
そうでなければ、BackWPupをDropboxに接続しても、5月10日以降は機能しなくなります。
「IMPORTANT!!! – UPDATE your Dropbox Authentification after Release 3.6.9」を意訳

セキュリティ上の理由から、ドロップボックスへの接続方法が変更になったことが原因との事です。

更新方法のページに移動します。
How to restore the Dropbox connection in BackWPup 3.6.9 or later – BackWPup Docs

簡単な3ステップで修正できそうです。以下に解説します。

解決方法の解説

対象はBackWPup → ジョブ →　一般　→ジョブの宛先の「バックアップファイルの保存方法」を「Dropbox にバックアップ」にしている人です。

1.BackWPupを最新バージョンへアップデート
2.ドロップボックスとの接続を解除
3.改めてドロップボックスと接続
で完了です。

1.BackWPupを最新バージョンへアップデート

現在の最新バージョン、3.69以降になっていることを確認しましょう。

2.ドロップボックスとの接続を解除

BackWPup→「ジョブ」から該当のジョブを選択します。
「Dropboxの認証を削除」ボタンをクリックして、接続を解除します。

3.改めてドロップボックスと接続

2種類の方法があります。

Dropboxのアプリへのアクセス

Dropboxの「アプリ」フォルダ内に、「BackWPup」が作られ、その中にバックアップファイルが保存されます。
「バックアップ設定」の「保存先フォルダー」にフォルダ名を入力した場合は、上記の「BackWPup」内にその名前のフォルダが作成され、そこにバックアップファイルが保存されます。

「Dropboxのアプリへのアクセス」を利用する場合は「Dropboxのアプリ認証コードを取得」をクリックして進めます。

Dropboxへのフルアクセス

Dropboxのルートフォルダに、「バックアップ設定」の「保存先フォルダー」に入力したフォルダが作られ、そこにバックアップファイルが保存されます。

「Dropboxへのフルアクセス」を利用する場合は「Dropboxのアプリ認証コードを取得」をクリックして進めます。

どちらを選んでも、このような感じでDropboxとの連携の確認画面が表示されるので、そのまま進めて認証コードを取得、上記のフォームにペーストし、保存して完了です。

バックアップを確認

正常にバックアップが取得できました！

投稿 BackWPup「エラー: ステップを中止: 回数が多すぎます！」の対処方法。Dropboxの認証ステップが原因。 は 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 に最初に表示されました。

WordPressのプラグインアップデート中に、稀にサイト、管理画面共エラー画面で停止してしまうことがあります。
エラーメッセージは「Briefly unavailable for scheduled maintenance. Check back in a minute.」です。

復旧方法

FTPソフトでWordPressのインストールディレクトリ※を開き、「.maintenance」というファイルを削除して完了です。

「.maintenance」が見当たらない

FTPソフトの設定を確認しましょう。「.」始まるファイル（.htaccessなど）を非表示にしているかもしれません。
Filezillaであれば、フィルターをオフにして確認しましょう。

エラーの原因

プラグインのアップデート中はメンテナンスモードに入っています。通常は数秒なので意識しませんが、この間にアップデート中のプラグインを開いたり記事の更新を行おうとすると、メンテナンスモードから回復できなくなることがあります。
これが「Briefly unavailable for scheduled maintenance. Check back in a minute.」エラーの原因です。

時間が経つと回復することも

最近は2回ほどこのエラーを誘発してしまいましたが、「.maintenance」ファイルを探しているうちに回復していました。
見た目的に動きが無いので不安になりますが、3分程度待ってみるのも良いでしょう。

投稿 【復旧は簡単】エラー「Briefly unavailable for scheduled maintenance. Check back in a minute.」が表示されたときは は studioDoghands に最初に表示されました。

先日、Bootstrap4をベースとしたスターターテーマ、UnderStrapのモバイルメニュー（ハンバーガーメニュー）が開閉しなくなる問題が発生しました。

正確には、スマホメニューが一瞬開いた後にすぐに閉じてしまう、という状況です。

UnderStrapのモバイルメニューは#navbarNavDropdownのクラスが下記のように変化します。

動作した後すぐにshowクラスが消えてしまうので、CSSやPHPの問題では無く、JSの問題であることは明らかでした。
まずは自分で追加したスクリプトをチェックしましたが、モバイルメニューで利用されているコードとの衝突は無し。

そこで、プラグインを全て停止するとモバイルメニューの挙動が復活。
後はひとつずつ有効化して検証しました。

するとファイルダウンロードサポートプラグイン「Download Manager」を有効化した際にエラーが復活し、問題のプラグインを特定しました。
「Download Manager」は良く利用するプラグインなので、嫌な予感を抑えつつ、設定項目を確認。
すると、簡単に原因が分かりました。

「Download Manager」もBootstrap jSを利用しており、これが重複して読み込まれていたことが原因でした。
読み込みを解除するチェックボックスがあるので、「Bootstrap JS」と「Bootstrap CSS」をチェック。ついでに、UnderStrapで既に読み込んでいる「Font Awesome」にもチェックします。
すると、モバイルメニューの動作が正常に戻りました。

設定場所は「Downloads」→「Settings」ページ下部の「Misc Settings」です。

同様の事象が発生した場合、利用中のプラグインがBootstrapファイルの読み込みをしていないか確認することをお勧めします。
プラグインの設定で読み込みの解除をサポートしていない場合は、該当のコードからリンク部分をコメントアウトすることになると思います。

投稿 Bootstrap4ベースのWordPressテーマでモバイルメニューが開閉しない時はプラグイン設定を確認 は studioDoghands に最初に表示されました。

普段あまり馴染みのないhetemlで詰まったのでメモ

状況
hetemlでワードプレスサイトを公開。
ブログも固定ページも問題無く更新できるが、テーマのCSSが更新出来ていない。
その他、ちょっとしたプラグインの設定変更後、403エラーが出て反映出来ない。
該当するフォルダやファイルのパーミッションも問題無し。

原因
ヘテムル標準装備のWAF(ウェブアプリケーションファイアウォール)がONになっている事が原因。

対処
方法1.WAF機能をOFFに

管理画面から、「WAF設定」をクリック。

該当するドメインの「詳細を見る」をクリック。

「WAF設定」をOFFに。少し時間がかかりますが、プラグイン設定やCSSの上書きが出来るようになりました。

方法2.または、管理者の操作を除外設定に

「ログ参照」をクリック。遮断されたアクセスが表示されるので、自分っぽい（殆どが該当すると思います）操作ログの「.htaccessによる除外記述」をコピー。サイトのhtaccessファイルの一番下にペーストします。

通常の操作や表示には問題無いので、通常はONにしておいても良いかな、と思います。

参考
WAFについて
http://heteml.jp/service/waf/

ヘテムル403エラーについて
http://heteml.jp/support/faq/490.html

投稿 heteml(ヘテムル)でCSSの更新が出来ない時は は studioDoghands に最初に表示されました。

http://www.makeuseof.com/answers/uninstall-then-reinstall-google-chrome-but-still-slow/
makeuseof.comより。質問者、回答者は実際は統一されていませんが、意訳です。

Q
再インストールもした。キャッシュも消したしクッキーも履歴もプラグインも全部消した。でも遅いんだ。

A1
遅いって、ホームページの閲覧？それとも起動が？
クロームはメモリー喰いだよ。クロームが起動中の時の物理メモリーの残量をタスクマネージャで調べてみなよ。
あと、セキュリティソフトとの相性もある。chrome.exeのプロセスはアンチウイルスソフトの対象から外したほうが良いね。
ホームページの閲覧が重いのなら、JAVAとかFLASHとかのプラグインが帯域を圧迫しているかもしれない。
アドレスバーに”chrome://plugins”を打ち込んで、とりあえず全部”無効”にしてチェックできる。
クローム自身が使用している
Program Files (x86)GoogleChrome
Program Files (x86)GoogleUpdate
は無効にしたらダメだよ。

A2
“本物”のアンインストーラーを使ったかい？ウィンドウズの”プログラムのアンインストール”じゃなくて。と言うのは、標準のアンインストーラーは結構消し残しがあるからね。それが再インストールした後、悪さしている可能性もある。
Q
TuneUp Uninstall Managerを使っている。これなら大丈夫回？
A2
それなら大丈夫だね。でも念の為にfilesやregistryもスキャンしておくといいよ。

A3
Adobe Flash Player プラグインが原因の場合も。
https://support.google.com/chrome/answer/108086?hl=en

あとはアンチマルウェアソフトのホワイトリストにクロームを加える。（スキャン対象から外す）

念のため、レジストリクリーナーでPCをスキャン
http://www.wisecleaner.com/wiseregistrycleanerfree.html

投稿 再インストールしてもchrome遅い件、海外サイトから紹介 は studioDoghands に最初に表示されました。

同じ悩みを抱えている人は少数だと思いますが、流れを箇条書きで。ベストな解決方法では無いと思いますが、極力コードを追記しない処置。

前提
・WP-MEMBERSで会員制サイト構築
・特に会員同士のSNSでは無く（その場合はBuddyPressの方が良い。）、どちらかと言うと告知的な要素が強い
・なので、コメント欄はいらない。停止。
・出来ればfunction.phpや、テーマ固有のCSSは触りたくないし、子テーマにフィルターフックもしたくない

症状
・会員登録ページのフォームがずれる（これはまだOK）
・やっと直したら、下部の「この投稿はパスワードで保護されています。コメントを閲覧するにはパスワードを入力してください。」の表示がおかしい
・段になったり、典型的なalighn-leftがずれる、よくあるあれ
・WP-MEMBERSが表示している訳では無く、ワードプレス固有の表示
・上部で、「このコンテンツはパスワード保護されています」的な事をWP-MEMBERSで表示しているので、下部で、コメントの表示云々はいらない
・色々やって直したら「コメントは停止中です。」の文字が表示され、ぐったり。この表示はいらない。

解決方法
・プラグイン、Disable Commentsでコメント全部停止。
・一部コメント許可、等の運用ルールになるまでは、とりあえずは表示がすっきりします。

投稿 WP-MEMBERS(会員制サイト構築プラグイン)の会員登録フォームの下のコメント関連表記のズレ は studioDoghands に最初に表示されました。