Symfony Page Migration in PrestaShop 9.2: What to Recheck

A Back Office extension can survive a page migration visually and still fail functionally. Its field may appear but never save. Its grid column may show values while filters use the wrong query. Its navigation link may work for an administrator and fail for ordinary staff.

PrestaShop 9.2 continues the migration of administrative pages. Concrete upstream work includes Quick Access, the Countries list and email-body translations. These are specific page changes, not a new general module architecture. Quick Access migration, Countries list work, email-body translation migration.

For RC1 testing as of September 26, 2026, identify the active page path and the exact extension build. The review below concentrates on how an existing customization crosses the migrated page’s boundaries.

Record the active implementation using the feature-flag testing workflow; a customization can behave differently on legacy and migrated paths.

Map each customization to the contract it depends on

Start with the business behavior: a custom field on a country form, a link in Quick Access, an additional grid filter or a translation workflow. Then identify how the module implements it.

Possible dependencies include a form-builder hook, a form-handler hook, a grid definition, a grid query, a route name, a template block or a JavaScript selector. These dependencies have different failure modes. Treating them all as “a hook issue” makes diagnosis slower.

Read the module source and record where each dependency is declared. Search for the affected page’s identifiers, template names and selectors. Use the installed candidate source to verify the corresponding extension points; do not derive a hook name merely by capitalizing the page label.

A useful inventory looks like this:

This inventory should be small enough to review. If a customization no longer serves a business need, remove it through a deliberate maintenance change rather than carrying it forward automatically.

Follow a form value through the complete round trip

A form integration has several stages: initial data, form construction, validation, command or persistence handling, and the next read. An extension that touches only one stage can appear functional until a user reloads.

For a country-related customization, choose a valid fixture value and write down its intended storage and scope. Load the form, change the value, submit it and reopen the same entity. Then repeat with an invalid value and confirm that the previous valid value remains intact.

Check whether the module reads raw request parameters that belonged to the legacy page. A migrated form can use a different data structure. Avoid solving that mismatch by accepting arbitrary input without the form’s validation path.

If the module modifies a form builder, verify that it also integrates with the correct persistence stage. A field rendered by a generic hook does not automatically become part of the page’s domain operation. Conversely, a handler should not write a field that was not actually submitted in the current action.

Inspect partial edits and disabled fields. An absent value can mean “not part of this submission,” not “clear the stored value.” Document the distinction before changing the handler.

Test grids as queries, not just tables

A custom grid column often has a companion query modification. Verify the data query and any count query together. A join that multiplies rows can make pagination inconsistent even though the visible first page looks plausible.

Use fixtures that expose duplication: more than one related row, different shop associations and a record with no related value. Test the filter and sort order used by staff. Compare the expected record identifiers with the rendered result.

Do not add an unbounded join merely to make a column appear. Understand the migrated grid’s aliases and query structure in the candidate source. An alias copied from a legacy implementation may refer to a different table or no table at all.

Also inspect row actions after a filter is applied. The action should target the intended entity and preserve a sensible return context. A successful unfiltered action does not prove that filtered navigation behaves correctly.

For the Countries migration, a useful acceptance case combines list filtering, a permitted status operation and a refreshed result. The aim is to verify the module’s integration with the migrated list, not to reproduce the page’s entire core test suite.

Routes, shortcuts and employee rights form one boundary

Quick Access is an especially clear example of a small UI feature with several dependencies. A shortcut has a destination, display text and an employee who follows it. A route change can affect the destination; a permission change can affect whether the operation is allowed.

Generate administrative links through the appropriate supported routing mechanism in the installed version. Avoid preserving a hard-coded legacy URL solely because it still works in an administrator’s session.

Test a shortcut with an employee who has the permissions used in normal work. A SuperAdmin account can hide missing permission mappings. Test a denied operation as well, and confirm that a custom link does not create an authorization bypass.

If the module stores a destination, decide whether it represents a stable business route or a transient URL containing session-related information. The latter should not become a permanent shortcut through accidental copying.

When an old link is no longer valid, document the replacement contract in the module’s update notes. Do not make staff discover the change through unexplained navigation failures.

Translation pages need language-specific evidence

For an extension touching email-body translations, distinguish the employee interface language, the language being edited and the language of the generated customer message. They may differ.

Use two visibly different fixture translations. Save one, switch to the other and verify that the first remains unchanged. Then render the relevant test message into a mail sink through the supported workflow. A form reload proves persistence; the rendered message proves the intended consumer used it.

Check any module-specific template selection and fallback assumptions against the migrated page. A customization that searches for a particular legacy DOM element may stop activating even if the translation data remains correct.

Prefer supported form and template extension points over brittle page-wide script replacements. If JavaScript is necessary, attach it to a documented element or lifecycle and ensure repeated navigation does not register the same behavior twice.

Do not treat translated labels as evidence that translated content is stored correctly. Those are separate paths and deserve separate assertions.

Compare extension behavior on the relevant paths

Where the candidate exposes both legacy and migrated paths, run the same business case on each and record the active path. The feature-flag article explains how to manage that comparison; this article’s focus is the extension contract that changes.

A compatibility adapter should choose the appropriate integration without executing both writes. If a module subscribes to old and new events for transitional support, verify that one user action causes one intended persistence operation.

Keep failures narrow. “The module is incompatible with Symfony” is not a useful diagnosis. “The custom field is rendered through the new builder hook but the handler still reads the legacy request key” identifies a fixable boundary.

Preserve the exact candidate revision when reporting issues upstream. Branch documentation may move while the release archive remains unchanged. A source reference from a later branch cannot prove how an earlier package behaves.

Review a silent failure before adding fallback code

Consider a custom field that appears on the migrated page but returns to its old value after saving. First capture the submitted form data, then follow the supported handler path in a private test environment. Establish whether the value was rejected, ignored, transformed or saved under another scope.

Do not immediately add a second direct database write after the form submits. That may conceal the missing integration while bypassing validation, events or transactional behavior. Fix the boundary responsible for the lost value and add a round-trip test that would fail if it regressed.

Likewise, if a grid column is empty, distinguish an absent query value from a rendering mismatch. A template fallback that displays a default can make the page look repaired while hiding missing data. Use a fixture whose correct value differs visibly from the fallback.

These investigations keep compatibility adaptations small. They replace a specific broken assumption instead of layering another persistence or rendering path over it.

Ship an evidence-backed adaptation

Before publishing the adapted extension, test its actual distributable package on a clean candidate installation. Development files can conceal missing assets, stale service definitions or packaging exclusions.

The acceptance record should name affected pages, relevant flags, employee roles and the operations that passed. State any unsupported path explicitly. If a temporary workaround requires a legacy page, give it an owner and a retirement condition.

PrestaShop 9.2’s page migrations reward precise extension boundaries. Follow the data through forms, verify grids as queries and treat routes and permissions together. That produces a smaller and more reliable adaptation than rewriting a module around assumptions about the new interface.

For the underlying platform context, see our PrestaShop 9 module development guide and apply the version-specific checks above to the installation you are evaluating.

When selecting an extension, browse PrestaSuite’s PrestaShop 9 modules and check the documented version support and integration requirements against your own test results.