Question 1

新しくスキャフォールドされた content-editor プラグインが、"contentAccess is required when any cms.content.* permission is granted" というエラーで lint に失敗するのはなぜですか？

Accepted Answer

スキャフォールドはプラグイン設定に `contentAccess` を書き込みますが、`definePlugin` の `DefinePluginConfig` 型には `contentAccess` キーがなく、マニフェストの組み立てでもそれが転送されないため、生成される `cms.content.*` パーミッションがそれを必要としているにもかかわらず、このキーは警告なく破棄されます。回避策: `instatic-plugin lint` またはビルドを実行する前に、組み立て済みのマニフェストに `contentAccess` を再注入します。例えば、リポジトリのソースを変更せずに、マニフェストを後処理して `contentAccess: [{ table: 'pages', modes: ['read', 'write'] }]` を追加する設定を持つ使い捨てのコピーを lint/ビルドします。恒久対策: `definePlugin.ts` の `DefinePluginConfig` に `contentAccess` を追加し、マニフェストの組み立て時にそれを転送することで、スキャフォールドが変更なしで lint を通過できるようにします。

Question 2

ビルドされたスタイルシートで、min-width のメディアクエリがより小さいブレイクポイントによって上書きされてしまうのはなぜですか？

Accepted Answer

ビルダーは min-width メディアクエリブロックを大きい値から順に出力するため（例: `@media (min-width: 1024px)` が `@media (min-width: 768px)` より先）、詳細度が等しい場合、ソース順序によって 1024px を超えるすべてのビューポートで狭い方の 768px ブロックが勝ち、モバイルファースト CSS が実質的に逆転します。`site_read_styles` でルールを読み戻すか、ビルド済みのスタイルシートを調べることで確認できます。保存されている CSS は記述した通りに見えますが、出力順序が逆になっています。修正が適用されるまでの回避策: 同じプロパティを等しい詳細度で複数の min-width ブレークポイントに分割しないでください。すべてのデスクトップ向けオーバーライドを単一の最小のデスクトップブレークポイントに統合するか、より広いブレークポイントのルールの詳細度を上げて、ソース順序が勝者を決めないようにしてください。恒久対応は、ビルド時に出力されるコンテキストをソートすることです: min-width は昇順、max-width は降順。

Question 3

content.entry.created プラグインイベントが公開フォームの送信時に発火しないのはなぜですか？また、どうすれば修正できますか？

Accepted Answer

パブリックフォームハンドラー（`server/forms/handler.ts`）は `createDataRow(...)` で行を作成しますが、管理画面の書き込みパス（`server/handlers/cms/data/tables.ts:344`、`rows.ts:190/220/239`）とは異なり、その後に emit ヘルパーを呼び出しません。修正オプション1（最小限の変更）：パブリックパスで行が作成された直後に `emitContentEntryCreated(db, row.id, { kind: 'system' })` を呼び出します。修正オプション2（フォーム固有のプラグインにより適した方法）：`{ formId, pageId, tableSlug, entryId }` を含む専用の `forms.submission.created` コアイベントを追加します。パッチが適用されるまでのプラグイン側の回避策：フロントエンドアセットで `window.fetch` をラップして送信レスポンスを監視し、さらに JavaScript が無効になっている訪問者へのフォールバックとして、スケジュール実行される reconcile スイープを実行します。

Question 4

プラグイン FrontendAsset の `attrs` が `type`、`rel`、`href` を削除してしまうのはなぜですか？また、それでも JSON-LD 構造化データ（`application/ld+json`）を出力するにはどうすればよいですか？

Accepted Answer

原因：`server/publish/frontendInjections.ts` 内の `formatAttrs` は `src`、`href`、`rel`、`type`、`defer`、`async`、`data-plugin-id` をグローバルに予約しているため、`attrs` 内のこれらのキーは警告なく削除されます。`type` を出力する唯一のコードパスは `kind: 'script'` にのみ存在する `strategy: 'module'` であり、インラインスクリプトや `kind: 'link'` にはこれらの属性への経路がありません。そのため、ドキュメントに記載されている `{ "kind": "link", "attrs": { "rel": "preconnect", "href": "..." } }` の例は、空の `` としてレンダリングされます。 JSON-LD の回避策：`attrs.type` に依存する代わりに、通常のインラインスクリプトを宣言し、実行時に JSON-LD ノードを挿入します： ```ts { kind: 'script-inline', placement: 'head-end', content: `var s=document.createElement('script');s.type='application/ld+json';s.textContent=JSON.stringify({"@context":"https://schema.org","@type":"Article"});document.head.appendChild(s);` } ``` Googlebot は JavaScript をレンダリングし、動的に挿入された構造化データを認識するため、これは静的タグと同様に検証されます。なお、インラインスクリプトアセットが存在する場合、ページの CSP はすでに `script-src 'self' 'unsafe-inline'` に緩和されているため、追加の CSP 変更は不要です。 `` については、マニフェスト内での回避策はありません。両方のキーが予約されており、`kind: 'link'` 分岐では何も復元されません。恒久的な修正（issue #392 で追跡中）は、kind ごとの属性予約です：`src` は `script` のみで予約し、`href`/`rel` は `link` のみで予約し、`type` は `strategy: 'module'` が設定されている場合のみ予約します。

Question 5

なぜJavaScriptで切り替えたCSSクラスが、公開後にスタイルシートから消えてしまうのですか？

Accepted Answer

公開ステップでは、オーサリングされたドキュメント内のどのノードにもアタッチされていないクラスを持つCSSルールがすべてプルーニングされます。これには、JSによるトグルで実行時にのみ存在するモディファイアクラス（例：`.mobilenav--open`）も含まれます。そのルールは公開前には `site_read_styles` で正しく読み取れますが、公開されたスタイルシートからは除去されるため、スクリプトが何をしても要素は基本状態（例：`display: none`）のままになります。回避策：(1) オーサリングされたドキュメント内にそのクラスへの参照を保持する — モディファイアクラスを少なくとも1つのノード（非表示のダミー要素でも可）にアタッチし、プルーナーがそれを使用中と判断して、ルールが公開後も残るようにします。(2) クラスのトグルの代わりに、スクリプトから実行時の状態をインラインスタイルとして適用する（例：`el.style.display = 'flex'`）— これは機能しますが、カスケードが失われます。その状態にはメディアクエリ、疑似状態、テーマ設定が適用されなくなります。診断するには、`site_read_styles` の出力と公開されたスタイルシートを差分比較します。前者に存在し後者に存在しないルールは、プルーニングされたものです。

Instatic

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト