記事の投稿

1. 画面オプション
2. 各フィールドの説明
3. 投稿のベストプラクティス
4. ビジュアルエディターとテキストエディター
5. 参考情報

注意: このページでは WordPress 5.0 から導入された「ブロックエディター」(Gutenberg) を使用して説明します。それ以前のバージョンのクラシックエディターの私用については こちらのページ を参照してください。
投稿とは、ホームページやブログページに新しいものから古いものの順番で表示されるエントリーのことです。通常、それぞれの投稿の下にはコメント欄があり、サイトの RSS フィードに含まれます。
投稿するには

1. WordPress の管理画面 (ダッシュボード) にログインします。
2. サイドバーメニューの「投稿」をクリックしてください。
3. その下の「新規追加」をクリックしてください。
4. 空いているところを埋めていきます。上のフィールドに投稿のタイトルを入力し、その下のメインの投稿編集ボックスにコンテンツ本体を記入します。
5. 必要であれば、カテゴリーやタグを選択し、各セクションの設定を選択します。それぞれのセクションについては、以下で説明します。
6. 書き終えたら、公開ボタンをクリックします。

画面オプション
There are more editing fields available to you than you see on first login. The Screen Options area allows you to choose which Post Fields are displayed or hidden from your editing area, which allows you to minimize clutter and customize according to your needs.
You’ll find the Screen Options tab at the very top of your screen, and if you click on it, you’ll see a list of available editing boxes that you can use. Check the box for each Post Field you want displayed, or uncheck the box to hide that module. Click the Screen Options tab again to close the tab.
Once you’ve customized how editing screen, your options are saved so you don’t have to select or hide them again next time you log in.
各フィールドの説明

WordPress Admin Writing Post Advanced Panel – Top of Page
Title/Headline Box
This box should contain the title of your post. You can use any phrase, words, or characters. (Avoid using the same title on more than one page.) You can use commas, apostrophes, quotes, hyphens/dashes, and other typical symbols in the post like “My Site – Here’s Lookin’ at You, Kid.” WordPress will then clean it up to generate a user-friendly and URL-valid name of the post (also called the “post slug”) to create the permalink for the post.
Permalink
Permalink stands for “permanent link.” That means a post URL that does not expose the post ID which could be subject to a change (e.g. when moving to different blogging system), but it rather contains a user-friendly post name derived from the post title which could also change, although not recommended, but in a more controllable way. This post name (also referred to as “post slug” or just “slug”) can be edited, depending on your Permalinks settings, using the “Edit” button. (To change your settings, go to Administration Panels > Settings > Permalinks). The permalink is automatically generated based on the title you set to the post and is shown below the title field. Punctuation such as commas, quotes, apostrophes, and invalid URL characters are removed and spaces are substituted with dashes to separate each word. If your title is “My Site – Here’s Lookin’ at You, Kid”, it will be cleaned up to create the slug “my-site-heres-lookin-at-you-kid”. You can manually change this, maybe shortening it to “my-site-lookin-at-you-kid”.
Body Copy Box
The blank box where you enter your writing, links, images, links to images, and any information you want to display on your site. You can use either the visual (WYSIWYG) editor or the text view to compose your posts. For more on the text view, see the section below, Visual Versus Text Editor .
Publish Box
Contains buttons that control the state of your post. The main states are Draft and Published. Draft means the post has not been published and remains in draft status for the post creator. A Published status means the post has been published and is live on your site.
Preview Button
Allows you to view the post before publishing.
Save Draft
Allows you to save your post as a draft rather than immediately publishing it. To return to your drafts later, visit Posts – Edit in the menu bar, then select your post from the list.
Status
If you select a specific publish status (click Edit next to Status:Draft ) and click the update post or “Publish” button, that status is applied to the post. For example, to save a post in the Pending Review status, select Pending Review from the Publish Status drop-down box, and click Save As Pending. (You will see all posts organized by status by going to Administration Panels > Posts > Edit).
Visibility
This determines how your post appears to the world. (click Edit next to Visibility ) Public posts will be visible by all website visitors once published. Password Protected posts are published to all, but visitors must know the password to view the post content. Private posts are visible only to you (and to other editors or admins within your site).
Revisions
Click Browse to see all of the changes you’ve made to your post.
Scheduling
To schedule a post for publication on a future time or date, click Edit next to the words “Publish immediately.” You can also change the publish date to a date in the past to back-date posts. Change the settings to the desired time and date. You must also click the Publish button when you have completed the post to publish at the desired time and date.
Format Box

Allows you to choose a format for a post. Styling and appearance are handled by the individual themes.
Categories Box
The general topic of the post. It is typical for a blog to have 7-10 categories for content. Readers can browse specific categories to see all posts in the category. You can manage your categories by going to Administration Panel > Posts > Categories.
Tags Box
These are micro-categories for the post, similar to including index entries for a page. Posts with similar tags are linked together when a user clicks one of the tags. Tags have to be enabled with the right code in your theme for them to appear in your post. Add new tags to the post by typing the tag into the box and clicking “Add.” You can also click on the “Choose from the most-used tags” link to see all of the tags used by the site.
Excerpt
A summary or brief teaser of your post that may appear on the front page of your site as well as on the category, archives, and search non-single post pages. Note: the Excerpt does not usually appear by default. It only appears in your post if you have modified the template file listing the post to use the_excerpt() instead of the_content() to display the Excerpt instead of the full content of a post. If so, WordPress will automatically use as the Excerpt the first 55 words of your post content or the content before the <!–more–> quicktag. If you use the “Excerpt” field when editing the post, this will be used no matter what. For more information, see Excerpt.
Send Trackbacks
A way to notify legacy blog systems that you’ve linked to them. If you link other WordPress blogs, they’ll be notified automatically using pingbacks. No other action is necessary. For those blogs that don’t recognize pingbacks, you can send a trackback to the blog by entering the website address(es) in this box, separating each one by a space. See Trackbacks and Pingbacks for more information.
Custom Fields
Custom Fields offer a way to add information to your site. In conjunction with extra code in your template files or plugins, Custom Fields can modify the way a post is displayed. These are primarily used by plugins, but you can manually edit that information in this section.
Discussion
Options to enable interactivity and notification of your posts. This section hosts two check boxes: Allow Comments on this post and Allow trackbacks and pingbacks on this post . If Allowing Comments is unchecked, no one can post comments to this particular post. If Allowing Pings is unchecked, no one can post pingbacks or trackbacks to this particular post.
Post Author
A list of all blog authors you can select from to attribute as the post author. This section only shows if you have multiple users with authoring rights in your blog. To view your list of users, see Administration Panel > Users. For more information, see Users and Authors.

WordPress Admin Writing Post Advanced Panel – Bottom of Page
Note:You can set basic options for writing, such as the size of the post box, how smiley tags are converted, and other details by going to Administration Panel > Settings > Writing.
投稿のベストプラクティス
You can say or show the world anything you like on your WordPress site. Here are some tips you need to know to help you write your posts in WordPress.
Practice Accessibility
To be compliant with web standards for accessibility, be sure to include ALT and TITLE descriptions on links and images to help your users, such as <a title=”WordPress.ORG” href=” https://wordpress.org/ “>WordPress.ORG</a>.
Use Paragraphs
No one likes to read writing that never pauses for a line break. To break your writing up into paragraphs, use double spaces between your paragraphs. WordPress will automatically detect these and insert <p> HTML paragraph tags into your writing.
Use Headings
If you are writing long posts, break up the sections by using headings, small titles to highlight a change of subject. In HTML, headings are set by the use of h1, h2, h3, h4, and so on.
Use HTML
You don’t have to use HTML when writing your posts. WordPress will automatically add it to your site, but if you do want control over different elements like boxes, headings, and other additional containers or elements, use HTML.
Spell Check and Proofread
There are spell check Plugins available, but even those can’t check for everything. Some serious writers will write their posts in a text editor with spell check, check all the spelling and proof it thoroughly before copying and pasting into WordPress.
ビジュアルエディターとテキストエディター
When writing your post, you have the option of using the Visual or Text mode of the editor. The visual mode lets you see your post as is, while the Text mode shows you the code and replaces the WYSIWYG editor buttons with quicktags. These quicktags are explained as follows.

1. b– <strong></strong> HTML tag for strong emphasis of text (i.e.bold).
2. i – <em></em> HTML tag for emphasis of text (i.e. i talicize).
3. b-quote – <blockquote></blockquote> HTML tag to distinguish quoted or cited text.
4. del – <del></del> HTML tag to label text considered deleted from a post. Most browsers display as striked through text.
5. link – <a href="http://example.com"></a> HTML tag to create a hyperlink.
6. ins – <ins></ins> HTML tag to label text considered inserted into a post. Most browsers display as underlined text.
7. ul – <ul></ul> HTML tag will insert an unordered list, or wrap the selected text in same. An unordered list will typically be a bulleted list of items.
8. ol – <ol></ol> HTML tag will insert a numbered list, or wrap the selected text in same. Each item in an ordered list is typically numbered.
9. li – <li></li> HTML tag will insert or make the selected text a list item. Used in conjunction with the ul or ol tag.
10. code – <code></code> HTML tag for preformatted styling of text. Generally sets text in a monospaced font, such as Courier .
11. more – <!--more--> WordPress tag that breaks a post into “teaser” and content sections. Type a few paragraphs, insert this tag, then compose the rest of your post. On your blog’s home page you’ll see only those first paragraphs with a hyperlink ( (more...) ), which when followed displays the rest of the post’s content.
12. page – <!--nextpage--> WordPress tag similar to the more tag, except it can be used any number of times in a post, and each insert will “break” and paginate the post at that location. Hyperlinks to the paginated sections of the post are then generated in combination with the wp_link_pages() or link_pages() template tag.
13. lookup – Opens a JavaScript dialogue box that prompts for a word to search for through the online dictionary at answers.com. You can use this to check spelling on individual words.
14. Close Tags – Closes any open HTML tags left open–but pay attention to the closing tags. WordPress is not a mind reader (!), so make sure the tags enclose what you want, and in the proper way.

Workflow Note – With Quicktag buttons that insert HTML tags, you can for example click i to insert the opening <em> tag, type the text to be enclosed, and click /i or Close Tags to insert the closing tag. However, you can eliminate the need for this ‘close’ step by changing your workflow a bit: type your text, select the portion to be emphasized (that is, italicized), then click i and your highlighted text will be wrapped in the opening and closing tags.
参考情報

1. About Weblogs – What is Blogging all about?
2. First Steps With WordPress

固定ページ

1. WordPress ページを作成する
2. ページを整理する
   1. サブページを作成する
3. ページの URL(またはスラッグ) の変更
4. ページテンプレート
5. WordPressページの動的な性質

WordPress では新規にコンテンツを作成する際、「投稿 (post)」または「ページ (page)」のどちらかを作成することができます。普通のブログエントリを書く場合には「投稿」を作成します。投稿は、自動的にあなたのブログのホームページに時系列に従って表示されます。
対照的に「固定ページ」は 「管理人について」や「連絡先」などのように、ブログの時系列順の外に置く情報、つまり常に必要がある情報を表示する場合に使用します。
ページを使用して、Web サイトの情報を整理および管理できます。
一般的な 「このサイトについて」、「連絡先」 などのページに加え、「管理人について」、 「コピーライト」「法規に関する情報」「再掲載の許可」「管理人の連絡先」「アクセシビリティ宣言」などのを公開することができます。
一般的には WordPress ページと投稿は似ていると言えるでしょう。どちらにもタイトルやコンテンツがあり、サイト表示テンプレートを使って全体のデザインやレイアウトとマッチさせることができます。しかし WordPress ページには、投稿にはないユニークな機能があります。
WordPress ページとはこんなものです：

1. 投稿に比べると日時にあまり依存しません。
2. トップレベルのページと サブページ に整理することができます。
3. ページによって、異なる「 ページテンプレート 」が使えます。各ページに合わせた テンプレートファイル ・ テンプレートタグ ・PHP コードを組み込めます。
4. テーマによってはページごとに表示オプションを設定することが可能です。
5. ページのみを使用して Web サイトを作成することも可能です。

WordPress ページを誤解しないために:

1. WordPress ページは投稿とは別物です。ブログのメインページでは表示されません。
2. 「ページ」は階層性 (親 – 子) 構造のみで構成され、カテゴリーを割り振ったりタグを付けることはできません。
3. WordPress ページは個別ファイルではありません。WordPress ページのコンテンツは投稿と同じく、データベース内に保存されています。
4. ページテンプレート内にテンプレートタグや PHP コードを書くことはできますが、プラグインを使用しない場合は WordPress ページのコンテンツ内に書いても動作しません。ただし、PHP コードを直接記載したコンテンツを投稿した場合、セキュリティ上の問題が発生したり、Web サイトで予期しないエラーが発生する可能性があります。
5. ページは RSS や Atom などの「feed」には含まれません。
6. ページと投稿は、サイト訪問者や検索エンジンなどから異なるものとして解釈されます。一般的に検索エンジンは静的なページより、時間に依存するページを妥当なものとして扱います。
7. 特定のページ (または特定の投稿) は、 トップページに固定して表示 させることができます。この方法で設定された Web サイトでは、通常最新の記事が表示される別ページを設定します。

WordPress ページを作成する
WordPress ページを新規作成するには、まず、WordPress の管理画面にログインします。このとき使うユーザー ID に、新規ページ作成の権限が与えられていることが必要になります。ログインしたら、 ページ  >  新規追加 を選びます。
ページを整理する
カテゴリ内にサブカテゴリを設定できるように、ページ内にサブページを設定してページの階層を作成することができます。
たとえば、地域のページを作成する場合、 「東北」のページの下に青森県、岩手県、宮城県、秋田県、山形県、福島県があります。別の 「関東」のページの下に茨城県、栃木県、群馬県、埼玉県、千葉県、東京都、神奈川県があります。
サイト上のページの構造は次のようになります。

1. 東北 (touhoku)
   1. 青森県 (aomori)
   2. 岩手県 (iwate)
   3. 宮城県 (miyagi)
   4. 秋田県 (akita)
   5. 山形県 (yamagata)
   6. 福島県 (fukushima)
2. 関東 (kanto)
   1. 茨城県 (ibaraki)
   2. 栃木県 (tochigi)
   3. 群馬県 (gunnma)
   4. 埼玉県 (saitama)
   5. 千葉県 (chiba)
   6. 東京都 (tokyo)
   7. 神奈川県 (kanagawa)

サブページを作成する

1. ログイン後に、 ページ  >  新規追加 を選びます。
2. 右メニューの「ページ属性」のタブを開きます。「親ページ」のドロップダウンには、すでに作成されたすべてのページのリストが表示されています。
3. ドロップダウンから作成したページの親ページを選択します。
4. 公開します。

ページに階層構造ができあがると、子ページは親ページの下にネストされます。ページの パーマネントリンク もこのページを反映します。
上記の例の構成で、 パーマリンク を設定済みの場合、東京のWordPressページのリンク先は以下のようになります。
http://example.com/kanto/tokyo/
ページの URL(またはスラッグ) の変更
URL の一部で固定ページの名前を含む「スラッグ」を変更するには、2通りの方法があります

1. タイトルが選択されている状態で、タイトルの上に表示される「パーマネントリンク」の「編集」ボタンをクリックし、変更後「保存」をクリックする。
2. 右メニューの「パーマネントリンク」の部分を開き、「URL スラッグ」を変更する。

固定ページ一覧の作成
wp_list_pages()  という テンプレートタグ を使って、サイト内のWordPress ページへのリンクをサイドバーなどに自動的に表示することができます。以下のように表示をカスタマイズしたい場合は、 wp_list_pages  のページを参照してください。
投稿内や WordPress テーマの他の領域内にページのリストを表示するプラグインもあります。
ページテンプレート
それぞれのページはあなたがテーマ内に作成した特定のカスタムページテンプレート（PHP テンプレートファイル。例: snarfer.php）を使うように設定できます。ページのカスタムテンプレートファイルを作成する方法については、 カスタムページテンプレート を参照してください。この新しいページテンプレートは、あなたのテーマ内に含まれているデフォルトの page.php ページテンプレートを上書きします。
WordPressページの動的な性質
一般的に、Web ページには「静的」なものと「動的」に生成されるものがあります。例えば Dreamweaver で作る従来の HTML ページのような静的ページは、一度作成・保存されたら同じ状態で訪問者に表示されます。一方、WordPress が生成するような動的ページは、訪問者がページを見ようとするたびに新しく生成されます。この場合、ページの作者は「どんなデータを表示させるか」のみを特定しておき、実際に表示されるページは作成しません。
WordPress では、WordPress ページを含む大半の表示ページが動的に生成されています。投稿者が作成したコンテンツ (記事、コメント、ブログロールリンク、カテゴリー項目など) は  MySQL  データベースの中に保存されており、サイトにアクセスがあると WordPress はデータベースに対し、現在使っている テーマ 内の テンプレート をもとにしてデータのリクエストを行います。
静的ページの例としては、 PHP  コードなどを含まない  HTML  文書が挙げられます。例えば、「管理者について」という100% 静的な HTML ファイルを作って aboutl.html として保存し、サイト内からリンクすることもできますが、これはあまりメンテナンスしやすいとは言えません。WordPress の設定や テーマ 内の テンプレート に変更を加えたりした際に、その変更は HTML ファイルには自動的に加わりません。代わりに、動的なWordPress ページと的テンプレートを使うことにより、更新をスムーズに行うことができます。
WordPress ページは動的に生成されているにも関わらず、この機能はよく「静的ページの作成機能」といった形で呼ばれることがあります。Web パブリッシングの分野では、「静的」と「動的」の違いは上記の説明のように区別されています。しかし、一般的な用語では、「静的」とは「変化がない状態」を指すこともあります。ブログの記事は他の新しい記事が追加されるに従ってトップページなどから消えてしまいますが、WordPress ページはサイトについて、管理者についてのページなど、常に同じ場所にあり内容にもあまり変化がないことが多いので、このような呼ばれ方をしています。
つまり、「WordPress ページには静的な情報が含まれているが、生成は動的に行われている」と言い換えることができます。このため、WordPress ページは静的・動的どちらと言っても間違いではありません。しかし、WordPress ページのコンテンツはデータベースから動的に呼び出されているので、混乱を防ぐためにこの記事内では「WordPress ページは動的なページである」としています。
メディアライブラリ画面

1. メディアライブラリ

メディアライブラリのグリッドビュー

1. フィルタリングオプション
2. メディアの削除
3. 添付ファイルの詳細

メディアライブラリのリストビュー

1. メディア一覧
   1. 列の並べ替え
   2. ページナビゲーション
   3. 表示オプション
   4. 検索
2. フィルタリングオプション
3. 選択、アクション、適用
   1. 選択
   2. アクション
   3. 投稿またはページを検索
   4. 適用

「メディア」には、アップロードしてブログに使用する、画像・動画・音声などのファイルを含みます。一般には  記事を投稿する 、または  固定ページを作成する 場合に、アップロードしてコンテンツに挿入します。気をつけるべきことは、アップロードディレクトリ（アップロードされたメディアファイルが保存される場所）の場所や構造は、 管理画面/メディア設定 の「ファイルアップロード」の設定で変わることです。もし、特定の投稿や固定ページに結びつけずにメディアファイルをアップロードする際には、 管理画面/メディア/新規追加 を使う必要があります。
新しいメディアを追加するには、画面の先頭の「新規追加」リンクをクリックするか、左側のメニューから  メディア  >  新規追加  を選択して 「 メディア新規追加 」画面を開きます。
メディアライブラリ
メディアライブラリ では、以前にアップロードしたメディアを編集・閲覧・削除することができます。削除する際には、複数のメディアファイルを選択できます。メディアを探す際には、検索やフィルタリングの機能が使えます。
メディアライブラリには、シンプルな「 グリッドビュー 」と従来からの「 リストビュー 」の2つのビューが提供されています。左上のアイコンをクリックして、2つのビューを切り替えられます。
メディアライブラリのグリッドビュー
メディアライブラリのグリッドビューではアップロードした画像のサムネイル、音声や映像を表すアイコンがグリッドで表示されます。

フィルタリングオプション
グリッドビュー上部にメディアの形式によるフィルタリングと、日付によるフィルタリングがあります。
すべてのメディア
メディア一覧 内で、メディアの形式「画像」「音声」「動画」ごと、または投稿や固定ページに添付されていない「未添付」のどのメディアを表示するかを選択します。デフォルトでは、「すべてのメディア」が表示され、すべてのメディアが表示されます。
All Dすべての日付ates
グリッドビュー内で、どのメディアを表示するかを日付ごとに選択します。デフォルトでは、「すべての日付」が表示され、すべてのメディアが表示されます。
また右側には「検索」ボックスがあります。キーボードから検索語をタイプするごとに、ヒットした検索結果が表示されます。
メディアの削除
メディア項目を削除するには画面上部の「一括選択」ボタンをクリックします。削除したい項目を選択したら、「選択した項目を削除」ボタンをクリックします。「選択をキャンセル」ボタンをクリックするとメディアの表示に戻ります。
添付ファイルの詳細
グリッドビューで表示されている画像のサムネイルや音声アイコン、動画アイコンをクリックすると「添付ファイルの詳細」ダイアログが開かれます。「添付ファイルの詳細」ダイアログではメディアやその属性情報をプレビューしたり、クイック編集できます。添付詳細へのすべての変更は自動的に保存されます。個々の項目を削除したり、拡張された編集にアクセスすることもできます。 ダイアログの上の矢印ボタンもしくはキーボードの左右の矢印キーを使い、メディアアイテム間を簡単に移動できます。

「添付ファイルの詳細」ダイアログはメディア形式により表示や情報が変わります。画面左側には画像、音声プレイヤー、または動画プレイヤーが表示されます。画面右側には次のようなメディアファイルの属性やオプションの情報が表示されます。一部の情報は直接編集できます。

