WordPressメモ

2009.06.01

便利だと思うことメモ。
このブログは『SQLite』だから、通常とは若干違う場合があるということを認識した上でどうぞ。

仮定として基本的には、サイトのURLは『http://example.com/』

    1. ログインしている時のみ、表示させる場所を作りたい
    2. 現在『more』以降の内容を表示中かどうかを確認する
    3. WordPressでSQLiteを使う
    4. 開発環境と本番環境で完全共通化
    5. 管理画面の投稿一覧にて、親カテゴリから、子カテゴリを抜き、表示させたい
    6. 管理画面にアクセスすると『このページにアクセスする権限がありません。』
    7. アップデート後、管理画面が真っ白になってしまった！
    8. とにかく管理画面にログイン出来ない！
      1. 他のブラウザでなら、ログイン出来た！
      2. リダイレクト先URLおかしいかも？
      3. もしかして管理画面のURL自体がおかしい？
    9. 管理画面にて、全オプション変更の隠しページを呼び出す
    10. 読み込み済みのjQueryを使う
    11. お気に入りプラグインと相性
    12. データベースの接頭辞($table_prefix)を変更する
    13. 記事の状態をDBから直接変更
    14. 親子カテゴリを階層表示にする
    15. 画像の標準保存場所を変更
    16. ファイルUP容量を突破
    17. memory sizeエラー
    18. ディレクトリ変更によるURL変更
    19. WordPressのアドレスとサイトアドレス
    20. 予約日時やdate関数がズレる
    21. wordpressのバージョンを表示
    22. wordpressのSSL(https)化に変えた際に変更
    23. ユーザ情報・ブログ情報の表示方法（マルチサイト対応）
      1. メンテナンスモード

ログインしている時のみ、表示させる場所を作りたい

ログイン時、記事を表示しているときに出る『編集(edit)』がそれ。

<?php if (is_user_logged_in()) : ?>
ログイン時のみ表示する内容
<?php endif;?>

現在『more』以降の内容を表示中かどうかを確認する

現在moreまでしか表示されていない状態なのか、それ以降も表示された状態なのかを判別する方法。
WordPressでmore以降の表示状態次第で、more前の内容を変える

WordPressでSQLiteを使う

標準ではMySQLだけど、プラグインの力でSQLiteにすることが出来る。
[wp×SQLite]WordPressでSQLiteを使う[確定版]

開発環境と本番環境で完全共通化

SQLiteなら開発環境と本番環境で全く同じものにすることが出来る。
WordPressを開発環境と本番環境で完全共通化

管理画面の投稿一覧にて、親カテゴリから、子カテゴリを抜き、表示させたい

仮定として下記のような設定とする。

  • ID 3:カテゴリーA(親)
  • ID 4:カテゴリーB(Aの子)

例えば、投稿一覧の絞り込み検索にて『カテゴリーA』を選択。
すると『カテゴリーB』の記事まで出てくる。
『カテゴリA』から『カテゴリB』を省いて表示させたいという話。

通常、投稿一覧で『カテゴリA』を指定すると、下記のようなURLになる。

Unsupported Browser — WordPress.com
wp.com

この内カテゴリに当たる『cat』の部分を引き算指定する『-4』を追加する。
『cat=3-4』を指定したくなるが、半角スペースが大事で『cat=3 -4』。
更にそれをURLバリデートした『cat=3%2C-4』を設定する。

Unsupported Browser — WordPress.com
wp.com

となる。

管理画面にアクセスすると『このページにアクセスする権限がありません。』

プラグインやテーマの相性で、そうなったと思われる場合、pluginディレクトリやthemesディレクトリから、怪しいと思われるものを、直接丸っと消すか、ディレクトリ名変更すれば解決する。

データベースの接頭辞($table_prefix)の変更が原因と思われる場合は『データベースの接頭辞($table_prefix)を変更する』を見て、抜けがないか要確認。

アップデート後、管理画面が真っ白になってしまった！

ログインすると『500エラー』で画面が真っ白！

大概、原因はプラグインと本体のバージョンの関係。
プラグインは本体より先にアップデートすること！

もし現象を起こしてしまった場合は、『wp-content/plugins』内を直接いじるしかない。

  • 直接1個1個、ZIP落としてきてはアップデート
  • 怪しいと思われるプラグインのディレクトリを消すか名前変えることで無効化

くらいじゃないかな、と思う。

とにかく管理画面にログイン出来ない！

理由は不明だが、とにかく何度試そうとログイン出来ない！という場合の話。

他のブラウザでなら、ログイン出来た！

ブラウザに保存されているCookieが原因なので、ブラウザの該当ドメインのCookieを削除する。

リダイレクト先URLおかしいかも？

http://example.com/wp-admin/
ではなく
http://example.com/wp-login.php
でログインしてみる。

