雑学まとめブログ

カテゴリー: WordPress

  • SeesaaからWordPressに引っ越す手順まとめ

    SeesaaブログからWordpressに記事移転する手順のまとめです。

    Seesaaブログ管理画面でPCにエクスポート。
    設定はデフォルトのまま「UTF8」でOK。

    画像を載せている場合は、ファイルマネージャから1個1個PCにダウンロード。
    画像を右クリックして保存する。

    またはSeesaaBLOGの画像バックアップを利用し、一括ダウンロードする。

    保存したエクスポートファイルをエディタで開いて、
    画像の元のURLを引っ越し先のURLに置換します。

    通常、Seesaaの画像URLは
    「自分のブログのサブドメイン名.up.seesaa.net/image/画像ファイル名」
    となってます。
    これをWordpressの画像を表示するURLにキーワード置換で変換します。
    例えば当ブログだと
    「browsetrivia.com/image/画像ファイル名」
    なので、
    「自分のブログのサブドメイン名.up.seesaa.net」
    を
    「browsetrivia.com」
    に置換します。

    WordPress管理画面でインポートするには「Movable TypeとType Pad」を選択。
    インポートの途中で「Movable Type and TypePad Importer」をインストールするので、画面の指示通りに実行。

    インポートした記事はスラッグが元のSeesaaのHTMLファイルの数字になってるので、
    ページ表示でスラッグ表示しない設定にするか、
    スラッグを適切に書き換えます。

  • Code Snippets functions.phpの内容を制御するプラグイン

    Code Snippetsは、functions.phpを直接書き換えずに、
    既存のコードを上書きしたり、
    新しいコードを追加できるプラグインです。

    登録したプラグインのオンオフも自由。

    https://wordpress.org/plugins/code-snippets/

    インストール後「Add New」で登録画面へ遷移。
    Code Snippets
    「Name」に自由な名前を入力。

    「Code」にphpコードを記述。

    「Description」にコードを説明するメモを任意に記述。

    「Tags」は後で登録したコードを見つける際に見つけやすいタグを任意に付ける。

    「Settings」は基本的には「Run sunippet everywhere」のまま。
    「Only run in administration area」は管理画面のみで動作させる場合。
    「Only run on site front end」はサイトの表示の際のみで動作させる場合(管理画面では動作しない)。

  • WordPress Popular Postsの3.3はメディアライブラリの画像URLが狂う

    WordPress Popular Postsをバージョン3.3に更新したところ、
    メディアライブラリの画像URLが悉く狂ってしまい、
    画像が正常表示されなくなりました。

    WordPress Popular Postsの3.3はメディアライブラリの画像URLが狂う

    メディアライブラリの画像URLが狂うので、記事への画像挿入のURLも狂ったまま。

    具体的には
    「http://example.com/image//絶対パス/public_html/example.com/指定したディレクトリ/画像ファイル.jpg」
    というURLになってしまいます。

    しかし本来の正常なアドレスに修正すると、きちんと画像が表示されるので、
    ファイルをアップロードする機能は正常なまま、
    指定したとおりの場所にきちんと保存されるようで、
    アップロード済みの元の画像群もそのままのようです。

    なので、Wordpress Popular Postsを3.3に更新するのは辞めた方が良いかと。
    更新してしまったら、このプラグインを一時停止すると元の正常な表示に戻ります。

  • WassUp Realtime Analytics が動かないとき

    アクセス解析プラグインとして有名なWassUpは、WordPressとのバージョンの相性やらサーバーとの相性やらで動かなくなることがあります。

    再び正常動作させるには、まずWassUpの管理画面を開いて下部の「Reset to Default」をクリックします。
    これで全ての設定が初期値に戻るので、設定を変えて使っている場合は事前に設定をメモしておきます。

    次にプラグイン一覧を開いてWassUpを「停止」させ「有効化」します。

    プラグインの一覧画面が更新されてページの上部に
    「Database created/upgraded successfully」と表示されれば成功。

    これで正常動作になります。

  • バージョン4.4で記事編集画面に短縮URLボタンが表示されなくなりました

    4.4以前のWPには、記事編集画面に「?=p」という形式の短縮URLボタン(ショートリンク)が表示されていましたが、
    4.4からは非表示になりました。

    これを表示させる設定もありません。

    表示させたいなら、自力でアクションフックを利用して表示させるプラグインなり、functions.phpのカスタマイズなりが必要です。

    ちなみにアクションフックは
    pre_get_shortlink
    get_shortlink
    のどちらか。

  • Site Guard WP Plugin ログイン画面を詳細に制御できるプラグイン

    最近、WordPressの管理画面への不正アクセスの試みが増加してるので、
    Site Guard WP Plugin
    というプラグインを導入してみましたが、効果は上々。

    インストールして有効化すると初期設定として、
    ログインページが通常の「wp-login.php」から異なるURLに変更されます。

    攻撃者は通常のURLで不正アクセスを試みますが、
    異なるURLなので存在しないページという判断となってログイン画面にアクセスできなくなります。

    この異なるURLは任意の文字列に設定可能です。

    他の機能は以下の通りです。

    管理画面アクセス制限
    管理画面に関するファイルへのアクセスをログイン中のユーザーのみにします。
    一部のファイルは任意に例外にできます。

    画像認証
    ログイン時、コメント投稿時などに画像認証を追加します。
    認証は個別に設定可能です。

    ログイン詳細エラーメッセージの無効化
    エラーメッセージが表示されないようにします。
    エラーメッセージを表示すると攻撃者に手がかりを与えてしまいます。
    ログイン画面へのアクセスを異なるURLにすれば、ほとんどの攻撃は回避できますが、
    仮にその異なるURLがバレても、エラーメッセージが表示されないと更に安全性が高まるわけです。

    ログインロック
    ログイン時にエラーとなった際の処理を選択肢から設定できます。
    個人的には時間や回数を自由に指定できるLimit Login Attemptsの方がオススメです。

    ログインアラート
    ログインが発生したらメールで通知します。
    身に覚えの無い通知が来たら、攻撃者にサイトを乗っ取られたということです。

    フェールワンス
    正規にログインが成功しても、1度だけわざと失敗扱いとする機能です。
    初期設定ではオフ。
    攻撃者が正規のIDとパスワードを入力しても、失敗となるので使えないと判断するわけです。

    ピンバック無効化
    ピンバック機能を停止します。
    WordPressには記事中にURLがあると、自動的に更新を通知する機能があります。
    ただしそのURLのサイトがWordPressを使っていないと無意味。

    更新通知
    WordPress本体やプラグイン、テーマの更新があるとメールで通知します。
    WordPress標準のアドバンスド自動更新に同じ機能があるので、無効で良いかと。

    WAFチューニング
    Site Guard WP Pluginを作っている会社によるオプション機能で、
    誤検出を防ぐ機能らしいのですが、WAFのインストールが別途必要なので具体的な使用感はわかりません。

  • WordPressで500エラーに対応

    WordPressの管理画面を利用中に突然500エラーとなりました。

    500エラー以降は管理画面が白紙のまま何もできません。

    500エラーの原因として考えられるのは、

    ・.htaccessの設定ミス
    ・プラグインのエラー
    ・CGIのパーミッションミス
    ・CGIへの高負荷

    などがあります。

    .htaccessの内容がおかしいなら初期化するのも手。
    以下の記述が正当な.htaccessの記述なので食い違ってないか確認。

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress

    食い違いがあるなら修正しますが、その前に念のためにバックアップを取っておきます。

    プラグインのインストールで新しい記述が.htaccessに追加される場合もあり、その記述を削除します。

    プラグインをインストールしたら500エラーとなったのなら、そのプラグインを削除すれば元通りになります。
    サーバーの管理画面かFTPで直に該当ディレクトリにアクセスしてプラグインを手動で削除します。

    CGIへの高負荷の場合、xmlrpc.phpへのブルートフォースアタックが原因かもしれません。
    サーバーのログを開いて(ダウンロードして)ログ内のxmlrpc.phpを検索し、
    大量に該当ログがあるならブルートフォースアタックが原因の可能性が濃厚です。
    この場合、xmlrpc.phpへのアクセスを遮断するのが対症療法としては有効。
    .htaccessに以下の記述を追加します。

    <Files xmlrpc.php>
    deny from all
    </Files>

    ただし、この方法だとあらゆるアクセスを禁じてしまうので自分のアクセスすらできなくなります。
    またコメントやトラックバックも使えなくなります。

    CGIのパーミッションミスは直接弄ってないなら起こりえないはず。
    644、707とか755だと思いますが、適切なパーミッションはサーバー毎に異なるので確認してください。

  • 記事投稿者ページのURLを書き換えるEdit author slug

    WordPressには記事投稿者のIDをそのまま使った投稿者アーカイブ「author」ページが存在します。
    通常「http://ドメイン/author/ID」というURL構成になっています。
    このauthorページは、記事投稿者のIDをパラメータとして置換するだけでもアクセス可能です。
    例えばドメインの末尾に「/?author=1」を追加すると、
    このID「1」のauthorページにアクセス(リダイレクト)できてしまい、記事投稿者のIDがバレます。
    これを防ぐ為にauthorページのURLを書き換えるのがedit author slugです。
    Edit Author Slug
    プラグインをインストールしたらプロフィールの「ニックネーム」と「ブログ上の表示名」をIDとは異なる名称にします。
    Edit author slugのプロファイル

    プロフィール下部に「Edit Author Slug」という項目が表示されているはずです。
    Edit author slugのカスタム画面
    ここでslugとしてニックネームを選択するか、customで任意の文字を入れて保存します。
    画像では「administlator」としてありますが、これは一例であって何でも良いのです。
    こうやって書き換えることで、攻撃者は書き換え後の名称をIDと思い込んで本来のIDに気づきません。
    またEdit Author Slugの設定画面で、Author Baseも書き換えます。
    wordpress-edit-author-slug.jpg
    これでauthorページが「http://ドメイン/書き換え後のAuthor Base/書き換え後のAuthor Slug」というURL構成になり、authorページへのアクセスが困難になり、IDが推測されにくくなります。
    「ユーザーがプロフィールを変更したら自動的に Author Slug を更新します。」にチェックを入れると、
    ニックネームやブログ上の表示などが変更されると自動的にAuthor Slugも連動して変更されます。
    wordpress-edit-author-slug-auto.jpg

  • WordPressのテンプレートのカスタマイズは子テーマを介して行う

    WordPressには「子テーマ」という仕組みがあります。
    子テーマを作って子テーマ側を編集することで、
    親テーマがバージョンアップしてファイルが上書きされても、
    子テーマで編集した内容は上書きされず、新しいバージョンになっても編集内容が有効になります。
    子テーマを作るのに必要なのは「子テーマ用ディレクトリ」と「CSS」です。
    「functions.php」も必要とされていますが、実際には無くても動きます。
    まずFTPなどでテンプレートが置いてあるディレクトリを開き、子テーマ用のディレクトリを作ります。
    子テーマ用ディレクトリの名前は「親テーマの名前-child」と名づける事が推奨されていますが、別に自分がわかるなら何でも良いのです。
    そして子テーマのディレクトリにCSSファイルを作ります。
    そのCSSには以下の内容を記述します。

    /*
    Theme Name: Child
    Template: templatename
    */

    Childには好きな名称を書きます。
    templatenameは親テーマのディレクトリの名前を書きます。
    最低限、この2つの記述が必要です。
    それから

    @import url(‘../templatename/style.css’);

    を記述して、親テーマのCSSを子テーマへインポートします。
    ただしこれは現在では、子テーマにfunctions.phpを用意して以下の記述を書くことで、CSSをインポートするよう推奨されています。
    子テーマより。

    add_action( ‘wp_enqueue_scripts’, ‘theme_enqueue_styles’ );
    function theme_enqueue_styles() {
    wp_enqueue_style( ‘parent-style’, get_template_directory_uri() . ‘/style.css’ );
    }

    これを記述する必要から「functions.php」も必要と説明されているのです。
    ちなみに子テーマのfunctions.phpの関数と親テーマのfunctions.phpの関数が重複している場合、エラーとなりますが、
    親テーマで関数の定義の仕方を「条件付き定義」にしている場合はエラーにはなりません。
    あとはカスタマイズしたいテンプレートファイルを子テーマへコピーし、子テーマの方を編集します。
    例えばブログのトップページを弄りたい場合は「index.php」をコピーして編集します。

  • WordPressのxmlrpc.phpを無効にして不正アクセス対策

    WordPressのxmlrpc.phpはウェブサイト攻撃の「踏み台」に使われているそうです。
    WordPressの16万サイトが大規模攻撃の踏み台に、「Pingback」機能悪用
    私の手持ちサイトも妙な不正アクセスが発生して、参りました。
    xmlrpc.phpにはリンクが張られたことを通知する機能があります。
    これを「Pinback」と呼びます。
    自分が何の悪意も無くとも、このPinbackの仕組みを使って他のサイトを攻撃する「踏み台」に使われかねません。
    xmlrpc.phpを削除してもWordPress本体のバージョンアップで復活してしまいます。
    なのでxmlrpc.phpそのものを無効にしておきましょう。
    ちなみにxmlrpc.phpを無効にすると、メールアドレスを送信して記事投稿する機能も失われます。
    functions.phpを書き換える必要があります。
    以下の記述をfunctions.phpに追加します。

    add_filter(‘xmlrpc_enabled’, ‘__return_false’);

    xmlrpcを無効にするプラグインもありますが、
    Disable XML-RPC Pingback
    このプラグインを利用する場合は、GETにしか対応してないので、POSTで攻撃されると効果が無いとのこと。
    GETメソッドはURLにパラメータが付く送信方法。
    POSTメソッドはURLにパラメータが付かない送信方法とのことですが、私も詳しくはわかりません。
    ちなみにこのプラグインで以下の記述がfunctions.phpに追加されるとのこと。

    add_filter( ‘xmlrpc_methods’, ‘Remove_Pingback_Method’ );
    function Remove_Pingback_Method( $methods ) {
    unset( $methods[‘pingback.ping’] );
    unset( $methods[‘pingback.extensions.getPingbacks’] );
    return $methods;
    }

    .htaccessで無効化する方法もありますが、

    <Files xmlrpc.php>
    Deny from all
    </Files>

    この場合は攻撃者が諦めない内はサーバー負荷は続くらしいです。
    最も負荷がかからないのは以下の方法とのこと。
    wordpressのxmlrpc.phpに対するブルートフォースアタックを防ぐ

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^xmlrpc\.php$ “http\:\/\/0\.0\.0\.0\/” [R=301,L]
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    7
    RewriteCond %{REQUEST_FILENAME} !-d
    8
    RewriteRule . /index.php [L]
    </IfModule>

    xmlrpc.phpにアクセスすると自動的に「http://0.0.0.0/」にリダイレクトします。