1. ファイル名– メディアファイルの名前
2. ファイルタイプ– メディアファイルの MIME Type
3. 更新日– メディアファイルがアップロードされた日付
4. ファイルサイズ– メディアファイルのサイズ
5. サイズ– (画像ファイルのみ) 画像のサイズ
6. URL– メディアファイルへの直接のリンク
7. タイトル– メディアの名前。テーマやプラグインによっては添付ファイルのページやギャラリーで表示されます。
8. キャプション– メディアの簡単な説明
9. 説明– メディアの説明
10. 代替テキスト– (画像ファイルのみ) イメージの代替テキスト。「モナリザ」などのようにメディアを説明するテキストで、アクセシビリティ支援に使用される。
11. アーティスト– (音声ファイルのみ) このメディアの歌手、作曲家、プロデューサー
12. アルバム– (音声ファイルのみ) このメディアを含むアルバムのタイトル
13. アップロード– メディアをアップロードしたユーザー
14. アップロード先– メディアファイルが投稿や固定ページに添付されている場合、投稿や固定ページのタイトル。クリックすると投稿や固定ページの「編集」画面が開きます。

画面右下には次のリンクメニューが表示されます。
添付ファイルのページを表示
このメディアがテーマでどのように表示されるかをシミュレーションしたビューを表示します。
さらに詳細を編集
「メディアの編集』画面が開かれます。メディアの編集の詳細については「 メディアの編集 」を参照してください。
完全に削除する
メディアを削除します。
メディア形式が画像の場合、左下に「画像を編集」ボタンが表示されます。
画像を編集
(画像ファイルのみ) 画像の回転、サイズ変更、トリミング等の編集を実行できます。詳細については「 画像を編集 」画面を参照してください。
メディアライブラリのリストビュー
メディアライブラリのリストビューではすべてのメディアが行ごとに、新しいメディアを先頭にして表示されます。

メディア一覧
メディア一覧には次の列があります。

1. [ ] – 一括操作で操作するメディアを ‘選択’ する場合、このチェックボックスをクリックします(オンにします)。
2. “サムネイル” – “サムネイル” という列ヘッダーはありませんが、この列に実際のメディアの小さな画像が表示されます。
3. ファイル – このメディアの名前を示すタイトルがリンク形式で表示されます。タイトルリンクをクリックすると「メディアの編集」画面が開かれます。メディアの編集の詳細については「 メディアの編集 」を参照してください。タイトルの下には、メディアを保持する実際のファイルの名前が表示されます。
4. 作成者 – メディアをアップロードした 作成者 がリンク形式で表示されます。作成者リンクをクリックすると、同じ作成者のすべてのメディアがメディア一覧に表示されます。ここから同じ作成者のメディアに対して「一括操作」を適用できます。
5. アップロード先 – このメディアを含む投稿や固定ページのタイトル、および、投稿や固定ページの日付が表示されます。投稿や固定ページのタイトルをクリックすると、編集画面が開かれます。どの投稿や固定ページにも含まれないメディアには「投稿に添付」リンクが表示されます。クリックして、メディアを選択した投稿や固定ページに添付できます。選択の詳細については「 投稿またはページを検索 」を参照してください。1つ以上の投稿や固定ページに添付されたメディアは、最初の投稿や固定ページの情報が表示されます。
6. コメント吹き出し – 各メディアの行には、メディアに付けられたコメント数を描いた吹き出しが表示されます。吹き出しをクリックすると コメント画面 が表示され、コメントをモデレートできます。
7. 日付 – メディアがアップロードされた日付

列の並べ替え
「ファイル」「作成者」「アップロード先」「日時」などの列のヘッダーをクリックすると、メディア一覧を昇順、または降順で並べ替えできます。列のヘッダー、例えば「ファイル」にマウスを移動すると上向き矢印、または下向き矢印が表示されます。クリックすると並べ替え順序が変わります。
ページナビゲーション
「表示オプション」の中で、「ページごとに表示する項目数」を指定できます。メディアが複数ページにわたる場合、最初のページ、最後のページにジャンプする二重矢印と、前のページ、次のページにジャンプする一重矢印が表示されます。また現在のページ番号を表示するテキストボックスは編集可能で、直接ジャンプしたいページ番号を入力できます。
表示オプション
表示オプション でメディア一覧内の列の表示、非表示を選択できます。「表示オプション」タブをクリックすると、チェックボックス付きの列のリストが表示されます。チェックボックスをオンにするとテーブルに列は表示され、オフにすると表示されません。また「ページごとに表示する項目数」も設定できます。再度「表示オプション」タブをクリックすると、表示オプションは閉じます。
検索
メディア一覧の上部、右側に検索ボックスがあります。1つ以上の英単語を入力し、Enter キーを押すと、条件に合うメディアが表示されます。
フィルタリングオプション
リストビュー上部にメディアの形式によるフィルタリングと、日付によるフィルタリングがあります。
すべて
メディア一覧 内で、メディアの形式「画像」「音声」「動画」ごと、または投稿や固定ページに添付されていない「未添付」のどのメディアを表示するかを選択します。デフォルトでは、「すべて」が表示され、すべてのメディアが表示されます。
すべての日付
グリッドビュー内で、どのメディアを表示するかを日付ごとに選択します。デフォルトでは、「すべての日付」が表示され、すべてのメディアが表示されます。
絞り込み検索
このボタンをクリックするとドロップダウンでの選択が適用されます。
選択、アクション、適用 選択
この画面から、1つまたは複数のメディアを一括操作できます。複数のメディアを一度に操作する一括操作では、まず以下の手順のどれかを使用してメディアを選択する必要があります。

1. 1つずつメディアを選択する – メディアを選択するには、メディアの左のチェックボックスをオンにします(クリックします)。複数のメディアを選択するには、それぞれのチェックボックスをオンにします。
2. テーブル内のすべてのメディアを選択する – テーブル内のすべてのメディアを選択するには、テーブルのヘッダーまたはフッターのチェックボックスをオンにします。同じチェックボックスをオフにすればテーブル内のすべてのチェックボックスはオフ(メディアは非選択)になります。
3. リバース選択 – リバース選択では選択されたアイテムが非選択となり、非選択のアイテムが選択となります。リバース選択するには、キーボードの Shift キーを押しながら、テーブルのヘッダーまたはフッターのチェックボックスをクリックします。

アクション
選択したメディアに対して実行される処理を「アクション」と呼びます。アクションには 一括操作 と 即時操作 の2種類があります。以下ではそれぞれについて解説します。

1. 一括操作 – 1つ、または複数のメディアに対して一度に実行できるアクションです。複数のメディアに対して実行する場合、事前にメディアを 選択 しておく必要があります。一括操作で実行できるアクションは、各テーブルの上の「アクション」ドロップダウンボックス内に表示されます。「完全に削除する」のみが一括操作可能です。
2. 即時操作 – それぞれのメディアに対して即座に実行されるアクションです。メディアの行の上にマウスカーソルを移動すると、「編集」「完全に削除する」「表示」オプションが表示されます。メディアのタイトルをクリックしても、「編集」アクションが実行されます。

実行可能なアクションの一覧を以下に示します :

1. 編集 – 「メディアの編集」画面を開く即時操作です。このアクションはメディアのタイトルをクリックしても実行できます。メディアの編集の詳細については「 メディアの編集 」を参照してください。
2. 完全に削除する – このアクションはメディアを削除します。「完全に削除する」は「一括操作」「即時操作」の両方で実行できます。
3. 表示 – このアクションはメディアがテーマでどのように表示されるかをシミュレーションしたビューを表示します。「表示」は即時操作としてのみ実行できます。
4. 投稿に添付 – 絞り込み検索で「未添付」のメディアを表示している場合、「投稿に添付」アクションが表示されます。クリックして、選択した投稿や固定ページにメディアを添付できます。選択の詳細については「 投稿またはページを検索 」を参照してください。

投稿またはページを検索

「アップロード先」列の「投稿に添付」リンク、または絞り込み検索で「未添付」のメディアを表示している場合に「ファイル」列の「投稿に添付」リンクをクリックすると、「投稿またはページを検索」ダイアログが開きます。次の手順で投稿、または固定ページを選択できます。

1. キーワードで投稿または固定ページを検索する。
2. メディアを添付する投稿または固定ページを選択する。
3. 「選択」ボタンをクリックする。

適用
1つ以上のメディアを 選択 し、 一括操作 を選択したあとは、適用ボタンをクリックして選択したメディアに対して指定のアクションを実行します。

1. 適用 – 「適用」ボタンをクリックすると、選択したメディアに対して「アクション」ドロップダウンボックスで指定した一括操作が実行されます。すでに述べたようにアクションの実行前に、忘れずに 1つ以上のメディアを選択してください。

ユーザーのプロフィール画面

1. ユーザー → あなたのプロフィール
2. あなたのプロフィールと個人設定
   1. プロフィールを更新

ユーザー → あなたのプロフィール
「 あなたのプロフィール 」は管理画面の ユーザー 画面と WordPress のメインナビゲーションメニューの名前をクリックしてアクセスできます。
ここでは、あなたの名前、サイトのアドレス、管理用メールアドレス、その他の個人情報などを設定できます。ユーザーのメールアドレスは重複しないようにする必要があります。

あなたのプロフィールと個人設定
WordPressが最低限必要とする情報は、電子メールアドレスとニックネームです。 ここで入力するメールアドレスは管理にのみ使用されます。  電子メールアドレスは他のサイトに送信されることはなく（WordPress の開発元を含む）、自分で設定しない限りサイトに表示されることはありません。 WordPressに登録された他のユーザーしか知ることはできません。また、各メールアドレスは重複しないものである必要があります。
注意: テーマに the_author_meta('user_email') を記述すると、サイトにメールアドレスを表示することができます。メールアドレスをサイトに表示するよう設定されているにもかかわらず、その事実をダウンロード前に通知しないテーマには注意が必要です。デフォルトのWordPressテーマではサイトの公開部分にはメールアドレスを表示しません。
ここで要求されるすべての個人情報の入力は任意です。また、これらの情報もほかのサイトに送信されたりすることはありません。ただし、使用するテーマによってはサイトに表示される場合がありますので、あなたの使用するテーマをテストする必要があります（個人情報に対して神経質な運用を行う場合）であれば、あなたは自分が使用しようとしているテーマをテストするべきです。また、どのようにこれらの情報を表示するかに関しては、 the_author とそれに関連するテンプレートタグの項目を見てください（そして、テーマを使用したときに個人情報が表示されないか確認してください）。 一般的には、ブログ上での表示名フィールドの内容のみが公開されます。ただし、投稿者のユーザー名は投稿者アーカイブの URL や各投稿者向けのスタイルの CSS クラスに含まれていることがよくあります。
個人設定 :

1. ビジュアルエディター – ビジュアルリッチエディターを使用しないにチェックを入れると、視覚エディタを無効化します。HTML エディタを使用したいときは、このチェックボックスにチェックを入れてください。
2. 管理画面の配色 –  管理画面 の配色を切り替えることができます。左の2色はメニュー背景の色で、右の2色はロールオーバー用の色です。

1. キーボードショートカット – コメント承認のキーボードショートカットを使う。にチェックを入れると、キーボードショートカットによって高速にコメントをモデレートすることができるようになります。  キーボードショートカット のページに詳しい使い方などが書かれています。
2. ツールバー – サイトを表示する際に 管理ツールバー を表示したい場合はチェックを入れてください。
3. 言語– サイトの訪問者に表示される言語に影響を与えることなく、 管理画面 の言語を選択できます。

名称 :

1. ユーザー名 – ログインプロセスで使用されているユーザー名は変更できません。また、 管理者 のユーザー名も変更することができません。
   通常、自分以外はこのユーザー名を知ることはありません。
2. 名 – 名前を入力する欄です。
3. 姓 – 名字を入力する欄です。
4. ニックネーム – すべてのユーザーに必要であるニックネームを入力してください。ユーザー名と同じでもかまいません。もしこの欄を空欄にした場合、ユーザー名が代わりに表示されます。
5. ブログ上での表示名 – ドロップダウンメニューからどの名前を表示するかを選択します。デフォルトは名、姓です。ニックネーム、 ログイン名、 名、姓、名、姓の中から選択できます。また、”姓、名”の順番で名前を表示したい場合は姓テキストボックスに,（コンマ）を入力し、一番下の項目を選択してください。

連絡先情報:

1. メールアドレス – 必ず必要です。メールアドレスは一意でなくてはなりません（他のユーザーと同じものは登録できません）。あなたのブログにコメントがきたときや、管理目的で使用されます。すでに上でも書かれていますが、このブログの登録ユーザーのみがこのメールアドレスを知ることができます。どこにも送信されません。
2. ウェブサイト – あなたのウェブサイトのアドレスを入力します。

あなた自身について :

1. 経歴 – 自分の簡単な自己紹介か、プロフィールを入力してください。このオプション情報は、テーマ作者によって設定されている場合テーマ内に表示することもできます。 the_author_meta('description')  テンプレートタグをご覧ください。
2. Gravatar でのあなたの写真がここに表示されます。 変更するには、 https://en.gravatar.com/ にアクセスします。 Gravatarの使用 も参照してください。

アカウント管理:

1. パスワードの設定– このボタンをクリックして、アカウントの新しいパスワードを生成できます。 これにより、生成されたパスワードを含む新しいフィールドが表示されます。 このパスワードを変更する場合、弱いパスワードを使用することを確認するチェックボックスが表示されます。 このボックスをチェックして、安全なパスワードの代わりに独自のパスワードを使用することを確認できます。
2. 強度インジケータ– 入力したパスワードが非常に弱い、弱い、中程度、または強い（緑色で表示される）かどうかを示します。 パスワードが強いほど、ログインの安全性が高まります。 ヒント：パスワードは7文字以上にする必要があります。 より強くするには、大文字、小文字、！ “？$％^＆）のような数字と記号を使用します。
3. どこでもログアウト– このボタンをクリックすると、電話や公共のコンピューターなど、他のデバイスからログアウトできます。

プロフィールを更新
このボタンをクリックするとプロファイルと個人オプションに加えた変更を保存されます。 このボタンをクリックすると、画面の上部に「ユーザーが更新されました」というスプラッシュメッセージが表示されます。そのメッセージが表示されない場合、変更は保存されていません！
パーマリンクの使い方

1. パーマリンクの形式
   1. デフォルト：”Ugly”
   2. mod_rewrite: “Pretty パーマリンク”
   3. PATHINFO: “Almost Pretty”
2. パーマリンク構造の選択
   1. 構造タグ
   2. カテゴリーベースとタグベース
   3. 複数カテゴリにした投稿の %category% と %tag%
3. “Pretty” パーマリンクの使い方
   1. .htaccess ファイルはどこ？
   2. .htaccessの作成と編集
   3. .htaccessの自動更新
4. パーマリンクについての問題点と対処法
   1. .htaccess 生成時の問題
5. ヒントと小技
   1. アーカイブリンクとして解釈されるのを避ける
   2. パーマリンク構造をチェックする
6. 参考

パーマリンクとは、ブログの個々の投稿、カテゴリーなどの投稿一覧ページへの恒久的 (半永久的) な URL です。
パーマリンクは、他のブロガーがあなたの記事やセクションにリンクを張るときや、投稿へのリンクを Eメールで送ったりするときに使います。
個別の投稿への URL は常に存在して決して変わらないようにすべきです。
そのため、「perma」リンクと呼ばれます。
パーマリンクの形式
WordPress の基本的なパーマリンク形式は以下の3種類です。
デフォルト：”Ugly”
デフォルトでは、投稿 ID が N のときに
http://example.com/?p=N
のようになります。すべてのサーバ環境で動くように、新規インストール時のデフォルトはこうなっています。
mod_rewrite: “Pretty パーマリンク”
mod_rewrite や lighttpd を使用すると、より良いパーマリンクにすることができます (詳しくは ブログ入門 をご覧ください)。フォーマットは様々ですが、最も一般的で汎用性が高いのは次のような形です。
http://example.com/2012/post-name/
あるいは
http://example.com/2012/12/30/post-name
Pretty パーマリンクは、以下の環境で利用できます。

1. Apache：mod_rewrite モジュール有り
2. Nginx：try_filesを使用 ( 参考サイト )
3. Hiawatha Webサーバー ：URLリライティングが有効
4. Lighttpd： 404 handler  あるいは mod_rewrite を使用
5. Caddy：using rewrite ( 参考サイト )

PATHINFO: “Almost Pretty”
PATHINFO パーマリンクは mod_rewrite パーマリンクによく似ています が、一つだけ例外があり、次のような形で途中に /index.php が挿入されます。
http://example.com/index.php/yyyy/mm/dd/post-name/
それ以外は “pretty” mod_rewrite と変わりなく、柔軟さも同じです。
/index.php の部分のおかげで、 mod_rewrite パーマリンクでできることは、PATHINFO パーマリンクでも実現可能です。
パーマリンク構造の選択
管理画面の「設定」→「パーマリンク設定」で、 一般的な設定から1つを選択するか、構造タグを使用して「カスタム構造」フィールドに記述することができます。
注：パーマリンクの欄には、サイト URL を決して入れないでください。構成タグあるいは構成タグの組み合わせのみを使用してください。
PATHINFO パーマリンクを有効にするには、パーマリンク構造が index.php/ で始まるようにします。
構造タグ
“Pretty” あるいは “Almost Pretty” パーマリンクをカスタマイズするために、以下の構造タグを使用できます。
ヒント

1. パーマリンクの欄には、サイト URL を決して入れないでください。構成タグあるいは構成タグの組み合わせのみを使用してください。
2. 構造は必ず ％post_id％ あるいは ％postname％ で終了し、各パーマリンクが個々の投稿を指すようにしてください (例 /％year％/％monthnum％/％day％/％postname％/ )。

%year%
投稿された年を4桁で取得します。例えば、2018です。
%monthnum%
投稿された月を取得します。例えば、05です。
%day%
投稿された日を取得します。例えば、28です。
%hour%
投稿された時 (時間) を取得します。例えば、15です。
%minute%
投稿された分を取得します。例えば、43です。
%second%
投稿された秒を取得します。例えば、33です。
%post_id%
投稿の固有IDを取得します。例えば、423です。
%postname%
投稿名 (投稿 / 固定ページ編集パネルのスラッグ) を取得します。例えば、「This Is A Great Post!」というタイトルであれば、「this-is-a-great-post」というURIになります。
%category%
カテゴリー名 (カテゴリー新規追加 / 編集パネルのスラッグ) を取得します。サブカテゴリーは入れ子になったURIとなります。
%author%
投稿の作成者を取得します。
カテゴリーベースとタグベース
カテゴリーベースとタグベースは、カテゴリー / タグアーカイブのパーマリンクの前に置かれます。
example.net/wp/category_base/category_name example.net/wp/tag_base/tag_name
カテゴリーベースのデフォルト値は category です。タグベースのデフォルト値は tag です。値を変更することはできますが、URLから取り除くことはできません。
これらのパーマリンクはほとんどのシステムで問題なく動作しますが、問題が生じる環境もあります。
複数カテゴリにした投稿の %category% と %tag%
一つの投稿に複数カテゴリを指定していても、パーマリンクには一つしか表示できません。カテゴリはアルファベット順に並べられ、サブカテゴリの各グループでもアルファベット順になります ( カテゴリ管理 参照)。投稿には、どのカテゴリからもアクセスできます。
パーマリンクに表示するカテゴリを選択する場合は、 WP Category Permalink プラグインを試してください。
“Pretty” パーマリンクの使い方
要件：

1. mod_rewrite モジュールがインストールされた Apache ウェブサーバー
2. WordPress のホームディレクトリで、
   1. FollowSymLinks オプションが有効になっている。
   2. FileInfo directives が許可されている (例: AllowOverride FileInfo あるいは AllowOverride All)。
   3. .htaccess ファイルが存在する (存在しない場合は、”pretty” パーマリンクを有効にしたときに、WordPress は .htaccess ファイル作成を試みます)。
   4. .htaccess ファイルを自動的に更新するには、WordPress が書き込み権限を持っている必要があります。

1. 優れた同時実行性、高パフォーマンス、低いメモリ使用量を目的としたWebサーバーであるnginxの場合、サーバーブロック内に次の location ブロックを追加します:

location / {
try_files $uri $uri/ /index.php?$args;
}

1. セキュリティに重点を置いた Hiawatha Webサーバー の場合は、次のURLツールキットを使用します：

UrlToolkit {
ToolkitID = wordpress
RequestURI exists Return
Match .*\?(.*) Rewrite /index.php?$1
Match .* Rewrite /index.php
}

1. WordPressをローカルで実行しているMacユーザーは、httpd.confファイルを開き、 “/ Library / WebServer / Documents” ディレクトリに対して、AllowOverride を All に指定する必要があります。Mac OS X 10.5.x以降では、このファイルは /private/etc/apache2/users/[your-username].conf にあります。それ以外の場合は、 / etc / httpd / httpd.conf にあります。