もしかして管理画面のURL自体がおかしい？

『wp-config.php』に追記する。

define('RELOCATE',true);

通常はサイト引っ越しのときに使うもの。
これを設定すると、ログイン画面にアクセスした際のパスを使ってサイトURLが更新される。
これで新しいURLで管理画面を使うことができる。

管理画面にて、全オプション変更の隠しページを呼び出す

直接URL打たねば見れない特設ページがある。
ブラウザのURLの欄に『/wp-admin/options.php』と直接入力。
　例：http://example.com/wp-admin/options.php
出たページでは全オプションを直接変更が可能。
ただし『SERIALIZED DATA』とテキストボックスに表示された項目は編集不可能。

読み込み済みのjQueryを使う

テーマにもよるがjQueryが読み込み済みの場合、その使い方について。
WordPressに読み込み済みjQueryを使う

お気に入りプラグインと相性

作るときには必ず入れるほどのお気に入りのオススメしたいプラグイン。
相性問題も見つけたら書いておく。
オススメしたいWordPressプラグインと相性！

データベースの接頭辞($table_prefix)を変更する

例えばサーバの引っ越しで、今まで別のアカウントで置いていたものを同じデータベースに置かなきゃいけなくなったときとかに、今まで『wp_』だったのを『wp_2_』に変えなきゃいけないとか、そういった場合に必要になる。
WordPressで後からデータベースの接頭辞($table_prefix)を変更

記事の状態をDBから直接変更

勝手にリビジョン記事とかになってる場合、面白くないので通常記事にしてやる話。
wordpressのrevision記事を通常記事にDBから変更

親子カテゴリを階層表示にする

自動的にはならない。管理画面で設定が必要。
『外観』→『ウィジェット』で『カテゴリー』を開く。
そこにある『階層を表示』をチェックする。

他にも『ドロップダウン表示』『投稿数を表示』とかあるんだね。

画像の標準保存場所を変更

デフォルトで『wp-content/uploads/年/月』フォルダ内になっている。

年月ベースをやめるだけなら、管理画面『設定』→『メディア』の先で
『アップロードしたファイルを年月ベースのフォルダに整理』のチェックを外す。

自分の指定したフォルダ(仮として『aaa』)に入れたいとするなら
上記紹介の『全オプション変更の隠しページ』にて
『upload_path』：『wp-content』を含むディレクトリから指定フォルダまでのパスを入力。
　例：wp-content/aaa
『upload_url_path』：指定フォルダまでの完全なURLを入力
　例：http://example.com/wp-content/aaa

そして『設定』→『メディア』の先に追加されている
『アップロードするファイルの保存場所』『ファイルへの完全な URL パス』に
先ほどの指定した内容が記載されていることを確認する。

または
wp-config.phpに『define("UPLOADS", "XXX");』を追加
　例：define("UPLOADS", "../aaa");

いずれの場合も、失敗した場合、失敗した時点で、フォルダ権限を755なり変更してください。

ファイルUP容量を突破

ファイルのUploadで容量制限がかかるのは『php.ini』の設定をそのまま使っているから。
インポートでも似た問題が起きる。
解決方法は『.htaccess』に以下のような設定を書き足す。

php_value memory_limit 34M
php_value post_max_size 33M
php_value upload_max_filesize 32M
php_value max_execution_time 600

数値は自分で考えて、増やすなりしてください。
尚、Flashアップローダーは、別の制限なので解決出来ない様子。
まぁ、最近使わないから問題ないよね！

参照：WordPressのインポート機能で2MB制限を突破する方法 - IDEA*IDEA ～ 百式管理人のライフハックブログ

memory sizeエラー

ダッシュボードで外部からニュース的なものを読み込んでる際に
『# Fatal error: Allowed memory size of XXXX bytes exhausted (tried to allocate XXXX bytes)』
のようなエラーが出る場合、メモリが足りてない。
SQLiteだからの可能性があり、皆が足りないワケではないと思う。

『.htaccess』に下記を書き足す。

php_value memory_limit 100M

自分の環境では40Mでもエラーが出たため、少し大きめに100Mとした。
※『php.ini』で設定でもいいが、影響を考えると『.htaccess』の方がいいと思う。

ディレクトリ変更によるURL変更

一度作成した後、フォルダ名変更した場合での変更方法。
仮として現在の置き場が『/wordpress』、変更後が『/wp』とする。

『設定』→『一般設定』にて
『WordPress のアドレス (URL)』『ブログのアドレス (URL)』の2つを
『/wordpress』から『/wp』に変更。
更新後、遷移するページが『404エラー』になればOK。

サーバに置かれたフォルダを、FTPなどで手動で『wordpress』から『wp』に変更して完了。
『http://example.com/wp/』にてアクセスできることが確認出来ればOK。

