Element Saving for Drafts, Revisions, Multi-Site need documentation for Plugin Development
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- ドキュメント
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
調査の方向性
issue のスプレッドシートと、そこに記載された保存シナリオから始めます。新規および既存のエントリ、下書き、自動保存、変換、複数サイトへの伝播、コンソール、キュー、マイグレーション、バリデーション失敗が含まれます。custom Elements と Field Types のチェックリストおよびフレームワークを、各シナリオを特定する例とともに文書化します。Plugin 開発者が、Live Scenario で Element が初めて保存されるタイミングを判断できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Since the move to make Drafts and Revisions Elements, it has been increasingly confusing for the number of scenarios custom Elements and Field Types need to support (measured by bug reports, time spent on client Yii modules dealing with Elements/Field Types, and curse words). In most cases, I think the solution is easier than I'm making it but the lack of documentation on how to even think about the problem makes it challenging to even know if you're considering all the possible scenarios for Drafts, Revisions, and Multi-Site.
Using X-Debug to troubleshoot is a challenge too as even if you are trying to just watch a single method involved in the save behavior the code ends up hitting that method countless times for things like auto-save, SCENARIO_ESSENTIALS, SCENARIO_LIVE, drafts, revisions, multi-site propagation, and more. Throw in a few variations on the Element settings or different Translation Methods and you have even more scenarios to make sense of as you try to figure out a simple question such as what is a reliable condition I can use to make sure I only trigger something when an Element is saved in the Live Scenario for the first time?, which should not be a complicated question to answer. It is. Or at least feels like it.
To illustrate my confusion here's a spreadsheet I made while trying to figure out how to save a custom field type with a separate data table:
https://share.barrelstrength.co/YEu1nwBK
The spreadsheet is trying to make sense of the number of different times Elements were saving in 6 different scenarios, which each save Elements multiple times.
- Create a New Entry
- Update Existing Entry
- Save as Draft
- Auto-save Draft
- Convert Draft to Entry
- Convert Revision to Entry
This doesn't even get into examples of Elements saving for Multi-site or scenarios where Element saves get triggered from the console, queue, migrations, or failed validation.
Ideal documentation would identify (and give us a checklist for) ALL of the different scenarios we need to plan for, give us a framework on how to think about the problem (at least for custom Elements and Field Types), and clearly show an example of how our code can identify each scenario.
- 主要言語
- JavaScript
- スター
- 43
- フォーク
- 160
- 平均マージ
- 3時間 57分
- マージ済み PR（30日）
- 3
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
craftcms/docs のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
Broken Link対応中かも @PerceiveWorld が 143 日前に担当しました。 オープンBroken Link
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 1/5 1〜3時間 初心者へのやさしさ 68/100
-
Broken LinkオープンBroken Link
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 76/100
521xueweihan/HelloGitHub#3939 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
needs-website-changes
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
[Bug] critique requires the detector on native targets, but audit.native.md says it does not applyオープンneeds triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
pbakaus/impeccable#1017 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信