Skip to content

[6.x] Inertia section edit#18491

Draft
brianjhanson wants to merge 52 commits into6.xfrom
feature/inertia-section-single
Draft

[6.x] Inertia section edit#18491
brianjhanson wants to merge 52 commits into6.xfrom
feature/inertia-section-single

Conversation

@brianjhanson
Copy link
Contributor

@brianjhanson brianjhanson commented Feb 27, 2026

To-Do

  • Implement autocomplete into the template field of the site settings field
  • When selecting an entry type you should be able to navigate via keyboard (probably a separate PR)
  • Handle editable tables responsively (separate PR)
  • Restore helper text to column headers

The main focus here is porting the sections edit page over to Inertia but maybe the real code was all the things we had to change along the way.

Editable Tables

The biggest of those is figuring out how to manage editable tables. In the end, I ended up creating our own version of TanStack Table's columnHelper which will eventually have dedicated methods for each of the input types the current editableTable.twig supports. At the moment we only have the ones that were needed for this port (text, lightswitch and checkbox).

Vue Wrappers

Another fairly large shift in this PR is that we've added a script that will generate Vue components from the lit web components. I wanted to avoid this, but annoyingly Vue and Lion don't agree on some prop values. The Vue wrappers smooth this out so you can just v-model the inputs as you would expect. These components are only to handle the v-model binding which is why we still have a Select component in the main resources/js/components folder. The Select component takes in an options prop and handles normalizing those before rendering the appropriate markup.

Not ideal, but at least these layers keep things flexible.

It may end up that using Lion's form components isn't really worth it if we're living in a purely Vue world but for now, I still like the flexibility it allows us. That way if we have some views that we can't fully convert to Vue for some reason, we can ensure some visual consistency by using the @craftcms/cp components.

Copilot's summary

Including this because it did a pretty good job of summing things up.

Component Enhancements and Features:

  • craft-action-item now supports checkable items with new checked, active, and type properties, updated rendering logic, and corresponding style adjustments to allow for checkbox-like menu items. [1] [2] [3] [4]
  • craft-chip gains an icon property for easy prefix icon rendering, improved slot handling, and minor style adjustments for layout consistency. [1] [2] [3] [4] [5]
  • craft-button introduces a new dashed appearance, with corresponding styles and property updates for more visual variety. [1] [2]
  • craft-input and craft-select components now support additional sizing and alignment options, including small, medium, and large sizes, a center property, and a corrected use of maxlength instead of size for input length. [1] [2] [3] [4]
  • craft-switch-button and craft-switch have updated sizing logic for better consistency across controls, and a new Storybook story is added for craft-switch with various usage examples. [1] [2] [3]

Build Process and Exports:

  • The build process now includes a step to generate Vue wrappers, with a new script and npm command (generate:vue-wrappers), and updates to package.json exports to better support consumption from different environments and frameworks. [1] [2] [3] [4] [5]

Storybook and Documentation:

  • New stories and improved story rendering for craft-action-item and craft-switch components, demonstrating new features and usage patterns. [1] [2] [3]

- Roughed in some pagination
- Add ability to change number of results per page

# Conflicts:
#	src/Http/Controllers/Settings/SectionsController.php
The controller tests should be responsible for making sure the data is
sent correctly. These are just smoke tests
I think the odds of the section being deleted between the time the
request was validated and when we try to delete it is pretty low
SQLite is case sensitive by default which meant the tests were failing because the factory would create lower case sections but our test had uppercase. This isn't the most ideal fix, but it works for the moment.
@brianjhanson brianjhanson changed the title Feature/inertia section single [6.x] Inertia section edit Feb 27, 2026
@brianjhanson brianjhanson requested a review from Copilot February 27, 2026 19:15
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR migrates the Settings → Sections index/create/edit flows to Inertia pages, modernizes shared table/UI infrastructure, and aligns frontend imports with the packaged @craftcms/cp dist/type entrypoints.