WordPressのアドレスとサイトアドレス

get_bloginfo('url') // 表示『WordPressURL』
get_bloginfo('home') // 非推奨の↑。使わないほうが良い。
get_bloginfo('wpurl') // 表示『サイトURL』
get_bloginfo('siteurl') // 非推奨の↑。使わないほうが良い。
get_bloginfo('stylesheet_directory') // 使用中テーマのスタイルシートある場所のURL
get_bloginfo('stylesheet_url') // 使用中テーマのスタイルシートのURL
get_bloginfo('template_directory') // 使用中テーマのURL
site_url() //『WordPressURL』
home_url() //『サイトURL』
admin_url() // 管理画面URL
content_url() // wp-contentディレクトリのURL
ABSPATH // インストールPATH(≠URL)

『bloginfo('url')』は『echo home_url();』と『bloginfo('wpurl')』は『echo site_url();』と同義。
home_url()はprintやechoをしないと表示されないが、bloginfo()は表示される。
『$aa=XXX』のように代入目的なら、home_url()やsite_url()の方を使う。
『echo esc_url( site_url('/') );』とすると最後に『/』が付く。

仮としてインストールディレクトリは『/wordpress』とすると
『WordPressのアドレス（URL)』→『http://example.com/wordpress』
『サイトのアドレス（URL)』→『http://example.com』

『サイトのアドレス』なのに『site_url』じゃないとか気持ち悪いことである。
それのせいか『http://example.com』と『http://example.com/wordpress』の両方にwordpressを入れた場合、上記の設定では変な動きをする。

上位ディレクトリにて『RewriteCond %{REQUEST_URI} !(^/wordpress/)』と除外設定したところで解決しない。
テーマによるところもあるのかも知れないが、解決方法が不明で、誰か教えてほしいもの。

予約日時やdate関数がズレる

予約日時を過ぎても、記事が公開にならないことがある。
そして時間が9時間ずれていたりする。(UTC)

『.htaccess』に下記のように書いても無視される。

php_value date.timezone Asia/Tokyo

WordPress内部で設定してされているためなので当然である。
『設定』→『一般』の『タイムゾーン』のタブを『東京』に設定を変更する。

しかしdate()関数では9時間ズレた『2024-12-04 09:01:06』。
『wp-settings.php』の『date_default_timezone_set( 'UTC' );』が原因なので、
どうしてもdate関数が使いたいなら、今後の不安要素覚悟でコメントアウトとなる。

テンプレート等PHPで使う場合は、WordPress側に用意された『date_i18n』を使用する。

print(date_i18n("Y-m-d H:i:s"));

結果『2024-12-04 18:01:06』となり求めた時間になる。

参照：【date関数を使うとずれるので】WordPressで日時を扱うときは、この関数が便利でした | 今村だけがよくわかるブログ

wordpressのバージョンを表示

出力させる方法2つ

global $wp_version;
echo $wp_version;[code]
[code]bloginfo('version');

wordpressのSSL(https)化に変えた際に変更

サバ缶の相方の力でサーバのSSL化設定してくれて、自分は特に何もせずに解決した。
基本的にDBは変更しなくても問題ないが、wp_optionsのサイトURL等は直しておいた方が、プラグインが出力するURL関係で安心。
wp_postのguidは余裕がある日で大丈夫。
ひっそりhttpがwordpressのテーマの中に入っていたりすることがあるので注意。

ユーザ情報・ブログ情報の表示方法（マルチサイト対応）

仮として説明リスト表記しておく。

<?php
$acount_id = 1; // 表示したいユーザのID 
$show_user = new WP_User( $acount_id ); ?>
<dt><?php echo $show_user->nickname; ?></dt>
<dd style="text-align:center;">
	<?php echo nl2br($show_user->description); ?>
	<img src="<?php echo network_home_url(); ?>/img/<?php echo $acount_id; ?>.png" alt="<?php echo $show_user->nickname; ?>" width="90%" />
</dd>

$acount_idで取得したいユーザIDを指定して使う。
マルチサイトでもユーザを増やしているのでも無ければ、基本的には『1』で大丈夫。

解説すると『管理画面』→『ユーザ』の『プロフィール』
$show_user->nickname　：　名前
$show_user->description　：　プロフィール情報。nl2brでテキスト改行をhtml改行に変換。
network_home_url()　：　マルチサイトでも使える大元HOMEのURL。

メンテナンスモード

WordPressのインストールディレクトリに『.maintenance』置いておくと、フロントにはアクセスできない『メンテナンスモード』になる。
公開中の物を変更する場合などに便利。
このファイルを削除しないと、公開状態に戻せないので忘れずに消すこと！

コメント

タイトルとURLをコピーしました