I deliberately keep the legacy approach — ModuleAdminController + HelperForm + getContent() — when I need to stay cross-compatible between PrestaShop 8 and PrestaShop 9 without rewriting the whole module as Symfony controllers.

PrestaShop 9 still supports many legacy patterns, but it is stricter about a few contracts: URL generation, translations, and inherited method signatures.

Here are three common traps, with the fix for each.

Trap 1 — getAdminLink(): put legacy AJAX params in the 4th argument

In PrestaShop 1.7/8, many modules used to build AJAX URLs by hand and the dispatcher was often forgiving.

In PrestaShop 9, URL generation is less forgiving, especially around legacy/Symfony route conversion. Manually appending &ajax=1&action=... can easily produce broken or non-routed URLs.

// ❌ Fragile on PS9
\(url = \)this->context->link->getAdminLink('AdminMyModuleAjax')
     . '&ajax=1&action=MyRequest';

The safer cross-compatible way is to pass ajax, action, and your own AJAX parameters through the 4th argument of getAdminLink():

// ✅ ajax + action in the 4th argument ($params)
\(url = \)this->context->link->getAdminLink(
    'AdminMyModuleAjax',
    true,   // with token
    [],     // Symfony route params, 3rd argument
    ['ajax' => 1, 'action' => 'MyRequest'] // legacy query params, 4th argument
);

The signature to keep in mind:

getAdminLink(\(controller, \)withToken = true, \(sfRouteParams = [], \)params = [])

The 3rd argument is for Symfony route parameters. The 4th argument is for legacy query parameters.

So anything AJAX-related — ajax, action, id_item, or your own parameters — belongs in the 4th argument. The security token does not go there: it is generated automatically by the 2nd argument (true / $withToken).

Trap 2 — Don't rely on $this->l() inside module controllers

Inside a ModuleAdminController, avoid relying on:

// ❌ Not reliable in PS9 module controllers
\(msg = \)this->l('Saved successfully');

Use the module instance instead.

For legacy cross-compatibility, this remains a practical option:

// ✅ Legacy-compatible translation through the module instance
\(msg = \)this->module->l('Saved successfully', 'mymodule');

If you are already working with PrestaShop's newer translation system, the cleaner PS9-friendly approach is:

// ✅ Newer translation system
\(msg = \)this->module->trans(
    'Saved successfully',
    [],
    'Modules.Mymodule.Admin'
);

In short:

• for legacy/cross-compatible controllers: use $this->module->l(...);

• for modern PS9-oriented code: prefer $this->module->trans(...).

The important point is: in a module controller, translate through the module instance, not through $this->l().

Trap 3 — ajaxRender(): don't override it with an incompatible signature

This is a classic blank-page culprit.

Some older modules used to redefine ajaxRender() with a single argument, or use it as a custom JSON helper.

But in PrestaShop 9, ControllerCore::ajaxRender() has its own signature:

protected function ajaxRender(\(value = null, \)controller = null, $method = null)

If your controller declares an incompatible method like this:

// ❌ Incompatible override
public function ajaxRender($data)
{
    echo json_encode($data);
    exit;
}

PHP 8 + PrestaShop 9 can throw a fatal compatibility error such as:

Declaration must be compatible with ControllerCore::ajaxRender(...)

In production, this can easily look like a blank page or a silent AJAX failure.

The simplest fix: do not override ajaxRender(). Create your own dedicated JSON response method instead:

// ✅ Dedicated JSON helper, no signature clash
protected function renderAjaxJson(array $data): void
{
    header('Content-Type: application/json; charset=utf-8');
    echo json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
    exit;
}

Putting it together

Controller side:

class AdminMyModuleAjaxController extends ModuleAdminController
{
    public function ajaxProcessMyRequest(): void
    {
        $id = (int) Tools::getValue('id_item');

        // ... business logic ...

        $this->renderAjaxJson([
            'success' => true,
            'message' => $this->module->l('Update done', 'mymodule'),
        ]);
    }

    protected function renderAjaxJson(array $data): void
    {
        header('Content-Type: application/json; charset=utf-8');
        echo json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
        exit;
    }
}

And the AJAX URL:

\(ajaxUrl = \)this->context->link->getAdminLink(
    'AdminMyModuleAjax',
    true,
    [],
    [
        'ajax' => 1,
        'action' => 'MyRequest',
    ]
);

If you need to pass an additional parameter:

\(ajaxUrl = \)this->context->link->getAdminLink(
    'AdminMyModuleAjax',
    true,
    [],
    [
        'ajax' => 1,
        'action' => 'MyRequest',
        'id_item' => (int) $idItem,
    ]
);

Takeaway

PrestaShop 9 did not completely remove the legacy ModuleAdminController approach, which is still useful when you need one module to remain compatible across multiple PrestaShop versions.

But PS9 is stricter about the contracts around legacy controllers:

• generate admin AJAX URLs properly;

• pass legacy AJAX parameters in the 4th argument of getAdminLink();

• translate through the module instance;

• do not override inherited methods with incompatible signatures.

For new back-office pages, Symfony controllers remain the recommended long-term direction. But if you maintain existing legacy modules, these small fixes can keep your ModuleAdminController-based code stable across PrestaShop 8 and PrestaShop 9.

That is the approach I keep across DataFirefly modules when compatibility matters: modernize where it makes sense, but avoid unnecessary rewrites when a clean legacy controller still does the job.

💡 Hit a fourth AJAX trap on PS9? Drop it in the comments — I'll add it to the list.