Installation on 9.1

[Kevapo]

Hi

I'm on docker, fresh prestashop 9.1 install when trying to 8.3.0 of everblock

[2026-04-13T11:11:47.357348+02:00] request.CRITICAL: Uncaught PHP Exception Symfony\Component\ErrorHandler\Error\UndefinedMethodError: "Attempted to call an undefined method named "link_rewrite" of class "Tools"." at everblock.php line 6117 {"exception":"[object] (Symfony\Component\ErrorHandler\Error\UndefinedMethodError(code: 0): Attempted to call an undefined method named "link_rewrite" of class "Tools". at /var/www/html/modules/everblock/everblock.php:6117)"} []

can't even click on anything on the admin pages.

[pawelkierklo]

[pawelkierklo]

delete /modules/everblock or change in code link_rewrite to str2url

[CySSoO]

Hello,
The module has been updated with a complete migration to Symfony.
Could you please try it on a pre-production instance and let me know if the issue persists?

Best regards

[Progerance]

Hi,

I'm running Everblock on PrestaShop 9.1 and encountered three breaking errors. I've identified the root causes and the fixes needed. Here's a summary:

---

1. Tools::link_rewrite() removed in PS9

Error: UndefinedMethodError: Attempted to call an undefined method named "link_rewrite" of class "Tools" at everblock.php line 4700.

Cause: Tools::link_rewrite() was removed in PrestaShop 9. The equivalent method is Tools::str2url().

Fix: Replace all Tools::link_rewrite(...) calls with Tools::str2url(...).

Affected files (10 occurrences):

• everblock.php — lines 2154, 2170, 4700, 4703
• controllers/front/faqs.php — lines 245, 268, 270
• src/Entity/Page.php — line 280
• src/Handler/SaveAdminItemHandler.php — line 135
• src/Service/EverblockTools.php — lines 6395, 6460

---

2. Symfony\Component\Translation\TranslatorInterface replaced by Contracts interface

Error: TypeError: EverblockAdminController::__construct(): Argument #6 ($translator) must be of type Symfony\Component\Translation\TranslatorInterface, PrestaShopBundle\Translation\DataCollectorTranslator given

Cause: PrestaShop 9 uses Symfony 6+, where Symfony\Component\Translation\TranslatorInterface has been replaced by Symfony\Contracts\Translation\TranslatorInterface.

Fix: In src/Controller/Admin/EverblockAdminController.php, line 34, change:

// Before
use Symfony\Component\Translation\TranslatorInterface;

// After
use Symfony\Contracts\Translation\TranslatorInterface;

---

3. CQRS handlers: Tactician replaced by Symfony Messenger

Error: NoHandlerForMessageException: No handler for message "Everblock\Tools\Query\ListAdminItemsQuery"

Cause: PrestaShop 9 replaced the Tactician command bus with Symfony Messenger. The module's handlers are registered with the tactician.handler tag, which is no longer recognized.

Fix — two parts:

a) Update config/services.yml — replace Tactician tags with Messenger tags:

# Before
- { name: tactician.handler, command: Everblock\Tools\Query\ListAdminItemsQuery }

# After
- { name: messenger.message_handler, handles: Everblock\Tools\Query\ListAdminItemsQuery }

This applies to all 5 handler service definitions (ListAdminItemsHandler, GetAdminItemHandler, SaveAdminItemHandler, DeleteAdminItemHandler, ClearEverblockCacheHandler).

b) Rename handle() to __invoke() in all handler classes:

Symfony Messenger expects handlers to be invocable (i.e. use __invoke() instead of handle()).

Affected files:

• src/Handler/ListAdminItemsHandler.php
• src/Handler/GetAdminItemHandler.php
• src/Handler/SaveAdminItemHandler.php
• src/Handler/DeleteAdminItemHandler.php
• src/Handler/ClearEverblockCacheHandler.php

[Luifer-dnk]

Additionally, to add content, GetAdminItemHandler.php needs to be corrected: The handler needs to implement MessageHandlerInterface.