“pretty” パーマリンク構造を作成または更新する時、WordPress は書き換え規則を生成し、.htaccess ファイルの適切な箇所に挿入します。挿入できなかった場合、「.htaccess を更新する必要があります」のようなメッセージが表示され、ファイルにコピー＆ペーストする (ファイルの最後に付け足す) 書き換え規則が表示されます。
WordPress は内部で書き換え作業を行うので、この作業は一度行うだけで済みます。WordPress のホームディレクトリ (サイトアドレス) を移動させるときは、この作業を再度行う必要があるでしょう。
WordPress は既存の .htaccess と共存できます。既存の書き換え規則や他のディレクティブを削除しません。他に mod_rewrite 規則がある場合は、WordPress の規則よりも前に記述してください。
.htaccess ファイルはどこ？
WordPress の index.php と .htaccess ファイルは、一般設定のサイトアドレス (URL) で指定されたディレクトリに一緒に置く必要があります。ファイル名がドットで始まるため、FTPクライアントソフトウェアでは、隠しファイルを含む全ファイルを表示するように設定していないと、ファイルが見えないかもしれません。 一部のホスティングサービス (例: GoDaddy) では、GoDaddy ホスティング接続インストールを利用して WordPress をインストールした場合、.htaccess が表示されず、編集することもできません。
.htaccessの作成と編集
.htaccess ファイルが存在しない場合は、新規作成してください。シェルあるいは ssh アクセスでサーバーにアクセスできる場合は、touch .htaccess コマンドで作成することができます。FTP を用いてファイル転送する場合は、ローカルコンピュータ上で 1.htaccess のような名前でファイルを作成し、WordPress ディレクトリのルートにアップロードし、.htaccess にリネームしてください。
.htaccess ファイルは、FTP、シェル、あるいは (設定されていれば) ホスティングサービスの 管理パネル から編集することができます。
.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 ファイルにサイトをダウンさせるエラー（”Internal Server Error (500)”）が含まれている場合は、FTP またはホスティングサービスの 管理パネル を使用して欠陥のある .htaccess ファイルを削除する必要があります。
.htaccessの自動更新
WordPress が .htaccess ファイルを自動更新できないときは、設定 → パーマリンク画面の下部に「あなたの .htaccess が書き込み可能ならこの操作は自動的に行われますが、そうでない場合は…」というメッセージが表示されます。
WordPress に自動更新させたい場合は、 ファイルパーミッションの変更 が必要になります。 適切なパーミッションは、お使いのサーバーの設定によって異なります。まずは所有者に書き込み権限を与えて試してください。駄目なら次はグループ、その次は全ユーザーに書き込み権限を与えて試してください。WordPress がファイル編集できるようになったら、書き込み権限をそれ以上付与しないでください。
パーマリンクを適用した後は、他者が .htaccess にアクセスするのを防ぐために、660 あるいは 644 のような制限の厳しいパーミッションに変更してください。
パーマリンクについての問題点と対処法 .htaccess 生成時の問題
WordPress のインストール時に.htaccess ファイルが生成されない場合や、既存の .htaccess ファイルに新しい規則が追加されない場合は、いろいろな原因が考えられます。以下の手順を上から順に1つずつ、問題が解決しない場合のみ次のステップに進む方式で実行してください。

1. ファイルパーミッションの変更：WordPress ビルトインエディタで .htaccess ファイルを編集するには、.htaccess のパーミッションを 666 に変更する必要がありますが、この方法はお薦めできません。あなたのブログのユーザーで、テンプレート編集権限を持つユーザーなら誰でも .htaccess を編集できてしまうからです。パーミッションをサーバーが書き込み可能な 660 に変更することもできますが、同様の制限があります。
2. サーバーブロック：ホスティングサービスによって SERVER_SOFTWARE 変数がブロックされているため、WordPress が .htaccess を生成できていない可能性があります。サーバー上で Apache が実行されていることが確かであれば、wp-includes/vars.php ファイルを変更することで、Apache が実行されていると WordPress に思い込ませることができます。これらの変更を実装するには、以下の手順を行ってください。
   1. WordPress 管理パネルのビルトイン・エディタを使用して wp-includes/vars.php を開きます。WordPress にログインし、「管理」をクリックし、「ファイル」をクリックし、画面を下までスクロールし、「その他のファイル」テキストボックスで wp-includes/vars.php と入力してください。
      $is_apache = strstr($_SERVER[‘SERVER_SOFTWARE’], ‘Apache’) ? 1 : 0;
      という部分を探して、
      // $is_apache = strstr($_SERVER[‘SERVER_SOFTWARE’], ‘Apache’) ? 1 : 0;
      に置き換えてください。
   2. 次の部分の下に一行追加し、
      // $is_apache = strstr($_SERVER[‘SERVER_SOFTWARE’], ‘Apache’) ? 1 : 0;
      次のように入力してください。
      $is_apache = 1;
