Open post
Twenty Twenty - CSS list

CSS Class List – wordpress “Twenty Twenty”

Css class : “Twenty Twenty”

WordPress 5.0 の標準テーマに既に定義されている CSS の クラス。再使用が可能なクラスなら新しいブロックエディターで十二分に活用できる。テーマを Twenty Twenty から別のものに変更してしまっているのであれば、CSS編集 などで追加しておくのも使い勝手がいいかもしれない。

“Twenty Twenty – CSS class list”

再利用が可能な定義済クラス

WordPress.org 英語

CSSのクラス( class )とは

一つ以上のスタイルプロパティを、ひと固まりに設定し、名前を付けたもの。

Twenty Twenty とは

WordPress.org 日本語

WordPress 2020年のデフォルトテーマ。 ブロックエディターの柔軟性を最大限に活用するデザインになっている。

定義済みクラスの使い方

ブロックエディターの右側に表示されるメニューの、高度な設定という欄に入力すると、適用されて使用できる。

高度な設定という欄
高度な設定という欄

Open post
UPDATING FAILED

wordpress “updating failed”

WordPress 5.0 のリリース当初に “updating failed” が出てしまった時のこと :

WordPressの5.0がリリースされた際、 “updating failed” が世間を騒然とさせた。この記事では WordPress.org の Fixing WordPress Forum に立てられた とあるスレッド を振り返りつつ、このようなWordPressの問題がどうやって解決されていくのかを垣間見てみたいと思う。

“updating failed”

“更新に失敗しました”

WordPress.org 日本語

updating failed | 更新に失敗しました

事の起こりと経緯 : 今から二年前の2018年10月、WordPressの最新バージョンである5.0のbeta版が公開された。それからいくつもの更新を経てついに同じ年の12月 正式版となる WordPress 5.0 “Bebo” がリリースされる。

長年親しまれてきたエディターを刷新した WordPress 5.0 では、その新しさゆえに生じる問題が当初は多くあり、掲題の updating failed | 更新に失敗しました 問題もそのひとつであった。

そうして今から1年と2か月ほど昔、 WordPress 5.0 “Bebo” がリリースされるのとほぼ同時期に WordPress.org の サポート「Fixing WordPress Forum」にはこんなスレッドが立ち上がっている。

READ THIS FIRST WordPress 5.0 Master List

最初にお読みください。WordPress 5.0マスターリスト( 日本語意訳 )

Hooray! WordPress 5.0 “Bebo” is here! But OMGWTFBBQ!? WordPress 5.0 broke everything?

やった! WordPress 5.0「Bebo」はこちら!しかしなんてこったこんちきしょーめ !? WordPress 5.0 が全部を台無しにした? ( 日本語意訳 )

※以降は全部日本語意訳(翻訳: Google翻訳 | 編集: COCOROZASI.NET)にてお届けします。

お・ち・つ・け!

焦る前に、プラグインとテーマを最新バージョンに更新し、ブラウザのキャッシュとCookieをクリアして、WordPressダッシュボードに再ログインしてくれ。

新しいエディターは無効にできる!

