wordpress – 羊ページ

羊ページメンテ

投稿日2019年1月3日2020年9月11日コメントをどうぞ

一年間ほったらかした間も、WordPressは自分で自分を更新し、不正ログインを跳ね返し、ちゃんと動き続けた。偉い。

久々に記事を書いてみたら、エディタが総入れ替えになっていて、しかもウンザリするブロック機能（ MS Wordの自動成形機能を3倍くらいお節介にした感じ）のお陰で、まともに文章が書けたものでは無くなっていたが、クラシックモードを使えば安心。あんなお節介機能、誰が喜ぶんだろう？でも、そういうのがやがて標準となるんだろうか。

今年の正月は時間も気力もあるので、積年の課題にしていたデザインもちょっと変えた。このサイト、元は手打ちのHTMLで出来ていて、それを手作業（！）でWordPressに移行した。以前のサイトの感じに近いデザインにできるCatch Boxというテーマを使っているのだが、100%自分の思い通りのデザインという訳でも無い。このテーマ、珍しく左側にサイドバーを持って来れたり（意外と少ない）、レスポンシブ対応とか必須機能は網羅されているし、アップデートも頻繁なのだが、既製品なのでカスタマイズが限られる。カスタムCSSも付加できるのだが、元の構造を理解しないといじれないので、、数年放置。

で、久々に手を付けてみたら、1日でだいたいやりたかった事ができてしまった。Webを作る環境自体の進化が、やっぱり凄いなと感じた。CSSのエディット機能はプロパティのオートサジェストや構文チェックがライブで出来るようになっていたり、Chromeのインスペクト機能も凄く使いやすくなって、複雑なCSSの効き方や相互関係が追いやすく、構造が理解できた。

エントリーのタイトル下のグラデーションバーも、昔はGifでやっていたものをCSSに無事置き換えたし、文章とサイドバーの比率も、手打ちしていた当時に近くなって、読みやすくなった。@mediaなんて使ったこと無かったので、最初は全部にPC用の横幅を上書きしてしまって、レスポンシブ非対応サイトになってしまったりしたけれど。。

で、結局、一周回って昔のデザインに近しいものにすることができた。こういう文章とか、CSSとかをじわじわいじっているのはやっぱり楽しいし、時間を忘れるなと思う。

そうそう、Catch Boxとの相性と諦めていた、無限スクロールもプラグインを見直したら使えるようになった。根性と時間があれば、羊ページの全エントリーを一気読みする事も可能です。（1,496件あります）

WordPressの管理画面(wp-admin)が白紙になる

投稿日2011年10月24日2017年8月27日コメントをどうぞ

羊ページは、共用ホスティングサーバの上にwordpressをインストールして運用している。先日wordpressの管理画面(wp-admin)が真っ白になった。ブラウザによって挙動が違っていて、Chromeではログイン画面は出るが、ログインしようとするとinternal server 500が出る。Safariの場合は、白紙になってしまう。

通常のページ表示は問題ないのだが、管理画面だけが動かない。ホスティングを行っているさくら側で何かの設定変更があっての影響か？と色々考える。結論から言えば、プラグインの問題だったのだが、幾つかの原因でこのような障害が発生するようなので、トラブルシュートの過程を書き留めておく。

サーバー側のエラーログに、エラーは記録されていない。Webサーバ側から中途半端なHTMLでも送られてきていれば、まだ解決のしようがあるが、完全に白紙でなにも入力されていない。一番、やっかいなタイプのエラーだ。google先生でいろいろ調べてみると、プラグインのメモリが足りないとか、wp-login.phpが壊れているとか、.htaccessの設定が違うとか、ファイルパーミッションが違うとか、幾つか可能性があったがどれも今回のケースには該当しなかった。

調べていくうちに、プラグインが怪しいとは思い始めたが、管理画面が使えないので、プラグインをdisablesにすることが出来ない。そのため、FTPクライアントでプラグインの入っているディレクトリから、各々のプラグインの入っているディレクトリ(/wp-content/plugins)のタイムスタンプを見て、直近のものからパーミッションを一気に000にして、様子を見ていく事にした。で、一番最初のディレクトリのアクセス権を変えたら、あっさり管理画面が表示された。

結局、プラグインの一つが原因だった。最後に管理画面を使用したときから特に何も変えていないつもりだったが、サードパーティーのプラグインの更新は無意識に行ってしまう。実際にはプラグインの更新作業をした直後から、障害が発生していたが、気がつくのは次回のログインの時だったというのが答えだ。なお、当該のプラグインは一旦削除して再度入れ直した所、普通に動作した。

WordPress のPHP環境をもう少しセキュアにする

投稿日2010年9月27日2010年9月28日コメントをどうぞ

はてなブックマークを見ていたら、文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定というエントリを見つけた。

全て PHP で実装され、かつ日本語版は UTF-8 がデフォルトの文字コードになっているWordpress にも効果的と思い早速導入してみることにした。

エントリーはphp.iniの設定追加（変更）を前提に書かれているが、共有ホスティングの場合は、php.iniがいじれない。そこで、.htaccess に php_value/php_flag ディレクティブを指定することで、自分のwebサイトに対して、カスタムの php オプションを指定することができる機能を利用する。実際にどのように書き換えるか、簡単ではあるが役に立つかもしれないので、エントリしておく。

「.htaccess」ファイルでの設定を参考にさせてもらいながら、php.ini の書式を.htaccess 用に変更する。On/Off で設定するものについては、php_flag ディレクティブを、それ以外は、php_value ディレクティブを使用する。また、値の指定に「=」は使用しないので、空白にする。

自分が使っている、.htaccess に以下のエントリを追加。

　
#出力バッファリングを無効にする
php_flag output_buffering Off
#HTTPレスポンスの文字エンコーディングを設定
php_value default_charset UTF-8
#デフォルトの言語を日本語にする
php_value mbstring.language Japanese
#HTTP 入力変換を有効にする
php_flag mbstring.encoding_translation On
#HTTP 入力エンコーディング変換を UTF-8 に設定（UTF-8→UTF-8の変換）
php_value mbstring.http_input UTF-8
#HTTPレスポンスは変換しない
php_value mbstring.http_output pass
#内部エンコーディングを UTF-8 に設定
php_value mbstring.internal_encoding UTF-8
#無効な文字は「?」に
php_value mbstring.substitute_character “?”

（※元の設定項目・コメントは徳丸浩さんの文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定そのままです。これを .htaccess で使えるように変更したものになります。設定の詳細についてはこちらのサイトをご参照下さい。）

これを、自分の web サイトのドキュメントルートにアップロードすれば完了する。念のため、表示が正しいかどうか、確認しておいた方が良いでしょう。