Skip to content

feat: add url and name to alp admin overview#151

Open
ahuininga-orisha wants to merge 12 commits into
developfrom
feat/add-url-and-name-overview
Open

feat: add url and name to alp admin overview#151
ahuininga-orisha wants to merge 12 commits into
developfrom
feat/add-url-and-name-overview

Conversation

@ahuininga-orisha

Copy link
Copy Markdown
Collaborator

Summary

  • Adds a Store URLs column to the landing page admin grid, showing each store's URL path prefixed with the store name (e.g. Global: my-landing-page). Store ID 0 is labelled Global.
  • Replaces the Name column with store-scoped names from emico_attributelanding_page_store, rendered with the same store_id prefix as the URL column.
  • Both columns are searchable via a HAVING GROUP_CONCAT(...) LIKE ? clause, avoiding issues with aggregate expressions in WHERE.
  • Fixes a pre-existing bug where the grid showed one row per store per page (due to an inner join in Page\Collection); the grid now always shows one row per landing page with all store values grouped.
  • Introduces Model\ResourceModel\Page\Grid\Collection, a dedicated grid collection extending SearchResult, keeping grid-specific query logic isolated from the general-purpose Page\Collection used on the frontend.

How to test

Scenario 1 — Store URLs and Names are visible

  1. Go to Content > Landing Pages in the admin.
  2. Confirm the grid shows a Name column and a Store URLs column.
  3. For a landing page configured on multiple stores, confirm both columns show one line per store prefixed with the store name (e.g. Global: my-url, Default Store View: my-url).
  4. For a landing page with only a global (store_id = 0) row, confirm the prefix reads Global.

Scenario 2 — One row per landing page

  1. Create a landing page and save it for at least two store views.
  2. Open the landing page grid.
  3. Confirm the page appears once in the grid, not once per store.

Scenario 3 — Searching on Store URLs

  1. In the Store URLs filter field at the top of the grid, type part of a known URL path.
  2. Confirm only matching landing pages are returned.
  3. Confirm no SQL error occurs and pagination works correctly.

Scenario 4 — Searching on Name

  1. In the Name filter field, type part of a known landing page name.
  2. Confirm only matching landing pages are returned.
  3. Confirm no SQL error occurs and pagination works correctly.

Scenario 5 — Frontend is unaffected

  1. Visit a landing page URL on the storefront (e.g. https://magento2.test/default/women/tops-women2/).
  2. Confirm the page loads correctly with filters applied as before.
  3. Confirm no regression in URL matching or filter behaviour.

ahuininga-orisha and others added 11 commits May 13, 2026 10:11
…d collection

parent::getSelectCountSql() strips GROUP BY and clones the SELECT without
re-running _beforeLoad, so the store join is absent in the count query.
HAVING clauses referencing GROUP_CONCAT aggregates then cause a fatal SQL
error (SQLSTATE[42S22]: unknown column) when any name/store_urls filter
is active, breaking admin grid pagination entirely.

Fix: override getSelectCountSql() to re-add the join and GROUP BY when a
HAVING clause is present, then wrap in a subquery so MySQL returns a single
COUNT(*) instead of one row per group.
Implements getExtensionAttributes/setExtensionAttributes as required
by Magento ExtensibleDataInterface contract. Enables third-party
modules to attach extension attributes to LandingPage via di.xml.

test: add LandingPageTest covering null default and round-trip
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.

1 participant