>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3611602. --> Reported by: [andileco](https://www.drupal.org/user/2054544) Related to !2 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Currently, the expectation is that users generated the book metadata fields and then map them to the appropriate endpoints in the ePub via the settings form. Let's give the option to have the site take these actions.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Add a <code>BookMetadataFieldInstaller</code> service holding the canonical definition of every metadata field, and expose it as a one-click action on the field mapping form plus a Drush command.</p> <p>The definitions are the single source of truth and match what <code>BookEpubAssembler</code>'s extraction expects: author is unlimited cardinality (all items are read), the layout/spread/orientation lists carry exactly the values the assembler passes through to the package document, and the viewport fields are integers. <code>description</code> is deliberately excluded &mdash; it maps to the standard <code>body</code> field, which node types already have (though we may update this for Drupal 12).</p> <p><code>install()</code> is idempotent: existing storages and instances are reported and left untouched, fields whose type module (image, options) is disabled are skipped with a warning, and a pre-existing storage of a mismatched type is treated as a conflict rather than reused.</p> <p>The canonical field names match the existing <code>config/install</code> mapping defaults, so sites that never use the action see no behavior change.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Review.</li> <li>Run the unit tests for the field definitions.</li> <li>Add kernel test coverage for <code>install()</code> &mdash; field creation, form display placement, and idempotency on re-run are not reachable from unit tests.</li> <li>Kernel test coverage for the form itself, which now depends on <code>BookHelperTrait</code> and therefore needs Book installed. Two Book 3.x incompatibilities reached testing precisely because no test installs Book: reading <code>book.settings:allowed_types</code> as a flat list of type IDs (it is a sequence of <code>{content_type, child_type}</code> mappings) and reading <code>$node-&gt;book</code> as a plain property (Book 3.x uses a bundle class with a protected property behind <code>getBook()</code>).</li> <li>Decide whether the assembler should honor Book 3.x's per-content-type <code>child_type</code>, which it currently ignores. Not a bug today; relevant if the recipe scaffolds an outline.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <ul> <li>ePub Book Field Mapping gains a "Set up metadata fields" section: a content type select (marking types allowed in Book outlines, defaulting to the first) and a "Create and map metadata fields" button.</li> <li>The action reports its outcome via the messenger, grouped into created, already present, skipped (field type module disabled), and conflicting (existing field of a different type).</li> <li>New Drush command <code>epub:setup-book-fields &lt;bundle&gt;</code> (alias <code>epub-sbf</code>) for scripted or demo-site builds.</li> </ul> <h3 id="summary-api-changes">API changes</h3> <p>New service <code>epub_generator_book.field_installer</code> (<code>BookMetadataFieldInstaller</code>) with a public static <code>getFieldDefinitions()</code>, plus <code>install(string $bundle)</code> and <code>applyMapping()</code>. <code>BookFieldMappingForm</code> gains a constructor and <code>create()</code>; it previously used the base class defaults, so any subclass overriding the constructor needs updating.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None to the module's own schema. The action creates optional field storages and instances on a site-chosen content type &mdash; <code>field_book_author</code>, <code>field_subtitle</code>, <code>field_isbn</code>, <code>field_book_publisher</code>, <code>field_copyright</code>, <code>field_edition</code>, <code>field_cover_image</code>, <code>field_epub_layout</code>, <code>field_viewport_width</code>, <code>field_viewport_height</code>, <code>field_epub_spread</code>, <code>field_epub_orientation</code> &mdash; and writes <code>field_mapping</code> in the existing <code>epub_generator_book.settings</code>. Nothing is created on install or uninstall; the action is opt-in and additive.</p>