WordPress Demo

ブロックエディターチャットの概要: 2020年10月21日水曜日

この投稿は、 2020年10月21日水曜日の14： 00UTCにSlackで開催された毎週のエディターチャットミーティングをまとめたものです。

Gutenberg 9.2およびWordPress 5.6ベータ1

@ jorgefilipecostaは、Gutenberb 9.2が数時間前にリリースされたことを発表しました: https://make.wordpress.org/core/2020/10/21/whats-new-in-gutenberg-21-october/

WordPress 5.6 Betaに関しては、予定どおり前日にリリースされました: https://wordpress.org/news/2020/10/wordpress-5-6-beta-1/

残念ながら、ウィジェットブロックは WordPress リリースの一部には含まれないことになりました。詳細については https://core.trac.wordpress.org/ticket/51506#comment:13 をご覧ください。

@ jorgefilipecostaは、次のWordPressリリースhttps://github.com/WordPress/gutenberg/projects/48の前に対処する必要がある問題を含む必須のボードがあると述べました。これらの問題のいくつかはまだ誰にも割り当てられていないので、貢献して次のWordPressリリースに影響を与えようとしている人にとっては良い機会です。

毎月の計画の更新

フルサイト編集–ナビゲーション– @ vindl

フルサイト編集–ナビゲーション– @ ntsekouras

  • クエリブロック（ https://github.com/WordPress/gutenberg/pull/26279 ）にスティッキーサポートを追加する必要があります。
  • クエリブロックの機能強化（結果メッセージを読み込んでいない、挿入にクエリを集中させる）

グローバルスタイル– @ jorgefilipecosta

  • クライアント側でプリセットクラスを生成するためのPRを提案しましたhttps://github.com/WordPress/gutenberg/pull/26224 。
  • グローバルスタイルの代わりにグローバルスタイルのブロックパネルのブロック設定を使用するPRを提案しましたhttps://github.com/WordPress/gutenberg/pull/26319 。
  • ダイナミックエディタ設定のパスを編集サイト画面のブロックエディタにマージしました。
  • ピクセル以外の他の単位を許可するようにフォントサイズプリセットの改善に取り組んでいます。

ウィジェット画面– @ zieladam

  • ＃feature-widgets-block-editorで再グループ化して、次のことを理解しています。このプロジェクトに興味のある人は誰でも参加できます。
  • ウィジェット関連の作業には、ウィジェットAPIエンドポイントや、WordPressでのバッチリクエストのサポートの導入など、いくつかのプラスの効果がありました（特に@timothybjacobsと@Jonny Harrisへの小道具）。

タスクの調整

@jasmussen

次のPRを提出しました。

@ annezazu

私たちのホストへの主要な小道具で主要なリリースのために、ブロックエディタリリースプロセスを出荷し@ jorgefilipecostaと@tellthemachines、13のウィジェットは、関連のGitHubの問題、およびFSEの最新を含む追加試験の多くを画面に報告。

@ ajlende

  • 新しい画像関連機能のウォーキング：ダブルトーンフィルターのサポート＃26361 。
  • メニューの一部は＃26115 （ @ ajlendeが現在取り組んでいる）によってブロックされています。
  • カバーブロックのサポートは＃25171によってブロックされています。

@ mapk

  • クエリブロック
    • プレースホルダー画面のご紹介。
    • ブロックから新しい投稿を作成します。
    • パターンをブロックに交換します。
  • ウィジェット画面
    • フィードバックを確認し、設計関連の問題を支援します。

@ youknowriad

  • 5.6のコアパッケージのアップデートとパッチを少し手伝ってみました。
  • 5.6で新しいAPIのドキュメントの作成を開始しました。
  • FSEに関連するいくつかのプロトタイピングを行う。
  • e2eテストで少し助けました（時間があればそこで助けてください、私たちは今のところ大きな停止ではありません）。

@ジエラダム

@ mcsf

  • 私たちのブロックで始まる、実装をサポート再考に多くを焦点を当て26111 、その後で詳細を議論し、 @youknowriadと@nosoloswに26192とフォローアップのPR
  • 一般的なPRレビュー

@ ntsekouras

  • クエリブロックにスティッキーサポートを追加（https://github.com/WordPress/gutenberg/pull/26279）–レビューが必要
  • クエリブロックの機能強化（結果メッセージを読み込んでいない、挿入にクエリを集中させる）
  • 古いブロックタイプまたは派生ブロックタイプを認識して、正規の形式に変換します（ https://github.com/WordPress/gutenberg/pull/26147 ）
  • 5.6バグ修正

@ jorgefilipecosta

  • クライアント側でプリセットクラスを生成するためのPRを提案しましたhttps://github.com/WordPress/gutenberg/pull/26224 。
  • グローバルスタイルの代わりにグローバルスタイルのブロックパネルのブロック設定を使用するPRを提案しましたhttps://github.com/WordPress/gutenberg/pull/26319 。
  • 動的エディター設定のパスをサイト編集画面のブロックエディターにマージしました。
  • ビデオテキストトラック機能を繰り返してマージしました。
  • 列とグループブロックtemplateLock制御機能を繰り返してマージしました。
  • 重要と見なされ、古いバージョンにバックポートされるタイムゾーンの問題を修正しました。フロントエンドで日付をフォーマットする方法を監査し、一般的な修正を提案しました（現在、時間HTML要素に「c」のような完全なタイムスタンプを持つフォーマットを使用すると問題が発生します）
  • いくつかのPRレビューをしました。

来週は、日時の進め方、関連するPRの確認などを行います。フォントサイズのプリセットを改善します（グローバルスタイルをフォントサイズのピクセル値のみに依存させることはお勧めできません）。ブロックインスタンスがグローバルスタイルセレクターと一致するかどうかの識別に関して何ができるかを確認してください（見出しなどの場合）。開いているPRの反復を継続し、いくつかのPRレビューを行います。

@ vcanales

  • momentjsからdate-fnsに移行するためのPR： https ： //github.com/WordPress/gutenberg/pull/25782 —レビューが必要です。すべての入力を歓迎します—ほとんどのテストに合格し、 @ vcanalesは現在これをテストして修正しようとしています。ライブラリが交換された、スケジュール後の日付の不一致に関連する問題。

@frankklein

2つのFSEバグ修正PRを開きました：

  • テンプレートパーツ生成の修正（つまり、テキストドメインを使用しない）：https：//github.com/WordPress/gutenberg/pull/26275はすでに確認されており、マージの準備ができています。
  • テーマのエクスポートを修正します（これらは現時点ではまったく機能しません）https://github.com/WordPress/gutenberg/pull/26268

@ nosolosw

彼の焦点は最近、5.6に着陸するために重要なさまざまなことに焦点を当てています。今週、FSE / GSの作業に戻る予定です。

@ bph

plugin.zipのデイリービルドをテストします（現在はGutenberg Timesで公開されています）。

@ karmatosed

現在、オプションの反復は5.6であり、次のリリースの反復を超えています。また、5.6を羊飼いにし、途中でいくつかの小さな断片を拾います。

@ itsjonq

  • デザインツールのサポートに重点を置いて、G2コンポーネントの調査を続けました（タイポグラフィから開始）
  • CSS検証やよりスマートなユニット解析（ px 、 vmax ）などのvmax 、カスタム値を処理するグーテンベルクの機能を拡張します（グローバルスタイルの進化にvmax ）
  • ズームセッションを介したあらゆる種類（G2、デザイン、UI、開発）の継続的な知識共有

オープンフロア

WordPressトランクエディターをより頻繁に更新する

@クロリスは言った：

トランク内の継続的なグーテンベルクリリース。現在、グーテンベルクプラグインへの変更は、通常、メジャーリリースのベータ1がリリースされる数日前にコアにマージされます。

その期間には、数か月が経過する可能性があり、プラグインには複数のリリースがありました（5.5を例にとると、Gutenbergの9つのリリースがバンドルされ、WP 5.4と同じラングが5.3になりました） 。これは多くの変更であり、すべてが明らかではありませんが、ベータの直前にすべてが着陸すると、純粋にコアで相互作用をテストし、実験的なプラグインのものと実際にコアで計画されているものを分離することが難しくなります。 2つのプロジェクト間の継続的インテグレーションを確認するために、これに関する議論を開始するために提案された実行タイムラインの概要を説明しました。-プラグインには新しいバージョンのリリースがあります。

–変更はプラグインに3週間有効です

–これらの3週間後、変更はトランクにマージされます

–トランク/コアに関するフィードバックは、プラグインの他のすべてのベルやホイッスルなしでそれらがどのように機能するかに関する機能について提供できます。プラグインを使用している人からプラグインのフィードバックを得るのに十分な時間を与えるため、3週間の任意の数を選択しましたテストのために、変更を「長すぎる」ためにコアから遠ざけず、グーテンベルクの雑用を任されたコミッショナーに過度の余分な作業をもたらさない（理想的には、2週間のターンオーバーが欲しいと思うので）プラグインのフィードバックには十分な時間がありますが、これが私たちがここで議論することです🙂）

@ youknowriadによると、公式の計画は、リリースごとにトランクと実際にマージすることです。唯一の障害は、そうするためのリソースがないことです。また、自動化できる部分はすでに自動化されていると付け加えました。パッケージの更新とコアに対するe2eテストです。残り（PHPの変更）は自動化できません。

複数行のコードが回帰をブロックする

@ getdaveは言った：

Codeブロック（および場合によってはClassicブロック）の最新のGutenbergリリースには、フォーマットが完全に壊れているというリグレッションがあります。

https://github.com/WordPress/gutenberg/issues/26301

これは、PlainTextからRichTextコンポーネントに変更することで導入されたようです。すべてのリンクブレークがbrタグとして返されるようになり、すべてが1行でレンダリングされます。

たとえば、私の個人的なWebサイトでは、すべてのコードスニペットが1つのフォーマットされていない長い行に表示されますが、これは（まったく）優れていません。

これを修正するのがどれほど複雑かはわかりませんが、優先度の高い（っぽい）ものとして対処する必要がありますか？

@ jorgefilipecostaは、 @ ellatrixはすでにこの問題を認識しており、解決策を検討していると考えていると述べました。

PRごとに問題が発生する必要がありますか？

@ paaljoachim言いました：

今日、PRを作成し、誰かにレビューしてもらい、デザインやアクセシビリティの誰かがPRを通過しなくても、それをマージするのはかなり簡単なようです。出てくる質問…すべてのPRに関連する問題があるべきですか？

問題の可視性が高まり、誰かが正しいラベルを追加して見やすくなると私は信じています。

@ jorgefilipecostaと@ youknowriad PRごとに問題を強制するという考えに対して、積荷目録に自分の考え。

最大の問題は、当然の注目を集めていないラベルのないPRを持っていることであるように思われ、私たち全員がPRが適切にラベル付けされていることを確認する必要があります。 PRを開いている場合は、すべてにラベルが含まれているかどうかを確認してください。

＃ block-editor 、 ＃ chats 、 ＃ core-editor 、 ＃ core-editor-summary 、 ＃ gutenberg 、 ＃ meeting-notes

原文

投稿日

カテゴリー:

, , , , , , ,

投稿者:

admin

タグ:

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です