`<?php

declare(strict_types=1);

namespace Everblock\Tools\Handler;

use Everblock\Tools\Entity\Block;
use Everblock\Tools\Entity\Faq;
use Everblock\Tools\Entity\Page;
use Everblock\Tools\Entity\Shortcode;
use Everblock\Tools\Query\GetAdminItemQuery;
use Everblock\Tools\Repository\BlockRepository;
use Everblock\Tools\Repository\FaqRepository;
use Everblock\Tools\Repository\HookRepository;
use Everblock\Tools\Repository\PageRepository;
use Everblock\Tools\Repository\ShortcodeRepository;
use Symfony\Component\Messenger\Handler\MessageHandlerInterface;

final class GetAdminItemHandler implements MessageHandlerInterface
{
public function __construct(
private readonly BlockRepository $blockRepository,
private readonly ShortcodeRepository $shortcodeRepository,
private readonly FaqRepository $faqRepository,
private readonly PageRepository $pageRepository,
private readonly HookRepository $hookRepository
) {
}

...
}`

[CySSoO]

Hi, and thanks for the detailed report — the root-cause analysis is spot on, and it made verification quick.

Good news: all three issues are already fixed. Please upgrade to the current release, V9.0.6: https://github.com/TeamEver/everblock/releases/tag/V9.0.6

Point by point, for the record:

1. Tools::link_rewrite() removed in PS9 — fixed. Rather than replacing each call site individually, the module now routes everything through a single helper:

// src/Service/EverblockTools.php
public static function linkRewrite(string $value): string
{
    if (method_exists(Tools::class, 'str2url')) {
        return (string) Tools::str2url($value);
    }

    return (string) Tools::link_rewrite($value);
}

All the occurrences you listed now call EverblockTools::linkRewrite() — everblock.php (2484, 2500, 5064, 5067), controllers/front/faqs.php (270, 293, 295), src/Entity/Page.php:294, src/Handler/SaveAdminItemHandler.php:139. No direct Tools::link_rewrite() call remains outside that guarded fallback.

2. TranslatorInterface — fixed. src/Controller/Admin/EverblockAdminController.php and src/Checkout/EverblockCheckoutStep.php both import Symfony\Contracts\Translation\TranslatorInterface. This is also safe on PS8: in 8.2 as in 9.1, PrestaShopBundle\Translation\TranslatorInterface extends the Contracts interface, so the type hint resolves on both.

3. CQRS handlers: Tactician → Symfony Messenger — fixed, using a dual-registration approach so PS8 keeps working:

config/services.yml carries both tags on each of the 5 handlers:

Everblock\Tools\Handler\ListAdminItemsHandler:
    tags:
        - { name: tactician.handler, command: Everblock\Tools\Query\ListAdminItemsQuery }
        - { name: messenger.message_handler, handles: Everblock\Tools\Query\ListAdminItemsQuery }

PS 8.2 does not depend on symfony/messenger, so the Messenger tag is simply ignored there; PS9 ignores the Tactician tag for the same reason. And each handler exposes __invoke() for Messenger plus a handle() that delegates to it, so the Tactician handler locator still finds a method to call.

Verified against the cores: on PS9, PrestaShop\PrestaShop\Core\CommandBus\CommandBusInterface is implemented by PrestaShopBundle\CommandBus\MessengerCommandBus, which uses HandleTrait on messenger.bus.default (the only bus declared in app/config/messenger.yml). So $commandBus->handle($query) correctly returns the handler's return value, and no bus: option is needed on the tag.

---

One caveat on your last suggestion, though: please don't add implements MessageHandlerInterface — it would break PS9 rather than fix it.

The module's config/services.yml sets autoconfigure: true in _defaults. Implementing that interface would make Symfony add a second messenger.message_handler tag on top of the explicit one. MessengerPass::registerHandlers() does not deduplicate (it appends unconditionally to $handlersByBusAndMessage[$bus][$message][$priority][]), so the handler would be registered twice for the same message on the same bus, get invoked twice, and HandleTrait would throw "Message of type … was handled multiple times". The explicit tag alone is sufficient. As a bonus, MessageHandlerInterface has been deprecated since Symfony 6.2 and removed in Symfony 7, so avoiding it also keeps the door open for future PrestaShop versions.

---

For completeness, I re-ran a PHPStan cross-check of V9.0.6 against the 8.2.0 and 9.1.0 cores side by side. Only three findings appear against PS9 and not PS8 — Tools::encrypt(), PrestaShopBundle\...\ActionsBarButton, and the Tools::link_rewrite() fallback above — and all three are already behind a method_exists() or version_compare(_PS_VERSION_, '8.0', '<') guard, so they are dead code on a PS8+ install rather than actual regressions.

Could you give V9.0.6 a try and confirm? If you still hit any of these three errors on that release, that would be a different bug and I would very much like to reproduce it.