• 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。(詳細

このWikiはいつでも誰でも編集できます

「FAQ/トラブルシューティング」の版間の差分

提供: WordPress Codex 日本語版
< FAQ
移動先: 案内検索
(英文に書かれていたプラグインそのものが2005年の古いものでNotFoundになっていた。codex-searcherという名前のもの。なので、まず英文の方を削除。そのあと日本語の方も編集しました)
(最新英語版を反映、和訳完了 en:FAQ Troubleshooting 14:20, 26 March 2016‎ Atachibana版)
1行目: 1行目:
 
[[FAQ|Back to FAQ]]
 
[[FAQ|Back to FAQ]]
 
{{NeedTrans|一部}}
 
  
 
__TOC__
 
__TOC__
  
 
<div id="Why_can.27t_I_see_my_posts.3F_All_I_see_is_Sorry.2C_no_posts_match_your_criteria.3F">
 
<div id="Why_can.27t_I_see_my_posts.3F_All_I_see_is_Sorry.2C_no_posts_match_your_criteria.3F">
==「該当する投稿は見つかりませんでした」と表示されるだけで投稿が見えないのはなぜですか?==
+
==「該当する投稿は見つかりませんでした」と表示されるだけで投稿が見えないのはなぜですか ?==
 
</div>
 
</div>
  
16行目: 14行目:
  
 
<div id="How_do_I_find_more_help.3F">
 
<div id="How_do_I_find_more_help.3F">
==ヘルプが必要な場合はどうすればいいですか?==
+
==ヘルプが必要な場合はどうすればいいですか ?==
 
</div>
 
</div>
  
25行目: 23行目:
 
* [[サポートフォーラムの利用]]
 
* [[サポートフォーラムの利用]]
 
* [[Technical Articles|WordPressに関する技術情報]] /[[:en:Technical Articles|en]]
 
* [[Technical Articles|WordPressに関する技術情報]] /[[:en:Technical Articles|en]]
* [[Troubleshooting#Installation_Problems|インストール時の問題]] /[[:en:Troubleshooting#Installation_Problems|en]]
+
* [[トラブルシューティング#Installation_Problems|インストール時の問題]]
  
 
<div id="Where_can_I_find_help_with_the_CSS_problems_I.27m_having.3F">
 
<div id="Where_can_I_find_help_with_the_CSS_problems_I.27m_having.3F">
===CSS 関連の問題のヘルプを得るには?===
+
===CSS 関連の問題のヘルプを得るには ?===
 
</div>
 
</div>
  
40行目: 38行目:
  
 
<div id="Why_does_the_password_emailed_to_me_look_weird.3F">
 
<div id="Why_does_the_password_emailed_to_me_look_weird.3F">
 
==メールで届いたパスワードがおかしいのはなぜですか?==
 
</div>
 
 
If the password emailed to you looks strange, see [http://allnarfedup.com/2004/11/10/solving-garbled-text/ Solving Garbled Text].
 
  
 
<div id="Why_do_I_get_an_error_message_about_Sending_Referrers.3F">
 
<div id="Why_do_I_get_an_error_message_about_Sending_Referrers.3F">
==''リファラー送信''関連のエラーメッセージが表示されるのはなぜですか?==
+
==「リファラー送信」関連のエラーメッセージが表示されるのはなぜですか ?==
 
</div>
 
</div>
  
If you got this message when trying to save a post, consider checking [[管理パネル|Administration]] > [[管理パネル#General|Settings]] > [[Settings General SubPanel|General]] and make sure both your '''WordPress address (URI)'''  and the '''Blog address (URI)''' do not use 'www'.  For example, instead of '''<nowiki>http://www.example.com</nowiki>''' use '''<nowiki>http://example.com</nowiki>''' in those fields.  This information orginally reported via http://wordpress.org/support/topic/72235
+
投稿を保存する際にこのメッセージが表示される場合、[[管理画面]] > [[管理画面#General|設定]] > [[管理画面/一般設定|一般設定]] を開き、「WordPress アドレス (URL)」と「サイトアドレス (URL)」の両方に「www」が使われていないことを確認してください。たとえば「<nowiki>http://www.example.com</nowiki>」の代わりに「<nowiki>http://example.com</nowiki>」を使用してください。この情報は http://wordpress.org/support/topic/72235 で最初に報告されました。
  
 
参照:
 
参照:
 
* [[Enable Sending Referrers|リファラー送信の有効化]]
 
* [[Enable Sending Referrers|リファラー送信の有効化]]
 
<div id="Are_there_are_any_problems_with_using_MySQL_4.1.7_for_WordPress.3F">
 
==MySQL 4.1.7 を WordPress に使う際に何か問題はありますか?==
 
</div>
 
 
参照: [[FAQ/インストール#Can_I_install_WordPress_on_Windows_2000.3F|Windows 2000 に WordPress をインストールできますか?]]
 
  
 
<div id="How_do_I_empty_a_database_table.3F">
 
<div id="How_do_I_empty_a_database_table.3F">
==データベーステーブルを空にするには?==
+
==データベーステーブルを空にするには ?==
 
</div>
 
</div>
  
69行目: 56行目:
  
 
<div id="How_do_I_fix_the_following_error_SQL.2FDB_Error_errcode_13_Can.27t_create.2Fwrite_to_file.3F">
 
<div id="How_do_I_fix_the_following_error_SQL.2FDB_Error_errcode_13_Can.27t_create.2Fwrite_to_file.3F">
==''SQL/DB Error errcode 13 Can't create/write to file'' というエラーを解決するには?==
+
==''SQL/DB Error errcode 13 Can't create/write to file'' というエラーを解決するには ?==
'''Problem:''' The MySQL variable <tt>tmpdir</tt> is set to a directory that cannot be written to when using PHP to access MySQL.
+
'''問題:''' PHP を使用して MySQL にアクセスする際、MySQL 変数 <tt>tmpdir</tt> が書き込みできないディレクトリに設定されています。
  
To verify this, enter MySQL at the command line and type <tt>show variables</tt>;
+
この問題を確認するには MySQL コマンドラインで <tt>show variables</tt> を実行します。
  
You'll get a long list and one of them will read: '''tmpdir = /somedir/''' (whatever your setting is.)
+
長いリストが表示されますが、その中に「'''tmpdir = /somedir/'''(ディレクトリ名は異なります)のような行が含まれます。
  
'''Solution:''' Alter the '''tmpdir''' variable to point to a writable directory.
+
'''解決策:''' '''tmpdir'''」変数を変更し、書き込み可能なディレクトリを指定します。
 
+
'''Steps:'''
+
'''手順:'''
 
<ol>
 
<ol>
<li>Find the '''my.cnf''' file. On *nix systems this is usually in '''/etc/'''.</li>
+
<li>'''my.cnf'''」ファイルを探します。*nix システムであれば通常「'''/etc/'''」の下です。Windows システムであれば「'''my.ini'''」ファイルを探します。</li>
<li>Once found, open this in a simple text editor and find the '''[mysqld]''' section.</li>
+
<li>テキストエディタでこのファイルを開き、'''[mysqld]''' セクションを探します。</li>
<li>Under this section, find the '''tmpdir''' line. If this line is commented (has a '''#''' at the start), delete the '''#''' and edit the line so that it reads: '''tmpdir = /writable/dir''' where '''/writable/dir''' is a directory to which you can write. Some use '''/tmp''', or you might also try '''/home//'''.
+
<li>セクションの中で「'''tmpdir'''」行を探します。行頭に「'''#'''」でコメントアウトされていれば「'''#'''」を削除し、「'''tmpdir = /writable/dir'''」と書き換えます。ここで「'''/writable/dir'''」は書き込み可能なディレクトリです。一般に「'''/tmp'''」または「'''/var/tmp'''」、「'''/usr/tmp'''」を指定します。Windows であれば「'''C:/Windows/tmp'''」を指定します。
</li>
+
<li>Save the file.</li>
+
<li>Shutdown MySQL by typing <tt>mysqlshutdown -u -p shutdown</tt>.</li>
+
<li>Start MySQL by going to the MySQL directory and typing <tt>./bin/safe_mysqld &</tt>. Usually the MySQL directory is in '''/usr/local''' or sometimes in '''/usr/''' on Linux systems.
+
 
</li>
 
</li>
 +
<li>ファイルを保存します。</li>
 +
<li>MySQL をシャットダウンします。「<tt>mysqlshutdown -u -p shutdown</tt>」を実行してください。</li>
 +
<li>MySQL を起動します。MySQL ディレクトリに移動し「<tt>./bin/safe_mysqld &</tt>」を実行します。 Linux システムであれば通常 MySQL ディレクトリは「'''/usr/local'''」または「'''/usr/'''」です。</li>
 
</ol>
 
</ol>
If none of this make sense and you have someone to administrate your system for you, show the above to them and they should be able to figure it out.
+
 
 +
問題が解決しない場合、システム管理者がいれば上のエラーおよび手順を伝え、修復を依頼してください。
  
 
<div id="How_do_I_solve_the_Headers_already_sent_warning_problem.3F">
 
<div id="How_do_I_solve_the_Headers_already_sent_warning_problem.3F">
==''Headers already sent'' エラーを解決するには?==
+
==''Headers already sent'' エラーを解決するには ?==
 
</div>
 
</div>
'''Description:''' You get a warning message on your browser that says:
+
'''詳細:''' ブラウザ上に次の警告メッセージが表示されます:
  
 
<tt>Warning: Cannot modify header information - headers already sent by
 
<tt>Warning: Cannot modify header information - headers already sent by
 
(output started at</tt>
 
(output started at</tt>
 +
<br />
 +
(警告: ヘッダー情報を変更できません。ヘッダーは以下で送信されました。以下、ファイル名、行番号が表示される)
 +
 +
'''原因と解決策:'''
  
'''Reason and Solution :'''
+
恐らく開始タグ「'''<tt><?php</tt>'''」の前、または終了タグ「'''<tt>?></tt>'''」の後に空白文字、改行、その他の文字が含まれています。一般には「'''wp-config.php'''」の中ですが、その他のファイルの場合もあります。エラーメッセージを確認すると、エラーの発生したファイル名が表示されています(以下の「エラーメッセージの解釈」を参照してください)。エラーの発生したファイルを最新のバックアップ、または新規にダウンロードした WordPress 内のファイルで置き換えてください。これが最良の方法になります。ただそれが難しい場合は以下の手順に従ってください。
  
It is usually because there are spaces, new lines, or other stuff before an opening '''<tt><?php</tt>''' tag or after a closing '''<tt>?></tt>''' tag, typically in '''wp-config.php'''. This could be true about some other file too, so please check the error message, as it will list the specific file name where the error occurred (see "Interpreting the Error Message" below).  Replacing the faulty file with one from your most recent backup or one from a fresh WordPress download is your best bet, but if neither of those are an option, please follow the steps below.
+
人間の目に見えないからと言って、PHP からも同様だとは言い切れません。
  
Just because you cannot see anything does not mean that PHP sees the same.
+
# [[FTP クライアント|FTP]] またはプロバイダの管理パネル付属のファイルマネージャーを使用して、エラーメッセージ内に示されたファイルをダウンロードしてください。
 +
# [[用語集#.E3.83.86.E3.82.AD.E3.82.B9.E3.83.88.E3.82.A8.E3.83.87.E3.82.A3.E3.82.BF|テキストエディタ]]でファイルを開いてください。Microsoft Word 等のワープロソフトは'''使えません'''。メモ帳や BBEdit は使えます。
 +
# ファイルの''先頭''が '''<tt><?php</tt>''' であることを確認してください。
 +
# ファイルの''末尾''が PHP の終了タグ「'''<tt>?></tt>'''」ではないか、または終了タグ「'''<tt>?></tt>'''」の場合、後続に改行や空白文字がないことを確認してください。
 +
# ファイルの保存前に、ファイルのエンコーディングが「'''<tt>UTF-8 BOM</tt>'''」ではなく、単純な「'''<tt>UTF-8</tt>'''」か、または同様の'''<tt>BOM</tt>''' 接尾辞なしのものであることを確認してください。
  
# Download the file mentioned in the error message via [[FTP Clients|FTP]] or the file manager provided in your host's control panel.
+
ファイルの末尾を確認するには次の手順に従ってください。
# Open that file in a [[Glossary#Text editor|plain text editor]] ('''NOT''' MS Word or similar. Notepad or BBEdit are fine).
+
# ? と > の間にカーソルを置いてください。
# Check that the ''very'' first characters are '''<tt><?php</tt>'''
+
# DELETE キーを押してください。
# Check that the ''very'' last characters are either '''NOT''' a PHP closing tag or a closing tag '''<tt>?></tt>''' with no blank lines or spaces after it.
+
#* Mac ユーザーへの注意: PC 上の "DELETE" キーはカーソルの''右側''の文字を削除します。
# Before saving, or use the Save as dialog, ensure the file encoding is not '''<tt>UTF-8 BOM</tt>''' but plain '''<tt>UTF-8</tt>''' or any without the '''<tt>BOM</tt>''' suffix.
+
# キーを押し続けてください、
 +
# 少なくとも15秒間。
 +
# そして > を入力してください。
 +
# 他のキーはまったく触らずにファイルを'''保存'''してください、
 +
# 他のキーを押すとまた問題が発生するかもしれません。
 +
# 不要なコードブロックを作成しないでください。単一の PHP ブロック内で記述してください。
  
To be sure about the end of the file, do this:
+
間違い:<pre>
#Place the cursor between the ? and >
+
#Now press the DELETE key on your computer
+
#*Note to MAC users: The "DELETE" key on a PC deletes characters to the ''right'' of the cursor.  That is the key noted here.
+
#Keep that key pressed
+
#For at least 15 seconds
+
#Now type > and
+
#'''save''' without pressing any other key at all.
+
#If you press another key, you will bring the problem back.
+
# DO '''NOT''' PUT CODE IN UNNECESSARY CODE BLOCKS, PUT THEM IN A SINGLE PHP BLOCK.
+
Wrong:<pre>
+
 
<?php
 
<?php
some code;
+
あるコード;
 
?>
 
?>
  
 
<?php
 
<?php
some other codes;
+
別のコード;
 
?>
 
?>
 
</pre>
 
</pre>
  
Correct:<pre>
+
正しい:<pre>
 
<?php
 
<?php
code;
+
あるコード;
  
some other code;
+
別のコード;
 
?>
 
?>
 
</pre>
 
</pre>
  
 +
サーバーの元の場所に、編集し保存したファイルをアップロードしてください。
  
Upload the file back to your server after editing and saving the file.
+
'''注意''': ファイルのエンコーディングも確認してください。BOM 付きの UTF-8 でファイルをエンコードすると、BOM が出力の開始文字とみなされます。
  
'''Note''': Also check the encoding of the file. If the file is encoded as UTF-8 with BOM, the BOM is seen as a character which starts the output.
 
  
 +
'''エラーメッセージの解釈:'''
  
'''Interpreting the Error Message:'''
+
例えばエラーメッセージが
 +
<pre>Warning: Cannot modify header information - headers already sent by (output started at /path/blog/wp-config.php:34) in /path/blog/wp-login.php on line 42</pre>
 +
の場合、問題は <code>wp-config.php</code> の34行目で発生しています。<code>wp-login.php</code> の 42行目ではありません。このシナリオで <code>wp-login.php</code> の 42行目は犠牲者です。<code>wp-config.php</code> の34行目の余分な空白文字の影響を受けています。
  
If the error message states: <code>Warning: Cannot modify header information - headers already sent by (output started at /path/blog/wp-config.php:34) in /path/blog/wp-login.php on line 42</code>, then the problem is at line #34 of <code>wp-config.php</code>, not line #42 of <code>wp-login.php</code>.  In this scenario, line #42 of <code>wp-login.php</code> is the victim.  It is being affected by the excess whitespace at line #34 of <code>wp-config.php</code>.
+
エラーメッセージが
 +
<pre>Warning: Cannot modify header information - headers already sent by (output started at /path/wp-admin/admin-header.php:8) in /path/wp-admin/post.php on line 569</pre>
 +
の場合、問題は <code>admin-header.php</code> の8行目で発生しています。<code>post.php</code> の 569行目ではありません。このシナリオで <code>post.php</code> の 569行目は犠牲者です。<code>admin-header.php</code> の8行目の余分な空白文字の影響を受けています。
  
If the error message states: <code>Warning: Cannot modify header information - headers already sent by (output started at /path/wp-admin/admin-header.php:8) in /path/wp-admin/post.php on line 569</code>, then the problem is at line #8 of <code>admin-header.php</code>, not line #569 of <code>post.php</code>.  In this scenario, line #569 of <code>post.php</code> is the victim.  It is being affected by the excess whitespace at line #8 of <code>admin-header.php</code>.
+
'''同じエラーが起きるその他の問題:'''
  
'''Other issues that might cause that error:'''
+
関数 wp_redirect() の呼び出しや、ヘッダーまたは任意のコンテンツの送信後にヘッダーリダイレクトを使用しても同じエラーメッセージが表示されます。この場合、リダイレクトが必要であれば代わりに JavaScript リダイレクションを使用してください。
  
In case you've used the function: wp_redirect() or tried to use a header redirect after the header (or any content at all was sent) that error message will pop. Instead use javascript redirection if needed.
+
==「公開」や「下書きとして保存」ボタンが動作しません。==
  
==Safari ブラウザでビジュアルリッチエディターやクイックタグボタンが使えないのはなぜですか?==
+
この問題や同様の問題を解決するにはプラグインを1つずつ無効化して、問題の原因を探します。一般にこの問題は2つ以上のプラグインが、JQuery や他の Java ベースツールなどの同じリソースの使用を試みて発生します。
 +
 
 +
またブラウザに問題がある場合もあります。まずブラウザのキャッシュを削除してください。手順については各ブラウザのドキュメントを参照してください。
 +
 
 +
==Apple の Safari ブラウザでビジュアルリッチエディターやクイックタグボタンが表示されないのはなぜですか ?==
 
</div>
 
</div>
  
164行目: 163行目:
 
</div>
 
</div>
  
'''Description:''' When users try to register with your blog or change their passwords by entering their username and/or email, WordPress indicates that their password has been emailed to them, but it is never received.
+
'''詳細:''' ユーザーがユーザー名やメールアドレスを指定してブログに登録したりパスワードを変更したところ、メールでパスワードが送信された旨の通知がありましたが、メールが届きません。
  
'''Reason and Solutions:''' WordPress uses the standard PHP mail() function, which uses sendmail. No account information is needed. This is not generally a problem if you are using a hosting service, but if you are using your own box and do not have an SMTP server, the mail will never send. If you are using a *NIX box, you should have either postfix or sendmail on your machine; you will just need to set them up (search the Internet for how-to's). If you do not want to go through setting up a complete mail server on your *NIX box you may find [http://packages.debian.org/stable/mail/ssmtp| ssmtp] useful -- it provides ''"A secure, effective and simple way of getting mail off a system to your mail hub"''. On a Windows machine, try a sendmail emulator like [http://glob.com.au/sendmail/| Glob SendMail].
+
'''原因と解決策''': WordPress は通常の PHP mail() 関数を使用し、mail() は sendmail を使用します。アカウント情報は必要ありません。一般にホスティングサービスを使用している場合、これは問題になりませんが、個別にサーバーを立てていて SMTP サーバーがない場合、メールは送信されません。*NIX を使用している場合、サーバー上に postfix または sendmail が必要です。ネットで手順を検索しセットアップしてください。*NIX 環境で完全なメールサーバーを構築したくなければ [http://packages.debian.org/stable/mail/ssmtp ssmtp] が便利でしょう。「システムからメールハブにメールを送信する安全で効果的で単純な方法」だそうです。Windows 環境では [http://glob.com.au/sendmail/| Glob SendMail] などの sendmail エミュレータを試してください。
  
More help can be found on this thread of the WordPress Support Forums: http://wordpress.org/support/topic.php?id=24981 For a plugin based alternative, you could try [http://coffee2code.com/wp-plugins/configure-smtp/| Configure SMTP]: ''"Configure SMTP mailing in WordPress, including support for sending e-mail via SSL/TLS (such as GMail)."''
+
より詳細な情報については WordPress サポートフォーラムの次のスレッドを参照してください。http://wordpress.org/support/topic.php?id=24981
  
'''Windows Host Server Specific:''' With the Configure SMTP plugin you can work around the issue of e-mails not being received. Alternately, check your "Relay" settings on the SMTP Virtual Server. Grant access to <tt>127.0.0.1</tt> . Then in your ''php.ini'' file, set the <tt>SMTP</tt> setting to the same IP address. Also set  <tt>smtp_port</tt> to <tt>25</tt>.
+
'''Windows ホスティングサーバー固有の情報''': SMTP 仮想サーバーの「Relay」設定を確認し <tt>127.0.0.1</tt> のアクセスを許可してください。次に「''php.ini''」ファイル内で <tt>SMTP</tt> を同じ IP アドレスに設定してください。また <tt>smtp_port</tt> <tt>25</tt>に設定します。
  
'''Ensure Proper Return Address is Used:''' By default, the WordPress mailer fills in the From: field with ''wordpress@yourdomain.com'' and the From: name as ''WordPress''.
+
'''返信用アドレスの確認:''' デフォルトで WordPress のメイラーは From: フィールドを「''wordpress@yourdomain.com''」、From: の名前を「''WordPress''」とします。
  
This is fine if this is a valid e-mail address. For example, if your real e-mail is ''wordpress@yourdomain.com'', your host should pass the email on for delivery. It will probably send your mail as long as ''yourdomain.com'' is setup to send and receive mail, even if ''wordpress'' is not a valid mail box. But if you set you real email as the From: address and it's something like ''wpgod@gmail.com'', the mail may not send because ''gmail.com'' is not a domain handled by the mail server.
+
これが正しいメールアドレスであれば OK です。たとえば本当のメールアドレスが「''wordpress@yourdomain.com''」で、ホストがメールを送信するとします。この場合、「''yourdomain.com''」でメールを送受信するよう設定していれば恐らく「''wordpress''」が正しいメールアカウントでなくても送信されるはずです。しかし From: アドレスに本当のメールアドレス、例えば「''wpgod@gmail.com''」を設定すると、「''gmail.com'' はメールサーバーで処理可能なドメインでないため、メールが送信されない場合があります。
  
When using the plugin Configure SMTP the same applies, and there is an option to hard code the From: address. You can also use <tt>'wp_mail_*'</tt> filters to change the From: address and name used. It's strongly suggested you do this because people involved with several blogs may get email from all of those blogs, and each of them likely is From: ''WordPress''. Make your blog stand out as different!
+
'''迷惑メールとして処理された:''' メールが迷惑メールフォルダ―に仕分けされたか、最悪の場合、害を与えるメールとして単純に削除されたのかもしれません。メールは正当であり、宛先に送信すべきであることを受け取り側メールサーバーに伝えるには、次のような方法があります。
  
<pre>function cdx_from_email() {
+
'''SPF:''' (Sender Policy Framework) もっともよく使用されている迷惑メール対策システムです。ホストコンピュータから使用中のメールサーバーに対して SPF が設定されているかどうかを確認できます。WordPress から自身にメールを送り、メッセージが SPF のチェックをパスした証拠をメッセージヘッダーの中に確認してください。ログインページの「パスワードをお忘れですか ?」リンクに従うとメッセージを受信できます。今のパスワードを変えたくなければ、メッセージ内のリンクをクリックしないでください。
return "wpgod@yourdomain.com";
+
}
+
add_filter( 'wp_mail_from', 'cdx_from_email' );
+
function cdx_from_name() {
+
return "WPGod";
+
}
+
add_filter( 'wp_mail_from_name', 'cdx_from_name' );</pre>
+
Use the above code by adding it to your theme or child theme ''functions.php'' file.
+
  
'''Treated as Spam:''' Your email message may have been routed to a spam folder or even worse, simply discarded as malicious. There are a couple measures you can use to convince recipient's mail servers that your message is legitimate and should be delivered as addressed.
+
メールが SPF のチェックに失敗している場合、DNS レコードへのアクセス権を持ち、メールサーバーのドメインを保持していれば認証情報を設定できます。システムが送信したメールの Return-Path を確認してください。メールサーバーのリストの中にドメイン名が含まれていれば、SPF の認証情報を設定できます。ネット上で手順を検索してください。
  
'''SPF:''' (Sender Policy Framework) This is the most common anti-spam measure used. If you are on a hosted system, there is a good chance your host has set this up for the mail server you are using. Have Wordpress email you and check the message headers for evidence that the message passed the SPF check. You can get a message sent by following the Forgot Password link on the login page. To keep your old password, do not follow the link in the message.
+
'''DKIM:''' (Domain Key Identified Mail) このシステムもよく使用されています。同じメッセージに SPF と DKIM の両方を使用できます。DKIM も SPF の場合と同様、メールヘッダーを調べることで受け取り側メールサーバーがホストのドメインキーを正当とみなしたかどうかを確認できます。多くの場合、ホストでこのプロトコルを使用しておらず、したがって署名鍵がありません。SPF と同じように、DNS レコードを編集でき、メールサーバーがドメインに属していれば DKIM 認証を自分でセットアップできます。ネットを検索し、手順に従ってください。
If your system email failed the SPF check, you can set up the credentials if you have access to your DNS records and your mail server's domain belongs to you. Check the return path of the email your system sent. If the mail server listed there has your domain name, you can set up SPF credentials. There are several how-tos on the Internet.
+
  
'''DKIM:''' (Domain Key Identified Mail) This system is also used. You can use both SPF and DKIM in the same message. Again, just as with SPF, you can check if your receiving mailserver verified your host's domain key by examining the mail header. There is a fair chance no signature key was provided, indicating your host chose to not use this protocol. Also as with SPF, if you can edit your DNS records and the mail server belongs to your domain, you can set up DKIM credentials yourself. Some how-tos exist if you search the Internet.
+
WordPress から正しくDKIM キーを送信するには、<tt>'phpmailer_init'</tt> アクションをフックします。<tt>$phpmailer</tt> オブジェクトが渡されますので、必要なプロパティを設定し、オブジェクトを返してください。詳細についてはクラスのソースコードを参照してください。''wp-includes/class-phpmailer.php'' にあります。
 
+
To get WordPress to send the proper DKIM keys, hook the <tt>'phpmailer_init'</tt> action. You are passed the <tt>$phpmailer</tt> object. Set the necessary properties and return the object. See the class source code for more information. It's on ''wp-includes/class-phpmailer.php'' .
+
 
+
 
+
<div id="How_do_I_get_the_Quicktag_.3C.21--nextpage--.3E_back.3F">
+
 
+
==クイックタグ <nowiki><!--nextpage--></nowiki> をエディタに表示させるには?==
+
</div>
+
 
+
In some [[Using Themes|Themes]], such as the WordPress Classic Theme, you may see the <nowiki><!--nextpage--></nowiki> work properly on your main page, but other [[Using Themes|Themes]], such as the WordPress default Theme,  may only show the ''page break'' when viewing the posts individually.  It may be necessary to change your Theme's [[Templates|template]] ''page.php'' or ''index.php'' file to make this feature work according to your wishes.  You'll need to add the following:
+
<pre><?php wp_link_pages(); ?></pre>
+
  
 
<div id="I_used_the_Quicktag_.3C.21--nextpage--.3E_in_a_post_so_why_doesn.27t_it_work.3F">
 
<div id="I_used_the_Quicktag_.3C.21--nextpage--.3E_in_a_post_so_why_doesn.27t_it_work.3F">
  
==投稿内で <nowiki><!--nextpage--></nowiki> クイックタグを使いましたが動作しません。どうしてですか?==
+
==投稿内で <nowiki><!--nextpage--></nowiki> クイックタグを使いましたが動作しません。どうしてですか ?==
 
</div>
 
</div>
  
In some [[テーマの使い方|Themes]], such as the WordPress Classic Theme, you may see the <nowiki><!--nextpage--></nowiki> work properly on your main page, but other [[テーマの使い方|Themes]], such as the WordPress default Theme,  may only show the ''page break'' when viewing the posts individually. It may be necessary to change your Theme's [[テンプレート|template]] ''page.php'' or ''index.php'' file to make this feature work according to your wishes.  You'll need to add the following:
+
WordPress Classic テーマなどの[[テーマの使い方|テーマ]]ではメインページで <nowiki><!--nextpage--></nowiki> が正しく動作するが、WordPress のデフォルトテーマなどの[[テーマの使い方|テーマ]]では投稿を表示すると「改ページ」のみが表示される場合があります。これを解決するには「''page.php''」や「''index.php''」などのテーマ[[テンプレート|template]]ファイルを希望に応じて変更する必要があります。次のタブの追加が必要かもしれません。
 
<pre><?php wp_link_pages(); ?></pre>
 
<pre><?php wp_link_pages(); ?></pre>
  
 
<div id="MySQL_Error_28">
 
<div id="MySQL_Error_28">
  
== MySQL Error 28 ==
+
== MySQL エラー 28 ==
 
</div>
 
</div>
  
以下のようなエラーが表示される場合:
+
このエラーは一般に次の場合に発生します。
 
+
* /tmp あるいは tempdir の参照先のディスクに空き容量がない、または、
Error code 28: No space left on device
+
* /tmp に空き容量はあるが、大量のファイルが存在する
 
+
This is a MySQL error and has nothing to do with WordPress directly; you should contact your host about it. Some users have reported that running a "repair table" command in [[phpMyAdmin]] fixed the problem.
+
 
+
[http://www.mysql.com/newsletter/2003-10/a0000000249.html Error 28, and how to avoid it]:
+
 
+
<pre>
+
If you get this error, check all filesystems in
+
which MySQL operates. If you followed recommendations
+
to split datadir, tmpdir and log files into dedicated
+
filesystems, more than one filesystem is involved. In
+
addition, be aware that MySQL often creates temporary
+
tables for some queries. Most of these are placed in
+
tmpdir; however, some may be found in the database
+
directory (e.g. ALTER TABLE). Also, ensure that
+
sufficient free disk space is available for MySQL.
+
</pre>
+
 
+
It could be because:
+
* you are out of space on /tmp (wherever tmpdir is), or,
+
* you have too many files in /tmp (even if there is lots of free space)
+
 
+
Relevant discussion threads:
+
* http://wordpress.org/support/3/1738
+
* http://wordpress.org/support/3/2923
+
* http://wordpress.org/support/3/2760
+
  
 +
これは MySQL のエラーで WordPress から直接、何かできることはありません。ホスティング会社に相談してください。[[phpMyAdmin]] から「repair table」コマンドの実行で問題が解決したというユーザーもいました。
  
 
<div id="Why_are_the_Quote_Marks_escaped_or_not_escaped.3F">
 
<div id="Why_are_the_Quote_Marks_escaped_or_not_escaped.3F">
  
==引用符がエスケープされたりされなかったりしているのはなぜですか?==
+
==引用符がエスケープされたりされなかったりしているのはなぜですか ?==
 
</div>
 
</div>
  
If you write plugins, or use a plugin like [http://www.nosq.com/2004/10/runphp-wordpress-plugin/ RunPHP], or make advanced custom templates, you may eventually find yourself dealing with data in the database.  WordPress <em>usually</em> manages this data for you in such a way that it is immediately usable.  There are circumstances though (especially if you are dealing directly with the database without using WordPress) where you will experience weirdness.
+
プラグインや高度なカスタムテンプレートを作成していると、データベース内のデータを直接扱う場合があります。<em>通常は</em> WordPress が、すぐにデータを利用できるようデータを管理していますが、特に WordPress を使用せずに直接データベースを処理する場合などはこのような状況になり、面倒な思いをします。
  
For example, quote marks cannot be stored directly in the MySQL database. MySQL uses quote marks in its SQL language. When a quote mark is used, for example, in a post, When the post is saved to the database, every quote mark gets escaped. That means a backslash character is prepended, which signifies that the next character should be taken as part of the input, and not as part of the SQL command. 
+
たとえば引用符(<tt>'</tt>)は直接 MySQL データベースに保存できません。MySQL は SQL 言語で引用符を使用します。たとえば投稿の中で引用符が指定されると、データベース内にその投稿が保存される際、すべての引用符はエスケープされます。つまり引用符の前にバックスラッシュ文字(日本語環境では「\」文字)が付加され、次の文字を SQL コマンドの一部でなく、入力の一部として扱うよう伝えます。
  
For example, if you are adding the following in your post:
+
たとえば次の投稿を追加します。
  
 
<pre>...an article about "Happiness" is at  
 
<pre>...an article about "Happiness" is at  
264行目: 219行目:
 
if you would like to read it...</pre>
 
if you would like to read it...</pre>
  
Is actually imported into the database looking like this:
+
実際にはデータベースに次のようにインポートされます。
  
 
<pre>...an article about \"Happiness\" is at  
 
<pre>...an article about \"Happiness\" is at  
270行目: 225行目:
 
if you would like to read it...</pre>
 
if you would like to read it...</pre>
  
When pulling data out of the database, the backslashes may not always be automatically removed. If this becomes an issue, you can use the [http://jp.php.net/stripslashes stripslashes()] PHP function on the text.
+
データベースから直接データを取り出すと、バックスラッシュ文字が自動で除去されない場合があります。これが問題であれば、テキストに対して PHP 関数 [http://jp.php.net/stripslashes stripslashes()] を使用してください。
  
 
<div id="Why_do_I_get_a_blank_page_when_I_submit_a_comment.3F">
 
<div id="Why_do_I_get_a_blank_page_when_I_submit_a_comment.3F">
==コメントを投稿したときにページが真っ白になるのはなぜですか?==
+
==コメントを投稿したときにページが真っ白になるのはなぜですか ?==
 
</div>
 
</div>
'''Description:''' When anyone tries to comment on a post, the window goes blank and the comment doesn't appear to have been recognised by WordPress.
+
'''詳細:''' 投稿にコメントした際、画面が真っ白になり、WordPress に登録されたはずのコメントが表示されない。
 +
 
 +
'''原因と解決策:'''
 +
使用中のテーマにコメントフォームの重要な部分が抜けているため、コメントの参照している投稿が WordPress から分かりません。テーマの comment.php を調べ、フォームに次のコードがあることを確認してください。
  
'''Reason and Solution:'''
 
The Theme that you are using is missing a critical part of the comment form so WordPress doesn't know which post the comment refers to.  You need to check the comment.php in your Theme and ensure that the following code appears within the form.
 
 
<pre>
 
<pre>
 
<input type="hidden" name="comment_post_ID" value="<?php echo $id; ?>" />
 
<input type="hidden" name="comment_post_ID" value="<?php echo $id; ?>" />
 
</pre>
 
</pre>
  
Relevant discussion threads:
+
関連する議論のスレッド:
  
 
* http://wordpress.org/support/topic/38683
 
* http://wordpress.org/support/topic/38683
  
 
<div id="How_to_deactivate_all_plugins_when_not_able_to_access_the_administrative_menus.3F">
 
<div id="How_to_deactivate_all_plugins_when_not_able_to_access_the_administrative_menus.3F">
== 管理パネルにアクセスできないときに全プラグインを停止するには? ==
+
== 管理画面にアクセスできない場合にすべてのプラグインを停止するには ? ==
 
</div>
 
</div>
全てのプラグインを停止(無効化)しなければならないが、それを行なう管理パネルにアクセスできない場合があります。そんなときは、次のどちらかの方法で全プラグインを停止できます。
+
すべてのプラグインを停止 ( 無効化 ) しなければならないが、管理画面にアクセスできない場合があります。次のどちらかの方法ですべてのプラグインを停止できます。
 +
 
 +
[[phpMyAdmin]] を使用してすべてのプラグインを無効化する
  
* '''[[phpMyAdmin]]/[[:en:phpMyAdmin|en]] を使う方法'''
+
*# [[データベース概要#Table: wp_options|wp_options テーブル]]で、''option_name'' 列 ( フィールド ) の値が ''active_plugins'' の行を探す  
*# [[データベース概要#Table: wp_options|wp_options テーブル]]で、''option_name'' フィールド(カラム)の値が ''active_plugins'' の行を探す  
+
 
*# その行の ''option_value'' フィールドを '''a:0:{}''' に変更する
 
*# その行の ''option_value'' フィールドを '''a:0:{}''' に変更する
  
または、
+
または [[FTP Clients|FTP]] やホスティングサーバーの管理パネルのファイルマネージャーを使用して、プラグインフォルダーをリセットする。この方法ではプラグインのオプションはそのまま保持されますが、手動で再有効化する必要があります。
  
* '''中身が空の plugins ディレクトリを作る方法'''
+
# FTP やホスティングサーバーのファイルマネージャーから、wp-contents フォルダ (ディレクトリ) に移動する。
*# [[FTP クライアント]]またはホスト(レンタルサーバ)のコントロールパネルから、
+
# FTP やホスティングサーバーのファイルマネージャーから、フォルダ "plugins" "plugins.hold" に名前を変更する。
*## wp-contents ディレクトリ(フォルダ)へ移動する
+
# WordPress 管理画面のプラグインのページ /wp-admin/plugins.php にログインする。この操作により「見つからない」プラグインはすべて無効化されます。
*## "plugins" ディレクトリを "plugins.hold" にリネーム(名前を変更)する
+
# FTP やホスティングサーバーのファイルマネージャーから、フォルダ "plugins.hold" "plugins" に名前を戻す。
*## 新たに "plugins" というディレクトリを作成する(中身は空)
+
*# WordPress の管理パネルにログイン
+
*# [[FTP クライアント]]またはホスト(レンタルサーバ)のコントロールパネルから、
+
*## 上記 1-3 で作成した空の "plugins" ディレクトリを削除する
+
*## "plugins.hold" ディレクトリを "plugins" に戻す
+
  
 
<div id="How_to_clear_the_.22Briefly_unavailable_for_scheduled_maintenance.22_message_after_doing_automatic_upgrade.3F">
 
<div id="How_to_clear_the_.22Briefly_unavailable_for_scheduled_maintenance.22_message_after_doing_automatic_upgrade.3F">
  
==自動アップグレードの後に出てくる "Briefly unavailable for scheduled maintenance" というメッセージを消すには?==
+
==自動アップグレードの後に出てくる「現在メンテナンス中のため、しばらくの間ご利用いただけません。」または「Briefly unavailable for scheduled maintenance」というメッセージを消すには ?==
 
</div>
 
</div>
As part of the automatic upgrade WordPress places a file named <tt>.maintenance</tt> in the blog '''base''' folder (folder that contains the wp-admin folder). If that file exists, then vistors will see the message '''Briefly unavailable for scheduled maintenance. Check back in a minute.''' 
+
自動アップグレードの途中、WordPress はブログの '''ベース''' フォルダー (wp-admin フォルダーの親フォルダー ) にファイル「<tt>.maintenance</tt>」を作成します。このファイルが存在すると、ユーザーにメッセージ「現在メンテナンス中のため、しばらくの間ご利用いただけません。」または「Briefly unavailable for scheduled maintenance. Check back in a minute.」が表示されます。
  
 
このメッセージが訪問者に表示されないようにするには、<tt>.maintenance</tt> ファイルを削除するだけです。もし自動アップグレードに失敗した際は、再度実行できるはずです。
 
このメッセージが訪問者に表示されないようにするには、<tt>.maintenance</tt> ファイルを削除するだけです。もし自動アップグレードに失敗した際は、再度実行できるはずです。
319行目: 271行目:
  
 
<div id="How_to_fix_404_error_when_using_Pretty_Permalinks.3F">
 
<div id="How_to_fix_404_error_when_using_Pretty_Permalinks.3F">
==スラッグを含むパーマリンクを使った場合の404エラーを解決するには?==
+
==スラッグを含むパーマリンクを使った場合の404エラーを解決するには ?==
 
</div>
 
</div>
  
If an error 404 occurs when using the [[ブログ入門#Pretty_Permalinks|Pretty Permalink]] choices such as '''Day and Name''' in [[管理パネル]] > [[管理パネル#Settings|設定]] > [[Settings Permalinks SubPanel|パーマリンク設定]] it could be a result of the '''mod_rewrite''' module not being activated/installed.  The solution is to activate '''mod_rewrite''' for the Apache web-server.  Check the apache\conf\httpd.conf file for the line ''`# LoadModule rewrite_module modules/mod_rewrite.so''
+
[[管理画面]] > [[管理画面#Settings|設定]] > [[管理画面/パーマリンク設定|パーマリンク設定]] で「日付と投稿名」などの [[ブログ入門#Pretty_Permalinks|Pretty パーマリンク]] を使用すると 404 エラーが発生する場合があります。これは「'''mod_rewrite'''」モジュールが有効化されていないか、インストールされていないためです。解決するには Apache Web サーバーの「'''mod_rewrite'''」モジュールを有効化してください。まずファイル「apache\conf\httpd.conf」の行「''# LoadModule rewrite_module modules/mod_rewrite.so''」を確認し、先頭の「#」を削除します。次に Apache を停止し、再起動します。'''注意:''' mod_rewrite の有効化にはホスティング会社への連絡が必要な場合があります。
and delete the # in front of the line.  Then stop Apache and start it again.  '''Note:''' you may have to ask your host to activate mod_rewrite.
+
  
 
参照:
 
参照:
 
* [[パーマリンクの使い方]]
 
* [[パーマリンクの使い方]]
<!--
+
 
Relevant discussion thread:
+
関連する議論のスレッド:
* http://wordpress.org/support/topic/234726 -->
+
* http://wordpress.org/support/topic/234726
  
 
<div id="Why_isn.27t_the_admin_user_listed_as_an_author_when_editing_posts.3F">
 
<div id="Why_isn.27t_the_admin_user_listed_as_an_author_when_editing_posts.3F">
==投稿を編集する際に管理者が投稿者として表示されないのはなぜですか?==
+
==投稿を編集する際に管理者が投稿者として表示されないのはなぜですか ?==
 
</div>
 
</div>
Not sure why this problem happens, but here's a couple of things to try one of these two solutions.
 
  
This usually fixes the problem:
+
この問題が発生する原因は不明ですが、次の2つの方法のどちらかで解決する場合があります。
#Create new admin user (e.g. newadmin) with Administrator Role
+
 
#Login as 'newadmin'
+
ほとんどの場合、次の手順で解決します。
#Degrade the old 'admin' user to Role of Subscriber and Save
+
#「管理者」権限グループに属する新しい管理者ユーザーを作成する。例えば「newadmin」
#Promote the old 'admin' back to Administrator Role and Save
+
#作成した「newadmin」でログインする。
#Login as the old 'admin'
+
#古い「admin」ユーザーの権限グループを「購読者」に下げ、保存する。
 +
#古い「admin」ユーザーの権限グループを「管理者」に戻し、保存する。
 +
#古い「admin」ユーザーでログインする。
  
If that doesn't work, try:
+
上の手順でうまくいかない場合、次の手順を試してください。
#Create a new admin user (e.g. newadmin) with Administrator Role
+
 
#Login as 'newadmin'
+
#「管理者」権限グループに属する新しい管理者ユーザーを作成する。例えば「newadmin」
#Delete the old 'admin' user and assign any posts to 'newadmin'
+
#作成した「newadmin」ユーザーでログインする。
#Create 'admin' user with Administrator Role
+
#古い「admin」ユーザーを削除し、すべての投稿を「newadmin」に割り当てる。
#Login as 'admin'
+
#「管理者」権限グループに属する「admin」ユーザーを作成する。
#Delete 'newadmin' user and assign posts to 'admin'
+
#「admin」ユーザーでログインする。
 +
#「newadmin」を削除し、すべての投稿を「admin」ユーザーに割り当てる。
  
 
<div id="An_update_was_just_released.2C_so_why_does_my_blog_not_recognize_the_update_is_available.3F">
 
<div id="An_update_was_just_released.2C_so_why_does_my_blog_not_recognize_the_update_is_available.3F">
==アップグレードがリリースされた直後に管理画面で表示されないのはなぜですか?==
+
==最新バージョンがリリースされた直後に管理画面で表示されないのはなぜですか ?==
 
</div>
 
</div>
When an update is released, notification of that release is displayed at the top administration panels saying '''WordPress x.x.x is available! Please update now.'''  Not every blog will see that message at the same time.  Your blog is programmed to check for updates every 12 hours, but the timing of that check is purely random.  So if your blog just checked for updates minutes before an update was released, you won't see the update message until your blog checks for updates 12 hours later.
 
  
If you want your blog to check right now for updates, you can delete the '''update_core''' option name record in your ''wp_options'' table. Note that plugins and themes each have their own check and update cycle, controlled by the records '''update_plugins''' and '''update_themes''', in ''wp_options''.
+
最新バージョンがリリースされると管理画面の先頭に通知「WordPress x.x.x が利用可能です。更新してください」が表示されます。ただしこの通知はすべてのブログで同時には表示されません。プログラムは12時間ごとに更新を確認しますが、タイミングは完全にランダムです。このため最新バージョンのリリース直前に更新を確認した場合、12時間後に再び確認するまで通知メッセージは表示されません。
  
Relevant discussion thread:
+
システムからすぐに更新を確認するには、「''wp_options''」テーブルの「'''update_core'''」オプション名レコードを削除してください。注意: プラグインやテーマにもそれぞれ確認や更新の周期があります。これらは「''wp_options''」テーブルの「'''update_plugins'''」レコードや「'''update_themes'''」レコードで制御されます。
 +
 
 +
関連する議論のスレッド:
 
* http://wordpress.org/support/topic/242485  
 
* http://wordpress.org/support/topic/242485  
  
 
<div id="#Why_did_I_lose_custom_changes_to_the_WordPress_Default_Theme_during_the_last_automatic_upgrade.3F">
 
<div id="#Why_did_I_lose_custom_changes_to_the_WordPress_Default_Theme_during_the_last_automatic_upgrade.3F">
==自動アップグレードの際にどうして WordPress デフォルトテーマへの変更が消えてしまうのですか?==
+
==自動アップグレードの際にどうして WordPress デフォルトテーマへの変更が消えてしまうのですか ?==
 
</div>
 
</div>
A core upgrade copies all the new files from the distribution over the old ones, so if you changed existing files in the WordPress Default Theme (e.g. ''wp-content/themes/default/style.css''), those changes got overwritten with the new version of that file. 
+
コア (WordPress 本体) のアップグレードでは、パッケージ内のすべての新しいファイルで古いファイルを上書きします。既存の WordPres のデフォルトテーマ内のファイル、例えば ''wp-content/themes/twentysixteen/style.css'' を変更していた場合、変更は新しい同名のファイルで上書きされます。
  
Please note, a core upgrade goes through a list of "old files", as defined in ''wp-admin/includes/update-core.php'', and deletes those files. Any files not on the list, and not in the distribution, are preserved. 
+
注意: コアのアップグレードは ''wp-admin/includes/update-core.php'' で定義された「古いファイル」リストに従って行われ、削除されます。リストにないファイルや、パッケージに含まれないファイルは削除されません。
  
'''Remember, that before upgrades, whether automatic or manual, both the WordPress Files and database should be backed-up as explained in [[WordPress のバックアップ|WordPress Backups]].'''
+
'''注意: 自動であれ手動であれアップグレードの前には、「[[WordPress のバックアップ]]」に説明された方法で、WordPress ファイルおよびデータベースをバックアップしてください。'''
  
A better way to modify the default theme is by using a [[Child Themes|child theme]]. It's a little more work to set up, but worth the effort because your customizations will be safe when the main theme is updated.
+
デフォルトテーマを変更する場合は[[子テーマ]]を使用してください。セットアップに多少の手間は必要ですが、デフォルトテーマが更新されてもカスタマイズ内容は失われず安全です。
  
See also:
+
参照:
*[[WordPress のバックアップ|WordPress Backups]]
+
*[[WordPress のバックアップ]]
*[[Child Themes]]
+
*[[子テーマ]]
  
 
<div id="#How_do_you_repair_a_MySQL_database_table.3F">
 
<div id="#How_do_you_repair_a_MySQL_database_table.3F">
  
==MySQL データベーステーブルを修復するには?==
+
==MySQL データベーステーブルを修復するには ?==
 
</div>
 
</div>
Every once in a while, it may be necessary to repair one or more MySQL database tables.  According to the [http://dev.mysql.com/doc/refman/5.1/en/repair.html How to Repair Tables article at dev.mysql.com] there are a number of reasons to repair a table including errors such as "tbl_name.frm is locked against change",  "Can't find file tbl_name.MYI (Errcode: nnn)", "Unexpected end of file", "Record file is crashed", or "Got error nnn from table handler".
+
まれに 1つ以上の MySQL データベーステーブルの修復が必要な場合があります。[http://dev.mysql.com/doc/refman/5.7/en/myisam-repair.html dev.mysql.com の「MyISAM テーブルの修復方法」]によると、テーブルの修復が必要な様々な理由が挙げられています。「tbl_name.frm が変更に対してロックされます」「ファイル tbl_name.MYI が見つかりません (エラーコード: nnn)。」「予期しないファイルの終わり」「レコードファイルがクラッシュしました」「テーブルハンドラからエラー nnn を取得します」
  
Here are the steps to repair a table in a MySQL database using [[phpMyAdmin]]
+
[[phpMyAdmin]] を使用した MySQL データベーステーブルの修復手順は次のとおりです。
  
# Login to hosting account.
+
# ホスティングサーバーにログインする。
# Login to [[phpMyAdmin]].
+
# [[phpMyAdmin]] にログインする。
# Choose the affected database. If you only have one database, it should choose it by default so you don't need to do anything.
+
# 影響を受けたデータベースを選択する。データベースが1つしかない場合にはデフォルトで選択されているため、操作は不要です。
# In the main panel, you should see a list of your database tables. Check the boxes by the tables that need repair.
+
# メインパネルにデータベーステーブルのリストが表示されます。修復が必要なテーブルのチェックボックスをオンにする。
# At the bottom of the window just below the list of tables, there is a drop down menu. Choose "Repair Table"
+
# ウィンドウ末尾、テーブルのリストの下にドロップダウンメニューがあるので「テーブルを修復する」を選択する。
  
'''Remember, that it is advisable to have a current backup of your database at all times.
+
'''注意: どのような場合も、データベースの現在のバックアップを取得しておくことが最善の策です。
  
 
参照:
 
参照:
 
*[[WordPress のバックアップ]]  
 
*[[WordPress のバックアップ]]  
 
==Why can't I see the Widgets menu?==
 
The Widgets menu item will only appear if your site has a widgetized sidebar.
 
 
See also:
 
* [[WordPress Widgets]] 
 
  
  
 
[[FAQ|FAQに戻る]]
 
[[FAQ|FAQに戻る]]
  
{{原文|FAQ Troubleshooting|154439}}<!-- 04:38, 1 November 2015 Show-ko 版 -->
+
{{原文|FAQ Troubleshooting|156223}}<!-- 14:20, 26 March 2016‎ Atachibana版 -->
  
 
{{DEFAULTSORT:}}
 
{{DEFAULTSORT:}}
411行目: 359行目:
  
 
[[en:FAQ Troubleshooting]]
 
[[en:FAQ Troubleshooting]]
 +
[[ja:FAQ/トラブルシューティング]]
 +
[[pt-br:FAQ Resolvendo Problemas]]
 +
[[th:FAQ Troubleshooting]]
 
[[zh-cn:错误问题跟踪常见问题解答]]
 
[[zh-cn:错误问题跟踪常见问题解答]]

2016年3月26日 (土) 18:12時点における版

Back to FAQ

目次

「該当する投稿は見つかりませんでした」と表示されるだけで投稿が見えないのはなぜですか ?

ブラウザーのキャッシュと Cookie を削除すれば問題を解決できるかもしれません。また、search.php および index.php テンプレートファイルにエラーがないか確認してください。

参照:

ヘルプが必要な場合はどうすればいいですか ?

ここにあるFAQだけでなく、WordPressを使うために役立ついろいろな情報があります。

CSS 関連の問題のヘルプを得るには ?

CSSの問題を解決するのに役立つ記事

「リファラー送信」関連のエラーメッセージが表示されるのはなぜですか ?

投稿を保存する際にこのメッセージが表示される場合、管理画面 > 設定 > 一般設定 を開き、「WordPress アドレス (URL)」と「サイトアドレス (URL)」の両方に「www」が使われていないことを確認してください。たとえば「http://www.example.com」の代わりに「http://example.com」を使用してください。この情報は http://wordpress.org/support/topic/72235 で最初に報告されました。

参照:

データベーステーブルを空にするには ?

参照:

SQL/DB Error errcode 13 Can't create/write to file というエラーを解決するには ?

問題: PHP を使用して MySQL にアクセスする際、MySQL 変数 tmpdir が書き込みできないディレクトリに設定されています。

この問題を確認するには MySQL コマンドラインで show variables を実行します。

長いリストが表示されますが、その中に「tmpdir = /somedir/」(ディレクトリ名は異なります)のような行が含まれます。

解決策:tmpdir」変数を変更し、書き込み可能なディレクトリを指定します。

手順:

  1. my.cnf」ファイルを探します。*nix システムであれば通常「/etc/」の下です。Windows システムであれば「my.ini」ファイルを探します。
  2. テキストエディタでこのファイルを開き、[mysqld] セクションを探します。
  3. セクションの中で「tmpdir」行を探します。行頭に「#」でコメントアウトされていれば「#」を削除し、「tmpdir = /writable/dir」と書き換えます。ここで「/writable/dir」は書き込み可能なディレクトリです。一般に「/tmp」または「/var/tmp」、「/usr/tmp」を指定します。Windows であれば「C:/Windows/tmp」を指定します。
  4. ファイルを保存します。
  5. MySQL をシャットダウンします。「mysqlshutdown -u -p shutdown」を実行してください。
  6. MySQL を起動します。MySQL ディレクトリに移動し「./bin/safe_mysqld &」を実行します。 Linux システムであれば通常 MySQL ディレクトリは「/usr/local」または「/usr/」です。

問題が解決しない場合、システム管理者がいれば上のエラーおよび手順を伝え、修復を依頼してください。

Headers already sent エラーを解決するには ?

詳細: ブラウザ上に次の警告メッセージが表示されます:

Warning: Cannot modify header information - headers already sent by (output started at
(警告: ヘッダー情報を変更できません。ヘッダーは以下で送信されました。以下、ファイル名、行番号が表示される)

原因と解決策:

恐らく開始タグ「<?php」の前、または終了タグ「?>」の後に空白文字、改行、その他の文字が含まれています。一般には「wp-config.php」の中ですが、その他のファイルの場合もあります。エラーメッセージを確認すると、エラーの発生したファイル名が表示されています(以下の「エラーメッセージの解釈」を参照してください)。エラーの発生したファイルを最新のバックアップ、または新規にダウンロードした WordPress 内のファイルで置き換えてください。これが最良の方法になります。ただそれが難しい場合は以下の手順に従ってください。

人間の目に見えないからと言って、PHP からも同様だとは言い切れません。

  1. FTP またはプロバイダの管理パネル付属のファイルマネージャーを使用して、エラーメッセージ内に示されたファイルをダウンロードしてください。
  2. テキストエディタでファイルを開いてください。Microsoft Word 等のワープロソフトは使えません。メモ帳や BBEdit は使えます。
  3. ファイルの先頭<?php であることを確認してください。
  4. ファイルの末尾が PHP の終了タグ「?>」ではないか、または終了タグ「?>」の場合、後続に改行や空白文字がないことを確認してください。
  5. ファイルの保存前に、ファイルのエンコーディングが「UTF-8 BOM」ではなく、単純な「UTF-8」か、または同様のBOM 接尾辞なしのものであることを確認してください。

ファイルの末尾を確認するには次の手順に従ってください。

  1.  ? と > の間にカーソルを置いてください。
  2. DELETE キーを押してください。
    • Mac ユーザーへの注意: PC 上の "DELETE" キーはカーソルの右側の文字を削除します。
  3. キーを押し続けてください、
  4. 少なくとも15秒間。
  5. そして > を入力してください。
  6. 他のキーはまったく触らずにファイルを保存してください、
  7. 他のキーを押すとまた問題が発生するかもしれません。
  8. 不要なコードブロックを作成しないでください。単一の PHP ブロック内で記述してください。
間違い:
<?php
あるコード;
?>

<?php
別のコード;
?>
正しい:
<?php
あるコード;

別のコード;
?>

サーバーの元の場所に、編集し保存したファイルをアップロードしてください。

注意: ファイルのエンコーディングも確認してください。BOM 付きの UTF-8 でファイルをエンコードすると、BOM が出力の開始文字とみなされます。


エラーメッセージの解釈:

例えばエラーメッセージが

Warning: Cannot modify header information - headers already sent by (output started at /path/blog/wp-config.php:34) in /path/blog/wp-login.php on line 42

の場合、問題は wp-config.php の34行目で発生しています。wp-login.php の 42行目ではありません。このシナリオで wp-login.php の 42行目は犠牲者です。wp-config.php の34行目の余分な空白文字の影響を受けています。

エラーメッセージが

Warning: Cannot modify header information - headers already sent by (output started at /path/wp-admin/admin-header.php:8) in /path/wp-admin/post.php on line 569

の場合、問題は admin-header.php の8行目で発生しています。post.php の 569行目ではありません。このシナリオで post.php の 569行目は犠牲者です。admin-header.php の8行目の余分な空白文字の影響を受けています。

同じエラーが起きるその他の問題:

関数 wp_redirect() の呼び出しや、ヘッダーまたは任意のコンテンツの送信後にヘッダーリダイレクトを使用しても同じエラーメッセージが表示されます。この場合、リダイレクトが必要であれば代わりに JavaScript リダイレクションを使用してください。

「公開」や「下書きとして保存」ボタンが動作しません。

この問題や同様の問題を解決するにはプラグインを1つずつ無効化して、問題の原因を探します。一般にこの問題は2つ以上のプラグインが、JQuery や他の Java ベースツールなどの同じリソースの使用を試みて発生します。

またブラウザに問題がある場合もあります。まずブラウザのキャッシュを削除してください。手順については各ブラウザのドキュメントを参照してください。

Apple の Safari ブラウザでビジュアルリッチエディターやクイックタグボタンが表示されないのはなぜですか ?

旧版の Safari ブラウザは一部の機能に対応していません。最新版にアップグレードしてください。

パスワードリセットのメールが届きません。

詳細: ユーザーがユーザー名やメールアドレスを指定してブログに登録したりパスワードを変更したところ、メールでパスワードが送信された旨の通知がありましたが、メールが届きません。

原因と解決策: WordPress は通常の PHP mail() 関数を使用し、mail() は sendmail を使用します。アカウント情報は必要ありません。一般にホスティングサービスを使用している場合、これは問題になりませんが、個別にサーバーを立てていて SMTP サーバーがない場合、メールは送信されません。*NIX を使用している場合、サーバー上に postfix または sendmail が必要です。ネットで手順を検索しセットアップしてください。*NIX 環境で完全なメールサーバーを構築したくなければ ssmtp が便利でしょう。「システムからメールハブにメールを送信する安全で効果的で単純な方法」だそうです。Windows 環境では Glob SendMail などの sendmail エミュレータを試してください。

より詳細な情報については WordPress サポートフォーラムの次のスレッドを参照してください。http://wordpress.org/support/topic.php?id=24981

Windows ホスティングサーバー固有の情報: SMTP 仮想サーバーの「Relay」設定を確認し 127.0.0.1 のアクセスを許可してください。次に「php.ini」ファイル内で SMTP を同じ IP アドレスに設定してください。また smtp_port25に設定します。

返信用アドレスの確認: デフォルトで WordPress のメイラーは From: フィールドを「wordpress@yourdomain.com」、From: の名前を「WordPress」とします。

これが正しいメールアドレスであれば OK です。たとえば本当のメールアドレスが「wordpress@yourdomain.com」で、ホストがメールを送信するとします。この場合、「yourdomain.com」でメールを送受信するよう設定していれば恐らく「wordpress」が正しいメールアカウントでなくても送信されるはずです。しかし From: アドレスに本当のメールアドレス、例えば「wpgod@gmail.com」を設定すると、「gmail.com はメールサーバーで処理可能なドメインでないため、メールが送信されない場合があります。

迷惑メールとして処理された: メールが迷惑メールフォルダ―に仕分けされたか、最悪の場合、害を与えるメールとして単純に削除されたのかもしれません。メールは正当であり、宛先に送信すべきであることを受け取り側メールサーバーに伝えるには、次のような方法があります。

SPF: (Sender Policy Framework) もっともよく使用されている迷惑メール対策システムです。ホストコンピュータから使用中のメールサーバーに対して SPF が設定されているかどうかを確認できます。WordPress から自身にメールを送り、メッセージが SPF のチェックをパスした証拠をメッセージヘッダーの中に確認してください。ログインページの「パスワードをお忘れですか ?」リンクに従うとメッセージを受信できます。今のパスワードを変えたくなければ、メッセージ内のリンクをクリックしないでください。

メールが SPF のチェックに失敗している場合、DNS レコードへのアクセス権を持ち、メールサーバーのドメインを保持していれば認証情報を設定できます。システムが送信したメールの Return-Path を確認してください。メールサーバーのリストの中にドメイン名が含まれていれば、SPF の認証情報を設定できます。ネット上で手順を検索してください。

DKIM: (Domain Key Identified Mail) このシステムもよく使用されています。同じメッセージに SPF と DKIM の両方を使用できます。DKIM も SPF の場合と同様、メールヘッダーを調べることで受け取り側メールサーバーがホストのドメインキーを正当とみなしたかどうかを確認できます。多くの場合、ホストでこのプロトコルを使用しておらず、したがって署名鍵がありません。SPF と同じように、DNS レコードを編集でき、メールサーバーがドメインに属していれば DKIM 認証を自分でセットアップできます。ネットを検索し、手順に従ってください。

WordPress から正しくDKIM キーを送信するには、'phpmailer_init' アクションをフックします。$phpmailer オブジェクトが渡されますので、必要なプロパティを設定し、オブジェクトを返してください。詳細についてはクラスのソースコードを参照してください。wp-includes/class-phpmailer.php にあります。

投稿内で <!--nextpage--> クイックタグを使いましたが動作しません。どうしてですか ?

WordPress Classic テーマなどのテーマではメインページで <!--nextpage--> が正しく動作するが、WordPress のデフォルトテーマなどのテーマでは投稿を表示すると「改ページ」のみが表示される場合があります。これを解決するには「page.php」や「index.php」などのテーマtemplateファイルを希望に応じて変更する必要があります。次のタブの追加が必要かもしれません。

<?php wp_link_pages(); ?>

MySQL エラー 28

このエラーは一般に次の場合に発生します。

  • /tmp あるいは tempdir の参照先のディスクに空き容量がない、または、
  • /tmp に空き容量はあるが、大量のファイルが存在する

これは MySQL のエラーで WordPress から直接、何かできることはありません。ホスティング会社に相談してください。phpMyAdmin から「repair table」コマンドの実行で問題が解決したというユーザーもいました。

引用符がエスケープされたりされなかったりしているのはなぜですか ?

プラグインや高度なカスタムテンプレートを作成していると、データベース内のデータを直接扱う場合があります。通常は WordPress が、すぐにデータを利用できるようデータを管理していますが、特に WordPress を使用せずに直接データベースを処理する場合などはこのような状況になり、面倒な思いをします。

たとえば引用符(')は直接 MySQL データベースに保存できません。MySQL は SQL 言語で引用符を使用します。たとえば投稿の中で引用符が指定されると、データベース内にその投稿が保存される際、すべての引用符はエスケープされます。つまり引用符の前にバックスラッシュ文字(日本語環境では「\」文字)が付加され、次の文字を SQL コマンドの一部でなく、入力の一部として扱うよう伝えます。

たとえば次の投稿を追加します。

...an article about "Happiness" is at 
<a href="http://example.com/happy" title="Happiness">Happiness</a>
if you would like to read it...

実際にはデータベースに次のようにインポートされます。

...an article about \"Happiness\" is at 
<a href=\"http://example.com/happy\" title=\"Happiness\">Happiness</a>
if you would like to read it...

データベースから直接データを取り出すと、バックスラッシュ文字が自動で除去されない場合があります。これが問題であれば、テキストに対して PHP 関数 stripslashes() を使用してください。

コメントを投稿したときにページが真っ白になるのはなぜですか ?

詳細: 投稿にコメントした際、画面が真っ白になり、WordPress に登録されたはずのコメントが表示されない。

原因と解決策: 使用中のテーマにコメントフォームの重要な部分が抜けているため、コメントの参照している投稿が WordPress から分かりません。テーマの comment.php を調べ、フォームに次のコードがあることを確認してください。

<input type="hidden" name="comment_post_ID" value="<?php echo $id; ?>" />

関連する議論のスレッド:

管理画面にアクセスできない場合にすべてのプラグインを停止するには ?

すべてのプラグインを停止 ( 無効化 ) しなければならないが、管理画面にアクセスできない場合があります。次のどちらかの方法ですべてのプラグインを停止できます。

phpMyAdmin を使用してすべてのプラグインを無効化する

    1. wp_options テーブルで、option_name 列 ( フィールド ) の値が active_plugins の行を探す
    2. その行の option_value フィールドを a:0:{} に変更する

または FTP やホスティングサーバーの管理パネルのファイルマネージャーを使用して、プラグインフォルダーをリセットする。この方法ではプラグインのオプションはそのまま保持されますが、手動で再有効化する必要があります。

  1. FTP やホスティングサーバーのファイルマネージャーから、wp-contents フォルダ (ディレクトリ) に移動する。
  2. FTP やホスティングサーバーのファイルマネージャーから、フォルダ "plugins" を "plugins.hold" に名前を変更する。
  3. WordPress 管理画面のプラグインのページ /wp-admin/plugins.php にログインする。この操作により「見つからない」プラグインはすべて無効化されます。
  4. FTP やホスティングサーバーのファイルマネージャーから、フォルダ "plugins.hold" を "plugins" に名前を戻す。

自動アップグレードの後に出てくる「現在メンテナンス中のため、しばらくの間ご利用いただけません。」または「Briefly unavailable for scheduled maintenance」というメッセージを消すには ?

自動アップグレードの途中、WordPress はブログの ベース フォルダー (wp-admin フォルダーの親フォルダー ) にファイル「.maintenance」を作成します。このファイルが存在すると、ユーザーにメッセージ「現在メンテナンス中のため、しばらくの間ご利用いただけません。」または「Briefly unavailable for scheduled maintenance. Check back in a minute.」が表示されます。

このメッセージが訪問者に表示されないようにするには、.maintenance ファイルを削除するだけです。もし自動アップグレードに失敗した際は、再度実行できるはずです。

自動アップグレード機能はバージョン2.7で追加されました。

スラッグを含むパーマリンクを使った場合の404エラーを解決するには ?

管理画面 > 設定 > パーマリンク設定 で「日付と投稿名」などの Pretty パーマリンク を使用すると 404 エラーが発生する場合があります。これは「mod_rewrite」モジュールが有効化されていないか、インストールされていないためです。解決するには Apache Web サーバーの「mod_rewrite」モジュールを有効化してください。まずファイル「apache\conf\httpd.conf」の行「# LoadModule rewrite_module modules/mod_rewrite.so」を確認し、先頭の「#」を削除します。次に Apache を停止し、再起動します。注意: mod_rewrite の有効化にはホスティング会社への連絡が必要な場合があります。

参照:

関連する議論のスレッド:

投稿を編集する際に管理者が投稿者として表示されないのはなぜですか ?

この問題が発生する原因は不明ですが、次の2つの方法のどちらかで解決する場合があります。

ほとんどの場合、次の手順で解決します。

  1. 「管理者」権限グループに属する新しい管理者ユーザーを作成する。例えば「newadmin」
  2. 作成した「newadmin」でログインする。
  3. 古い「admin」ユーザーの権限グループを「購読者」に下げ、保存する。
  4. 古い「admin」ユーザーの権限グループを「管理者」に戻し、保存する。
  5. 古い「admin」ユーザーでログインする。

上の手順でうまくいかない場合、次の手順を試してください。

  1. 「管理者」権限グループに属する新しい管理者ユーザーを作成する。例えば「newadmin」
  2. 作成した「newadmin」ユーザーでログインする。
  3. 古い「admin」ユーザーを削除し、すべての投稿を「newadmin」に割り当てる。
  4. 「管理者」権限グループに属する「admin」ユーザーを作成する。
  5. 「admin」ユーザーでログインする。
  6. 「newadmin」を削除し、すべての投稿を「admin」ユーザーに割り当てる。

最新バージョンがリリースされた直後に管理画面で表示されないのはなぜですか ?

最新バージョンがリリースされると管理画面の先頭に通知「WordPress x.x.x が利用可能です。更新してください」が表示されます。ただしこの通知はすべてのブログで同時には表示されません。プログラムは12時間ごとに更新を確認しますが、タイミングは完全にランダムです。このため最新バージョンのリリース直前に更新を確認した場合、12時間後に再び確認するまで通知メッセージは表示されません。

システムからすぐに更新を確認するには、「wp_options」テーブルの「update_core」オプション名レコードを削除してください。注意: プラグインやテーマにもそれぞれ確認や更新の周期があります。これらは「wp_options」テーブルの「update_plugins」レコードや「update_themes」レコードで制御されます。

関連する議論のスレッド:

自動アップグレードの際にどうして WordPress デフォルトテーマへの変更が消えてしまうのですか ?

コア (WordPress 本体) のアップグレードでは、パッケージ内のすべての新しいファイルで古いファイルを上書きします。既存の WordPres のデフォルトテーマ内のファイル、例えば wp-content/themes/twentysixteen/style.css を変更していた場合、変更は新しい同名のファイルで上書きされます。

注意: コアのアップグレードは wp-admin/includes/update-core.php で定義された「古いファイル」リストに従って行われ、削除されます。リストにないファイルや、パッケージに含まれないファイルは削除されません。

注意: 自動であれ手動であれアップグレードの前には、「WordPress のバックアップ」に説明された方法で、WordPress ファイルおよびデータベースをバックアップしてください。

デフォルトテーマを変更する場合は子テーマを使用してください。セットアップに多少の手間は必要ですが、デフォルトテーマが更新されてもカスタマイズ内容は失われず安全です。

参照:

MySQL データベーステーブルを修復するには ?

まれに 1つ以上の MySQL データベーステーブルの修復が必要な場合があります。dev.mysql.com の「MyISAM テーブルの修復方法」によると、テーブルの修復が必要な様々な理由が挙げられています。「tbl_name.frm が変更に対してロックされます」「ファイル tbl_name.MYI が見つかりません (エラーコード: nnn)。」「予期しないファイルの終わり」「レコードファイルがクラッシュしました」「テーブルハンドラからエラー nnn を取得します」

phpMyAdmin を使用した MySQL データベーステーブルの修復手順は次のとおりです。

  1. ホスティングサーバーにログインする。
  2. phpMyAdmin にログインする。
  3. 影響を受けたデータベースを選択する。データベースが1つしかない場合にはデフォルトで選択されているため、操作は不要です。
  4. メインパネルにデータベーステーブルのリストが表示されます。修復が必要なテーブルのチェックボックスをオンにする。
  5. ウィンドウ末尾、テーブルのリストの下にドロップダウンメニューがあるので「テーブルを修復する」を選択する。

注意: どのような場合も、データベースの現在のバックアップを取得しておくことが最善の策です。

参照:


FAQに戻る

最新英語版: WordPress Codex » FAQ Troubleshooting最新版との差分