3. XAMPP (Windows) を利用する場合: XAMPP のバージョンによっては、デフォルトでは mod_rewrite が有効になっていません (Apache でコンパイルはされています)。mod_rewrite を有効にし、WordPress が pretty パーマリンク作成するのに必要な規則を .htaccess に書き込みできるようにするには、apache/conf/httpd.conf を開き、LoadModule rewrite_module modules/mod_rewrite.so の行のコメントを外す (行頭の「#」を消す) 必要があります。
4. WAMP (Windows) を利用する場合：WAMPのいくつかのバージョン (すべてのバージョン ?) では、 mod_rewrite が有効になっておらず、デフォルトでシンボリックリンクが許可されていません。必要な機能を有効にするには、apache/conf/httpd.confファイルをテキストエディタで開いて、LoadModule rewrite_module modules / mod_rewrite.soのコメントを解除します (行頭の「#」を消す)。次に、同じファイルのさらに下に、「Options FollowSymlinks」という行で始まるセクションがあります。そのセクションの2行目を「AllowOverride none」から「AllowOverride all」に変更します。編集したhttpd.confを保存し、すべてのWAMPモジュールを再起動します。これでパーマリンクが機能するはずです。
   

ヒントと小技 アーカイブリンクとして解釈されるのを避ける
一日に一投稿しか公開しないので %year%%monthnum%%day% というパーマリンクを使用したいと思うかもしれませんが、このリンクはその日の全投稿のアーカイブとして生成されることに注意してください。個別投稿へのリンクは、少なくとも %year%%monthnum%%day%%hour% にする必要があります。
パーマリンク構造をチェックする
ブログにパーマリンク構造があるかどうかチェックするには、以下のコードを使用します。
<?php if ( get_option('permalink_structure') ) { echo 'permalinks enabled'; } ?>
参考

1. User:Lazyking/Using Permalinks (Saetta Web Server)
2. 他の投稿へリンクする方法は、 投稿・ページ・カテゴリーへリンクする の記事を参照してください。

ウィジェット

1. ウィジェットのインストール
2. ウィジェットの表示
   1. 既存ウィジェットエリア内の既存ウィジェット
   2. ウィジェットエリア
3. 「テキスト」ウィジェットを使う
   1. テキストウィジェットへのコード追加
4. RSS ウィジェットを使う
5. リソース

WordPress ウィジェットは サイドバー にコンテンツや機能を追加します。WordPress にはデフォルトで「カテゴリー」「タグクラウド」「検索」などのウィジェットがあります。ウィジェットを追加するプラグインもあります。
ウィジェットはもともと、ユーザーに WordPress テーマのデザインや構造を管理するシンプルで使いやすい方法を提供する目的で設計されました。現在では適切に「ウィジェット化」された WordPress テーマであれば、ヘッダーやフッターを始め、WordPress デザインや構造の多くでウィジェットを使用します。 ウィジェットにプログラミングの経験やスキルは必要はありません。「テーマカスタマイザー」またはWordPress 管理画面の 「外観」> 「ウィジェット」から追加、削除、並べ替えできます。
カスタマイズをサポートする WordPres ウィジェットでは入力用のフォーム、データや情報の追加と削除、オプションの画像、その他のカスタマイズ機能などのオプションがあります。
「 外観ウィジェット画面 」では WordPress に同梱されたさまざまなウィジェットの使い方が説明されています。
ウィジェットが同梱されたプラグインは  WordPress プラグインディレクトリ で検索できます。
ウィジェットのインストール
WordPress にはさまざまな ウィジェット が同梱されていますが、足りないものがある場合は管理画面の 「プラグイン」>「新規追加」 から  WordPress プラグインディレクトリ  にアクセスし、新しいウィジェットを検索、追加できます。
ウィジェットの表示 既存ウィジェットエリア内の既存ウィジェット
ウィジェットを追加する前に、使用中のテーマがウィジェットを (正確に言うと、「 ウィジェットエリア 」を) サポートするかどうかを確認する必要があります。と言っても方法は単純で、管理画面の「外観」メニューの下に「ウィジェット」サブメニューがあればサポートされています。
テーマが「テーマカスタマイザー」をサポートしていれば次の手順でウィジェットを追加できます。「テーマカスタマイザー」では変更をすぐにプレビューできます。

1. 管理画面で 「外観」> 「カスタマイズ」 にアクセスします。
2. テーマカスタマイザーで「ウィジェット」をクリックします。ウィジェットカスタマイズ用画面に移動します。
3. ウィジェットエリア右側の下向き矢印をクリックします。登録済みのウィジェット一覧が表示されます。
4. サイドバー下部の「ウィジェットを追加」ボタンをクリックしてください。利用可能なウィジェットの一覧が表示されます。
5. 追加するウィジェットをクリックしてください。ウィジェットがサイドバーに追加されます。
6. プレビューで確認します。新しいウィジェットでコンテンツが表示されます。
7. サイドバー内でウィジェットを並べ替えるには、ウィジェットをドラッグアンドドロップして希望の順番に並べるか、「並べ替え」リンクをクリックして、各ウィジェットの上向き矢印、下向き矢印をクリックし、最後に「完了」をクリックします。
8. ウィジェットの機能をカスタマイズするには、右側の下向き矢印をクリックし、ウィジェットインターフェースを開きます。
9. ウィジェットを削除するには、上の手順のウィジェットインターフェースで 削除 をクリックします。

テーマが「カスタマイザー」をサポートしていなければ、次の従来の手順でウィジェットを追加できます。

1. 管理画面で 「外観」> 「ウィジェット」 にアクセスします。
2. ウィジェットを選択し、サイドバーの希望の位置にドラッグするか、ウィジェットをクリックし、テーマが複数のサイドバーをサポートしている場合はサイドバーを選択し、「ウィジェットを追加」ボタンをクリックします。複数のサイドバーオプションがある場合は、最初のサイドバーから始めてください。ウィジェットを配置するたびに、WordPress はテーマを更新します。
3. サイトをプレビューします。「デフォルト」のサイドバーの内容が、新しく追加したウィジェットで置き換わっているはずです。
4. 「ウィジェット」画面に戻り、ウィジェットを追加します。
5. サイドバー、またはウィジェットエリア内でウィジェットを並べ替えるには、ウィジェットをクリックし、希望の位置へドラッグします。
6. ウィジェットの機能をカスタマイズするには、左上隅の下向き矢印をクリックし、ウィジェットインターフェースを開きます。
7. ウィジェットのカスタマイズを保存するには「保存」をクリックします。
8. ウィジェットを削除するには「削除」をクリックします。

ウィジェットを取り除く際に、将来使う場合のために設定を残しておきたければ、そのウィジェットを「使用停止中のウィジェット」エリアにドラックしましょう。これは、ウィジェットエリアの数が種類が違うテーマに変更するときに特に便利です。
テーマを変更する場合、ウィジェットエリア/サイドバーの数や位置が異なるため移行がスムーズに行かない場合があります。テーマを変更した際にウィジェットがなくなってしまった場合、画面をスクロールして「使用停止中のウィジェット」で過去に利用した設定が保存済みのウィジェットを見つけてください。
表示オプションタブからアクセシビリティモードを有効化することで、ドラッグアンドドロップの代わりに「追加」「編集」ボタンを使うことができます。
ウィジェットエリア
ウィジェットエリアは通常 Web ページのサイドバーに位置しますが、テーマはページ内のどの位置にでもウィジェットエリアを配置できます。たとえば  Twenty Seventeen  テーマでは通常のサイドバーの位置以外に、すべてのページのフッターにもウィジェットエリアがあります。
事前に定義されたウィジェットエリア以外の、テーマ内の任意の場所にウィジェットを配置するにはプログラミングの知識が必要です。「 Widgets API 」の「 Displaying Widgets and Widget Areas (英文) 」を参照してください。
「テキスト」ウィジェットを使う
「テキスト」ウィジェットはもっともよく使用される WordPress ウィジェットの一つで、すべての WordPress インストールに含まれています。「テキスト」ウィジェットを使用して WordPress サイトにテキスト、動画、画像、カスタムリストなどを追加できます。
「テキスト」ウィジェットを使うには、以下の手順に従ってください。

1. 管理画面で 「外観」> 「カスタマイズ」 にアクセスし、「ウィジェット」をクリックします。または管理画面で 「外観」> 「ウィジェット」 にアクセスします。
2. 「テキスト」ウィジェットを追加するサイドバーを開きます。
3. 「利用できるウィジェット」リストで「テキスト」ウィジェットを探します。
4. ウィジェットを選択して希望の位置にドラッグします。

「テキスト」ウィジェットを開き、編集する際は以下のように行います。

1. 「テキスト」ウィジェットの右側の下向き矢印をクリックします。
2. 「テキスト」ウィジェットのタイトルを入力します(オプション)。
3. テキストボックスにテキスト、または HTML を入力するか、既存の内容を編集します。
4. 「自動的に段落追加する」オプションをオンにすると、テキストの各ブロックが HTML の <p> タグで囲まれます (テキストの場合、推奨)
5. 「保存」をクリックして、「テキスト」ウィジェットを保存します。
6. 「閉じる」をクリックして、「テキスト」ウィジェットを閉じます。
7. ブラウザで変更結果を確認し、必要であれば修正します。

「テキスト」ウィジェットにはさまざまな HTML、XHTML、マルチメディアリンク、動画や埋め込みオブジェクトのプレイヤーを挿入できます。
テキストウィジェットへのコード追加
基本的な HTML、埋め込みオブジェクト、JavaScript は簡単に WordPress「テキスト」ウィジェットへ追加できます。マルチメディアコンテンツのソーシャル共有サイト用埋め込みコードも WordPress「テキスト」ウィジェット内で動作します。ただしアクティブなコードや PHP のようなプログラミング言語は、ウィジェットが表示できないコードを取り除くため動作しません。
「テキスト」ウィジェットにアクティブなコードを追加するには、 WordPress プラグインディレクトリ  から、投稿内での PHP 使用に関する WordPress の制限を上書きする、多くのプラグインのどれかを使用してください。ただしウィジェットでは動作しないものもあるため確認が必要です。
RSS ウィジェットを使う
「RSS」ウィジェットでは外部のフィードソースからサイトのウィジェットエリアに、Twitter アカウント、Fecebook の投稿、Google+ の投稿、その他のブログなどのコンテンツを統合できます。
「RSS」ウィジェットは有効なフィードを使用し、任意のソースで最近公開されたコンテンツを表示します。これはサイトと外部コンテンツを統合する理想的な方法です。
デフォルトでは WordPress「RSS」ウィジェットは投稿のタイトル、ツイートの最初の 100文字、長いタイトルのない投稿を表示します。表示はフィードのデザインや構造により、リンク形式か、オリジナルのソースへのリンクとなります。

1. 最初のボックスに サイドバーや他のウィジェット用領域に表示するコンテンツの RSS フィード URL を入力します。RSS フィード URL はコンテンツのソースページからコピーします。
2. このフィードにタイトルをつける:オプションです。コンテンツのソースを紹介できます。
3. フィード内の項目をいくつ表示しますか ?:デフォルトでは 10件の投稿が表示されますが、1から20の間で指定できます。
4. 項目の内容を表示しますか ?:タイトル以外にコンテンツの抜粋を表示できます。
5. もしあれば項目の作成者を表示しますか ?:オリジナルのコンテンツの作成者を明記する場合は、このオプションをオンにして作者名を表示します。
6. 項目の日付を表示しますか ?:可能であれば、コンテンツのオリジナルの日付が表示されます。

WordPress サイトのサイドバーや他のウィジェット領域には、複数の RSS フィード用に複数の「RSS」ウィジェットを追加できます。
リソース

1. テーマのウィジェット対応
2. Widgets API
3. WordPress Tips on Exploring the WordPress Text Widget 「テキスト」ウィジェットの使い方
4. WordPress ウィジェットのアナウンス (過去文献としての参照)

ブルートフォース攻撃

1. 自分を守る
   1. ユーザー名 admin を使用しない
   2. 良いパスワードを使用する
   3. プラグイン
2. サーバーを守る
   1. wp-login.php をパスワード保護する
   2. wp-admin へのアクセスを IP アドレスで制限する
   3. リファラーの無いアクセスを拒否する
   4. ModSecurity
   5. Fail2Ban
   6. Blocklists
   7. Cloud/Proxy サービス
3. 外部資料

ソフトウェアの脆弱性に着目する攻撃とは異なり、ブルートフォース攻撃 (Brute Force Attack) は、非常に単純な方法でアクセス権を取得しようとします。ユーザー名とパスワードを入力し、ログイン成功するまで繰り返します。美しくないですが、ユーザー名 admin パスワード 123456 のようなものを採用している場合、攻撃が成功しやすいです。
手短に言うと、ウェブサイトのセキュリティで一番脆い場所、つまり、あなた、を狙っているのです。
攻撃の性質上、サーバーのメモリ上限に達してパフォーマンス低下を引き起こすかもしれません。http リクエストの数 (あなたのサイトを訪問する回数) が非常に多いため、サーバーがメモリ不足になるからです。
この攻撃は、WordPress 特有のものではありません。すべてのウェブアプリケーションに起こりえます。しかし WordPress は良く利用されているため、攻撃の標的となりやすいです。
自分を守る
WordPress へのよくある攻撃の場合、wp-login.php ファイルに繰り返しアクセスし、ログインできるかサーバーがダウンするかするまで継続します。自分を守るために、いくつかの方法があります。
ユーザー名 admin を使用しない
WordPress のデフォルトのユーザー名が admin のため、admin を使用していると仮定した攻撃が多いです。ユーザー名 admin を使用している場合は、新しいアカウントを作成し、全ての投稿を新しいアカウントに移譲し、admin を購読者に変更してください (あるいは削除してください)。
プラグイン Admin Renamed Extended を使用して自身のユーザー名を変更できます。
良いパスワードを使用する
パスワードの目的は、他者が推測しずらく、ブルートフォース攻撃が成功しにくいものにすることです。安全なパスワードを作成することができる、多くの automatic パスワード生成ツール (google 検索) があります。
WordPress にはパスワード強度を示すメーターがあり、パスワードを変更するときに表示されます。パスワードを変更するときは、十分な強度であることを確かめておきましょう。
プラグイン Force Strong Password を使用して、強固なパスワードを強制することができます。
パスワード生成時に避けたほうが良い事:

1. 本名、ユーザー名、会社名、ウェブサイトの名前やそれらの組み合わせ。
2. どんな言語であれ、辞書にある単語。
3. 短いパスワード。
4. 数字のみ、またはアルファベットのみのパスワード (両方を混ぜるのが良い)。

強固なパスワードは、ブログ投稿を守るのに必要ですが、それだけではありません。管理者アカウントのアクセスを取得した攻撃者が、悪意あるスクリプトをインストールし、サーバー全体が危うくなることがあります。
パスワードの強度をさらに上げ、ブログを守るために、 二段階認証 を有効にすることができます。
プラグイン
プラグインを用いて、ログイン試行回数を制限したり、wp-admin へのアクセスを禁止したりできます。There are many plugins available to limit the number of login attempts made on your site. Alternatively, there are also many plugins you can use to block people from accessing wp-admin altogether.
サーバーを守る
wp-login.php あるいは wp-admin をロックする事を決めた場合、これらのページへアクセスすると、404または401エラーに遭遇するでしょう。これを避けるには、.htaccess ファイルに下記のように記述します。
ErrorDocument 401 default
401エラーを 401.html に向けることもできます。ここで重要なのは、 WordPress で ない 、ということです。
Nginxの場合は、error_pageディレクティブを使用することができますが、URLを完全に指定する必要があります。
error_page 401 http://example.com/forbidden.html ;
wp-login.php をパスワード保護する
wp-login.php ファイル (と wp-admin フォルダ)をパスワード保護することにより、防御壁を増やすことができます。wp-admin をパスワード保護すると、フロントエンドで ajax を使用するプラグインを破壊するため、wp-login を保護するだけで通常は良いでしょう。
パスワード保護するには、.htpasswd ファイルを作成する必要があります。多くのホスティングでは生成ツールを提供してますが、もし手作業で作成する必要がある場合は、 htpasswd generator を使用することができます。.htaccess ファイル (拡張子のみを持つファイル) と同様、.htpasswd も拡張子のみです。
このファイルをウェブ公開領域(public_html や domain.com 等。ホスティングにより異なる)の外に置くことができます。同じフォルだに置くことも できます が、こうする場合は .htaccess ファイルに追加でセキュリティ対策を施す必要があります。
.htpasswd ファイルをアップロードしたら、どこにあるかを .htaccess に伝える必要があります。.htpasswd をホームディレクトリに置き、htpasswd ユーザー名が mysecretuser の場合、.htaccess に下記のように記述します。
# Stop Apache from serving .ht* files<Files ~ "^\.ht">Order allow,denyDeny from all</Files># Protect wp-login<Files wp-login.php>AuthUserFile ~/.htpasswdAuthName "Private access"AuthType Basicrequire user mysecretuser</Files>
AuthUserFile の実際の位置はサーバーに依存します。また ‘require user’ にはユーザー名を指定してください。
もしあなたが Nginx を使用している場合は、 HttpAuthBasicModule を使用することにより、wp-login.php を守ることができます。このブロックは、サーバーブロックの内部に設置すべきです。
location /wp-login.php { auth_basic "Administrator Login"; auth_basic_user_file .htpasswd;}
ファイル名のパスは、Nginx のコンフィギュレーションファイル (nginx.conf) のディレクトリに関連付けられています。
そのファイルは、以下のようなフォーマットにするべきです:
user:passuser2:pass2user3:pass3
パスワードは、必ず crype(3) によりエンコードしてください。これは、 htpasswd generator を使用することにより、オンラインで暗号化することもできます。
wp-admin へのアクセスを IP アドレスで制限する
自分だけが管理画面にログインする必要がある場合、もしあなたが固定 IP アドレスを持っていれば、.htaccess ファイルを用いて自分以外の wp-admin へのアクセスを拒否することができます。
Note:Beware your ISP or computer may be changing your IP address frequently, this is called dynamic IP addressing, rather than fixed IP addressing. This could be used for a variety of reasons, such as saving money. If you suspect this to be the case, find out out how change your computer's settings, or contact your ISP to obtain a fixed address, in order to use this procedure.
.htaccess をテキストエディタで開き、下記を追加する:
# Block access to wp-admin.order deny,allowallow from x.x.x.x deny from all
x.x.x.x は自分の IP アドレスに置き換えてください。インターネットサービスプロバイダに問い合わせると、自分の IP アドレスが分かるでしょう。あるいは What Is My IP のようなオンラインサービスを使用することもできます。
Nginxについては、locationブロックをサーバーブロックの内部に追加することにより、前述のApacheの例と同様に機能させることができます。
error_page 403 http://example.com/forbidden.html;location /wp-admin { deny 192.168.1.1; allow 192.168.1.0/24; allow 10.1.1.0/16; deny all;}
deny/allow の順序が重要である事に注意してください。アクセス指定順を変えても上手くいく、と思うかもしれません。実際はそうではありません。上記の例の順序を変えると、全てのアドレスからのアクセスを拒否します。
テーマやプラグインが AJAX を使用している場合、.htaccess に追加の設定を記述して、それらがうまく動作するようにする必要があります。
# Allow access to wp-admin/admin-ajax.php<Files admin-ajax.php> Order allow,deny Allow from all Satisfy any</Files>
このファイルを保存し、wp-admin フォルダにアップロードしてください。
Nginx の場合、もしあなたが wp-admin と ajax へのアクセスを制限している場合、別の location ブロックをサーバーブロックに追加する必要があるでしょう。
location /wp-admin/admin-ajax.php { allow all;}
許可する IP アドレスを複数指定することができます。
# Block access to wp-admin.order deny,allowallow from x.x.x.x allow from y.y.y.y allow from z.z.z.z deny from all
複数のインターネットサービスプロバイダを使用する場合 (モバイル環境から管理画面にアクセスする場合、等)や、何人かが管理画面にアクセスできるようにする場合に役立ちます。
IP アドレスブロックを許可する場合は、下記のように記述します。
# Block access to wp-admin.order deny,allowallow from x.x.x.* deny from all
例えば、192.168.1.* を設定すると、IP アドレス範囲 192.168.1 を許可します。
リファラーの無いアクセスを拒否する
Combatting Comment Spam の発展として、これを使用してサイトにアクセスしないでログインフォームにアクセスされたものを拒否することができます。
# Stop spam attack logins and comments<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{REQUEST_METHOD} POST RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php* RewriteCond %{HTTP_REFERER} !.*example.com.* [OR] RewriteCond %{HTTP_USER_AGENT} ^$ RewriteRule (.*) http://%{REMOTE_ADDR}/$1 [R=301,L]</ifModule>
Nginx – リファラの無いアクセスリクエストを拒否する
location ~* (wp-comments-posts|wp-login)\.php$ { if ($http_referer !~ ^(http://example.com) ) { return 405; } }
example.com は自分のドメインに変更してください。マルチサイトで複数ドメインを使用している場合は、 (example.com|example.net|example4.com) のように変更してください。
ModSecurity
ModSecurity を使用する場合は、 Frameloss – Stopping brute force logins against WordPress の指示に従ってください。サーバーのルート権限が必要になります。ホスティング業者の手助けが必要かもしれません。
ModSecurity 2.7.3 を使用している場合は、ルールを .htaccess ファイルに追記することもできます。
Fail2Ban
Fail2ban は、Python is a Python でかかれた常駐プログラムです。Fail2ban は、Apache (あるいは、SSHなど) をチェックし、特定のイベントが発生した場合に、ファイアウォールのルールを追加します。Fail2ban は、正規表現を使用したフィルタを使用します。もし、設定した正規表現にマッチしたイベントが例えば5分間に5回発生したら、そのIPアドレスを60分間 (あるいは任意の期間) ブロックすることができます。Fail2ban のインストール及び設定には、 root 権限が必要です。
Blocklists
多くのブルートフォース攻撃は、ロシア、カザフスタン、ウクライナのホストから行われています。これらの国々のIPアドレスブロックを選択し、ブロックすることができます。インターネット上に、このようなブロックリストが公開されており、ダウンロードすることができます。また、シェルスクリプトにより、 iptables にブロックルールを読み込ませることも可能です。ただし、これにより、攻撃のためのアクセスではない、合法なユーザーをブロックしてしまうことに注意してください。これについて、サポートが可能か確認し、またカスタマーにこの決断について説明を行いましょう。国ごとのブロックリストに加え、よく知られたスパマーのIPアドレスのリストがあります。このようなリストも、 iptables に使用することができます。これらのリストは定期的に更新した方がよいでしょう。
ブロックリストと iptables の設定には、root 権限が必要です。
Cloud/Proxy サービス
CloudFlare や Sucuri CloudProxy のようなサービスは、攻撃者がサーバーに到達する前に IP をブロックすることで、これらの攻撃を沈静化するのに役立つでしょう。
外部資料

1. Sucuri: Protecting Against WordPress Brute Force Attacks
2. Liquid Web: ModSecurity Rules To Alleviate Brute Force Attacks
3. HostGator: Password Protecting wp-login
4. Stopping Brute-force Logins
5. Swiss Army Knife for WordPress (SAK4WP) – Free Open Source Tool that can help you protect your wp-login.php and /wp-admin/ but not /wp-admin/admin-ajax.php with one click and much more
6. 本当は怖い WordPress: WordPress のパスワード強度チェック

FAQ ハッキングされた場合は

1. ハッキング／クラッキング被害の例
2. 助けて ! サイトがハックされました
3. 被害を受けた時には
   1. 冷静になる
   2. ローカル環境をスキャンする
   3. Web サイトをスキャンする
   4. Web サイトのスパム認定に注意する
   5. サーバー管理者に確認を取る
   6. アクセス制御の見直し
   7. 秘密鍵 (シークレットキー) を変更する
   8. 残っているデータとファイルのバックアップを取る
   9. ハッキングを見つけ、除去する
   10. コミュニティの利用
   11. バージョン管理システムを利用の場合
   12. バックアップからの復元を検討する
   13. バックアップが存在しない場合
   14. コアファイルを 新しくダウンロードした ZIP 内のファイルと入れ替える
   15. アップグレードを行う
   16. パスワードをもう一度変更する
   17. サイトのセキュリティを高める
   18. 事後分析を行う
   19. 定期的なバックアップをとる
4. Google の検索結果に警告がでる場合は
5. その他のリソース

注: 悪意を持ったサイトへの攻撃や不正アクセスは本来「クラッキング」と呼ばれますが、検索性などを考えて、ここでは一般的な用法に従い「ハッキング」と併記しています（ ウィキペディア » クラッキング ）。
ハッキング／クラッキング被害の例
WordPress サイトが受ける攻撃の被害には、以下のような例があります。

1. テーマファイルの改変
   1. スパムサイトやマルウェアサイトへのリンクが埋め込まれた
   2. iframe で外部サイトを表示させられた
   3. 悪意あるスクリプトを埋め込まれた
2. データの改竄／漏洩／破壊
   1. データベースの改竄／破壊
   2. ユーザーログインデータの漏洩
   3. 投稿パスワードの漏洩
3. 既存ファイルの削除、不正ファイルの追加

助けて ! サイトがハックされました
細心の注意を払って WordPress をインストール し、理想のデザインにぴったりの テーマ を見つけ、素晴らしい プラグイン をいくつか導入して、気の利いた投稿とページを作成し …. と、サイトの構築には誰もが膨大な時間と労力を注ぎ込んでいます。
そんなある日、ブラウザで自分のサイトにアクセスすると、そこには真っ白で何も表示されなかったり、アダルトサイトに自動で転送されたり、ページがステロイド剤の広告で埋もれていたり…。頭の中では「 私のサイトをハックして何の意味があるの ? 」という疑問がいっぱい。さて、どうしよう…。
ハッキングされたという事実自体が破壊的で、WordPress サイトを開いたことさえ悲観したくなるかもしれません。ただ安心してください。何も世界の終わりがきたわけではなく、発生した問題に対する解決に必要な具体的な手順はあります。再びハッキングされることを防止する方法もあります。
以下では、何年にもわたって蓄積されたハッキング後の後処理についての考察、特に、ハッキング被害にあったら何をすべきかを説明します。
被害を受けた時には 冷静になる
Web サイトのオーナーとしてセキュリティの問題への対応は非常なストレスがかかります。特に、「WordPress は簡単」と誰もが口にしていたのと反対の状況が起きては気弱になっても仕方ありません。ただ、すべてを失ったわけではありません ! 確かに少しお金を失ったかもしれません。ブランドが傷ついたかもしれません。しかし、そこから回復はできます。
まずは立ち止まって、冷静になりましょう。冷静になれば、より効率的に状況を把握、対処し、失った信頼を取り戻すことができます。
ローカル環境をスキャンする
まず最初に始めるべき場所はローカルコンピュータです。多くの場合、攻撃や感染の出どころはローカルコンピュータ、たとえばノートパソコン、デスクトップ PC です。
ローカルコンピュータでアンチウイルスやマルウェアのフルスキャンを必ず実行してください。ウィルスの中にはアンチウイルスソフトを検出し、スキャンを逃れるものもあるため、可能であれば別のソフトも使用してください。このアドバイスは Windows、OS X、Linux いずれにも当てはまります。WordPress 管理画面にログインできない場合 この問題は一般に考えられる以上に発生しています。慌てる必要はありません。「 ログインパスワードを変更・再発行する 」に丁寧に書かれた手順に従って対処してください。
phpMyAdmin や Adminer を使用すると WordPress の 管理画面 をバイパスし、データベースに直接ログインして、ユーザーテーブル wp_users 内のユーザーをリセットできます。
パスワードの暗号化についてよく分からなければ、メールアドレスを更新し、WordPress のログイン画面に戻り、「パスワードをお忘れですか ?」リンクをクリックしてメールを待ってください。
Web サイトをスキャンする
スキャンには多くの方法があります。現在では簡単にスキャンできる多くの優れた プラグイン も公開されています。
拡張子も含めてすべてのファイルやフォルダーを表示し、「*.exe」ファイルまたは実行可能ファイルをスキャンし、ファイルサイズの大きさで並べ替えます。ウィルスプログラムは多くの場合5MB 以下ですが、5MB 以上の場合もありますし、5MB 以下の「.exe」ファイルがすべてウィルスプログラムでもありません。既知のウィルスプログラム、ワームプログラムを削除し、不明な実行ファイルについてはリストを作成し、オンラインウィルスデータベースと照らしあわせてください。注意: システムファイルを削除しないように注意してください。Securelist が 感染したファイルの見つけ方に関する記事 (英文) を公開しています。
さまざまな症例や、Web サイト、訪問者への影響に注意してください。たとえば不正転送は Web サイトのルートの .htaccess ファイルや index.php ファイルなどで見つかります。他のウィルスでは wp-content/themes ディレクトリ内の index.php、header.php、footer.php、functions.php を狙います。もちろんもっと単純な例もあります。
Web サイトのスパム認定に注意する
Google Blacklist でのスパム認定はブランドにダメージを与えます。1日に 9,500 から 10,000 の Web サイトがスパムサイトとして認定され、この数字は日々増え続けています。スパムサイトの警告には、大きなスプラッシュページが表示され近づかないよう警告するものから、検索エンジンの結果ページに小さくポップアップするものまでさまざまな形があります。
スパムサイトのリストとしては Google Blacklist がもっとも有名ですが、他にも Bing や Yahoo、さまざまな種類のデスクトップアンチウイルスソフトがあります。クライアントやサイトの訪問者がこれらのツールを使用してサイトをスパム認定できることに注意してください。
最低限、Google Webmaster Tools のアカウントを取得した上で、現在、ハッキングの被害を受けているのであれば 実施すべき項目を確認し 、完了後に、 Google の登録取消手順に従ってください。
サーバー管理者に確認を取る
共有サーバーを利用している場合は特に、あなたのサイト以外にも被害が及んでいるかもしれません。サーバー管理者 (レンタルサーバー会社など) に確認し、必要な対策をとっているか確認しておくのも無駄ではないでしょう。また、実際に攻撃が起こったのか、単にサービスがダウンしていたのかなどの確認を行ってくれるかもしれません。
現代のハッキング被害で極めて深刻なものにメールアドレスのスパム認定があります。これはたびたび発生しています。サイトがスパムメール送信の踏み台に使用されると、スパムアドレスの管理会社や団体はサイトの IP アドレスを、スパムメール送信に使用されたサーバーと関連するものとして登録します。最良の方法は、ビジネスインパクトが発生した際に Google Apps などのメールプロバイダを調べることでしょう。
アクセス制御の見直し
同僚がパスワードの更新について話すのを聞いたことがあるはずです。確かに、パスワードの変更は重要です。しかしそれはより大きな問題の一部でしかありません。 アクセス権について考慮する場合 、全体の基本姿勢を変更する必要があります。たとえばパスワードは最初から複雑で、長く、ユニークなものを使用すべきです。最良の方法として 1Password や LastPass などのパスワードジェネレータを使用してください。
変更するパスワードには、すべてのアクセスポイントのパスワードが含まれることに注意してください。アクセスポイントには、FTP または SFTP、WP-ADMIN、CPANEL、その他サーバーで使用されるすべての管理パネル、そして MYSQL があります。
またサイトのユーザーのパスワードだけでなく、環境にアクセスするすべてのユーザーのパスワードも変更の対象とします。
秘密鍵 (シークレットキー) を変更する
攻撃者がパスワードを盗んでブログにログインした場合、パスワードを変更してもその人がログインした状態になってしまいます。これは、Cookie がまだ有効なためです。これを防ぐには、新しい秘密鍵を作成する必要があります。 WordPress キージェネレーター でランダムなキーを取得し、 wp-config.php ファイル内の値を上書き しましょう。
残っているデータとファイルのバックアップを取る
もしまだファイルやデータベースが残っているなら、 バックアップを取る ことを検討してみてください。そうしておけば、あとから検査を行ったり、クリーンアップに失敗したときに元に戻すことができます。ただし、「被害を受けたサイトのバックアップ」ということがはっきり分かるようにしておくようご注意ください。
ハッキングを見つけ、除去する
このリストの中で恐らくもっとも難しく、もっとも作業の必要な項目です。結局は Web サイトのハッキングに関する個人の技術的な知識力や洞察力に左右されますが、以下の項目から始めることで正しい方向に進むことができます。
Donncha O Caoimh（ダナカ）氏の記事 は、攻撃の可能性があることが疑われる場合にはどうすればよいかが書いてある役に立つ記事です。このページよりさらに深く踏み込んだ内容なので、しっかり読んで、実行する価値があるでしょう。
また「 被害を受けたサイトをクリーンインストールする方法 」も参照してください。
Sucuri は多くの技術的な記事を投稿しています。「 WordPress ブログからマルウェアを除去する方法 」では手順の詳細を説明しています。
さらに、転送のコツを紹介した記事「 Web サイトをクリーンにする FTP のヒントとコツ 」は問題の根本を探るために役立ちます。
ハッキングに対して、すべてを削除し、ゼロから始める方法は分かりやすい対処方法で、確かに魅力的な方法ですが、まったく現実的ではありません。実施すべきは Web サイトのコアに対する影響を考えず、サイトのある要素を再インストールすることです。常に Web サイトで使用していたソフトウエアと同じバージョンを再インストールしてください。古いバージョン、新しいバージョンの再インストールはサイトを殺すようなものです。再インストールの際には、WP-ADMIN で再インストールオプションを使用せず、FTP または SFTP アプリケーションを使用してバージョンをドラッグアンドドロップしてください。インストーラはしばしば存在するファイルのみを上書きする一方、ハッキングは新しいファイルを追加するため、長い実行ではこちらの方が効率的です … 🙂
攻撃者は、.htaccess を使ってあなたの URL から悪意のあるサイトに訪問者を誘導することができます。ブログのディレクトリだけでなく、サイトのルートディレクトリもチェックしてください。ハッカーはコードをファイルのかなり下の方に隠すことがあるので、最後までスクロールしましょう。また、.htaccess ファイルのパーミッションを変更して初心者がファイルの変更しづらくすることもあります。その場合はパーミッションを644に変更します (推奨される安全なパーミッションは 604です ) 。
コミュニティの利用
しばしば忘れられますが、WordPress はコミュニティベースのプラットフォームです。困っていれば、コミュニティの誰かが手を貸してくれるでしょう。サイトに火が付いた状態なら、あるいは単に手助けが欲しいだけでも、 WordPress.org フォーラムのタグ「Hacked」 または タグ「Malware」 から始めると良いでしょう。
バージョン管理システムを利用の場合
バージョン管理システムを使っている場合、何が変更されたかを素早く発見して直前のバージョンのサイトに戻すことができるかもしれません。ターミナルまたはコマンドラインから現在のファイルと公式 WordPress レポジトリ上の同じバージョンのファイルを比較するには、以下のコマンドを使います。
$ svn diff .
または、特定のファイルを比較するには以下を入力してください。
$ svn diff /path/to/filename
バックアップからの復元を検討する
被害を受けていない、クリーンなデータベースバックアップからデータの復元を行い、WordPress を再インストールし、プラグインやテーマを SFTP などからアップロードすれば、悪意のあるコードが含まれていない状態にできます。
バックアップが存在しない場合
2つのあまり喜ばしくない選択肢があります。新しいサイトをゼロからはじめるか、悪意のあるコードを手動で発見、削除することです。専門家にも、あなたのサイトを完全にクリーンアップすることは難しいでしょう。数日間ファイルを目視し続けてハッカーによって挿入された小さなスニペットコードを取り除く作業を行わなくてはなりません。ひとつでも見落とせば、サイトがオンラインになった瞬間にまたハッキングされてしまうでしょう。 バックドア について詳しく読み、対策を練らなくてはならない相手のことを少し理解してみましょう。これを読んでいる方でまだハッキングされていないという場合は、今すぐ始めてください。
コアファイルを 新しくダウンロードした ZIP 内のファイルと入れ替えるコアファイルを 新しくダウンロードした ZIP 内のファイルと入れ替える
最低限でも、コアファイルをすべてまっさらな状態にして、ハックされたコードが混入していないことを確実にしましょう。プラグインやテーマも忘れずに。
また「 優れたバックアップ戦略の立案 」のプロセスを通した考え方にヒントを得られるかもしれません。検討すべき多くの手順がありますので、これに従って計画してください。
アップグレードを行う
きれいな状態になったら、WordPress を 最新バージョン に アップデートしましょう 。古いバージョンを使っていると、攻撃を受ける危険性が高くなります。
パスワードをもう一度変更する
サイトがすべてきれいになったら、その後にまたパスワードを変更しましょう。攻撃を発見した後ににパスワードを変更しただけの場合は、 再度変更しましょう 。パスワードは複雑で、長く、ユニークなものを使用することを思い出してください。
サイトのセキュリティを高める
サイトの回復に成功したら、 お勧めのセキュリティ対策 の一部または全部を実行し、サイトの安全性を向上しましょう。WordPress の 脆弱性が高い部分についてよく理解しましょう 。
次に Web サイトがハッキングされる仕組みを理解 し、学んだ知識を使用して将来のセキュリティリスクを下げる環境を構築してください。
事後分析を行う
サイトが安全な状態になったら、ログを確認し、攻撃がどうやって起こったのか分析してみましょう。 OSSEC のようなオープンソースツールでログを分析し、攻撃どこでどのように発生したかを発見できます。「 Web サイトセキュリティのための OSSEC 」は OSSEC を使用したプロセスを概観するコンパクトで良い解説です。
「 Case Study: Analyzing a WordPress Attack (ケーススタディ: WordPress への攻撃の解析) 」はログを利用してハッカーの狙いを見つける別の良い記事です。
他にも多くの例があります。「 My WordPress Website Was Hacked(WordPress のサイトがハックされた) 」を読めば、ハッキング方法を識別するさまざまな手順を概観できます。
定期的なバックアップをとる
悪夢が終わりを告げたら、 データベース や ファイル の定期的なバックアップを取り始めましょう。万が一またこのようなことが起こってしまっても、前回取ったクリーンなバックアップから復旧し、パスワードと秘密鍵を変更するだけで済みます。
Google の検索結果に警告がでる場合は
こちらのドキュメントを参照して対処してください。

1. あなたのサイトにこの警告が表示されたら…

その他のリソース

1. How to Cope with a Hacked Site (OttoPress)
2. How to clean a hacked WordPress site
3. Website malware & blacklist scan (Sucuri)
4. Another malware scanner (Unmask Parasites)
5. Cloaked link checker (ERTW.com)
6. Step-By-Step Guide to Cope With a Hacked WordPress Site
7. WordPress Security – Cutting Through the BS (Sucuri)
8. Security Posts (Perishable Press)

管理画面での SSL 通信

1. SSL によるログインと管理画面へのアクセスを強制する
   1. 例
2. リバースプロキシの使用
   1. 例
3. 追加情報
   1. バーチャルホスト
      1. セキュアでないホストの Rewrite ルール
      2. セキュアなホストの Rewrite ルール (オプション)
      3. WordPress URIを設定する
      4. 構成例 (一部)
      5. ユーザーログインとユーザー登録の Rewrite
      6. 443番または80番ポートで動作するサイトの Rewrite
   2. まとめ
   3. 検証
   4. 制限
4. 関連

管理画面へのアクセスを簡単にかつ強制的に SSL 接続にするにはサイトの wp-config.php ファイルに FORCE_SSL_ADMIN 定数を定義します。この定数をプラグインファイル内に定義しても十分ではありません。 wp-config.php ファイルで定義する必要があります。なおここではサーバーの SSL 構成や、サイトの前でセキュアサーバー用に構成された (バーチャル) ホストはこの定数を true に設定しても正しく動作するものとします。
注意: FORCE_SSL_LOGIN は Version 4.0 で廃止されました。FORCE_SSL_ADMIN を使用してください。
SSL によるログインと管理画面へのアクセスを強制する
すべてのログイン、およびすべての管理画面へのアクセスを SSL を通して行うには FORCE_SSL_ADMIN 定数を true に設定します。
例
define('FORCE_SSL_ADMIN', true);
リバースプロキシの使用
SSL を提供するリバースプロキシにより WordPress がホストされ、自身は SSL なしでホストされる場合、このオプションを設定すると当初すべてのリクエストが無限リダイレクトループに陥ります。これを避けるには HTTP_X_FORWARDED_PROTO ヘッダーを認識するように WordPress を構成してください。ここでリバースプロキシは適切に構成されており、ヘッダーを設定するものとします。
例
define('FORCE_SSL_ADMIN', true);if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) { $_SERVER['HTTPS']='on';}
追加情報
この記事の後半では古いバージョンの WordPress を使っている場合 (使うべきではありませんが)、または SSL 設定が異なる場合、たとえば SSL 証明書が異なるドメイン用のものである場合等の構成を説明します。
https プロトコルを使用したセキュアな接続上で wp-admin 全体を動作させたいとします。このとき大きく以下の手順で設定します。

1. 同一 URL (ブログ URL) で、セキュア (SSL 通信) とセキュアでない2つのバーチャルホストを設定する。
2. セキュアなバーチャルホストでは、wp-admin 以外のすべてのトラフィックをセキュアでないサイトへ転送する Rewrite ルールを設定する。
3. セキュアでないバーチャルホストでは、wp-admin のすべてのトラフィックをセキュアなバーチャルホストへ転送する Rewrite ルールを設定する。
4. プラグイン経由で wp-admin 内のリンク用のフィルタを定義する。一度有効化されると、管理画面へのリンクは https を使用するように書き換えられ、cookie は暗号化した接続でのみ動作するように編集される。

以下のガイドでは WordPress 1.5 と httpd.conf (.htaccess ではなく) の Rewrite ルールを使用した mod_rewrite 稼働の Apache を使用します。他のホスティングのケースでも簡単に修正して適用できます。
バーチャルホスト
セキュアでないサイトに追加して、セキュアサーバー用に設定された (バーチャル) ホストが必要です。この例ではセキュアなバーチャルホストがセキュアでないホストと同じ DocumentRoot を使用します。仮に wpadmin.mysite.com のような異なる名前を使用する場合は DocumentRoot を wpadmin ディレクトリにリンクしてください。
セキュアなバーチャルホストの設定については、利用しているISPに問い合わせてください。管理者権限を持つ場合には自分で設定することもできます。注意: 異なる SSL サーバーの識別に名前ベースのバーチャルホストは使用できません。参照: http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts2
セキュアでないホストの Rewrite ルール
セキュアでないホストの .htaccess または httpd.conf のバーチャルホスト部分に次の Rewrite ルールを追加します。http://mysite.com/wp-admin/ や http://mysite.com/wp-login.php を表示する際に自動でセキュアなホストに転送されます。
メインの WordPress 系 Rewrite ブロックの上に追加する必要があります。
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC] RewriteCond %{HTTPS} !=on [NC] RewriteRule ^/?(wp-admin/|wp-login\.php) https://mysite.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]
パーマリンクの Rewrite ルールを使用している場合、この行は RewriteRule ^.*$ - [S=40] の前に設定する必要があります。
上のコードで重要な点は「THE_REQUEST」の使用です。これにより実際の http リクエストのみが書き換えられ、include や fopen のようなローカルでのダイレクトなファイル要求は書き換えられないことが保証されます。
セキュアなホストの Rewrite ルール (オプション)
以下の Rewrite ルールはオプションです。このルールによりセキュアな接続上のパブリックなサイトへのアクセスは無効化されます。以下のプラグインを使用してサイトのパブリックな部分にログインしたままにしたければ、このルールを追加しないでください。暗号化されていない接続上でプラグインが cookie を無効化します。
セキュアなバーチャルホストでは .htaccess ファイル内、またはバーチャルホストの宣言内で2つの Rewrite ルールを定義する必要があります (Rewrite の詳細については「 パーマリンクの使い方 」を参照してください)。
RewriteRule !^/wp-admin/(.*) - [C] RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
最初のルールは次の2番目のルールの対象から wp-admin ディレクトリを除外します。2番目のルールはセキュアサイトへのアクセスをセキュアでないサイトへのアクセスに変換します。閲覧者が意識することはなく快適さが保たれます。
WordPress URIを設定する
ある種のプラグインの動作のため、または何らかの理由によりオプションに WordPress URI を設定し https プロトコルを反映するには https://mysite.com を設定します。ブログのアドレスは変わりません。
構成例 (一部)
注意: 以下の構成は WordPress 2.8 以上と 100% 互換ではありません。これは WordPress 2.8 が wp-includes フォルダーからファイルを使用するためです。はじめの Rewrite ルールによるリダイレクトからセキュリティの警告が出る場合があります。詳細情報については https://core.trac.wordpress.org/ticket/10079 を参照してください。
<VirtualHost nnn.nnn.nnn.nnn:443> ServerName www.mysite.com SSLEngine On SSLCertificateFile /etc/apache2/ssl/thissite.crt SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown DocumentRoot /var/www/mysite <IfModule mod_rewrite.c> RewriteEngine On RewriteRule !^/wp-(admin|includes)/(.*) - [C] RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L] </IfModule> ...</VirtualHost># セキュアでないサイト<VirtualHost *> ServerName www.mysite.com DocumentRoot /var/www/ii/mysite <Directory /var/www/ii/mysite > <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} -f [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^wp-admin/(.*) https://www.mysite.com/wp-admin/$1 [C] RewriteRule ^.*$ - [S=40] RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L] ... </IfModule> </Directory> ...</VirtualHost>
ユーザーログインとユーザー登録の Rewrite
ユーザーログインとユーザー登録にも SSL を使用することは良い考えです。次の更新版 Rewrite ルールを検討してください。
セキュアでないホスト
RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]
セキュアなホスト
RewriteRule !^/wp-(admin|login|register)(.*) - [C]
443番または80番ポートで動作するサイトの Rewrite
# WordPress 開始<IfModule mod_rewrite.c>RewriteEngine OnRewriteBase /# 443番ポート等で動作するサイト (http over ssl)RewriteCond %{SERVER_PORT}  !^80$RewriteRule !^wp-(admin|login|register)(.*) - [C]RewriteRule ^(.*)$ http://%{SERVER_NAME}/$1 [L]# 80番ポートで動作するサイト (http)RewriteCond %{SERVER_PORT} ^80$RewriteCond %{REQUEST_FILENAME} -f [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^wp-(admin|login|register)(.*) https://%{SERVER_NAME}:10001/wp-$1$2 [L]RewriteCond %{SERVER_PORT} ^80$RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]</IfModule>
まとめ
この方法は WordPress に 内在するセキュリティリスク を修正しません。また、内部ユーザーからの攻撃やセキュアな接続を脅かすその他のリスクからも WordPress を保護しません。
それでも悪意あるユーザーによる cookie や認証ヘッダの取得、および管理者を偽装した wp-admin へのアクセスを非常に難しくします。またコンテンツが盗み見される可能性を減らします。ドラフト文書を保持する法律関連のブログなど厳格な保護が必要なサイトでは重要です。
検証
筆者のサーバーログで確認したところ GET リクエストと POST リクエストの両方が SSL を使用し、セキュアでないホスト上のすべての wp-admin へのトラフィックがセキュアなホストに転送されました。
サンプルの投稿ログ:
[Thu Apr 28 09:34:33 2005] [info] Subsequent (No.5) HTTPS request received for child 6 (server foo.com:443)xx.xxx.xxx.xxx - - [28/Apr/2005:09:34:33 -0500] "POST /wp-admin/post.php HTTP/1.1" 302 - "https://foo.com/wp-admin/post.php?action=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"
実際には追加のテスト、可能であればパケットスニファーや本格的なネットワーク解析ツールを使用した確認が必要です。
制限
筆者の考えでは (検証はしていません) ユーザーが cookie を保存するか、フォームのフィールドベースでなく、何らかの外部の認証の仕組みを使用してブラウザにパスワードを保管し、http://www.mysite.com/wp-admin/ にアクセスすると、パケットは平文で流れ、cookie または認証ヘッダを横取りされるのではないかと思います。したがって最大のセキュリティを確保するには、ユーザーは明示的に https ホストを使用するか、常に新しいセッションの最初でログインする必要があります。
関連

1. force_ssl_admin() / en
2. force_ssl_content() / en
3. is_ssl() / en

パスワードのベストプラクティス

1. 絶対に避けるべきもの
2. パスワードの管理

WordPress のセキュリティ強化は、強力なパスワードから始まります。強力なパスワードは複雑で手が込んだものです。認識可能な単語、名前、日付、数字が含まれておらず、推測するのは簡単ではありません。20文字以下のパスワードを選ぶことはおすすめしませんが、文字、数字、特殊文字のランダムな文字列を覚えるのが難しいというのは確かにそうでしょう。しかし、一般的には、より多くの文字と複雑さがあればあるほど良いのです。
そのため、強力なパスワードを作成する際には、以下のガイドラインを守ることをおすすめします。

1. 20文字以上 (できればそれ以上)
2. 小文字と大文字を使う
3. 数字を含める
4. ? や ! のような特殊記号を含める

例
上記のガイドラインに沿った良いパスワードは、”As32!KoP43??@ZkI??L0d” です。
絶対に避けるべきもの
自分と関連がある名前や言葉。

1. パートナーや子供の名前
2. ペットの名前
3. 所属会社名
4. 好きなスポーツチームや車ブランドの名前
5. 生まれた年
6. 誕生日

これらの項目はすべて個人情報であり、ほとんどが公開されています。そのため、ソーシャルエンジニアリングのリスクがあります。何があっても避けましょう。
例

1. もし名前が田中花子で1976年生まれなら、”TanakaHanako1976″ はパスワードとしては最悪の案です。

一般的なパスワード要素。

1. “123” や “54321” のような連番
2. “admin”、”administrator”、”pass”、”password”、”blue”、”house” のような一般的な言葉

この種の要素はパスワードを総当り攻撃で解析しようとするときにハッカーが最初に試みる用語ですので、これらも避けるようにしてください。
例
以下のパスワードの例は明らかにひどいパスワードであり、安全ではありません。

1. MattMullenweg2018
2. admin123

また、複数のサイトやアカウントで同じパスワードを使用することは避けるべきです。
パスワードの管理
最近では複雑なパスワードが欠かせなくなっているため、パスワードをいちいち覚えておくのは大変な負担になります。そのため、多くの人はパスワード管理ツール (パスワードマネージャー) に頼って異なるパスワードを管理しています。こういったツールは、1つの複雑なマスターパスワードで保護されたパスワード保管庫となります。また、保存されたパスワードを自動的に (またはコマンドを使って) 入力する機能もあります。この方法なら、マスターパスワードを1つ覚えておくだけで、パスワードマネージャーの保管庫にアクセスできます。
人気のパスワード管理ツール

1. 1Password
2. Dashlane
3. KeePass
4. LastPass
5. Roboform

ほとんどのパスワード管理ツールは有料のサービスですが、無料のものを探しているのであれば、KeePass を試してみてはいかがでしょうか。
WordPress のプライバシー

1. ユーザーのプライバシーとあなたの WordPress サイト
2. プライバシー設定
   1. プライバシーポリシー編集ヘルパー
3. 個人データエクスポートツール
4. 個人データ消去ツール
5. データ収集の同意

ユーザーのプライバシーとあなたの WordPress サイト
国内または国際的なプライバシー規制 (欧州連合の GDPR、一般データ保護規則など) によっては、個人情報の収集と共有状況を開示するプライバシーポリシーの表示を要求される場合があります。個人データには、ユーザーの名前、メールアドレス、生年月日、電話番号、IPアドレス、その他ユーザーを識別するために使用できるデータなどが含まれます。
また、ユーザーに対して、保有する情報のコピーを要求する手段や、削除を要求する手段を提供する必要がある場合があります。
現在の WordPress には、サイト管理者がこれらの手順を踏むために使えるシンプルなツールがいくつか用意されています。ツールを使用することで、サイトで収集されたデータについての透明性あるプライバシー告知を、ユーザーにより簡単に伝えることができます。通常は、少なくとも以下の内容が含まれています。

1. ユーザーに関するどのようなデータを収集しているのか
2. データ収集の理由と手段
3. そのデータで何をするのか (データを誰かと共有する可能性があるのかを含む)

また、これらの新しいツールを使用することで、ユーザーが自分のデータの複製や削除を要求することも容易になります。新しいデータプライバシーツールを使用することで (法律で要求されているかどうかに関わらず)、ユーザーのプライバシーを保護することが容易になります。
注: Web サイトはそれぞれ異なります。管理者の誰もが異なるコンプライアンス行程を持っているように、それぞれのプライバシー告知も同じではありません。さらに、新たな規制の確立や既存の規制の変更により、コンプライアンス行程が変更される可能性があります。プライバシーの保護は一回限りの責務ではない、と考えることを強くおすすめします。ユーザーのデータを保護したり、保護するための措置を講じたりすることは、オンラインとオフラインの両方における継続的なプロセスです。WordPress のツールは、その一部を支援することはできますが、ツール自体がコンプライアンスのプロセスというわけではありません。適用される規制や期待事項を確認し、必要に応じてこれらのツールの使用方法を調整することを強くおすすめします。
プライバシー設定
このツールを使用すると、プライバシーポリシーページを簡単に選択して作成することができます。専用のページを作成したり、既存のページを適応させたりするとともに、プロセスの開始に弾みをつけるためのプロンプトやヘッダーを提供します。
サイト管理者は、「設定 > プライバシー」と進み、「プライバシーポリシー」ページの設定を管理することで、このページを作成することができます。
The prompts and headers provided in the tool by default are based on the expectations of Europe’s GDPR as a leading privacy standard. While this gives you a start to build on, your privacy policy is not constrained by this starter text.  It is your responsibility  to write a comprehensive privacy policy, to ensure that it reflects all national and international legal requirements on privacy, and to keep your policy current and accurate.
このツールでデフォルトで提供されるプロンプトとヘッダーは、ヨーロッパの主要なプライバシー基準である GDPR の期待に基づいています。これは、あなたのプライバシーポリシーを構築するためのスタート地点を提供しますが、あなたのプライバシーポリシーは、このスターターテキストによって制約されるものではありません。包括的なプライバシーポリシーを作成し、それがプライバシーに関する国内および国際的な法的要件をすべて反映していることを確認し、あなたのポリシーを最新かつ正確に保つことは、あなたの責任です。
プライバシーポリシー編集ヘルパー
The  Editing Helper  feature is part of the new  Privacy Settings  tool. Drawing information from both WordPress core and a site’s themes and plugins, the Editing Helper pulls together a collected set of default texts which detail a site’s data collection and sharing, generating a starter text which you can use to complete your privacy policy.
While you do not necessarily need to use this tool to build a Privacy Policy, we believe it is helpful because it provides information on how your WordPress site likely collects and processes data in core, theme and plugin code. It is important to consider these back-end uses of data: While not all sites will use all functions (for example, an administrator may choose not to enable comments on posts) nearly every site uses features such as analytics cookies, social media sharing buttons, or contact form plugins. Please add as many additional disclosures as is necessary to be fully transparent about how your site uses personal data.
This tool ONLY collects policy help texts from WordPress and participating plugins.  Many sites will also embed third-party tools (such as email subscription services) which collect data in ways the the Editing Helper tool cannot detect, so the default template may not completely describe how your site might collect data about its user. Take the time to understand how your website actually collects your users’ data, and be transparent about what actually happens with data on your website to your users.
Further, theme and plugin developers are invited to learn how the Privacy Policy Editing Helper works, and to feed in the information about how your theme or plugin collects data into the privacy policy tool.
個人データエクスポートツール
WordPress now includes a feature to to archive user data for export. This is different from the  Tools > Export  tool which creates an archive file of posts, pages, or media; the new tool exports in captured elsewhere. You can use this tool by clicking on  Tools > Export Personal Data  in your WordPress dashboard.
This tool manages email export requests by your users. Following manual approval, it allows you to generate a ( .zip format) file containing the personal data which exists about a user within your WordPress site.
We strongly encourage you use the email validation feature built into the export tools. This confirmation process will help safeguard against abuse, such as malicious users pretending to be someone they are not.  As with the Erasure tool, the Erase Personal Data tool uses email validation to send a user’s request to an administrator. The administrator must manually approve the request to send the data in question to the user.
As this tool ONLY gathers data from WordPress and participating plugins, you may need to go beyond to comply with export requests.  While it may give you a good start in providing your users with the information they have requested, every site administrator should understand what data they collect and process outside their WordPress site as a full site request may have more responsibility than simply using this export alone.
While this tool’s scope covers much of the scope of WordPress user data, it likely does not include information that may be collected by your site using a third-party service, such as an analytics provider, newsletter subscription service, ad affiliate partner or embedded media.
個人データ消去ツール
Similar to the Export Personal Data tool, WordPress now includes a tool to delete a user’s personal data upon verified request. You will find this feature under  Tools > Erase Personal Data  in your WordPress dashboard.
We strongly encourage you use the email validation feature built into the export tool. This confirmation process will help safeguard against abuse, such as malicious users pretending to be someone they are not.  As with the Export tool, the Erase Personal Data tool uses email validation to send a user’s request to an administrator. The administrator must manually approve the request to remove the data in question.
Deleted data is permanently removed from the database.  Erasure requests cannot be reversed after they have been confirmed. Note that it does not remove the data from backups or archive files: When using the tool alongside automated backups or archives, we advise you to exercise caution when restoring user data from backups. When restoring an archived copy of your site, your requests for erasure should be respected.
As this tool ONLY gathers data from WordPress and participating plugins, you may need to go beyond to comply with erasure requests.  While it may give you a good start in complying with your users’ request to remvoe the information they have requested, every site administrator should understand what data they collect and process outside their WordPress site as a full site erasure request may have more responsibility than simply using this tool alone.
In particular (as with the Export tool) it likely does not include information that may be collected by your site using a third-party service, such as an analytics provider, newsletter subscription service, ad affiliate partner or embedded media.
When erasing user data, this tool does not automatically delete registered users and their profile data.  Administrators should perform that step themselves after successfully erasing personal data for a registered user. User deletion is available for each user in the  Users  menu in the Dashboard.
It is also important to understand that personal data deletion requests are not absolute.  A site administrator is not obliged to delete data that they may be required to keep for other legal or statutory reasons. For example, you may be required to keep sales records for a certain number of years for tax purposes. You may also wish to keep a user’s records for security purposes, for example, if there is an ongoing investigation into abuse. These situations should be handled internally.
データ収集の同意
Under some privacy laws, you may also be required to have your users’ active, clear, and unambiguous consent before collecting their personal data. Further, you may also be required to have your users’ active, clear, and unambiguous consent before certain kinds of processing of personal data, if that processing isn’t otherwise necessary for your site.
While WordPress.org does not yet have consent tools built,  there are various plugins available  to help in collecting consent to be compliant with the May 2018 GDPR compliance deadline. In addition, WordPress Core intends to add additional tools for WordPress theme and plugin developers for consent management in WordPress Sites.
Some plugins, especially in the case of forms and email subscription services, suggest that you add a “required” consent field that says something like  “I consent to my submitted data being collected and stored”  if this is a requirement for your website.

---

このセクションにおける @allendav と @webdevlaw のヘルプに感謝します。
各種注意点 (未訳):

1. To-do: Would be nice if we could add a “how-to-use” section by May 25 launch, see Woo article here doing a good job of this: https://woocommerce.wordpress.com/2018/05/04/woocommerce-3-4-gdpr-features/
2. Note: Leaving in “Explicit Consent” even though we don’t have much to show for it since it’s pragmatically a major concern for major plugins. We should replace with content about WP core when we can.
3. Would like feedback on whether to use link one or two:

1. https://wordpress.org/plugins/tags/gdpr
2. https://wordpress.org/plugins/gdpr/ Link two is built by a well-respected development shop and does Explicit Consent the way it should be, but link one is less endorsement-heavy.

カスタムフィールドの使い方

1. 関数リファレンス
2. 使い方
3. カスタムフィールドを記事内に表示する
4. カスタムフィールドを使ったさらに高度なテクニック
   1. カスタムフィールドを取得する
      1. 詳しいやり方
   2. PostMeta 関数
      1. 内部関数
      2. テンプレート関数
   3. 詳細情報およびリソース

WordPress には、投稿者が投稿にカスタムフィールドを追加できる機能があります。この任意の情報はメタデータと呼ばれており、たとえば以下のような情報を含めることができます。

1. 現在の気分:幸せいっぱい
2. 今読んでいる本:星の王子様
3. BGM:Rock Around the Clock
4. 今日の天気:晴れ

さらに、ちょっとしたコードを付け加えるだけで、このメタデータに投稿の表示期限を付け加えたりすることも可能です。
メタデータは名前と、その値の組み合わせからなっています。名前は、メタデータ要素の名称のことを指します。値は、その要素に対応する情報を指します。
また、ひとつの記事で複数のメタデータの名前を使用することもできます。例えば今読んでいる本が（職場での技術本と自宅でのフィクションのように）2冊ある場合、「今読んでいる本」という名前を2度使い、それぞれに対し1冊の本の題名を記入すればよいのです。
カスタムフィールドを記入した場合、記事中に以下のように表示できます :
今読んでいる本: 星の王子様 今日の天気: 晴れ
関数リファレンス

追加、更新、削除	カスタムメタデータの名前・値を取得	テンプレートタグ
add_post_meta()	get_post_custom()	the_meta()
update_post_meta()	get_post_custom_values()	get_post_meta()
delete_post_meta()	get_post_custom_keys()

使い方
上記の例に基づいて、実際にカスタムフィールドを使ってみましょう。ここでは、「今読んでいる本」と、「今日の天気」というカスタムフィールドの値を追加します。

1. 投稿を書いたあと、カスタムフィールドの欄までスクロールします。注: WordPress バージョン3.1 より、投稿・固定ページ編集管理画面の 表示オプション ではいくつかのものがデフォルトで非表示になっています。カスタムフィールドも、以前に使用されたことがない場合はデフォルトで非表示になっています。
2. 新しいカスタムフィールドを作成するには名前と書かれた下にある欄に書き込みます。まずはここに「今読んでいる本」というテキストを （引用符は無しで） 入力します。
3. 新規作成した名前（「今読んでいる本」）に対応する値を追加します。今回の場合は、読んでいる本の題名になります。 値 の欄に「星の王子さま」と書き込みます。ここでも引用符は不要です。
4. ここまで終わったら、カスタムフィールドを追加ボタンをクリックしましょう。

「今日の天気」を追加するには、同じ手順を繰り返します。「今日の天気」を名前に追加し、値のテキストボックスに天気を入力してカスタムフィールドを追加をクリックします。最後に「保存」（または「公開」）ボタンをクリックして記事を保存します。
次に記事を投稿する際、別の本や天気をメタデータとして追加することができます。一度追加した名前はカスタムフィールド欄にあるプルダウンメニューの項目として表示されます。「今読んでいる本」を選択肢、値に読んでいる本を入力します。カスタムフィールドを追加をクリックし、手順を繰り返して「今日の天気」を追加します。
新しい「名前」を作成する必要があるのは一度だけです。その後は必要に応じて、記事ごとにその名前と値を割り当てることができます。名前には複数の 値 を割り当てることもできます。これは、一度に複数の本を読む人にとって便利です。
カスタムフィールドを記事内に表示する
カスタムフィールドを記事に追加したら、その情報をサイトで公開しましょう。 各記事のカスタムフィールドを表示するには、 the_meta() テンプレートタグを使います。このタグは WordPress ループ 内に置く必要があります。 the_meta() テンプレートタグを記事の最初や最後の 記事メタデータセクション などに含めるという方法がよく使われます。以下が一般的なタグの記入例です。
<?php the_meta(); ?>
上記の例の場合、ソースコードではこのように表示されているはずです。
<ul class="post-meta"> <li><span class="post-meta-key">今日読んでいる本:</span> 星の王子様</li> <li><span class="post-meta-key">今日の天気:</span> 晴れ</li></ul>
テンプレートタグは、メタデータを順不同リスト（ <ul> ）形式で出力し、そのリストに post-meta というクラスを自動的に割り当ててくれます。さらに名前は post-meta-key というクラスの <span> 要素に囲まれるので、スタイルシートを使って見た目を変更することができます。
カスタマイズするには、以下の宣言を使用中のテーマのスタイルシート（style.css）に追加します。
.post-meta { font-variant: small-caps; color: maroon; }.post-meta-key { color: green; font-weight: bold; font-size: 110%; }
サイト上では、以下のように表示されます。

1. 今読んでいる本:星の王子様
2. 今日の天気:晴れ

さらに、 公式プラグインディレクトリ にはメタデータ表示に便利な機能を追加してくれるプラグインが色々とあります。 カスタムフィールドプラグインの Google 検索 でさらに多くのプラグイン情報を見つけられるでしょう。
カスタム投稿タイプ内でカスタムフィールドの対応を登録するには、以下のように ‘custom-fields’ を使って ‘supports’ $args を追加してください。
'supports' => array( 'title', 'editor', 'thumbnail', 'custom-fields' )
カスタムフィールドを使ったさらに高度なテクニック
以下はメタデータ/カスタムフィールドを利用したさらに高度なテクニックです。
カスタムフィールドを取得する
メタデータの値を取得するには、 get_post_meta() 関数を使います。
get_post_meta( $post_id, $key, $single );

1. $post_id は、メタデータの値を取得する記事のIDです。 $post->ID を使って記事のIDを取得してください。
2. $key は取得する名前の文字列です。
3. $single は true または false としてください。 true に設定されている場合、結果を1つの文字列として返します。 false の場合、カスタムフィールドの配列を返します。

詳しいやり方
PostMeta で取得された情報は新しいテーブル内に格納されます（ $wpdb->postmeta ）。このテーブルには4つのフィールドがあります。

1. ‘ meta_id ‘ – 各メタデータ項目の固有 ID
2. ‘ post_id ‘ – 取得したメタデータが属する記事の ID
3. ‘ meta_key ‘ – メタデータの名前
4. ‘ meta_value ‘ – メタデータの名前に対応する値

このテーブル内の値は、 wp-blog-header.php 内の $posts 配列が取得された直後、 $post_meta_cache と呼ばれる多次元配列に格納されます。この変数は、要求されたページ内に表示される記事に属する値のみが含まれています。配列の構造はこのようになっています。
[ postid1 => [ key1 => [ val1, val2, ... ], key2 => [ val1, val2, ... ], ... ], postid2 => [ key1 => [ val1, val2, ... ], key2 => [ val1, val2, ... ], ... ], ...]
つまり、ID 256の記事につけられた「今読んでいる本」のデータを取得したい場合、以下のような PHP コードを使えばいいのです。
// 今読んでいる本の配列値を取得$readinglist = $post_meta_cache[256]['今読んでいる本'];
注:  $readinglist  は1つの値ではなく配列となることに注意しましょう。
WordPress 2.1 以降では、 $post_meta_cache  にはデータが含まれません。メタデータの値は、以下の方法で取得してください。
PostMeta 関数 内部関数
これらの関数は、 WordPress ループ 内で使うためのものです。すべての関数は配列を返します。

1. get_post_custom() : 現在の記事に関するメタデータの名前および値を取得。
2. get_post_custom_keys() : 現在の記事につけられたすべてのメタデータの名前をリストとして取得。
3. get_post_custom_values($key) : 現在の記事中にあるメタデータの値を取得。
4. get_post_meta($post_id, $key, $single = false) : WP 1.5以降で、キャッシュ関連の問題を起こすことなくメタデータを返します。この関数には $post_id と $key が必須で、 $single が TRUE に設定されている場合、配列ではなく1つ目の結果のみを PHP で使用できるように返します。

// 以下は、メタデータの値を出力します（echo があることに注目してください）<?php $key="メタデータの名前"; echo get_post_meta( $post->ID, $key, true ); ?>
テンプレート関数
WordPress テンプレートファイルでは投稿メタ関数を利用できます。例えば以下のとおりです。
the_meta() ： 現在の記事のメタデータを順不同リストとして出力します。<ul> の CSS クラスは post-meta、<li> は post-meta-key となります。
<?php echo get_post_meta( $post->ID, 'key', true ); ?>
テンプレートファイル内で使うと、1つの名前（キー）に対する値を文字列として出力します。
詳細情報およびリソース
カスタムフィールドを管理するプラグインをインストールすることもできます。

1. Meta Box plugin – カスタムメタボックスとカスタムフィールドを作成できるプラグイン。
2. Piklist – WordPress のあらゆる場所でカスタムメタボックスとフィールドを作成できるプラグイン。
3. Advanced Custom Fields – ユーザーフレンドリーなインターフェースを使用して複雑なフィールドとレイアウトを作成できるプラグイン。

投稿タイプ

1. デフォルトの投稿タイプ
   1. 投稿 (post)
   2. 固定ページ (page)
   3. 添付ファイル (attachment)
   4. リビジョン (revision)
   5. Menus
   6. カスタム CSS (custom_css)
   7. チェンジセット (customize_changeset)
2. Custom Post Types
3. カスタム投稿タイプ
4. テンプレートファイル
5. 投稿タイプクエリ
6. 投稿クエリ

WordPress は多数の異なるタイプのコンテンツを保存し、表示することができます。「投稿」はひとつの「投稿タイプ」ですが、任意の投稿タイプのコンテンツを WordPress の内部では投稿と呼んでいます。どの「投稿タイプ」のコンテンツもすべてひとつの場所（データベースの  wp_posts  テーブル）に格納されていて、post_type というカラムによって区別されます。
WordPress 3.0  からは自分で カスタム投稿タイプ を追加して異なる用途に利用できるようになっています。
デフォルトの投稿タイプ
特に削除しない限り、WordPress のインストールの際に必ず含まれるデフォルトの投稿タイプは次のとおりです：

1. 投稿 (投稿タイプ: ‘post’)
2. 固定ページ (投稿タイプ: ‘page’)
3. 添付ファイル (投稿タイプ: ‘attachment’)
4. リビジョン (投稿タイプ: ‘revision’)
5. ナビゲーションメニュー (投稿タイプ: ‘nav_menu_item’)
6. カスタム CSS (投稿タイプ: ‘custom_css’)
7. チェンジセット (投稿タイプ: ‘customize_changeset’)

投稿 (post)
WordPress の「 投稿 (post) 」はブログで最もよく使われる投稿タイプです。「投稿」はふつう一番新しいものが最初にくる反時系列順で表示されます。「投稿」は フィード の作成にも使われます。
固定ページ (page)
WordPress の「 固定ページ  (page) 」は「投稿」に似ていますが、いくつかの非常に重要な違いがあります。「固定ページ」は「投稿」のように時系列構造では表示されません。また「固定ページ」は他の「固定ページ」を親に持つ階層化した構造にすることもできますが、ふつうは カテゴリー と タグ をつけることができません。
そして「固定ページ」は異なる ページテンプレート を使って表示できます。 パーマリンク を有効にすると、「固定ページ」のパーマリンクはメインサイトの URL と「固定ページ」の名前（親があれば親の名前も）を組み合わせたものになります。この名前は スラッグ とも呼ばれる、親しみやすく URL として正しい形式の文字列です。この違いについて詳しくは「 固定ページ 」の説明を見てください。
添付ファイル (attachment)
「 添付ファイル  (attachment) 」は特別な投稿で、WordPress のメディアアップロードシステムを使ってアップロードされたファイルについて、ファイル名や説明などの情報を保持します。これらの情報はメタデータと呼ばれ、 wp_postmeta  テーブルに格納されている情報とリンクしています。例えばファイルが画像の場合、メタデータは画像のサイズや自動生成されたサムネイル、ファイルの場所、HTML の alt 属性用テキスト、画像に埋め込まれていた EXIF データから取得した情報などになります。
リビジョン (revision)
「 リビジョン  (revision) 」は下書きや公開済みの投稿・固定ページなどの 変更履歴 を保存するための特別な投稿タイプで、投稿や固定ページなどで記述を間違えて保存してしまって以前のバージョン戻したい場合に利用されます。「リビジョン」は基本的には元となる公開済みの投稿や固定ページと同じ形式のデータですが、その子として保存されています。紐づけられた親は  wp_posts  テーブルの  post_parent  カラムで表されます。
Menus
「 ナビゲーションメニュー  (nav_menu_item) 」は Web サイトをナビゲートするために使用できるリンクのリストで、WordPress の ナビゲーションメニュー システムの各メニュー項目を保存するための投稿タイプです。これにより、訪問者が使用する Web サイトのさまざまな場所へのリンクのカスタムリストを作成し、ダッシュボードのテーマセクションで編集して、投稿やページなどの従来の投稿タイプから切り離すことができます。
カスタム CSS (custom_css)
「カスタム CSS (custom_css) 」は、カスタマイザーの「追加 CSS」画面から保存された CSS を保存するために使用されるテーマ固有の投稿タイプです。 各テーマには独自のカスタム CSS を含めることができますが、実際に使用されるのは有効化されているテーマのカスタム CSS のみです。
通常、カスタム CSS を投稿として意識する必要はありません。
チェンジセット (customize_changeset)
「チェンジセット (customize_changeset) 」はリビジョンに似ていますが、カスタマイザー専用です。 これは、カスタマイザーを永続的な状態に保つために利用されます。 WordPress は、チェンジセットでユーザーから編集中にカスタマイザーを介して行われたコンテンツの変更を保持し、現在の編集を終了した場合にそれらを復元します。
通常、このチェンジセットも投稿として意識する必要はありません。
Custom Post Types カスタム投稿タイプ
WordPress には既に多くの標準的な投稿タイプがありますが、より細かなカテゴリーに分類したい場合は、登録されている投稿タイプの数を増やすことができます。 たとえば、書籍に関するセクションが必要な場合は、書籍用のカスタム投稿タイプ「書籍」を作成する方が適しています。 これは、 register_post_type 関数を使用して実行できます。
テーマを切り替えた場合にカスタム投稿タイプがなくなってしまわないように、プラグイン（または mu-plugins ディレクトリ内のプラグイン）でカスタム投稿タイプを定義することを強くお勧めします。 これによって、テーマの変更に関わらずコンテンツに常にアクセスできるようになります。
テンプレートファイル
デフォルトでは、WordPress はテーマの index.php 、 single.php 、 archive.php ファイルを使用して、Web サイトのあらゆるタイプの投稿を表示します。
一方、カスタム投稿タイプを作成した場合は、他の投稿タイプとは異なる見た目でこの情報を表示したい場合があります。 これを行うには、テーマ内で投稿タイプ独自のカスタムテンプレートを使用します。
例えば上記のように「書籍（例としてスラッグを `book` とします）」という名前のカスタム投稿タイプを作成する場合、 single-book.php というテンプレートファイルを作成して、公開する個々の書籍の投稿を表示できます。 また、すべての書籍の投稿をカスタムアーカイブページに表示するには、 archive-book.php テンプレートファイルを作成します。これにより、公開したすべての書籍の投稿が表示されます。
投稿タイプクエリ
書籍という名前のカスタム投稿タイプのリストを取得したい場合は、新しい WP_Query インスタンスを作成してそれらをすべて取得することができます。 これは、Web サイトのどこかにカスタムループを作成し、他の投稿とは異なる方法で表示したい場合に便利です。
投稿クエリ
場合によっては、ブログ投稿のメインクエリにカスタム投稿を含めたいことがあります。 これを行うには、 pre_get_posts フィルターフックを使用します。これによって Web サイトに表示されるよりも先に、投稿を取得するクエリをカスタマイズできます。
タクソノミー

1. 分類とは ?
2. WordPress におけるタクソノミーとその関係の基本図
3. デフォルト分類
   1. カテゴリー
   2. タグ
   3. リンクカテゴリー
   4. 投稿フォーマット
4. カスタム分類
   1. 用例
   2. 分類の登録
   3. 登録した分類の使い方
   4. クラウド
   5. 項目一覧の表示
   6. 分類によるクエリ
5. 404 エラー
6. 追加情報
   1. 日本語情報
   2. 英語情報
7. 関連項目

分類とは ?
「カスタム分類」の英語表記は、「カスタムタクソノミー (Custom Taxonomies)」となっています。 聞き慣れない言葉だと思いますが、タクソノミーとは物事をグループ化する方法、つまり平たく言うと分類ということです。
例えば、いろいろな種類の動物を、特徴ごとに分類して各グループに名前をつけるようなものです。 これは多くの人が生物のクラスで経験するようなことで、 リンネの分類 ( Linnaean Taxonomy ) と呼ばれています。
WordPress では、「分類 (タクソノミー)」は投稿 (またはリンク、カスタム投稿タイプ) をグループ化するための仕組みのことです。
分類内のさまざまなグループ名を「terms (項目)」 と呼びます。 動物のグループ化を例に取ると、あるグループを「鳥」、別のグループを「魚」と名づけるでしょう。 「鳥」や「魚」は、分類内の項目です。 WordPress の例で言うと、あるカテゴリーやタグ (次の項目を参照) が項目となります。
WordPress におけるタクソノミーとその関係の基本図

Pieter Goosen 氏によるダイアグラム
デフォルト分類
WordPress には 4 種類の分類が組み込まれています。おそらくすでに使ったことがあるはずです。
カテゴリー
‘category’ 分類を使うと投稿をカテゴリーごとにグループ化し、 /category/name と言った形式の URL で表示できます。カテゴリーは事前に定義された広範囲なものであることが多いと言えます。
タグ
‘post_tag’ 分類はカテゴリーに似ていますが、より自由な形態です。 タグは投稿ごとにその場その場で入力して作成でき、 /tag/name と言った形式の URL で表示できます。 投稿には複数のタグがつけられることが多く、通常、投稿内容の近くまたはタグクラウドとして表示されます。
リンクカテゴリー
‘link_category’ 分類はリンクに対して使われます。 構成上の理由で内部に限って使われることが多く、通常サイトに直接表示されることはありません。 サイドバーなどに表示するためのリンクをグループ化するのに便利です。
投稿フォーマット
‘post_format’ 分類は WordPress 3.1 で導入されました。テーマが投稿の表示をカスタマイズするために使用できるメタ情報です。新しく作成したりデフォルトの投稿フォーマットに追加したりすることはできません。
カスタム分類
WordPress 2.3 以降でカスタム分類が作成できるようになりましたが、 バージョン 2.9 まではほとんど活用されていませんでした。 しかし実際は、色々な項目を色々な方法でグループ化するために非常にパワフルな機能なのです。
用例
例えば、 Matt’s Community Tags (Matt のコミュニティタグ) プラグインは、添付ファイルに対して “people” という分類を定義するために使われます。 写真の中に写っている人をタグ付けし、 person/name という URL でそれぞれの人の写真を表示できます。
分類の登録
分類を登録するには、 register_taxonomy() 関数を使います。
“people” 分類を登録する場合の例は以下のとおりです。
function people_init() { // 新規分類を作成 register_taxonomy( 'people', 'post', array( 'label' => __( 'People' ), 'rewrite' => array( 'slug' => 'person' ), 'capabilities' => array( 'assign_terms' => 'edit_guides', 'edit_terms' => 'publish_guides' ) ) );}add_action( 'init', 'people_init' );
ここで “people” 分類が定義されています。 投稿内で使い、スラッグを people ではなく person とリライトできるようになっています。
capabilities の行はオプションです。 指定しなければデフォルトとして、WordPress は投稿と同じユーザーの権限を適用します。 上記の例では、カスタムの “edit_guides” 権限を持つユーザーがこの分類を投稿へ付けることができます。 また “publish_guides” 権限を持つユーザーは、分類に新しい項目を加えることができます。
登録した分類の使い方
分類を追加すると、投稿編集ページに新しいメタ情報ボックスが追加されます。 このボックスはタグ用のボックスとほとんど同じで、カスタム分類用のキーワードを追加できます。
カスタム分類を投稿に対して使わない場合は管理画面で表示されないかもしれません。 分類は一般的なものなので、どんなオブジェクトに対してでも使うことができます。 カスタム分類を使ってオブジェクトにキーワードを追加するには、 wp_set_object_terms() 関数を使います。 以下は、”person” 分類のキーワード “Bob” を ID 123 の投稿に追加する例です。
wp_set_object_terms( 123, 'Bob', 'person' );
ご覧の通り、とてもシンプルです。 2 番目のパラメータを複数キーワードの配列にして、まとめて追加することもできます。
クラウド
カスタム分類の項目をタグクラウド形式で表示させたい場合は、 wp_tag_cloud() 関数に “taxonomy” パラメータを指定することができます。
項目一覧の表示
キーワードのカスタムリストを表示したい場合は、ループ内で分類名を the_terms() 関数に渡します。
the_terms( $post->ID, 'people', 'People: ', ', ', ' ' );
こうすると各投稿に追加された “people” 分類のキーワードが表示されます。
分類によるクエリ
タクソノミーを作成すると、通常は特別なクエリ変数が WP_Query クラスを使って自動的に生成されます。 これを使って投稿を取り出すことができます。 例えば、”person” という分類で “bob” という項目が付いている投稿の一覧を取得するには以下のようにします。
$query = new WP_Query( array( 'person' => 'bob' ) );
または、以下のようにパラメータを細かく指定する形式も使えます。
$args = array( 'tax_query' => array( array( 'taxonomy' => 'person', 'field' => 'slug', 'terms' => 'bob' ) ));$query = new WP_Query( $args );
404 エラー
カスタムパーマリンクを使っている場合は、分類 (タクソノミー) に変更を加えた後に、パーマリンクの内部構造を再構成する必要があります。 これを怠ると「ページが見つかりません」エラーが表示される場合があります。 WordPress ダッシュボードの 設定 > パーマリンク設定 を開いて保存の操作を行うと、パーマリンクの内部構造を再構成できます。
追加情報 日本語情報

1. カスタムタクソノミー(Custom Taxonomy)の導入と使い方 (WordPress 3.0)
2. カスタム投稿タイプとカスタム分類 (MdN Design Interactive)
3. WordPress のカスタムフィールド・投稿タイプ・タクソノミーを使い分けよう！

英語情報

1. WordPress Taxonomy Generator
2. Quick taxonomy creating class
3. Custom taxonomies in WordPress 2.8
4. Introducing WordPress 3 Custom Taxonomies
5. Custom user taxonomies in WordPress
6. Is There a Difference Between Taxonomies and Categories?

関連項目
カスタム分類: get_taxonomy() , taxonomy_exists() , register_taxonomy() , get_taxonomies() , the_taxonomies() , get_taxonomy_labels() , get_taxonomy_template() , is_object_in_taxonomy() , get_the_taxonomies() , get_post_taxonomies() , get_object_taxonomies() , is_taxonomy_hierarchical()
WordPress の一般的なエラー

1. 死の真っ白画面
2. サーバーの内部エラー
3. データベース接続確立エラー
   1. wp-config.php 内の不正な情報
   2. Web ホストの問題
   3. Webサイトのハック
4. 自動アップデートの失敗
5. 接続タイムアウト
6. アップグレード後のメンテナンスモード
7. 変更したのに何も変わらない
8. Pretty パーマリンクの 404 エラーと画像が動作しない
9. カスタム投稿タイプの 404 エラー
10. 固有のエラーメッセージ
    1. PHP エラー
       1. Fatal Error と Warning
       2. Parse Error
       3. Use of an undefined constant
    2. Database Error
       1. Cannot Create/Write to File
       2. CREATE Command Denied to User
       3. Error 28
       4. Error 145
       5. Unknown Column
    3. リソース

WordPress を使用していてエラーメッセージや真っ白な画面が表示されても慌てないでください。誰かが同じ現象にぶつかっていれば簡単に解決できるはずです。
この記事では WordPress ユーザーが経験する一般的なエラーと、その解決策への糸口を紹介します。より詳細な情報については WordPress Codex のページにリンクします。ここで解決策が見つからない場合はボランティアベースでの質疑応答が行われている「 WordPress フォーラム 」にあたってみてください。
死の真っ白画面
PHPエラーやデータベースエラーが発生すると、画面に何のメッセージも表示されず、ただ真っ白な画面が表示される場合があります。WordPress コミュニティではこれを一般に「WordPress 死の真っ白画面」(WSOD, White Screen of Death) と呼んでます。
闇雲に解決策をトライする前に、真っ白な画面にはいくつもの原因があることを知っておいてください。

1. プラグインが互換性問題を起こしている– 管理画面 にアクセスできるようであれば、すべてのプラグインを無効化し、一つずつ有効化してください。 管理画面 にアクセスできなければ FTP で Web サイトにログインしてください。次に「wp-content/plugins」フォルダーを探し「plugins_old」に名前を変えます。これですべてのプラグインは無効化されます。手動でプラグインを無効化する方法の詳細については「 FAQ/トラブルシューティング 」を参照してください。
2. テーマが問題を起こしている– 新しいテーマを有効化しただけ、あるいは WordPress マルチサイトで新しいサイトを作成しただけで真っ白な画面が表示される場合には、この可能性があります。 管理画面 にログインし、デフォルトの「 WordPress Twenty Sixteen テーマ 」を有効化してください。 管理画面 にアクセスできなければ FTP で Web サイトにログインし、「wp-content/themes/」フォルダーに移動し、有効なテーマのフォルダーの名前を変更してください。

WP_DEBUG 機能 を使用すると追加情報が表示される場合があります。障害が続き、エラーログが出力される場合はこの記事の後半の「 PHP Error 」を参照してください。
サーバーの内部エラー

サーバーの内部エラーにも多数の原因があります。解決方法をいくつか挙げます。

1. 多くの場合、原因は壊れた「.htaccess」ファイルにあります。FTP を使用してサイトにログインし、「.htaccess」ファイルを「.htaccess_old」に名前を変更してしてください。次にサイトにアクセスして問題が解決したかどうかを確認してください。動作していれば「 設定 」 > 「 パーマリンク設定 」にアクセスし、 パーマリンク をリセットしてください。この操作により新しい「.htaccess」ファイルが作成されます。
2. プラグインの問題かどうかを切り分けるために、すべてのプラグインを無効化してください。WordPress 管理画面 にアクセスできない場合は、FTP 経由で無効化してください。 こちらの手順 を参照してください。
3. テーマを WordPress Twenty Sixteen テーマに変更し、テーマ関連の問題を切り分けてください。
4. PHP へのメモリー割り当て を増やしてください。
5. WordPress の新規インストールイメージ から、「wp-admin」と「wp-includes」フォルダーを再アップロードしてみてください。

データベース接続確立エラー
ページにエラーメッセージ「データベース接続確立エラー」または「Error Establishing Database Connection,」が表示される場合、データベースとの接続に問題があります。多数の原因が考えられますが、主な原因と解決策を挙げます。

wp-config.php 内の不正な情報
「データベース接続確立エラー」の原因は通常、 wp-config.php にあります。FTP クライアントでサイトにアクセスしてください。wp-config.php を開き、次の情報が正しいことを確認してください。

1. データベース名
2. データベースのユーザー名
3. データベースのパスワード
4. データベースのホスト名

詳細については「 wp-config.php の編集 」を参照してください。
構成情報が正しいと思う場合は、 手動でMySQL パスワードをリセットしてみてください 。
Web ホストの問題
次のステップはサーバーホスティング会社への連絡です。サーバー側で次のような問題が発生しているかもしれません。

1. データベースサイズが上限に達し、シャットダウンした。
2. サーバーがダウンしている。

ホスティング会社に連絡し、上のような問題が起きていないかを確認してください。
Webサイトのハック
wp-config.php にエラーがなく、またホスティング会社側にも問題がないのであれば、サイトがハックされている可能性があります。
サイトを「 Sucuri SiteCheck 」でスキャンし、ウイルス等に感染していないことを確認してください。もし問題があれば「 FAQ/ハッキング・クラッキング被害 」を参照してください。
自動アップデートの失敗
WordPress の自動アップデートが失敗すると、次のような画面やエラーが表示されます。

1. 何のメッセージもない真っ白な画面
2. アップデートに失敗したという警告
3. PHP のエラーメッセージ

WordPress の自動アップデートの失敗の主な原因は、メインの WordPress ファイルの接続の問題、アップデート中のネット接続の問題、不正な ファイルのアクセス権 です。
手動で WordPress サイトをアップデートするには「 手動アップデートに関する記事 」を参照してください。
接続タイムアウト
接続タイムアウトエラーは、Web サイトがキャパシティを超える動作を行った場合に発生します。この問題は特に共有サーバー使用時の、メモリーの上限が厳しい場合に多く発生します。以下を試してみてください。

1. すべてのプラグインを無効化する。– サイトのすべての WordPress プラグインを無効化することで問題が解決する場合、1つずつ有効化して、どのプラグインで問題が発生するかを確認してください。 管理画面 にアクセスできない場合は、 こちらの手順 を参照して手動でプラグインを無効化してください。
2. デフォルトの WordPress Twenty Sixteen テーマに変更する。– テーマ関連の問題を切り分けてください。
3. PHP へのメモリー割り当て を増やす。– 共有サーバーを使用している場合は、ホスティング会社に連絡して、メモリー増加を依頼する必要があるかもしれません。
4. 「 php.ini 」ファイルで最大実行時間を増やす。– このファイルは WordPress コアファイルではありません。編集方法が分からなければホスティング会社に連絡し、最大実行時間を増やしてください。手順については「 最大実行時間の増加 」を参照してください。

アップグレード後のメンテナンスモード

WordPress をアップグレードすると、自動的に「.maintenance」ファイルがインストールされます。アップグレード後、メッセージ「現在メンテナンス中のため、しばらくの間ご利用いただけません。」が表示される場合があります。「.maintenance」ファイルが正しく削除されなかった可能性があります。
メッセージを削除するには、次の手順に従ってください。

1. FTP プログラムを使用して Web サイトにログインする。
2. サイトのルートにある「.maintenance」ファイルを削除する。

詳細については「 メンテナンスモードの問題 」を参照してください。
変更したのに何も変わらない
Web サイトに変更を加えたにも関わらず、ブラウザで変更を確認できない場合、 ブラウザキャッシュ をクリアする必要があります。ブラウザはアクセスしたサイトの情報を保存しています。これは再度同じサイトにアクセスした際、新規にダウンロードするのではなく、コンピュータ内にすでに保存されている情報をリロードすることで高速にロードするためです。
Web サイトに変更を加えても、大きな変更でないとブラウザが判断した場合、ブラウザはキャッシュから古いデータをロードするため変更が反映されません。この問題を解決するには、 ブラウザのキャッシュをクリアする か、タブをクローズし、リンクを再度開く必要があります。
Pretty パーマリンクの 404 エラーと画像が動作しない
“Pretty” パーマリンク を使用していて 404 エラーが発生し、画像をアップロードすると真っ白な画面が表示される場合、デフォルトで Apache 内の mod_rewrite が有効化されていない場合があります。Mod_rewrite は Apache Web サーバー ソフトウエアの拡張モジュールで、動的に URL を「リライト(書き換え)」します。”Pretty” パーマリンクの動作にはこの機能が必要です。
通常は WordPress マルチサイト ネットワークで発生しますが、共有ホスティングプロバイダーや、 サイトの移行後、サーバーの移動後 にも発生します。
設定 > パーマリンク設定を使用してパーマリンクをリセットしてください。動作しない場合は「.htaccess」ファイルを手動で編集する必要があります。
# BEGIN WordPress<IfModule mod_rewrite.c>RewriteEngine OnRewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]</IfModule># END WordPress
「.htaccess」ファイルの編集に慣れていない場合は、ホスティング会社に連絡し mod_rewrite ルールをオンにしてください。詳細については「 WordPress Codex 内のパーマリンク 」を参照してください。
カスタム投稿タイプの 404 エラー
カスタム投稿タイプ を使用していて 404 エラーが表示される場合には、次の手順を試してください。

1. どのカスタム投稿タイプも、単一ページと同じ名前でないことを確認してください。同じものがあれば、単一ページの名前を スラッグ も含めて変更してください。
2. WordPress 管理画面 にログインし、「設定」>「パーマリンク設定」にアクセスしてください。デフォルトのパーマリンクを選択し、保存します。次に希望のパーマリンクを選択します。リライトルールがクリアされ、問題が解決される場合があります。

固有のエラーメッセージ
エラーログには様々なエラーが表示されます。エラーログにアクセスするには、 デバッグ をオンにし、FTP でエラーログの場所に移動する必要があります。一般的なエラーメッセージを読み解くには以下の情報を参照してください。
PHP エラー
一般的な PHP エラーメッセージを挙げます。
Fatal Error と Warning Cannot modify header information – headers already sent
警告「WordPress cannot modify header information and headers are already sent (WordPress がヘッダー情報を更新できず、すでにヘッダーは送信された)」が表示される場合、通常は開始タグの前、または終了タグの後に、スペース、または文字が含まれます。修正するには「 Headers already sent エラーを解決するには ? 」を参照してください。
この現象が WordPress のインストール直後に発生する場合、wp-config.php の編集で構文エラーが発生している場合があります。エラーを修正するには こちらの手順 を参照してください。
Call to undefined function
エラー「call to undefined function (未定義関数の呼び出し)」は WordPress プラグインがコード内に存在しないかアクセスできないファイルやデータを探している場合に発生します。 原因としては

1. プラグインの自動インストール中、または自動アップグレード中のエラー。解決には 手動でプラグインをインストールするか、アップグレードしてください 。
2. テーマの自動インストール中、または自動アップグレード中のエラー。 手動でテーマをインストールするか、アップグレードしてください 。
3. 非互換の WordPress プラグイン 、または 非互換のテーマ を使用している可能性があります。これは古いバージョンの WordPress と 新しい WordPress プラグインの組み合わせ、またはシングルサイトインストールの上で WordPress マルチサイト用プラグインを使用すると発生します。この問題を解決するには WordPress をアップグレードしてください。
4. 存在しない関数を呼び出している可能性があります。「functions.php」内にスペルミスがないかを確認してください。

WordPress プラグインを無効化するか、WordPress テーマを変更して、問題が解消するかどうかを確認してください。 管理画面 から操作できない場合は、 FTPを使用して手動で 実行してください。
Allowed memory size exhausted
エラー「Allowed Memory Size Exhausted (利用可能なメモリーサイズを越えた)」は、WordPress に十分な実行可能メモリーがないことを意味します。以下の手順を試してください。

1. wp-config.php 内のメモリーの上限 を増やしてください。
2. php.ini を編集してメモリーの上限を増やしてください。このファイルは WordPress のファイルではないため、もし編集の方法が分からなければ、ホスティング会社に連絡し、メモリーの上限を増やしてください。

Maximum execution time exceeded
メッセージ「Maximum execution time of 30 seconds exceeded (最大実行時間 30秒 を経過した)」または「Maximum execution time of 60 seconds exceeded (最大実行時間 60秒 を経過した)」が表示される場合があります。処理の完了に時間がかかり、タイムアウトが発生しています。このエラーを修正するには多くの方法があります。
.htaccess の編集
.htaccess の編集前には必ずバックアップしてください。
.htaccess に次の行を追加してください。
php_value max_execution_time 60
php.ini の編集
php.ini に次の行を追加してください。
max_execution_time = 60
編集の方法が分からない、あるいは共有サーバーのため編集できない場合は、ホスティング会社に連絡し、最大実行時間の変更を依頼してください。
Parse Error Syntax Error
「Syntax Error (構文エラー)」は PHP コードの編集でミスがあったことを意味します。例えば

1. 行の最後の「;」を忘れた。
2. ストレート引用符「””」でなく、カーリー引用符「”“」を使用した。
3. ブレース「{}」を忘れた。

このエラーでは、どのファイル、例えば functions.phpの、何行目付近でエラーが起きたのかが表示されます。行番号は正確でない場合もあるため、前後の数行分も確認してください。
Unexpected
「parse error: unexpected (パースエラー: 予期しないエラー)」は一般に文字の入力を間違えた場合に発生します。よくある例としては

1. Unexpected ‘=’: 変数を参照する際に「$」を忘れた。
2. Unexpected ‘)’: 始まりの括弧「(」を忘れた。
3. Unexpected ‘(‘: 終わりの括弧「)」を忘れた。
4. Unepxpected T_STRING: クオーテーションを忘れた、または前の行の最後のセミコロン「;」を忘れた。
5. Unexpected T_ELSE:「if」を書かずに「else」を書いた。

Use of an undefined constant
パースエラーでの「use of an undefined constant (未定義定数の使用)」は文字の入力を忘れた場合に発生します。次のどちらかです。

1. 変数の参照で「$」を忘れた。
2. 配列のキーの前後にクオーテーションを忘れた。

Database Error
次のエラーは WordPress データベースに関連して発生します。
Cannot Create/Write to File
エラー「Cannot Create/Write to File (ファイルを作成できない、またはファイルに書き出せない)」には多くの原因が考えられます。

1. MySQL が一時ファイルを作成できない
2. ファイルパーミッション が正しくない

この問題を修正するには次のどちらかを実行してください。

1. 変数「tmpdir」を変更し、書き込み可能なディレクトリに設定する 。
2. ファイルパーミッション を修正する。

CREATE Command Denied to User
エラー「CREATE Command Denied to User (ユーザーはCREATEコマンドを許可されなかった)」は、データベースに割り当てられたユーザーが十分な権限を持たず、データベース内の列やテーブルの作成操作を実行できなかった場合に発生します。 CPanel または Plesk にログインしてデータベースユーザーに十分な権限を設定してください。
あるいは、代わりに データベースに割り当てる新しいユーザーを作成してください 。この場合、 作成したユーザーで wp-config.php を更新 する必要があります。
Error 28
エラー「Error 28」は MySQL のエラーで WordPress とは直接、関係ありません。ホスティング会社に連絡してください。多くの理由が考えられます。

1. サーバー上のキャッシュが一杯のため。解決するにはホスティング会社に連絡してください。
2. /tmp の下のファイルが多すぎるため。これもホスティング会社に連絡してください。

エラー「Error 28」の詳細については こちらの記事 も参照してください。
Error 145
エラー「Error 145」はデータベース内のテーブルが壊れたことを意味します。 phpMyAdmin を使えるなら、 こちらの手順 で MySQL データベーステーブルを修復してください。
実行する前には必ず データベースをバックアップ してください。
過去に phpMyAdmin を使ったことがないか、実行がためらわれる場合には、ホスティング会社に連絡してデータベースの「CHECK」や「REPAIR」の実行を依頼してください。
Unknown Column
エラー「Unknown Column (不明な列)」はデータベースに列が存在しない場合に発生します。WordPress をアップグレードした直後であれば、再度手動でアップグレードしてみてください。WordPress サイトを手動でアップグレードするには、 こちらの記事 を参照してください。
データベースを照会していてエラーが発生した場合は、誤ってクオーテーションマークを使用しているのかもしれません。詳細については Stack Overflow 上での質疑応答 を参照してください。また MySQL のマニュアル も参照してください。
リソース

1. トラブルシューティング
3. PHP Glossary
4. MySQL サーバーのエラーコードおよびメッセージ
5. WP Error Fix プラグイン

ログインできない場合

1. Cookie の有効化
2. WordPress マルチサイトネットワーク
3. プラグインの無効化
4. テーマの無効化
5. ログイン画面用ファイルの新規作成
6. Users テーブルの編集
7. パスワード関連の問題
8. サイト URL リダイレクト
9. サブドメインまたはサブディレクトリ
10. セキュア HTTPS
11. “Headers Already Sent” エラーの解決
12. URL 設定の確認
13. ファイアウォールの確認
14. それでもうまくいかない時は

WordPress の 管理画面 へログインできない場合は、以下の解決方法を試してみてください。
Cookie の有効化
ブラウザの Cookie が有効になっていることを確認するために、以下が必要になります。

1. ブラウザの Cookie を削除してみてください。
2. ブラウザのキャッシュをクリアしてみてください。

各種ブラウザでの Cookie とキャッシュの削除方法を知るには、 キャッシュと Cookie のクリア ページをご覧ください。
WordPress マルチサイトネットワーク
wp-config.php ファイル を開き、DOMAIN_CURRENT_SITE の値が正しいかどうか確認してください。
プラグインの無効化
ログインの際に邪魔をしている プラグイン があるかもしれません。すべてのプラグインを無効化してみましょう。 管理画面から行うか、 /wp-content/plugins/ フォルダから問題があるかもしれないプラグインを移動してみてください。
または、プラグインフォルダ名を /wp-content/pluginsXX/ などのように変更しても良いでしょう。これで、プラグインが認識されなくなります。問題が解決した後、このフォルダは /wp-content/plugins/ に改名し直してください。
テーマの無効化

1. FTP を使って有効化されているテーマのフォルダ（wp-content/themes内）名を変更します。変更すると、 WordPress は WordPress Twenty Seventeen テーマ にテーマを戻します。ログインできたら、別のテーマに変更してください。
2. テーマ内の問題がどこにあるのかを探すには、テーマが有効化されている際にこのコードを実行してみてください。

<?php ini_set('display_errors','1'); ini_set('display_startup_errors','1'); error_reporting (E_ALL);include('index.php'); ?>
ログイン画面用ファイルの新規作成
wp-login.php ファイルが壊れていたり、アップロードに失敗している場合もあります。

1. サーバから wp-login.php ファイルを削除し、新規ダウンロードした WordPress から再アップロードします。 FTP ツールを使って上書きしただけの場合は転送が完了しないことがありますので注意しましょう。
2. wp-login.php を以下のように編集します。
   1. case retrievepassword セクションで、以下のコメントを見つけます。

// redefining user_login ensures we return the right case in the email
以下の部分を、
$user_login = $user_data["user_login"];
このように書き換えます。
$user_login = $user_data->user_login;
Users テーブルの編集
phpMyAdmin にアクセス し、注意深くデータベースを編集します。

1. WordPress が使っているデータベースを開きます。
2. 左側のメニューから users テーブルを開きます（デフォルトは wp_users です。テーブル接頭辞を変更した場合は yourprefix _users になります）。
3. 表示をクリックします。
4. “admin” ユーザーの行にある編集アイコン（鉛筆マーク）をクリックします。
5. “user_pass” の行で、”関数” プルダウンから “MD5” を選択します。書かれた値を削除し、新しいパスワードを半角英数字で入力します。
6. 保存を実行します。
7. ユーザー名 “admin” と、先ほど作成したパスワードでログインします。

新しいバージョンの WordPress では、パスワードが二重ハッシュ処理されています。ただし、MD5 でハッシュしておけば、WordPress が自動的にパスワードをアップグレードしてくれるので心配はいりません。
パスワード関連の問題
パスワードが間違っている場合や、パスワードをなくしてしまった場合は、 ログインパスワードを変更・再発行する をご覧ください。
ユーザ名とパスワード欄では、大文字と小文字が別のものとして判断されますので注意しましょう。
サイト URL リダイレクト
WordPress のアドレス URL が何らかの理由でリセットされてしまっている場合があります。

1. PHPMyAdmin などで WordPress データベースの wp-options テーブルのsiteurlの値を確認しましょう（ サイト URL の変更についての説明ページ ・英語）
2. http:// になっていますか？
3. その場合は、siteurlを正しい値に修正します。
4. wp-login.php ファイルをテキストエディタで開き、以下の行を削除します。

// WordPress が移動された場合はどこにあるか検出//if ( dirname('http://' . $_SERVER['HTTP_HOST'] . $_SERVER['PHP_SELF']) != get_settings('siteurl') ) // update_option('siteurl', dirname('http://' . $_SERVER['HTTP_HOST'] . $_SERVER['PHP_SELF']) );
WordPress アドレスの URL を変更してしまったためにログインやデータベースへのアクセスができなくなった場合で、管理画面にはまだアクセス出来る場合は wp-login.php を使ってアドレスを変更できます。
//FIXME: データベースを変更したら以下はコメントアウトまたは削除update_option('siteurl', 'http://your.domain.name/the/path' );update_option('home', 'http://your.domain.name/the/path' );
サブドメインまたはサブディレクトリ
wp-login.php ファイルで、
define( 'SUBDOMAIN_INSTALL', true);
を以下に変更してみてください。
define( 'SUBDOMAIN_INSTALL', false);
セキュア HTTPS
セキュア HTTPS サイトで問題が発生している場合、 wp-includes/vars.php で以下の部分を見つけます。
define('COOKIEPATH', preg_replace('|http://[^/]+|i', '', get_settings('home') . '/' ) );
これを、以下のように書き直します。
define('COOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_settings('home') . '/' ) );
一般設定ページで URL を https:// にするのもお忘れなく。
“Headers Already Sent” エラーの解決
headers already sentというエラーメッセージが出る場合は、 FAQ の “Headers Already Being Sent” 問題の解決 をご覧ください。
URL 設定の確認
ドメイン内ではブログを見られても、外から見られないという場合があります。この場合、上記のテーブルの編集を行ってもログインできないかもしれません。
もしそうなってしまったら、 wp-options テーブルのsiteurl(WordPress のアドレス (URL)) とhome(ブログのアドレス (URL)) の値を再確認し、ベースが同一の利用できるアドレスであることを検証しましょう。例えば、http://blog.sample.com などです。標準インストールでは、http://servername のようなローカルホスト（内部ホスト）名になっているかもしれません。
もうひとつ考えられる問題は、 wp-options テーブルのsiteurl（WordPress アドレス URL）とhome（ブログアドレス URL）が www なしの URL に設定されているにもかかわらず、www なしの URL から www ありの URL へ .htaccess を使ってリダイレクトをしようとしている場合です。結果的に無限ループが作成されてしまいますが、これを防ぐ必要があります。解決方法の1つとして、.htaccess のリダイレクトを一時的に無効にすることです。リダイレクトの部分の行頭に # を書くか、その部分を削除して再度ログインしてみてください。上級ユーザーの方は、 wp-options テーブルのsiteurl（WordPress アドレス URL）とhome（ブログアドレス URL）をデータベースから更新してみるとよいでしょう。
ファイアウォールの確認
ファイアウォールには WordPress へのログインをブロックするものがあります（例: eTrust パーソナルファイアウォール）。ファイアウォールを無効にして再度試してみてください。
それでもうまくいかない時は
それでも問題が解決しない場合は、 WordPress サポートフォーラム に投稿してみましょう。その際、以下の内容を含めてください。

1. このページの方法を可能な限りすべて試したことの表明
2. サーバ設定の詳細 （MySQL と PHP のバージョン他）
3. パソコンのオペレーションシステム / OS（Windows、Mac、Linux など）
4. 使っているブラウザ
5. 問題が発生している WordPress のバージョン

WordPress でのデバッグ

1. WP_DEBUG
   1. PHP のエラー、警告、通知
   2. 非推奨の関数と引数
2. WP_DEBUG_LOG
3. WP_DEBUG_DISPLAY
4. SCRIPT_DEBUG
5. SAVEQUERIES
6. デバッグのための wp-config.php 例
7. デバッグプラグイン
8. 履歴
9. 外部リソース

どのプロジェクトでもPHP コードのデバッグは共通ですが、WordPress にはプロセスの簡素化目的にデザインされた専用のデバッグシステムと、コアやプラグイン、テーマに共通の標準化されたコードが備わっています。このページでは WordPress のさまざまなデバッグツールと、コードの生産性を向上し、同時に全体の品質を改善して相互運用を加速する方法について説明します。
注意:一般のアカウントではプラグインやテーマの WP_DEBUG は必須ではありませんが、プラグインやテーマを公開する開発者はコードの作業中に WP_DEBUG モードを使用することを強く推奨します。互換性のないプラグインやテーマはエラーや通知、警告を出力します。 WP_DEBUG を有効にして作業する他の開発者はこのような行儀の悪いプラグインやテーマを使いません。またエラーを含むテーマは公式 WordPress ツールを介した登録の対象になりません。
WP_DEBUG
WP_DEBUG / en は WordPress を「デバッグ」モードに切り替える際に使用する PHP の定数 ( 永続的なグローバル変数 )です。デフォルトは false で、通常は WordPress の開発環境の wp-config.php ファイル内で true に設定します。
define( 'WP_DEBUG', true );define( 'WP_DEBUG', false );
注: 上の例の値「true」や「false」はブール値 (true または false) のため、引用符 (‘) で囲みません。定数 ‘false’ を指定すると true として解釈されるため注意してください。引用符は値をブーリアン型でなく文字列型にします。
WP_DEBUG や他のデバッグツールを本番環境で使用することは推奨されません。これらはローカルのテスト環境やステージング環境での使用を想定しています。
PHP のエラー、警告、通知
WP_DEBUGを有効にすると、すべての PHP エラー、警告、通知が表示されます。通常の PHP の動きであれば、重要なエラーのみが表示され、エラーに達すると恐怖の「真っ白」画面が表示されます。
PHP の通知や警告は、コードは壊れてはいないものの PHP 内部の適切なデータ検証ルールに準拠しない場合に表示されるエラーメッセージです。これらの警告は、関連するコードが発見されれば修正は容易であり、また修正されたコードはほとんど常にバグに強く、保守しやすくなります。
非推奨の関数と引数
WP_DEBUG を有効にすると、サイトで使用されている非推奨の WordPress 関数および引数についての通知が表示されます。非推奨の関数や引数はまだコアのコードで提供されていますが、近い将来には削除される予定です。一般に非推奨の通知は、代替として利用可能な新しい関数についても示します。
WP_DEBUG_LOG
WP_DEBUG_LOG は WP_DEBUG と一緒に使用して、すべてのエラーをディレクトリ wp-content 下のログファイル debug.log に保存します。これはあとですべての通知を確認したり、画面の外で生成される通知を確認する場合に便利です(たとえば AJAX リクエスト中や wp-cron 実行中など)。
注意: この状態で PHP のビルトイン関数 error_log() を使用すると wp-content/debug.log に出力できます。これはたとえば AJAX のイベントをデバッグする際に便利です。
define( 'WP_DEBUG_LOG', true );
注: WP_DEBUG_LOG が動作するには WP_DEBUG に true を設定して有効化する必要があります。WP_DEBUG_DISPLAY は独立して無効化できます。
WP_DEBUG_DISPLAY
WP_DEBUG_DISPLAY も WP_DEBUG と一緒に使用してデバッグメッセージを HTML ページ内部に出力するかどうかを制御します。デフォルトは「true」で、生成されたエラーや警告をページに表示します。「false」を設定するとすべてのエラーは表示されません。この設定は WP_DEBUG_LOG と組み合わせて使用し、あとでログファイルでエラーを確認してください。
define( 'WP_DEBUG_DISPLAY', false );
注: WP_DEBUG_DISPLAY が動作するには WP_DEBUG に true を設定して有効化する必要があります。なお WP_DEBUG_LOG は独立して制御できます。
SCRIPT_DEBUG
SCRIPT_DEBUG はデバッグに関連する定数で、通常 WordPress にロードされる「縮小版」コアCSS や JavaScript ファイルの代わりに「開発版」を使用します。組み込みの .js ファイルや .css ファイルを変更してテストする場合に便利です。デフォルトは「false」です。
define( 'SCRIPT_DEBUG', true );
SAVEQUERIES
SAVEQUERIES 定義はデータベースクエリを配列に保存して表示し、クエリの解析を支援します。「true」を設定して有効化すると、各クエリが実行時間、呼び出し元の関数と共に保存されます。
define( 'SAVEQUERIES', true );
配列はグローバル $wpdb->queries 内に保存されます。
注意: この設定はサイトのパフォーマンスに影響を与えます。デバッグ時以外は無効化してください。
デバッグのための wp-config.php 例
次のコードをファイル wp-config.php に挿入するとすべてのエラー、通知、警告が wp-content ディレクトリ下のファイル debug.log に出力されます。画面へのエラー表示は抑止されるため、生成されたページはデバッグメッセージで邪魔されません。
// WP_DEBUG モードを有効化define( 'WP_DEBUG', true );// /wp-content/debug.log ファイルへのデバッグログの出力を有効化define( 'WP_DEBUG_LOG', true );// エラーと警告の画面への表示を無効化define( 'WP_DEBUG_DISPLAY', false );@ini_set( 'display_errors', 0 );// 「開発版」のコア JavaScript と CSS ファイルを使用 (これらのコアファイルを変更する場合のみ必要)define( 'SCRIPT_DEBUG', true );
注意: このコードはファイル wp-config.php 内の /* That’s all, stop editing! Happy blogging. */ より前に挿入してください。
デバッグプラグイン
WordPress のデバッグを助ける多くの 素晴らしいプラグイン があります。これらは特定のコンポーネント、または全体に関してより多くの内部情報を出力します。いくつか例を挙げます。 Debug Bar 、 Log Deprecated Notices 、 Total Security
履歴
WordPress 3.1 以前には STYLE_DEBUG 定数が JavaScript を除く CSS ファイルに対象を限定して SCRIPT_DEBUG と同じ働きをしていました。WordPress 3.1 で2つの定数は SCRIPT_DEBUG に統合され、両方の縮小版ファイルに働くようになりました。
外部リソース

1. WordPress ‘wp-config.php’ file Generator
2. ‘No White Screen’ plugin: Display the error instead of a white screen

FAQ トラブルシューティング

1. 「該当する投稿は見つかりませんでした」と表示されるだけで投稿が見えないのはなぜですか ?
2. ヘルプが必要な場合はどうすればいいですか ?
   1. CSS 関連の問題のヘルプを得るには ?
3. 「リファラー送信」関連のエラーメッセージが表示されるのはなぜですか ?
4. データベーステーブルを空にするには ?
5. SQL/DB Error errcode 13 Can’t create/write to file というエラーを解決するには ?
6. Headers already sent エラーを解決するには ?
7. 「公開」や「下書きとして保存」ボタンが動作しません。
8. Apple の Safari ブラウザでビジュアルリッチエディターやクイックタグボタンが表示されないのはなぜですか ?
9. パスワードリセットのメールが届きません。
10. 投稿内で <!–nextpage–> クイックタグを使いましたが動作しません。どうしてですか ?
11. MySQL エラー 28
12. 引用符がエスケープされたりされなかったりしているのはなぜですか ?
13. コメントを投稿したときにページが真っ白になるのはなぜですか ?
14. 管理画面にアクセスできない場合にすべてのプラグインを停止するには ?
15. 自動アップグレードの後に出てくる「現在メンテナンス中のため、しばらくの間ご利用いただけません。」または「Briefly unavailable for scheduled maintenance」というメッセージを消すには ?
16. スラッグを含むパーマリンクを使った場合の404エラーを解決するには ?
17. 投稿を編集する際に管理者が投稿者として表示されないのはなぜですか ?
18. 最新バージョンがリリースされた直後に管理画面で表示されないのはなぜですか ?
19. 自動アップグレードの際にどうして WordPress デフォルトテーマへの変更が消えてしまうのですか ?
20. MySQL データベーステーブルを修復するには ?

「該当する投稿は見つかりませんでした」と表示されるだけで投稿が見えないのはなぜですか ?
ブラウザーのキャッシュと Cookie を削除すれば問題を解決できるかもしれません。また、search.php および index.php テンプレートファイルにエラーがないか確認してください。
参照:

1. 変更を加えても何も起こりません / en

ヘルプが必要な場合はどうすればいいですか ?
ここにある FAQ だけでなく、WordPress を使うために役立ついろいろな情報があります。

1. トラブルシューティング
2. WordPress のヘルプ / en
3. サポートフォーラムの利用
4. WordPress に関する技術情報 / en
5. インストール時の問題

CSS 関連の問題のヘルプを得るには ?
CSSの問題を解決するのに役立つ記事

1. WordPress サイトデザイン リファレンス
2. CSS のスタイルを見つける / en
3. ブラウザのバグを修正する CSS / en
4. CSS のトラブルシューティング / en
5. CSS について

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

1. リファラー送信の有効化

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

1. Emptying a Database Table / en

SQL/DB Error errcode 13 Can’t create/write to file というエラーを解決するには ? # 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 エラーを解決するには ? # 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 キーを押してください。
   1. 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 サポートフォーラムの次のスレッドを参照してください。 https://wordpress.org/support/topic.php?id=24981
Windows ホスティングサーバー固有の情報: SMTP 仮想サーバーの「Relay」設定を確認し 127.0.0.1 のアクセスを許可してください。次に「 php.ini 」ファイル内で SMTP を同じ IP アドレスに設定してください。また smtp_port を25に設定します。
返信用アドレスの確認:デフォルトで 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
このエラーは一般に次の場合に発生します。

1. /tmp あるいは tempdir の参照先のディスクに空き容量がない、または、
2. /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; ?>" />
関連する議論のスレッド:

1. https://wordpress.org/support/topic/38683

管理画面にアクセスできない場合にすべてのプラグインを停止するには ?
すべてのプラグインを停止 (無効化) しなければならないが、管理画面にアクセスできない場合があります。次のどちらかの方法ですべてのプラグインを停止できます。
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 の有効化にはホスティング会社への連絡が必要な場合があります。
参照:

1. パーマリンクの使い方

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

1. https://wordpress.org/support/topic/234726

投稿を編集する際に管理者が投稿者として表示されないのはなぜですか ?
この問題が発生する原因は不明ですが、次の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」レコードで制御されます。
関連する議論のスレッド:

1. https://wordpress.org/support/topic/242485

自動アップグレードの際にどうして WordPress デフォルトテーマへの変更が消えてしまうのですか ?
コア (WordPress 本体) のアップグレードでは、パッケージ内のすべての新しいファイルで古いファイルを上書きします。既存の WordPres のデフォルトテーマ内のファイル、例えば wp-content/themes/twentysixteen/style.css を変更していた場合、変更は新しい同名のファイルで上書きされます。
注意: コアのアップグレードは wp-admin/includes/update-core.php で定義された「古いファイル」リストに従って行われ、削除されます。リストにないファイルや、パッケージに含まれないファイルは削除されません。
注意: 自動であれ手動であれアップグレードの前には、「 WordPress のバックアップ 」に説明された方法で、WordPress ファイルおよびデータベースをバックアップしてください。
デフォルトテーマを変更する場合は 子テーマ を使用してください。セットアップに多少の手間は必要ですが、デフォルトテーマが更新されてもカスタマイズ内容は失われず安全です。
参照:

1. WordPress のックアップ
2. 子テーマ

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

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

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

1. WordPress のバックアップ

サポートへようこそ
コミュニティベースのサポートフォーラムは、学び、共有し、問題解決をするための絶好の場所です。
はじめる
ドキュメンテーション
インストールからプラグインの作成まで。すべてについての情報を見つけられる、最初に訪問すべき場所です。
ドキュメンテーションを参照
参加・貢献
サポートハンドブックには、最善のサポートを提供するためのヒント、コツ、アドバイスが含まれています。
ハンドブック (英語) を読む

---

サイトについて
投稿ルールのご案内と管理者からのお知らせ
フォーラムを表示
インストール
インストール、アップグレード時のトラブルや不明点
フォーラムを表示
使い方全般
使用方法やカスタマイズ、導入後のトラブルなど
フォーラムを表示
マルチサイト
マルチサイトに関する質問と話題
フォーラムを表示
プラグイン
プラグインに関する質問と話題
フォーラムを表示
テーマ
テーマに関する質問と話題
フォーラムを表示
WordPress への貢献と参加
翻訳、コミュニティ支援など貢献全般の話題
フォーラムを表示
自作品の告知
自作プラグイン、自作テーマなどの告知
フォーラムを表示
バグ報告と提案
WP 日本語版、日本語サイトへのバグ報告や提案
フォーラムを表示
開発版
ベータ版、RC 版に関する質問と話題
フォーラムを表示
その他
上記フォーラムに該当しない話題はこちらへ
フォーラムを表示
テーマとプラグイン
特定の テーマ や プラグイン に対するサポートをお探しですか ? テーマやプラグインのページへ向かい、「サポートフォーラムを表示」のリンクから個別のフォーラムに移動してください。

|
|
|

Slack への参加方法

1. 手順1. WordPress + Slack (英語版) に登録する
2. 手順2. WordSlack (日本語版) に登録する
   1. Slack デスクトップアプリで WordSlack ワークスペースを追加する場合
   2. Slack モバイルアプリで WordSlack ワークスペースを追加する場合
3. WordSlack ワークスペース管理者
4. WordSlack チャンネル一覧

WordPress コミュニティでは Slack をメインのリアルタイムコミュニケーションツールとして使用しています。 Slack では「ワークスペース」と呼ばれる管理対象の中に、複数の「チャンネル」があり、議論はそれぞれの「チャンネル」内で行います。Slack に参加するにはまず「ワークスペース」に参加する必要があります。
WordPress の主なワークスペースには以下の2つがあります。

1. WordPress + Slack は WordPress の開発・コミュニケーションに使われている公式 Slack です。英語です。

1. WordSlack は WordPress 日本版コミュニティの Slack です。 日本語を使用できます。

WordPress の Slack に参加するには chat.wordpress.org ドメインのメールアドレスが必要です。日本語の WordSlack ワークスペースに参加する場合も以下の手順1と2を行った後に https://wpja.slack.com からアクセスするか、デスクトップまたはモバイルアプリを利用してください。
手順1. WordPress + Slack (英語版) に登録する

1. WordPress.org サイトにログイン します（まだアカウントがない場合は 登録画面 から作成してください）。
2. ログインしたら WordPress+Slack を開きます。
3. 「Joining the WordPress team on Slack」を読んで 理解し、合意したら 「I understand. Please send me an invite.」をクリックします。
4. すると転送専用の「wordpress.org ユーザー名@chat.wordpress.org」のメールアドレスが作成され、wordpress.org アカウントに登録されたメールアドレスに招待メールが送信されてきます。

英語版 Slack には、 https://wordpress.slack.com/ からアクセスできます。
手順2. WordSlack (日本語版) に登録する

1. https://wpja.slack.com/signup/ を開きます。
2. @chat.wordpress.org の左側にあなたの wordpress.org アカウントを入力し、「アカウントを作成する」をクリックします。
3. WordPress.org アカウントに登録されたメールアドレスへ招待メールが送られてくるので、「メールアドレスの確認」をクリックします。

Web からアクセスする場合はこれで準備完了ですので、 https://wpja.slack.com から参加してください。アプリを使う場合は以下を参照してください。
ヒント: ワークスペースが複数ある場合は、アプリのほうが切り替えがラクです。
Slack デスクトップアプリで WordSlack ワークスペースを追加する場合

1. https://slack.com/downloads からアプリをダウンロードします。
2. Window メニューから Sign in to another team… をクリックします。
3. Sign in ウィンドウが立ち上がりますので、Slack domain を入力します
   1. WordPress + Slack (英語版) の場合は wordpress
   2. WordSlack (日本語版) の場合は wpja
4. 「Continue」をクリックします。

Slack モバイルアプリで WordSlack ワークスペースを追加する場合

1. 右上サブメニューをタップします。
2. サブメニュー内より「Switch Teams」をタップします。
3. 「Add a team」をタップします。
4. Enter your team’s Slack domain の下に wordpress (WordPress + Slack (英語版) の場合)、または wpja (WordSlack (日本語版) の場合) と入力します。
5. 「Continue」をタップします。
6. Your email address の下にある @chat.wordpress.org の左側にあなたの wordpress.org アカウントを入力し「Continue」をタップします。
7. Your password 下にパスワードを入力し、「Sign in」をタップします。

WordSlack ワークスペース管理者
WordSlack の趣旨に賛同して集まった有志が管理者権限を持っています（アルファベット順、カッコ内は WordSlack ハンドル名）

1. Daisuke Takahashi https://www.extendwings.com/ (extendwings)
2. Hiroshi Urabe https://torounit.com/ (torounit)
3. Junko Nukaga http://nuuno.net/ (nukaga)
4. Nao http://ja.naoko.cc/ (nao)
5. Odyssey http://8bitodyssey.com/ (odyssey)
6. Tai http://wp.tekapo.com/ (taisuke)

WordSlack チャンネル一覧
現在、WordSlack 日本語版にあるチャンネルは以下となっています。

1. general

全体への連絡、議論など。

1. random

どのチャンネルにも属さないような気軽な話題など。

1. cli

WP-CLIの日本語用チャンネル。

1. code-of-conduct

行動規範に関する意見・議論など。

1. community

WordPress コミュニティが運営する各種勉強会やイベントについて。

1. community-translate

Meetup / WordCamp のドキュメント翻訳の情報共有チャンネル。

1. core

日本語で core の話をできるところ。 WordPress コミュニティが運営する各種勉強会やイベントについて。

1. core-edior

日本語でコアのエディタ (ブロックエディター、Gutenberg プロジェクト、Classic エディター) に関する話ができるところ。

1. design

WordPress のデザイン全般について日本語での情報共有チャンネル。

1. docs

WordPress のドキュメント全般についての日本語での情報共有チャンネル。Codex、ハンドブックを含む。

1. forum

WordPress.org 日本語フォーラムについて。

1. general

全体への連絡、議論など。

1. hosting-community

WordPress をホスティングするレンタルサーバー会社等の情報共有チャンネル。

1. ideas

https://github.com/jawordpressorg/ideas に関するチャンネル。

1. meetup

Meetup オーガナイザー同士の情報共有チャンネル。

1. meta

WordPress.org や WordCamp.org を支えるインフラを手伝う。日本語公式サイト ( ja.WordPress.org )のバグや改善についてもこちらへ。

1. plugin

WordPressプラグインについて。使い方、作り方、提案、情報、公式ディレクトリに掲載された際の宣伝など。

1. random

どのチャンネルにも属さないような気軽な話題など。

1. release

リリース関連。

1. requests

プラグイン、テーマ翻訳等の、承認(PTE )権限付与、翻訳承認リクエスト。

1. slack-help

Slack の使い方に関するチャンネル。

1. theme

WordPressテーマについて。使い方、作り方、提案、情報、公式ディレクトリに掲載された際の宣伝などなど。

1. theme-review

WordPressテーマのレビューについて。

1. translate

翻訳に関わる様々な事柄についてのチャンネル。

1. user-manual

WordPress ユーザーのためのドキュメントを作成するチャンネル。

1. wapuu-channel

自由にわぷーを呼んだり、slack に慣れるためのお試しチャンネルです。「わぷー いる？」等でわぷーに話しかけてみてください。

1. wapuu-request

わぷーアーカイブへの追加リクエストのためのチャンネル

1. wordcamp

各地をまたいだ WordCamp についての情報共有

1. wordcamp-ja-meta

WordCamp Japan のWebサイトについて。

1. wptv

WordPress TV（ [1] ）に関する話題。