非常にまずい状態で、できるだけ早くエディターをロールバックする必要がある場合は、古いエディターを復元するクラシックエディター(https://wordpress.org/plugins/classic-editor/)をインストールしてくれ。

とりあえずはこれでなんとかなる。落ち着いたら、本題に入ろう。

このスレッドには、5.0で見つかったプラグインとテーマに関する既知の問題が含まれている。この全トピックをひととおり読んでから、そうしたらまた新しい情報が出てくると思うので、そうしたら後で戻ってもう一度 頭から確認してくれ。

落ち着いて、忍耐強く、お互いに敬意を払いあうことを忘れないでほしい。ここで対応しているボランティアは皆、あなたを助けようという思いでここにいる。けれどそれにはあなたの助けも必要だ。ここにも通常のフォーラムルールはすべて適用されている。だから覚えておいてほしい、あなたは他のみんなと同じくらい重要なんだ ということを。

このスレッドへの投稿がすぐに表示されない場合は、しばらく気を落ち着けて待ってほしい。どうやら通常よりも投稿数が多いため、自動スパムツールによっていつもより多くの投稿がスパムとして報告されてきている。投稿のためのキューを空けるために中の人(機能)が一生懸命取り組んではいるが、あんたが複数の投稿を行うと、その中の人(機能)がもう一度最初に戻って既に投稿したかどうかを確認する必要が生じて、処理が遅れる。なので投稿するのは一度だけにしてくれ。

タイトルと本文には適切な大文字を使用してくれたまえ。また、本文には適切かつ人道的な句読点を付けてほしい。私たちが読むのに苦労しないですむように。

□ 説明的な件名を使用してくれたまえ。 「5.0にUpdateしたらすべてのパーマリンクが壊れた」の方が、「ああ! できるだけ早く助けて! このバージョンはひどいです!」よりは良い。

□ 問題を明確にしてくれたまえ。 最終的に画面に表示された内容を説明し、必要に応じてエラーメッセージとスクリーンショットを含めてほしい。問題がフロントエンドにある場合は、サイトへのリンクも役立つ。

□ 我慢をしてくれたまえ。サイトがダウンするのにはうんざりだろうが、ここに複数回投稿しても、すぐに助けになるなんてことはありえない話だ。

□ 独自のトピックを立ててくれたまえ。他人の投稿に便乗するのは、元になる投稿と同じプラグイン、テーマ、構成を持つ、同じホストで提供されている同じ物理サーバーで、まったく同じバージョンのWordPressを使用している場合にしてほしい。そうしたケースを除き、あなたはあなたの問題を独自のトピックとして作成してほしい。あなたはそれを奇妙に感じるかもしれないが、あなたがあなた自身のトピックを立ててくれる方が我々があなたを助けるのが簡単になる。

□ 修正されたトピックには解決済みのマークを付けてくれたまえ。そうすればそのトピックを開く時間の分、より多くの人を救える。

□ あなたは一人ぼっちじゃないってこと、忘れないでくれたまえ。

また、WordPressのデザインの方向性が気に入らないってたぐいの問題はバグではない。機能が気に入らないのだとしても、それについて文句を言う一連の投稿は行わないでくれ。これまでのトピックから、同じ問題を誰かが既に問い合わせたかどうかを確認し、そこにのっかって投稿するか、アーリープロセスに参加することを検討してほしい(ベータ版やSVNを介したテストなど)。今日目にしている見た目や機能については、何千時間もの作業とテストの結果であり、何かが完全に壊れていない限り、変更される可能性はほとんどないはずだ。

大事なことなのでもう一度だけ言う。投稿する前に :

このスレッドの全部と、5.0 の 新機能の記事を必ず読んでくれ。

〇 あなたのWordPress にあるインストール情報のページ ( //yourdomain/wp-admin/about.php )へ移動して、(または、あなたのWordPress の右上隅にあるWordPress のロゴをクリックして)最新情報を確認してほしい。

こうして WordPress 5.0 は正式にリリースされることとなる。

トラブルシューティングのステップ

READ THIS FIRST WordPress 5.0 Master List では、続けて トラブルシューティングのための手順が公開された。 Moderator であるスレッドの主 Marius L. J. はこのように続きを始めてゆく……


Before posting, please make sure you’ve tried started by performing the troubleshooting steps outlined below:

※以降は全部日本語意訳(翻訳: Google翻訳 | 編集: COCOROZASI.NET)にてお届けします。

記事を投稿する前に、以下で説明するトラブルシューティング手順を実行してみよう。

キャッシュプラグイン、およびサーバーやブラウザのキャッシュ。
こうした一連のキャッシュを開放しよう。ブラウザーだけでなく、Cloudflare などの任意の op キャッシュまたはコンテンツネットワークキャッシュも解放したまえ。これらは実に多くの奇妙な JavaScript の問題を解決してくれるだろう。

管理対象ホストキャッシュの解放。
マネージド WPホスティング には多くの場合、特別なキャッシュがある。ホストに「Purge Varnish」または「Flush Memcache」ツールがある場合は、それを試してみてほしい。必要に応じてホストのプロバイダーに memcache と Varnish を解放するように依頼するのもいい手だ。

パーマリンク設定を保存し直してみる。
いくつかのケースでは、Softaculous などのサードパーティのインストーラーが、.htaccessファイルにわずかに誤ったルールを使用してサイトを作成しているのを見てきた。これらのルールは以前のバージョンでは問題ないのだが、WordPress 5.0は、これらの不正なルールがあるとREST APIが破損する可能性がある。 WordPressの[設定]-> [パーマリンク]ページでパーマリンクを保存し直すと、.htaccessファイルのこれらのルールが修正され、新しいエディターで「失敗」エラーが修正される可能性がある。

ブラウザでトラブルシューティング。
ブラウザは JavaScript の問題や競合を特定するのに役立ち、そのためのこの記事は その診断を行う際に役立つ。このことはVisual Editorの問題を特定するのにも役立つ。

Visual Editor が有効になっていることを確認。
[ユーザー]-> [プロフィール]ページにアクセス。まず最初にビジュアルエディターを無効に設定する。オプションがオフになっていることを確認し、プロファイル設定を保存しよう。そうしてから改めてビジュアルエディターを有効にし、動作を確認していく。

すべてのプラグインを無効にして問題が解決するかどうかを確認。
これで問題が解決する場合、問題のあるプラグインが見つかるまで、プラグインを1つずつ再アクティブ化しながら確認するのが良い手だ。管理ダッシュボードにアクセスできない場合は、SFTP / FTP または PhpMyAdmin でプラグインフォルダーをリセットしてみよう。(ヘルプが必要な場合は、「wp-adminにログインできないときにすべてのプラグインを無効にする方法」をご覧ください)。時々、明らかに非アクティブなプラグインが問題を引き起こす可能性がある。また、mu-pluginsフォルダー内のプラグインを無効にすることを忘れないでほしい。最も簡単な方法は、そのフォルダーの名前を mu-plugins-old に変更するのも一手だ。

テーマ固有の問題を排除するために、以前の Twenty Nineteenテーマに切り替える。
ログインしてテーマを変更できない場合は、SFTP / FTP 経由でテーマフォルダーを削除して Twenty Nineteenテーマ が1つだけになるようにすればOKだ。あなたのサイトは残った一つのテーマを使用して呼び出されるだろう。

手動でアップグレードしてみる。
他のすべてが失敗したら、5.0。*のlatest.zipファイル(このページの右上)の新しいコピーをコンピューターにダウンロードし、それを使用して手動でアップグレードしてみる。この場合、サーバー上の wp-adminフォルダー と wp-includesフォルダー を削除する必要がある場合がある。(注: wp-contentディレクトリー と wp-config.phpファイル は削除しないでおくこと。)この手段をとる場合には必ず手動更新の指南書を読むこと。

プラグインをインストールできる場合は、「Health Check」をインストールする。
トラブルシューティングタブで、サイトへの通常の訪問者に影響を与えることなく、ログイン中にボタンをクリックしてすべてのプラグインを無効にし、テーマを変更することができる。

サポートトピックを作成する必要がある場合に、ヘルスチェックプラグイン Health Checkはサポートボランティアにデバッグデータを提供することもできる。

こう締めくくり、スレッドの二つ目の書き込みは終わっている。

とりあえず、ここに書いてある手順で確認をすれば、何が原因で updating failed | 更新に失敗しました のエラーが出ているか確認が可能だ。なので要点を整理しよう。

  1. キャッシュ プラグイン を利用している場合は、まずはキャッシュを全て削除し、そしてプラグインを停止する。Optimize 系のプラグインもあれば同様の扱いで、保存されているキャッシュを削除し、そしてプラグインを停止しよう。
  2. ホスティング サーバ 側のキャッシュ機能を確認し、稼働している様子であればこれも同じようにキャッシュを消してみる。ホストを提供しているプロバイダに、 “Purge Varnish” か “Flush Memcache” を実施して欲しいと問い合わせることも一手だ。
  3. WordPressの設定で、パーマリンクの設定を保存しなおす。これを実施することで .htaccess ファイル内のルールが修正されるため効果的だ。
  4. 複数のブラウザを使用して、JavaScript の問題かどうかを切り分けてみる。その際に「 Using Your Browser to Diagnose JavaScript Errors 」を読むと細かな手順がわかりやすい。内容をざっと書くとこんな感じだ。
    1. Step1 : 別のブラウザで試してみる
      ⇒ 例えば Chrome と Firefox、それに IE を使い、三つのブラウザで同じ問題が起きたならそれはブラウザに依存する JavaScript の問題ではないとわかるのでこの方法は終わり。逆にいずれかのブラウザだけで問題が起きるのなら、それはそのブラウザ固有の問題だと切り分けることができる。
      切り分け後にブラウザ固有の問題であれば、その詳細をサポートに送ることで、対処がしやすくなるだろう。またその場合は次の Step2 を実施してみよう。
    2. Step2 : SCRIPT_DEBUG(スクリプトデバッグ機能)を動作させる
      ⇒ wp-config.php の 終わりの方に「 /* That’s all, stop editing! Happy blogging */ 」あるいは「 /* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */ 」と書かれた行がある。それよりも前の行に define('SCRIPT_DEBUG', true); と記述してブラウザで確認してみる。
      これで問題が起きなければ設定を元に戻し、できればサポートフォーラムで問題を報告し、ボランティアにスクリプトデバッグをオンにして問題を解決したことを伝える。そうでない場合は Step3 を試してみる。
    3. Step3 : 診断
      ブラウザ固有の問題であり、なおかつスクリプトデバッグでは治らなかった。そうしたらその問題が起きているブラウザで診断機能を確認してみる。詳細はこちらのサイトを確認して欲しい(英語)
    4. Step 4: レポートの提供
      ブラウザでの問題切り分けと解決ができたのであれば、サポートフォーラムのリクエストを行おう。トラブルシューティングフォーラムにて歓迎されることだろう。
  5. Visual Editor が有効になっていることを確認
  6. すべてのプラグインを無効にして問題が解決するかどうかを確認
  7. Twenty Nineteenテーマに切り替えてみて動作を確認
  8. 手動でアップグレードしてみる
  9. ヘルスチェックプラグイン を使って動作を確認してみる

updating failed | 更新に失敗しました の問題だけであれば、実はもう少し事は簡単だ。後述する各サイトの情報を確認してもらえば簡単に解決できるだろう。

ここまで記述してきたこれらの情報は、WordPress の動作に問題が発生した際に、総合的に網羅した問題解決のための手順になっている。そのため、少しばかりやることが多い。

READ THIS FIRST WordPress 5.0 Master List ではこの後も「バグ」についての記載や、既存の「プラグイン」との相性、既存の「テーマ」との相性 について情報が続いていく。

その後は、こうしたフォーラムへの情報提供や改変を経て、現在は WordPress 5.3 “Kirk” がリリースされている。

オープンソースの開発は、こうした コミュニティの有志たちの活躍 により、今日もどこかで一歩一歩、確かに前進していくのであった。( 少々無理やりだけどまとめてみた。@json )

UPDATING FAILED
UPDATING FAILED
Open post
Yoast SEO assessment: Keyphrase in introduction

INTRODUCTION Keyphrase

Introduction Keyphrase

https://yoast.com/wordpress/plugins/seo/keyphrase-in-introduction-check/
Yoast SEO assessments: Overview

Yoast SEO評価:導入部のキーフレーズ

導入部のキーフレーズ

キーフレーズの単語がテキストの最初の段落で見つかるかどうかを確認します。
Yoast SEO Premiumでは、追加した同義語も考慮されます。

導入部のキーフレーズがSEOにとって重要なのはなぜ?

導入部は、読者にとって重要な段落です。
彼らはあなたのテキストが読みたいトピックに関するものかどうかを導入部で決定します。また、導入部でのキーフレーズはGoogleにとっても非常に重要な意味を持ちます。Googleは、導入部を使用して、テキストの内容を判断します。なのでフォーカスキーフレーズはその序文に含まれている必要があります。

読者の注意を引くのはほんの数秒です。
最初の段落が投稿のメインメッセージを伝えていることを確認してください。そうすることで、読者があなたの投稿が何であるかを簡単に理解できるようになります:同時にあなたの投稿が何であるかをGoogleに伝えることになります。

導入部をよりよくするために

導入部は、テキストの重要な段落です。 ほとんどすべての読者が読む最初の段落です。
ですので、あなたはそれを素晴らしいテキストにした方が良いです!
テキスト内の他のすべての段落を書いた後に、導入部分を書くことが最善の場合もあります!

ブログ投稿の最初の段落が明確で、適切に記述されており、ブログ投稿のコアメッセージが含まれていることを確認してください。
逆ピラミッドのように逆さまに書きます。
最初の段落のブログ投稿の最も重要な結論と、次の段落で続く結論の詳細と議論。
投稿の最後の段落で主要な結論を繰り返していることを確認してください。

テキストの導入の改善についてもっと知りたいですか?
Yoast Academyによる記事では、テキストの導入の改善について詳しく知ることができます。

Yoast SEO assessment: Keyphrase in introduction
Yoast SEO assessment

導入部にフォーカスキーフレーズを含める

https://yoast.com/academy/seo-copywriting-training/keyphrase-in-introduction/
Yoast SEO assessments: Overview

Yoast SEOプラグインは、テキストの最初の段落にフォーカスキーフレーズが含まれているかどうかを確認します。それはかなり面倒だと思われるかもしれませんが、簡単に慣れます! なぜこれがSEOチェックの一部なのか? そして、これをどのように解決し、オレンジまたは赤のシグナルを緑に変えるのか?このコンテンツで、SEOで導入部の重要性を見ていきましょう。

導入部でフォーカスキーフレーズを使用することの重要性

テキストの最初の段落は記事の紹介です。 これは、ユーザーと検索エンジンの両方にとって重要な場所です。前にも述べたように、読者がページにとどまるようにしたい場合は、読者の注意を最初につかむことが不可欠です。Googleは、最初の段落も重要だと考えています。
紹介にフォーカスキーフレーズを含めることは、検索エンジンに記事に関する特定の手がかりを与えるようなものです。また、Googleは最初の段落を使用してページ自体のメタ説明を作成する場合があることも知っておく必要があります。紹介文がテキストの内容を正確に反映しており、そこにフォーカスキーフレーズが含まれていることを確認してください。

覚えておいてください:ほとんどの人はウェブページをすぐに読むのではなくスキャンします。 ページの実際の件名を最初に言及することで、彼らにとって選択が簡単になります!

導入チェックでフォーカスキーフレーズを渡す

Yoast SEOプラグインでは、導入部でフォーカスキーフレーズを使用しているかを確認する事を十分重要であると考えています。このチェックで赤またはオレンジのシグナルを解くのは簡単に聞こえるかもしれません。紹介テキストでフォーカスキーフレーズを使用していることを確認してください。しかし、それは簡単に忘れられます。 役に立つかもしれないいくつかのポイントを議論しましょう。

良いパラグラフはコアセンテンスで始まり、その後、詳しく説明をしていきます。これは最初の段落である序文にも当てはまります。フォーカスキーフレーズに言及している中核的な文を考えてください。そしてそこから先に進みます。 テキストの残りの部分に何を期待するかを詳しく説明します。読者の注意を引くために、短い逸話や例から始めることもできますが、その場合は、できるだけ早くフォーカスキーフレーズでフォローアップしてください。

ページの内容を明確に。 読者だけでなく、検索エンジンのためにも!

シグナルがオレンジや赤のとき

Yoast SEOで「導入時にフォーカスキーフレーズ」チェックをトリガーする可能性のあるものがいくつかあります。 これは、何が起こっているかを把握するのに役立つかもしれません!

  • 主題については記述したが、フォーカスキーフレーズを記述していない。
  • 逸話を使用して注目を集めたが、フォーカスキーフレーズが含まれていない。
  • キーフレーズまたはその同義語について言及したが、最初の文中ではなかった。
  • キーフレーズの同義語について言及したが、Yoast SEO Premiumではない。

フォーカスキーフレーズとして入力した単語が最初の段落で言及されていることを確認してください。 さらに具体的には、同じ文内にある必要があります。 検索エンジンと読者があなたのテキストが何であるかを素早く理解するためには、主題を明確に述べる必要があります。 たとえば、逸話から始めることにした場合でも、テキストの主題を明確にする文を必ず追加してください。

導入部は第一印象のようなものです

第一印象を作るために二度目のチャンスを得ることはありません。このことわざは、人とテキストの両方に当てはまります。あなたのテキストの最初の段落が不明瞭で、話題から外れていたり、退屈なだけなら、人々は興味を失います。書籍を脇に置くか、クリックして別のWebサイトに移動します。

特にオンラインリーダーの場合:ページが自分の興味に合わない場合は、何百万ものページからクリックするだけで、より興味深いものになります。それを念頭に置いて、潜在的な読者をページにとどめてテキスト全体を読ませるにはどうすればよいでしょうか? どうすれば第一印象を良くすることができるでしょうか?

良い導入部をどのように書くか?

ここまで、キーワードの紹介を使用することの重要性について説明してきました。 しかし、一般的にどのようにして素晴らしい導入部を書くのでしょう? 読者の注意を引くには、最初の段落が重要であることは知っています。

まずは基本から始めましょう。導入部にはどのような要素が必要でしょうか?

導入パラグラフを使用して次のことを行います:

  1. トピックを紹介する
    できれば最初の段落の最初の文で、読者にテキストの内容を伝えてください。 短くシンプルにしてください。 注意の範囲はオンラインでは非常に短く、読者に迷惑をかけたくありません。 逆ピラミッド記述スタイルの使用を検討してください。 この方法では、すぐにそのポイントに到達して、注意を引くことができます。 最初の段落の目的は、読者に2番目の段落を読んでもらうことだと言う人もいます。
  2. 読者が期待できることを説明する
    読者を導きましょう。そのためにまず、テキストの残りの部分に何が期待できるかを伝えます。このテキストが彼に役立つかどうかを読者が判断するのに役立つのであれば、目的を述べ、構造を説明してください。多くの作家は、サイトを見つける方法がたくさんあることを忘れがちです。あなたの読者はあなたの物語と製品を知っている再訪問者だけで構成されていません。 検索結果から特定のブログ投稿に到達する新しい訪問者の視点を取ります。その投稿の導入部分は、訪問者に十分な手がかりを与えていますか?
  3. 読者に一緒に読んでもらう
    読者に記事の残りの部分を読むよう促すには、2つの方法があります。最初のものはコンテンツに焦点を当てています。トピックを紹介し、読者が期待できることを説明することで、情報を提供しています。一部の読者にとっては、この情報だけで読み続けるには十分かもしれません。他の読者は少しプッシュする必要があるかもしれません。文体的な要素を使用して、さらに興味を引くことができます。

最後のヒント

フォーカスキーフレーズが導入部にあることを確認するのに苦労している場合は、次のヒントを参考にしてください。

最初:同義語の使用。 Yoast SEO Premiumでは、フォーカスキーフレーズに同義語と関連キーフレーズを設定できます。これにより、繰り返しの少ないテキストを書くことができ、読みやすくなります。同義語を入力することにより、Yoast SEO Premiumは、異なるフォーカスキーフレーズチェックを分析する際に同義語を考慮します。導入段落の文内でフォーカスキーフレーズが言及されているかどうかを確認するチェックを含められえます。

しかし、同義語を使用する意味についてはよく考えてください。最も重要だと判断したフレーズの代わりに同義語を使用するのはなぜでしょう?

また、苦労している場合に役立つ別のヒントもあります。それはあなたのテキストの最初の段落ですが、間違いなくあなたが最初にそれを書かなければならないということではありませんということです!

完全な投稿を終えた後でも書くことができます。投稿の角度と内容をよりよく理解してから書くこともできます。そうすることで、フォーカスキーフレーズを含む優れた魅力的な導入部分を簡単に書くことができるようになります。

Yoast SEO assessment
Yoast SEO assessment
Open post
Yoast SEO assessment

Yoast SEO assessment.

Yoast SEO assessment.

https://yoast.com/wordpress/plugins/seo/assessments-overview/
Yoast SEO assessments: Overview

Yoast SEO評価:概要

Yoast SEO が評価する項目は、大きく分けて3つのカテゴリに含まれる。

評価のカテゴリー

キーフレーズベースの評価

導入部のキーフレーズ | Keyphrase in introduction
キーフレーズの単語がテキストの最初の段落で見つかるかどうかを確認します。

更新:キーフレーズの長さ | Updated: Keyphrase length
キーフレーズ内の(コンテンツ)単語の数が推奨制限内かどうかを確認します。 機能語をサポートする言語の場合、内容語のみが考慮されます。 機能語をサポートしない言語では、すべての語が考慮されます。

更新:キーフレーズ密度 | Updated: Keyphrase density
キーフレーズの(コンテンツ)単語がテキストで使用されているかどうか、および十分に頻繁に使用されているかどうか(ただし、あまり頻繁に使用されていないかどうか)をチェックします。 一致するものを見つけるには、すべての内容の単語が1つの文に含まれている必要があります。 1つの文内のすべてのコンテンツワードの複数の出現は、複数の一致と見なされます。

メタディスクリプションのキーフレーズ | Keyphrase in meta description
キーフレーズのすべての(コンテンツ)単語がメタ記述で使用されているかどうかを確認します。 キーフレーズのすべての単語が文に含まれている場合、一致がカウントされます。 文ごとの複数の一致は複数回カウントされます。

更新:小見出しのキーフレーズ | Updated: Keyphrase in subheadings
小見出しがコピーのトピックを反映しているかどうかを確認します(キーフレーズまたは同義語に基づいて)。 サブフレーズは、キーフレーズの少なくとも1つの(コンテンツ)単語が使用されている場合、トピックを反映すると見なされます。

リンクフォーカスキーフレーズ | Link focus keyphrase
テキストにキーフレーズが含まれているリンクテキストがあるかどうかを確認します。

更新:画像の代替属性のキーフレーズ | Updated: Keyphrase in image alt attributes
画像のalt属性にキーフレーズまたは同義語があるかどうかを確認します。

更新:タイトル内のキーフレーズ | Updated: Keyphrase in title
ページフレーズでキーフレーズが使用されているかどうかを確認します。

スラグのキーフレーズ | Keyphrase in slug
キーフレーズがURLで使用されているかどうかを確認します。

以前に使用したキーフレーズ | Previously used keyphrase
キーフレーズの単語が以前に別の投稿のキーフレーズで使用されていたかどうかを確認します。

キーフレーズの配布(プレミアムのみ) | Keyphrase distribution (only in Premium)
キーフレーズの単語がテキスト全体にどの程度うまく分布しているかを確認します。

その他のSEO評価

テキストの長さ | Text length
テキストが十分に長いかどうかを確認します。

更新:アウトバウンドリンク | Updated: Outbound links
アウトバウンドリンクが存在し、続いているかどうかを確認します。

内部リンク | Internal links
内部リンクが存在しているかどうかを確認します。

SEOタイトルの幅 | SEO title width
タイトルの長さが適切かどうかを確認します。

メタ記述の長さ | Meta description length
メタ記述の長さが適切かどうかを確認します。

更新:分類法ページのテキストの長さ | Updated: Text length for taxonomy pages
分類法ページの長さが適切かどうかを確認します。

新規:古いコーナーストーンコンテンツ(プレミアムのみ) | New: Stale cornerstone content (only in Premium)
最近、コーナーストーンコンテンツを更新したかどうかを確認します。

可読性評価

小見出しの分布 | Subheading distribution
長いテキストが小見出しで分割されているかどうかを確認します。

段落の長さ | Paragraph length
段落が推奨最大長を超えているかどうかを確認します。

文の長さ | Sentence length
文が推奨最大長を超えているかどうかを確認します。

連続した文章 | Consecutive sentences
同じ単語で始まる行に3つ以上の文があるかどうかを確認します。

受動態 | Passive voice
受動態を含む文の数が推奨最大量を超えているかどうかを確認します。

移行の言葉 | Transition words
遷移語を含む十分な文があるかどうかを確認します。

フレッシュリーディングイーズ | Flesch Reading Ease
Flesch Reading Easeテストに従って、テキストの読みやすさを確認します。

テキストの存在 | Text presence
コピーに十分なテキストがあるかどうかを確認します。

新規:シングルH1 | New: Single H1
コピーにH1ヘッダーが1つしかないかどうかを確認します。

Yoast SEO assessment
Yoast SEO assessment
Open post
Custom CSS

Custom CSS Guide for Japanese.

SiteOrigin CSS

https://siteorigin.com/css/

Custom CSS Guide – SiteOrigin CSS

A Custom CSS Guide to Page Builder Row, Cell & Widget Attributes の邦訳

A Custom CSS Guide to Page Builder Row, Cell & Widget Attributes

カスタムCSSは、愛好家や開発者が利用可能な設定を使用して実行できる以上のスタイル変更を行うための、迅速でアクセス可能な方法です。
このチュートリアルでは、ページビルダーの[属性]タブと、カスタムCSSを変更する際の使用方法について説明します。
この簡単なガイドは、CSSの基本的な知識があるユーザー、またはSiteOrigin CSSのビジュアルエディターの使用を超えたいユーザーを対象としています。

「属性」タブは、ページビルダーの行、セル、ウィジェットを編集するときに使用できます。

Attributes tab

Row Attributes : 行属性

Page Builderの行を編集するには、右側のスパナアイコンにカーソルを合わせて[ Edit Row ]をクリックします。
右側の[ Attributes ]見出しをクリックして、パネルを開きます。

以下のフィールドが利用可能です。

Row ID

行に適用されるカスタムID。 ID名のみを挿入する必要があり、通常使用される前述のハッシュは挿入しないでください。 たとえば、カスタム行IDの名前が「services」の場合、servicesという単語のみを挿入します。 ID名は1回しか使用できないことに注意してください。

行IDは、次のようにPage Builderマークアップに出力されます。

Row Class

行に適用されるカスタムクラス。
クラス名のみを挿入する必要があります。通常使用される先行ピリオドは挿入しないでください
たとえば、カスタム行クラスの名前が「drop-shadow」の場合、drop-shadowという単語のみを挿入します。

行クラスは、次のようにPage Builderマークアップに出力されます。

Cell Class

行の各セルに適用されるカスタムクラス。
クラス名のみを挿入する必要があります。通常使用される先行ピリオドは挿入しないでください
たとえば、カスタム行クラスの名前が「dark-bg」の場合、dark-bgという単語のみを挿入します。

行クラスは、次のようにPage Builderマークアップに出力されます。

CSSをはじめて設定する場合、上記の3つのフィールドは、SiteOrigin CSSなどのプラグインまたは [カスタマイズ] -> [CSS編集]のコアフィールドと組み合わせて使用されます。
必要なIDまたはクラス名が上記のフィールドのいずれかに挿入されたら、[外観] -> [Custom CSS]に移動して、挿入したIDまたはクラス名をターゲットにしたルールを作成します。


Next: サンプルターゲット CSS

Open post
ANIMATE IT!

ANIMATE IT! EASY CSS3 ANIMATIONS FOR WORDPRESS

ANIMATE IT! – EASY CSS3 ANIMATIONS

ANIMATE IT! – EASY CSS3 ANIMATIONS FOR WORDPRESS

WordPress 5.0 で使う、CSS3 Animate It。

かんたんな説明

稼働中のWordPress環境に、プラグイン「Animate It!」をインストールし、投稿や固定ページに配置するブロックの「高度な設定」に、後述するクラスを記述。
そうすると、各ブロックでアニメーション動作を行えるようになります。

アニメーション 動作例

R & D
bounceIn
R & D
fadeOut
slideOutUp

注意事項

必ず、ご自身の責任の範囲内でご利用ください。こちらの記載事項を模倣して起こる問題については当方では責任を負いません。

JUICY LTD. 株式会社 十志


Next: インストールと初期設定

ANIMATE IT!
ANIMATE IT! – EASY CSS3 ANIMATIONS
Open post
php.ini - for WordPress.

php.ini – WordPress

WordPress と関わりの深い、php.ini の設定

php.ini 設定例

; 引用符をつけないセミコロン(;)の後のテキストは、すべて無視されます
[php] ; セクションマーカ (角括弧の中のテキスト) は無視されます
; 論理値は、次のいずれかで指定します
;    true, on, yes
; または false, off, no, none
register_globals = off
magic_quotes_gpc = yes

; 文字列を二重引用符で括ることも可能です
include_path = ".:/usr/local/lib/php"

; バックスラッシュは他の文字と同様に処理されます
include_path = ".;c:\php\lib"

アップロード サイズ

php.ini ファイルに以下のディレクティブを記載します

  • memory_limit: PHP スクリプトが確保できる最大メモリ(バイト数)
  • post_max_size: POSTデータに許可される最大サイズ
  • upload_max_filesize: アップロードされるファイルの最大サイズ
  • max_execution_time: スクリプトがパーサにより強制終了されるまでに許容される最大の 時間(秒単位)
記述例(初期値)
memory_limit = "128M"
post_max_size = "8M"
upload_max_filesize = "2M"
max_execution_time = "30"

Maximum execution time XXX exceeded

最大実行時間 XXX秒 を経過したと出るエラーの対処

記述例(初期値)
max_execution_time = "30"

エラーログ取得

エラーログの設定には少し注意が必要です。

まず、デフォルトの PHP エラーログおよび表示設定は php.ini ファイルで定義されています。このファイルにはアクセスできる場合とできない場合があります。

アクセスできる場合、公開する PHP ページに対して希望の設定を指定してください。公開ページにはエラーメッセージを表示せず、エラーログに保存することを強く推奨します。

さらに、エラーログは外部からアクセスできない位置に保存しましょう。

推奨する php.ini エラー設定のサンプルは以下のとおりです。

wp-config.php の編集 > エラーログ取得の設定 (新しいタブで開く)”> WordPress Codex (日本語) > wp-config.php の編集 > エラーログ取得の設定
記述例(推奨値)
error_reporting = "4339"
display_errors = "Off"
display_startup_errors = "Off"
log_errors = "On"
error_log = "/home/example.com/logs/php_error.log"
log_errors_max_len = "1024"
ignore_repeated_errors = "On"
ignore_repeated_source = "Off"
html_errors = "Off"
Error Reporting 4339について

このカスタム値はサイトの動作に影響する問題のみをログに記録し、エラーではない通知等の事象は無視します。4339を2進数で表すと 1000011110011 です。各ビットの意味は 定義済み定数 を参照してください。例えば、左端の 1 は E_RECOVERABLE_ERROR をすべて記録します。その隣の 0 は E_STRICT を記録しません(動作はするものの不注意なコードが使用されると投げられます)。目的にあったカスタムエラー報告番号を作成し、4339 の代わりに設定してください。

WordPress Codex (日本語) > wp-config.php の編集 > エラーログ取得の設定

セッション設定

  • session.use_cookies: クッキーを使用する セッションIDの、 クライアント側への保存について設定。初期値は1で有効、0を設定で無効。
  • session.use_only_cookies: クライアント側へのセッションIDの保存に、クッキーのみを使用可能とする設定。 初期値は1で有効、0で無効。
  • session.name: クッキーに設定されるセッション名の設定
  • session.auto_start: リクエスト開始時にセッションを自動的に開始するかどうかを設定
  • session.cookie_lifetime: クッキーの有効期間を秒単位で設定
    0を設定するとブラウザをクローズするまでセッションが有効
  • session.cookie_path: クッキーを有効とするパスの設定
    ここで指定したパス以下へのアクセスにのみ、クッキーが有効
  • session.use_trans_sid: URLへのセッションIDの設定を自動で行うか否かの設定
記述例(初期値)
session.use_cookies	= "1"
session.use_only_cookies = "1"
session.name = "PHPSESSID"
session.auto_start = "0"
session.cookie_lifetime = "0"
session.cookie_path = "/"
session.use_trans_sid = "0"

注意

 URLに基づくセッション管理は、Cookieに基づくセッション管理と比べ てセキュリティリスクが大きくなります。例えば、ユーザーは、emailに より友人にアクティブなセッションIDを含むURLを送信する可能性があ り、また、ユーザーは自分のブックマークにセッションIDを含むURLを保 存し、常に同じセッションIDで使用するサイトにアクセスする可能性 があります。 PHP 7.1.0 以降では、https://php.net/ のような完全な URL パスが、透過的セッションID機能で扱われるようになります。 これより前のバージョンでは、相対 URL パスだけが対象でした。 リライト対象のホストは session.trans_sid_hosts で定義します。

PHPマニュアル

文字コード設定

  • mbstring.language: デフォルトの言語を設定
  • mbstring.internal_encoding: 内部文字エンコーディングを設定
  • mbstring.http_input: HTTP入力文字エンコーディング変換を設定
  • mbstring.http_output: HTTP出力文字エンコーディング変換を設定
  • mbstring.encoding_translation: 内部文字エンコーディングへの変換を有効にするかどうかを設定
  • mbstring.detect_order: 文字コード検出を設定
  • mbstring.substitute_character: 無効な文字を代替する文字を設定

※ mbstring.language は、mbstring で使用される言語設定(NLS)のデフォルト値となります。この設定はphp.ini の中で mbstring.language の後に mbstring.internal_encoding を置く必要があることに注意してください。

記述例(初期値)
mbstring.language = "neutral"
mbstring.internal_encoding = NULL
mbstring.http_input = "pass"
mbstring.http_output = "pass"
mbstring.encoding_translation = "0"
mbstring.detect_order = NULL
mbstring.substitute_character = NULL

IIS 6 + WordPress

mod_rewrite なしでのパーマリンクの設定

IIS 6 上で WordPress を実行している場合に、 PATHINFO パーマリンクを 用いる際の php.ini 設定

初期値
 cgi.fix_pathinfo = 1
 cgi.force_redirect = 1
記述例( cgi.force_redirectの値を変更する)
 cgi.fix_pathinfo = 1
 cgi.force_redirect = 0
php.ini - for WordPress.
php.ini – for WordPress.
Open post
Site kit.

Site Kit for WordPress by Google

Site Kit is now available as a developer preview

Site Kit is now available as a developer preview

https://sitekit.withgoogle.com/news/site-kit-developer-preview/

WEDNESDAY, JUNE 19, 2019

Posted by Mariya Moeva, Product Manager @ Google


Site Kitが開発者向けプレビューとして利用可能になりました

サイトキットをWordCamp US 2018で発表してから、初期のテスターになることに興味を示してくれた多くの方々にインタビューを行い、テスターの皆様の意見に基づいて多くの改善を行いました。 まずはそのテスターに参加して感想を共有するのに時間をかけてくれた皆さんに感謝します!

今回のリリースでは、それらのご意見に基づき、次の機能に重点を置いています。

  • 検索コンソールによるシームレスなサイト検証
  • Analytics、AdSense、Tag Manager、Optimizeのプロビジョニングと設定
  • Search Console、 Analytics、AdSenseからの簡単な集計およびページごとのレポート。収益化の目標達成プロセスを理解するのに役立ちます。
  • PageSpeed Insightsによる継続的なサイトパフォーマンスの監査と監視。
  • 接続している製品やダッシュボードに表示される製品全体から得られる洞察を手助けするための情報を表示します。

本日、Site Kitの開発者向けプレビューに、これらすべての機能が含まれるようになりました。 このプラグインを一般にwordpress.orgやすべてのユーザーが利用できるようにする前の、開発者向けプレビュー版による私たちの目標は、次のとおりです。

  • WordPressの開発者向けに、開発版のプラグインの提供。
  • Site Kitと他のプラグインとの互換性をテストする。
  • 実装に関するフィードバックと推奨事項を収集する。

現在のプラグイン設定フローの実装には、開発者のノウハウと、Google Cloud PlatformおよびOAuth検証プロセスに関する知識が必要です。 現在のセットアップエクスペリエンスは、WordPressユーザーが利用できるようにする予定の最終的なユーザーエクスペリエンスではありません。

Site Kitはこちらからダウンロードできます。また、プロジェクトのGitHubリポジトリも公開しました。

あなたはWordPressの開発者ですか? 機能性、相互運用性、その他の実装に関するフィードバックや推奨事項についてのフィードバックをお待ちしています。
GitHubのプラグインをチェックして問題を解決するか、またはWordCamp Europeにいる場合はGoogleブースに立ち寄ってください – 私たちは直接あなたとチャットすることを楽しみにしています。

Site kit.
Site kit for WordPress. by Google inc.
Open post
Editing wp-config.php

Editing wp-config.php

WordPressのアップグレード定数

WordPressのアップグレードの問題を修正するために、必要な以下の定数のうちいくつかを定義する必要がありました。

FILE PERMISSION ISSUES

We were unable to modify required files. Please ensure that /home/directory/uploads/ has the proper read-write permissions, or modify your wp-config.php file to contain your FTP login credentials as outlined here.

必要なファイルを変更できませんでした。 / home / directory / uploads /が適切な読み書き権限を持っていることを確認してください。また、wp-config.phpファイルを変更してここに記載されているFTPログイン認証情報を保存してください。

これらを定義する必要がある最も一般的な原因は次のとおりです。

  • シンボリックリンクを含む特別なインストール設定で動作するホスト。 パス関連の定数(FTP_BASE、FTP_CONTENT_DIR、およびFTP_PLUGIN_DIR)を定義する必要があります。 しばしば単にベースを定義すれば十分です。
  • 特定のFTPサーバーと互換性のないPHP FTP拡張機能が付属している特定のPHPインストール。 このまれな状況では、FS_METHODを “ftpsockets”に定義する必要があります。

次はWORDPRESSの更新に有効な定数です。

  • FS_METHODはファイルシステムのメソッドを強制します。 「direct」、「ssh2」、「ftpext」、または「ftpsockets」である必要があります。 一般に、更新の問題が発生している場合にのみこれを変更してください。 あなたがそれを変更して助けにならない場合は、それを元に戻したり削除したりしてください。 ほとんどの状況で、自動的に選択されたメソッドがそうでない場合、それを ‘ftpsockets’に設定すると動作します。 ここでの選択はセキュリティに深刻な影響を与えることに注意してください。 あなたがそれらに精通していない場合は、変更する前に助けを求める必要があります。
    • (優先候補) “direct”はPHP内から直接ファイル入出力要求を使用するように強制します。 デフォルトで選択されているオプションです。
    • (2番目の候補) “ssh2″は、SSH PHP Extensionがインストールされている場合はそれを強制的に使用することです
    • (3番目の候補) “ftpext”は、FTPアクセスのためのFTP PHP拡張の使用を強制することです。
    • (最後の手段) “ftpsockets”はFTPアクセス用のPHPソケットクラスを利用します。
  • FTP_BASEは、WordPressインストールの「ベース」(ABSPATH)フォルダへのフルパスです。
  • FTP_CONTENT_DIRは、WordPressインストールのwp-contentフォルダへのフルパスです。
  • FTP_PLUGIN_DIRは、WordPressインストールのプラグインフォルダへのフルパスです。
  • FTP_PUBKEYは、SSH公開鍵へのフルパスです。
  • FTP_PRIKEYは、SSH秘密鍵へのフルパスです。
  • FTP_USERは、ユーザーFTPまたはSSHユーザー名です。 これらはほとんど同じですが、実行する更新の種類に適したものを使用してください。
  • FTP_PASSは、FTP_USERに入力されたユーザー名のパスワードです。 SSH公開鍵認証を使用している場合、これは省略できます。
  • FTP_HOSTは、SSH / FTPサーバーのホスト名:ポートの組み合わせです。 デフォルトのFTPポートは21で、デフォルトのSSHポートは22です。これらは言及する必要はありません。
  • FTP_SSL基底のトランスポートでサポートされている場合はSSL接続の場合はTRUE(すべてのサーバーでは使用できません)。 これは、SSH SFTPではなく「セキュアFTP」用です。

define( ‘FS_METHOD’, ‘ftpext’ ); define( ‘FTP_BASE’, ‘/path/to/wordpress/’ ); define( ‘FTP_CONTENT_DIR’, ‘/path/to/wordpress/wp-content/’ ); define( ‘FTP_PLUGIN_DIR ‘, ‘/path/to/wordpress/wp-content/plugins/’ ); define( ‘FTP_PUBKEY’, ‘/home/username/.ssh/id_rsa.pub’ ); define( ‘FTP_PRIKEY’, ‘/home/username/.ssh/id_rsa’ ); define( ‘FTP_USER’, ‘username’ ); define( ‘FTP_PASS’, ‘password’ ); define( ‘FTP_HOST’, ‘ftp.example.org’ ); define( ‘FTP_SSL’, false );

WordPress.org Editing wp-config.php

プラグインやWP自体を更新しようとすると503の問題を避けるために、FTP_HOSTをlocalhostに設定する必要があります。

情報元

WordPress.org Editing wp-config.php

Editing wp-config.php
Editing wp-config.php – WordPress
Open post
WordPress5.0 リリース

WordPress 5.0 リリース

WORDPRESS 5.0 リリース

WordPress 5.0 がリリースされましたね。

ついに、WordPress 5.0 がリリースされました。

このサイトも WordPress で稼働していますが、毎度アップデートには気を使います。なので次回にも活かせるよう、アップデートの際に気を付けた方がいい点を、ここにまとめておきます。

※あくまでも個人的な感想です。

アップデートの際に気を付けた方がいい点 一覧

  1.  データベースのバックアップ
  2.  記事(投稿、固定)のバックアップ
  3.  プラグインの再構成
  4.  アップデート
  5.  アップデート後の稼働確認

1. データベースのバックアップ

データベースのバックアップは、使用しているサーバ毎に手順が異なる場合が多く大変です。できれば定期的にバックアップ計画を立てて実施していると、手順で迷わないですみます。

データベースのバックアップ手順

MySQL 5.6 リファレンスマニュアル

有名どころのレンタルサーバ

Xserver データベース手動バックアップ

2. 記事(投稿、固定)のバックアップ

WordPressの「ツール」メニューから、「エクスポート」を選んで実施します。

どれをバックアップしようか、などで迷われた場合には、「全てのコンテンツ」が初期状態で選択されていると思いますのでそのまま実行でいいと思います。

これにはすべての投稿、固定ページ、コメント、カスタムフィールド、カテゴリー、タグ、ナビゲーションメニュー、カスタム投稿が含まれます。

3. プラグインの再構成

メジャーバージョンアップの場合、既に稼働しているプラグインは再構成をお勧めします。

理由は簡単。新しいバージョンに、まだ対応していないプラグインが入ったままだと、サイトの表示や投稿時の挙動に問題が出る場合があるからです。

要は、一旦すべてのプラグインを停止し、アップデート後に必要なプラグインだけを再度稼働させていく。という具合。

沢山のプラグインを使用しているとこの作業が大変です。でも、頑張ってやりましょう。

4. アップデート

WordPressの更新メニューから、ボタンをポチっとするだけ。

5. アップデート後の稼働確認

ちゃんと動くかなとチェックするために、最低限以下の作業をやっておきましょう。

  1.  新規記事の投稿
    投稿ができない不具合が、ベータ版使用時に起きました。その時の原因としてはプラグインの競合だったのですが、本リリースでも同じことが発生しました。プラグインをひとつひとつ停止させながら確認をしてようやく使えるようになるまで、およそ半日がかかりました。なので必須です。
  2.  固定記事の投稿
    1 が問題なくできれば、こちらは同じphpファイルが実行されているので問題ないと思います。時間に余裕があればやってみてもいい程度。
  3.  メディアファイルのアップロード
    画像のアップロードも一番最初に確認しておきましょう。上がらなかったら笑えません。5.0では、今のところこの不具合報告は見当たらないみたいです。(サーバの設定をいじってしまったケース以外には、です。)
  4.  表示の確認
    デフォルトのテーマが、いくつか更新されるかと思います。変更すると元のテーマで使用していたウィジェットが外れることが多いですから、むやみに変更して眺める作業などを入れるととても手間がかかります。弊社のサイトで実施したアップデートは、そのせいで半日かかったと言っても過言ではありません。
  5.  新規でプラグインの追加
    ついでだからこのタイミングで新しいプラグインを入れてしまおう。この、「ついで」という思考は実施する人の精神を崩していく最高の手段です。なんでアップデートのついでなの?と思わずにはいられません。「おかしいんじゃないの、頭が。」と、書きかけの小説みたいにそう口に出してしまいそうでした。
WordPress5.0 リリース
WordPress5.0 リリース

Posts navigation

1 2
Scroll to top