SWELLで追加したCSSが保存されないときはWAFも確認しよう
SWELLを使ってブログ記事を制作していると、投稿ごとにCSSを追加してデザインを調整したい場面があります。
たとえば、
- 特定の記事だけ余白を変更したい
- ボタンのデザインを調整したい
- スマートフォンだけ表示を変えたい
- 独自クラスへCSSを追加したい
といった場合です。
通常であれば、CSSを追加して記事を更新すれば、その内容も一緒に保存されます。
ところが今回のケースでは、「更新できませんでした」などのエラーは表示されませんでした。
WordPress上では、記事の更新操作自体は通常どおり完了したように見えます。
しかし、公開ページを確認しても変更したはずのデザインが反映されていません。
最初は、
「キャッシュが残っているのかな？」
と思いました。
ところが、もう一度投稿の編集画面を開いてCSSを確認すると、先ほど追加したCSS自体が保存されていないことに気づきました。
原因を切り分けていったところ、ConoHa WINGのWAFが影響していました。
WAFを一時的にOFFにして同じCSSを追加し、記事を更新すると、今度は正常にCSSが保存されました。
この記事では、この実体験をもとに、
- SWELLでCSSが保存されないときの症状
- WAFが影響する理由
- ConoHa WINGでWAFを確認する方法
- WordPress管理画面からWAFを切り替える方法
- CSSが保存されない場合と反映されない場合の違い
について解説します。
今回の環境
今回の症状が発生した環境は次のとおりです。
- WordPress
- SWELL
- SEO SIMPLE PACK
- ConoHa WING
- 投稿記事の編集画面からCSSを追加
SWELLでは、投稿記事ごとにカスタムCSSを追加できるため、その記事だけデザインを変更したいときに便利です。
今回問題になったのは、記事そのものが更新できなかったわけではありません。
記事の更新操作は通常どおり行えました。
しかし、追加したCSSだけが保存されていませんでした。
実際に起きた症状
今回の流れを整理すると、次のようになります。
投稿記事を編集する
↓
カスタムCSSを追加する
↓
「更新」を押す
↓
エラーは表示されない
↓
公開ページを確認する
↓
変更したはずのデザインが変わっていない
↓
投稿編集画面を再確認する
↓
追加したCSSが保存されていないことに気づく
という状態でした。
この症状だと、WordPress側では更新したように見えるため、最初はWAFを疑いにくいです。
特に公開ページだけを確認すると、
「CSSは保存されているけれど、キャッシュのせいで反映されていないのかな？」
と考えてしまいます。
しかし、編集画面を確認するとCSSそのものが残っていませんでした。
最初はキャッシュを疑った
Webサイトを制作していると、CSSを変更してもすぐにデザインが変わらないことがあります。
そのため今回も最初は、
- ブラウザキャッシュ
- SWELL側のキャッシュ
- レンタルサーバー側のキャッシュ
などが影響している可能性を考えました。
しかし、キャッシュが原因であれば、基本的にはCSS自体はWordPressに保存されています。
今回の場合は、投稿編集画面を開き直すと、追加したCSSそのものが保存されていませんでした。
そこで、
「反映されていない」のではなく、「そもそもCSSが保存されていない」
と分かりました。
この切り分けはかなり重要です。
「CSSが保存されない」と「CSSが反映されない」は別の問題
WordPressでデザインを変更したのに見た目が変わらない場合、大きく分けると2つの状態があります。
CSSが保存されていない
投稿編集画面を確認すると、追加したCSSが消えている・残っていない状態です。
この場合は、
- WAF
- セキュリティ機能
- WordPress側の保存処理
などを確認する必要があります。
CSSは保存されているけれど反映されない
投稿編集画面にはCSSが残っているものの、公開ページのデザインが変わっていない状態です。
この場合は、
- CSSの記述
- セレクタ
- 詳細度
- ブラウザキャッシュ
- SWELLのキャッシュ
- サーバー側のキャッシュ
などを確認します。
つまり、
編集画面からCSSが消えている → 保存処理を確認
編集画面にはCSSが残っている → CSSやキャッシュを確認
と分けると、原因を探しやすくなります。
ブラウザキャッシュについてはこちらの記事でも詳しく解説しています。
WAFとは？
WAFは、
Web Application Firewall
の略です。
Webサイトへの不正な通信や、Webアプリケーションの脆弱性を狙った攻撃などを検知・防御するためのセキュリティ機能です。
WordPressのようなWebアプリケーションを保護するために利用されます。
基本的には、WAFはONのまま使用する機能です。
ただし、WAFは通信内容を一定のルールで判定しています。
そのため、Webサイト管理者が入力した正常なコードでも、内容によってはWAFの検知対象になることがあります。
CSSやコードを追加したときにWAFが影響することがある
ブログ記事では文章や画像だけでなく、
- CSS
- HTML
- JavaScript
- コードサンプル
- 特殊な文字列
などを扱うことがあります。
これらは記事を制作するうえでは正常な内容です。
しかし、WAFから見ると、不正な通信と似たパターンが含まれている場合があります。
その結果、記事自体は更新できたように見えても、一部の入力内容が正常に保存されないことがあります。
今回がまさにそのケースでした。
ConoHa WINGのWAFを一時的にOFFにして確認した
原因を切り分けるため、ConoHa WINGのWAFを一時的にOFFにしました。
そのあと、先ほど保存されなかったCSSをもう一度入力します。
そして投稿記事を更新しました。
今度は公開ページにもデザイン変更が反映されました。
さらに投稿編集画面を開き直して確認すると、追加したCSSも正常に保存されていました。
このことから、今回のケースではWAFがCSSの保存処理に影響していたと判断できました。
作業が終わったあとは、WAFを再びONへ戻しています。
WAFは基本的にONのまま利用する
WAFをOFFにすると正常に保存できたからといって、
「それならWAFはずっとOFFでいい」
というわけではありません。
WAFはWebサイトを保護するためのセキュリティ機能です。
そのため、今回のような作業を行う場合は、
WAFを一時的にOFF
↓
CSSを追加
↓
投稿記事を更新
↓
CSSが保存されていることを確認
↓
WAFをONへ戻す
という流れがおすすめです。
作業後にWAFを戻すことを忘れないようにしましょう。
ConoHa WINGは専用プラグインからWAFを切り替えられる
今回便利だったのが、ConoHa WINGのコントロールパネルプラグインです。
ConoHa WINGでは、この専用プラグインを利用することで、WordPress管理画面からConoHa WINGの一部設定を確認・変更できます。
その中には、
- WAF
- キャッシュ
- WordPressセキュリティ
などがあります。
そのため、
記事を制作
↓
CSSを追加
↓
更新したのにCSSが保存されていない
↓
WordPress管理画面からWAFを一時的にOFF
↓
CSSを再度追加して更新
↓
WAFをONへ戻す
という流れをWordPress管理画面内で行いやすくなっています。
毎回ConoHa WINGの管理画面へログインして設定を変更しなくてもよいため、WordPress制作時には便利です。
コントロールパネルプラグインからWAFを確認する流れ
ConoHa WINGのコントロールパネルプラグインを利用している場合は、WordPress管理画面からWAFを確認できます。
大まかな流れは、
- WordPress管理画面へログインする
- ConoHa WINGの設定画面を開く
- セキュリティ設定を確認する
- WAFを一時的にOFFにする
- 投稿記事へ戻る
- CSSを追加して記事を更新する
- 編集画面を開き直しCSSが保存されているか確認する
- 作業終了後にWAFをONへ戻す
という形です。
管理画面の名称や配置は変更される場合があります。
実際に操作するときは、ConoHa WINGの現在の管理画面や公式サポートもあわせて確認してください。
ConoHa WINGの管理画面からもWAFを確認できる
コントロールパネルプラグインを使用していない場合でも、ConoHa WINGの管理画面からWAFを確認できます。
そのため、
- コントロールパネルプラグインを利用していない
- WordPress側からWAFを操作できない
- WAFの検知内容も確認したい
といった場合は、ConoHa WINGの管理画面を利用しましょう。
また、同じ操作で何度もCSSが保存されない場合は、WAFのログを確認することで原因を調べる手がかりになる場合もあります。
CSSを追加するたびにWAFをOFFにする必要はない
今回の記事を読むと、
「SWELLでCSSを書いたら毎回WAFをOFFにしないといけないの？」
と思うかもしれません。
そういうわけではありません。
CSSの内容によっては、WAFがONの状態でも問題なく保存できます。
今回のように、
特定のCSSを追加したときだけ保存されない
といった場合に、WAFを原因候補のひとつとして確認します。
普段から常にWAFをOFFにして記事を制作する必要はありません。
エラーが出ないため気づきにくい
今回のケースで少し厄介だったのが、明確なエラーが表示されなかったことです。
「保存に失敗しました」
「更新できませんでした」
などと表示されれば、保存処理に問題があるとすぐに分かります。
しかし今回は、
更新自体は普通に完了したように見える
ため、公開ページを確認するまで問題に気づきませんでした。
そして公開ページでデザインが変わっていないため、
「キャッシュかな？」
と考えます。
さらに編集画面を確認して初めて、
「CSSそのものが保存されていない」
と分かりました。
この症状を知っておくだけでも、同じトラブルが起きたときに原因を探しやすくなります。
CSSの記述ミスとは限らない
CSSを追加したあとにデザインが変わらないと、
「CSSの書き方を間違えたのかな？」
と思うかもしれません。
もちろん、CSSの記述ミスによってデザインが変わらないケースもあります。
しかし、
- 記事の更新自体は完了する
- 編集画面を開き直すとCSSが消えている
- WAFをOFFにすると同じCSSが保存できる
という状態であれば、CSSの文法だけを疑う必要はありません。
レンタルサーバー側のセキュリティ設定も確認してみましょう。
SWELLの不具合とは限らない
SWELLを使用している状態でCSSが保存されないと、
「SWELLの不具合なのでは？」
と思うこともあります。
しかし、WAFをOFFにすると同じCSSを正常に保存できるのであれば、SWELLそのものが原因とは限りません。
WordPressでは、
- WordPress本体
- テーマ
- プラグイン
- ブラウザ
- WAF
- キャッシュ
- レンタルサーバー
など、複数の機能が同時に動いています。
そのため、症状が出ている場所だけを見て原因を判断しないことが大切です。
DorabloでもWordPressテーマとしてSWELLを使用しています。
SEO SIMPLE PACKが原因とは限らない
今回の環境ではSEO SIMPLE PACKも利用しています。
投稿編集画面にはSEO関連の設定項目も表示されるため、
「プラグイン同士が干渉しているのかな？」
と考えることもできます。
しかし、今回のケースでは、WAFをOFFにした状態で同じCSSを正常に保存できました。
そのため、今回確認した症状については、SEO SIMPLE PACKそのものではなくWAFが影響していました。
WordPressではテーマやプラグインを複数利用することが多いため、
「この画面で起きたから、このプラグインが原因」
とすぐに決めつけないことが重要です。
投稿記事だけでなく固定ページでも考え方は同じ
今回はブログ記事の制作中に発生したケースを紹介しています。
しかし、固定ページなどでCSSやコードを追加している場合にも、同じような考え方で原因を切り分けられます。
たとえば、
固定ページへCSSを追加
↓
更新
↓
公開ページで変化がない
↓
編集画面を見るとCSSが保存されていない
という場合です。
このようなときも、WordPressやテーマだけでなくWAFなどレンタルサーバー側の設定を確認する価値があります。
CSS以外のコードでも確認候補になる
今回問題になったのはCSSでしたが、ブログ記事ではほかにも、
- HTML
- JavaScript
- PHPコードの紹介
- WordPressの設定コード
- サーバー設定のコード
などを扱う場合があります。
コードを追加したあとに、
更新はできたように見えるのに、追加した内容だけ保存されていない
という場合は、WAFなどのセキュリティ機能も確認候補になります。
ただし、すべての保存トラブルがWAFによるものではありません。
一時的にWAFをOFFにした状態で同じ操作を行い、症状が変わるか確認することで原因を切り分けましょう。
WAFをOFFにしてもCSSが保存されない場合
WAFをOFFにしてもCSSが保存されない場合は、別の原因を確認します。
たとえば、
- WordPress本体
- SWELL
- プラグイン
- ブラウザ
- サーバー障害
- 入力しているコード
などです。
特に、テーマやプラグインを更新した直後から症状が発生した場合は、直前に変更した内容を確認してみましょう。
原因を調べるときは、
一度に複数の設定を変更しない
ことも大切です。
ひとつ変更したら症状を確認し、改善しなければ次の項目へ進みましょう。
ConoHa WINGのプラグインがあると制作中の切り分けがしやすい
レンタルサーバーを選ぶときは、
- 料金
- 容量
- 表示速度
などを比較することが多いと思います。
しかし、実際にWordPressを制作・運営していると、
- WAF
- キャッシュ
- SSL
- バックアップ
- WordPressセキュリティ
など、サーバー側の設定を確認する場面があります。
今回のように、
「追加したCSSがなぜか保存されていない」
というときに、WordPress管理画面からWAFのON・OFFを切り替えて原因を確認できるのは便利でした。
ConoHa WINGの特徴やWAF・キャッシュについてはこちらの記事でも詳しく紹介しています。
より一般的な保存トラブルはこちら
今回の記事では、
SWELLで投稿記事へCSSを追加したものの、そのCSSだけ保存されていなかったケース
に絞って紹介しています。
WordPressの設定やプラグインなど、より一般的な保存・更新トラブルについてはこちらの記事でも解説しています。
症状によって確認する場所が違うため、まずは、
「何が保存されていないのか」
を確認することが大切です。
まとめ｜更新できたように見えてもCSSが保存されているか確認しよう
SWELLで投稿記事へCSSを追加したのに公開ページへ反映されない場合は、まず編集画面をもう一度確認してみましょう。
今回のケースでは、
CSSを追加
↓
記事を更新
↓
エラーは表示されない
↓
公開ページを確認してもデザインが変わっていない
↓
編集画面を見るとCSS自体が保存されていない
↓
ConoHa WINGのWAFを一時的にOFF
↓
同じCSSを追加して更新
↓
CSSが正常に保存され、公開ページにも反映
↓
WAFをONへ戻す
という流れで解決しました。
ポイントは、
「保存できなかった」というエラーが表示されたわけではない
ことです。
記事自体は普通に更新できたように見えるため、最初はキャッシュやCSSの記述を疑ってしまいます。
しかし、編集画面を確認してCSSそのものが消えている場合は、WAFなどのセキュリティ機能が影響していないか確認してみましょう。
ConoHa WINGでは、専用のコントロールパネルプラグインを利用することで、WordPress管理画面からWAFを切り替えられます。
今回のようにWordPressで記事を制作しながら原因を切り分ける場合には便利です。
ただし、WAFはWebサイトを保護するためのセキュリティ機能です。
原因確認のために一時的にOFFにした場合は、作業が完了したら忘れずにONへ戻すようにしましょう。
また、編集画面にはCSSが保存されているのに公開ページだけ変わらない場合は、WAFではなくCSSの記述やキャッシュなど別の原因を確認します。
WordPressのトラブルでは、
「更新できたか」だけではなく、「入力した内容が実際に保存されているか」
まで確認することが、原因を見つけるポイントです。
