Repository navigation
2.6.1
Fixed: the listing JSON carries its columns
Six listings (inbound, outbound, logs, deliveries, rules, templates) returned a meta without
columns in the AJAX response. Statamic's <Listing> calls
setColumns(response.data.meta.columns) first; if the key is missing the columns are
undefined, and the next access throws, in the success path of the same promise chain. That was
caught by the generic .catch, which, lacking e.response, only toasted "Something went wrong".
The result was a red error toast with no content on HTTP 200, on a page that visibly worked: the
table's first fill comes from the Inertia props, where the columns had been all along. Only the
half nobody looks at was broken (F32/F34).
New test ListingJsonCarriesColumnsTest covers all six listings and checks the JSON path, not
the Inertia path.
Fixed: the nav section is a key, not a translation
Statamic localises its own sections itself. A pre-translated value is a different key and puts a
second, identical-looking section next to it; in the German CP two "Werkzeuge" sections stood one
below the other (part of F36). On top of that, webhook-manager::nav.section was defined in no
language file: __() returned the raw key, and that became the section name.
Fixed: code style on the test stand-in
tests/Fakes/insights-contracts.php had been failing pint --test since 2.4.0, which kept the
code style job red. Formatted; the declarations are unchanged, InsightsContractsMatchTest
compares signatures by reflection.