Changes:

  • Convert Sections settings pages to Inertia (SettingsSectionsIndexPage, SettingsSectionsEditPage) and update controller/tests accordingly.
  • Enhance CpScreenResponse to support rendering Inertia screens, and expand AdminTable for pagination/sorting/metadata.
  • Add shared Vue composables/components (editable table, reorderable rows, input generator) and update CP package exports + generated Vue wrapper tooling.

Reviewed changes

Copilot reviewed 81 out of 85 changed files in this pull request and generated 9 comments.

Show a summary per file
File Description
tests/Feature/Integration/PagesTest.php Moves Sections page coverage to a dedicated Inertia page assertion.
tests/Feature/Http/Controllers/Settings/SectionsControllerTest.php Updates expectations for Inertia + adds sorting and delete assertions.
src/Section/Sections.php Clears query ordering before applying table sorting.
src/Http/Responses/CpScreenResponse.php Adds inertiaPage() and Inertia rendering path in toResponse().
src/Http/Controllers/Settings/SectionsController.php Implements Inertia-based Sections index/create/edit; adjusts flash responses.
resources/js/pages/SettingsSectionsIndexPage.vue New Inertia index page using TanStack table + server-side sorting/pagination.
resources/js/pages/SettingsSectionsEditPage.vue New Inertia edit page with form + per-site settings and preview targets.
resources/js/components/AdminTable/AdminTable.vue Adds pagination footer, sorting UI, meta-driven classes/tags, and search slot.
resources/js/composables/useEditableTable.ts New helper for inline-editable TanStack tables.
resources/js/components/ActionMenu.vue New action menu wrapper for craft-action-menu/craft-action-item.
resources/js/components/sites/SiteFields.vue Switches to useInputGenerator for handle/baseUrl generation.
packages/craftcms-cp/src/components/input/* Updates craft-input sizing/attrs handling.
packages/craftcms-cp/scripts/* + package.json Adds Vue wrapper generation script + export map changes.
Comments suppressed due to low confidence (1)

packages/craftcms-cp/src/components/input/input.ts:25

  • craft-input’s size attribute appears to have been repurposed from an HTML-style character width (used throughout the app as size="3", size="7", etc.) to a 'small' | 'medium' | 'large' enum. This is likely a breaking change: existing templates that pass numeric size will no longer size the underlying <input> as intended. Consider keeping a numeric size API (and using a different prop name for visual sizing, e.g. uiSize/variant), or updating all call sites and docs consistently.
  @property({type: Number, reflect: true}) maxlength?: string;
  @property({type: String, reflect: true}) size?: 'small' | 'medium' | 'large' =
    'medium';
  @property({reflect: true, type: Boolean}) small = false;
  @property({reflect: true, type: Boolean}) center = false;

  override connectedCallback() {
    super.connectedCallback();

    if (this._inputNode && this.maxlength) {
      const sizeInt = parseInt(this.maxlength, 10);
      if (sizeInt > 0) {
        this._inputNode.size = sizeInt;
      }
    }

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +44 to +69
$page = (int) $request->input('page', 1);
$limit = (int) $request->input('per_page', 50);
$searchTerm = $request->input('search');

$sort = $request->input('sort', [
['field' => 'name', 'direction' => 'asc'],
]);

$orderBy = match (Arr::get($sort, '0.field')) {
'handle' => 'handle',
'type' => 'type',
default => 'name',
};

$sortDir = match (Arr::get($sort, '0.direction')) {
'desc' => SORT_DESC,
default => SORT_ASC,
};

[$pagination, $tableData] = $sections->getSectionTableData(
page: $page,
limit: $limit,
searchTerm: $searchTerm,
orderBy: $orderBy,
sortDir: $sortDir,
);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't feel great. Ideally we'd use Laravel's paginate stuff but I'm not sure we're quite there yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants