DEV Community: Georges Cubas

`class:` ou `alias:`, un choix de conteneur Symfony, et un choix d'ingénierie

Georges Cubas — Thu, 10 Sep 2026 13:58:05 +0000

Pourquoi un fake S3 jetable peut être préférable à MinIO

Deux décisions se sont posées en recettant un pipeline d'import qui écrit sur S3, sans le moindre accès AWS en local.

La première est une question technique : pourquoi alias: fonctionne alors que class: échoue dans un override when@dev ?

La seconde est une décision d'architecture : pourquoi choisir un double maison jetable plutôt que MinIO ?

Le S3 n'est finalement qu'un prétexte. Les deux réponses se généralisent à bien d'autres situations.

Le contexte

Une plateforme Symfony 5.3 importe des fichiers d'achats déposés par une centrale. Les lignes qui référencent une entité encore inconnue sont mises de côté dans un fichier de rejets sur S3 ; un écran d'administration permet ensuite de résoudre l'entité, puis de réimporter ces lignes.

Le service qui parle à S3, AwsService, tire ses credentials du rôle de tâche ECS (CredentialProvider::ecsCredentials()), donc d'une infrastructure AWS uniquement disponible en production. Le nom du bucket vient quant à lui d'une ligne de paramétrage en base.

En local, avec DDEV : aucune variable AWS_*, aucun conteneur MinIO.

Tout appel à read(), putPro() ou move() est donc voué à l'échec. Pire : getBucket() renvoie null et le service échoue silencieusement (return false, sans exception).

Une recette qui se contente de constater que « ça n'a pas planté » peut donc passer sans que rien ne se soit réellement produit.

Il fallait exercer ce flux pour trois tickets successifs sur le même périmètre, à chaque fois sur une implémentation prête mais pas encore livrée.

Deux solutions, toutes les deux valables

Deux approches étaient possibles.

MinIO. Ajouter un conteneur S3-compatible au .ddev/config.yaml de l'équipe, et faire accepter à AwsService un endpoint et des credentials statiques en environnement de développement.
Un double maison. Créer un fake de AwsService qui redirige les opérations vers le système de fichiers local (var/fake-s3/), puis le brancher à la place du vrai service par un bloc when@dev non commité. Une fois la recette terminée, le double disparaît.

Les deux sont valables.

Le choix n'est donc pas une question de faisabilité mais une question de contexte.

`when@dev` : substituer une implémentation pour un seul environnement

when@<env> (introduit dans Symfony 5.3) permet de scoper de la configuration à un environnement dans un fichier de configuration normal, plutôt que dans un fichier séparé sous config/services/dev/.

Le bloc n'est pris en compte que lorsque kernel.environment correspond à l'environnement <env> ciblé et il est traité après le corps principal du fichier. Il peut donc redéfinir des services existants.

En production, ce bloc n'est pas pris en compte : le conteneur de production ne contient aucune définition issue de cet override.

C'est précisément ce qui en fait un bon réceptacle pour un hack temporaire : tout l'override tient dans un bloc contigu et greppable, en fin d'un seul fichier.

On le voit facilement au git diff et le supprimer est trivial. De toute façon c'est pour un test, normalement on ne livre rien à la fin.

Le plus petit changement réversible possible.

# ─── TEMPORAIRE — recette locale, NE PAS COMMITER ───
when@dev:
    services:
        App\Service\AwsService:
            ...

`class:` contre `alias:` : redéfinir, ou simplement pointer ailleurs

Classiquement un override consiste à remplacer la classe utilisée par le service de test :

when@dev:
    services:
        App\Service\AwsService:
            class: App\Service\FakeAwsServiceForManualTesting

Dans le cas rencontré, cette configuration aboutit à une erreur au premier appel :

Too few arguments to function

App\Service\FakeAwsServiceForManualTesting::__construct(),

0 passed ... and exactly 3 expected

Pourquoi ?

Il faut regarder comment le conteneur a été construit.

Le services.yaml par défaut contient notamment des _defaults (autowire: true, autoconfigure: true, bind:...) puis une ressource :

services:
    # default configuration for services in *this* file
    _defaults:
        autowire: true
        autoconfigure: true

    # makes classes in src/ available to be used as services
    App\:
        resource: '../src/'

    # ...

Cette ressource enregistre notamment App\Service\AwsService et App\Service\FakeAwsServiceForManualTesting comme services, avec leurs définitions issues de l'auto-découverte.

Mais une configuration placée sous when@dev.services constitue une nouvelle couche de configuration. Il faut donc être prudent lorsqu'on y redéfinit un service : on ne doit pas supposer que toute la configuration implicite de la définition initiale sera conservée telle quelle.

Dans le cas rencontré, la redéfinition avec class: n'a pas conservé la configuration nécessaire au constructeur du fake. Le service s'est retrouvé avec une définition qui ne savait plus résoudre ses trois dépendances.

On pourrait rendre cette redéfinition fonctionnelle en lui redonnant ce dont elle a besoin, par exemple avec autowire: true ou des arguments: explicites.

Mais ce n'est pas ce que l'on cherche ici, on ne veut pas redéfinir AwsService.
On veut dire :

« Quand quelqu'un demande AwsService en développement, donne-lui plutôt ce service-là. »

C'est exactement le rôle d'un alias.

when@dev:
    services:
        App\Service\AwsService:
            alias: App\Service\FakeAwsServiceForManualTesting
            public: true

Un alias n'est pas une nouvelle définition. C'est un pointeur : l'identifiant App\Service\AwsService se résout vers le service enregistré sous App\Service\FakeAwsServiceForManualTesting.

La définition du fake existe déjà grâce à l'auto-découverte de src/. Elle conserve donc sa propre configuration et son autowiring.

On ne rouvre aucune définition : on change simplement vers laquelle le conteneur pointe.

public: true est nécessaire ici parce qu'une commande console jetable va également récupérer le service par son identifiant.

En bref

class: sert à configurer une définition ; alias: sert à dire « à cet endroit, utilise cette autre implémentation ».

Ce n'est pas une règle absolue pour toutes les substitutions Symfony, mais c'est un excellent réflexe lorsqu'on dispose déjà de deux services correctement définis : si le besoin est simplement de faire pointer un identifiant vers une autre implémentation, l'alias est l'expression la plus étroite de l'intention.

On ne reconstruit pas ce qui existe déjà. On change le pointeur.

Choisir en fonction du contexte, pas des capacités

MinIO est plus fidèle à une infrastructure S3 réelle. Ça n'en fait pas le bon choix ici.
Les axes qui ont tranché sont les suivants.

Rayon d'impact

La solution MinIO modifie AwsService qui est déjà commité, partagé par toute la plateforme, présent dans tous les environnements, y compris les chemins S3 de production.

La solution avec le double ne touche aucun code commité : un fichier neuf et un bloc when@dev, tous deux jetés à la fin.

Le coût d'une erreur est donc borné par ce qu'on met en jeu.

Amortissement, ou sur-ingénierie

MinIO est un investissement.

Il devient intéressant si l'équipe doit régulièrement tester des flux S3 en local. Le besoin réel ici était beaucoup plus petit : trois tickets sur deux semaines, puis probablement plus rien avant des mois.

Sans récurrence pour l'amortir, construire le harnais MinIO revient à payer un coût d'infrastructure, de configuration et de maintenance pour une capacité que personne n'a demandée.

Le besoin est temporaire, la solution peut donc l'être aussi.

Demi-vie et réversibilité

Le hack a une demi-vie de quelques jours. Le retirer, c'est supprimer le bloc et le fake, puis éventuellement vider le cache.

La modification MinIO est permanente par construction. Or une chose permanente réclame un propriétaire, de la documentation, une ligne d'onboarding et de la maintenance.

Une branche endpoint dans AwsService, que plus personne n'exerce quelques mois plus tard, est exactement le genre de code qui peut finir par accueillir un bug sans que personne ne s'en aperçoive.

Alignement des modes de défaillance

Le double échoue comme le comportement attendu par le métier :

fichier absent → lecture vide → badge « non importé ».

Pas de faux vert.

MinIO, lui, peut échouer pour des raisons qui n'ont rien à voir avec le métier : mauvais bucket, mauvais endpoint, path-style, région, credentials...

On se retrouve alors à tester le harnais de test.

Fidélité consommée

La recette valide ici du métier :

le moteur de réimport parse-t-il correctement le fichier de rejets ?
insère-t-il les bonnes lignes ?
bascule-t-il correctement l'état ?

Ce métier est indifférent à l'origine des octets.

Reproduire fidèlement la sémantique S3 (cohérence, multipart, ACL, etc.) ajoute donc une fidélité que le test ne lit jamais.

La fidélité qu'on ne consomme pas est un coût, pas une qualité.

Coût de communication

Un relecteur qui voit FakeAwsServiceForManualTesting et un bloc NE PAS COMMITER a tout compris en trente secondes.

MinIO demande davantage : une note de conception, une explication en équipe, une mise à jour du guide d'onboarding, et potentiellement une réponse à la question :

« C'est quoi ce paramètre endpoint sur AwsService ? »

Et cela, pendant toute la durée de vie de la solution.

Ce que le double contient

Le double ne cherche pas à reproduire S3.
Il reproduit uniquement la surface publique réellement appelée par le code sous test.

Les helpers privés (put, list, check) ne peuvent pas être surchargés ; on surcharge donc les wrappers publics utilisés par l'application :

class FakeAwsServiceForManualTesting extends AwsService
{
    private string $root;

    public function __construct(
        KernelInterface $kernel,
        LoggerInterface $logger,
        ParametersService $parametersService
    ) {
        parent::__construct($kernel, $logger, $parametersService);

        $this->root = $kernel->getProjectDir() . '/var/fake-s3';
    }

    public function read(
        string $app,
        string $filename,
        string $folder
    ): ?string {
        $path = "{$this->root}/" . trim($folder, '/') . "/$filename";

        return is_file($path)
            ? (file_get_contents($path) ?: '')
            : '';
    }

    public function putPro(
        string $filename,
        string $content,
        string $folder
    ): bool {
        $path = "{$this->root}/" . trim($folder, '/') . "/$filename";

        @mkdir(dirname($path), 0777, true);

        return file_put_contents($path, $content) !== false;
    }

    // putShop / putFTP / copy / delete* / list* :
    // même forme, sur var/fake-s3/.

    // move() n'est pas surchargée :
    // la classe mère la fait en copy()+delete().
}

Ce n'est pas un émulateur S3 et c'est volontaire. Le double implémente uniquement ce que le flux testé consomme.

Tester le métier sans navigateur

Pour piloter les actions du contrôleur sans passer par le navigateur, une commande console jetable injecte le même service métier que le contrôleur.

Ce service est désormais backé par le fake grâce à l'alias.

La commande appelle donc les mêmes méthodes que le parcours applicatif.

Tout le cahier de test peut se dérouler en CLI ; le navigateur ne sert plus qu'à confirmer l'UI.

C'est aussi ce qui rend défendable l'argument :

On a validé le métier, pas S3.

Le principe

Deux réflexes de séniorité ressortent de cette expérience, l'un technique, l'autre architectural.

Pour substituer une implémentation, on ne redéfinit pas sa configuration si l'on peut simplement pointer vers une autre définition existante. alias: exprime cette intention ; class: est à utiliser lorsqu'on veut réellement configurer ou redéfinir une définition.
On choisit la solution dont le coût, humain autant que technique, est proportionné à la taille et à la durée de vie réelles du problème : rayon d'impact, maintenance, onboarding, réversibilité, fréquence d'utilisation.

Un jetable assumé bat souvent un permanent mal entretenu.

Et quand le contexte change, on refait le calcul.

Ici, le besoin était temporaire. Le double l'était aussi.

Le signe que le choix était bon est peut-être le plus concret : le pattern a été capturé dans la base de connaissances de l'équipe, puis réutilisé tel quel sur les deux tickets suivants.

Vingt minutes de mise en place, trois fois, contre un chantier de plusieurs jours.

Ce n'était pas la solution la plus complète. C'était la solution proportionnée.

Anonymiser les données de PrestaShop

Georges Cubas — Mon, 18 Jul 2022 12:25:48 +0000

Pour créer un environnement de développement, on duplique celui de production. Sauf qu’il ne faut pas garder les infos personnelles des clients. Déjà c’est dangereux, si vous gérez mal votre affaire vous risquez d’envoyer des mails aux clients et ça force tous les développeur et intervenant à faire attention au RGPD.

Donc on anonymise tout, c’est plus simple.

Voici un script MariaDB qui anonymise les données clients : noms, prénoms, adresses, téléphones, e-mails, ip, communications. Il remplace les lettres par xxx en respectant la casse, les n° de téléphone par 0 en respectant le format et passe les IP en 127.0.0.1.

UPDATE ps_address pa
SET pa.alias = REGEXP_REPLACE(REGEXP_REPLACE(pa.alias, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.lastname = REGEXP_REPLACE(REGEXP_REPLACE(pa.lastname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.firstname = REGEXP_REPLACE(REGEXP_REPLACE(pa.firstname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.address1 = REGEXP_REPLACE(REGEXP_REPLACE(pa.address1, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.address2 = REGEXP_REPLACE(REGEXP_REPLACE(pa.address2, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.city = REGEXP_REPLACE(REGEXP_REPLACE(pa.city, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.other = REGEXP_REPLACE(REGEXP_REPLACE(pa.other, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.company = REGEXP_REPLACE(REGEXP_REPLACE(pa.company, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.phone = REGEXP_REPLACE(pa.phone, '[0-9]', '0'),
pa.phone_mobile = REGEXP_REPLACE(pa.phone_mobile, '[0-9]', '0'),
pa.vat_number = REGEXP_REPLACE(REGEXP_REPLACE(REGEXP_REPLACE(pa.vat_number, '[0-9]', '0'), '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.dni = REGEXP_REPLACE(REGEXP_REPLACE(REGEXP_REPLACE(pa.dni, '[0-9]', '0'), '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X');

UPDATE ps_customer c
SET c.lastname = REGEXP_REPLACE(REGEXP_REPLACE(c.lastname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
c.firstname = REGEXP_REPLACE(REGEXP_REPLACE(c.firstname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
c.email = CONCAT(c.id_customer, '@example.com');

UPDATE ps_customer c 
SET c.ip_registration_newsletter = '127.0.0.1' 
WHERE c.ip_registration_newsletter IS NOT NULL AND c.ip_registration_newsletter != '0';

UPDATE ps_customer_message cm
SET cm.message = REGEXP_REPLACE(REGEXP_REPLACE(cm.message, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
cm.ip_address = '2130706433';

UPDATE ps_customer_thread ct
SET ct.email = CONCAT(IF(ct.id_customer > 0, ct.id_customer, '0'), '@example.com');

La syntaxe de REGEXP_REPLACE n’est pas la même pour MySQL et MariaBD, donc il faudra adapter.

Programmer les popups de Popup Builder

Georges Cubas — Wed, 20 Oct 2021 10:18:03 +0000

La version gratuite du plugin WordPress Popup Builder ne permet pas programmer l’affichage des popups. Cependant elle créé le filtre sgpbOtherConditions qui permet de les désactiver.

Ce filtre est appelé pour chaque popup qui peut s’afficher sur la page et si l’argument ‘status’ à false est ajouté à ceux existants, la popup ne s’affiche pas.

    /**
     * Check Popup conditions
     *
     * @since 1.0.0
     *
     * @return array
     *
     */
    private function isSatisfyForOtherConditions()
    {
        $popup = $this->getPopup();
        $popupOptions = $popup->getOptions();
        $popupId = $popup->getId();

        $dontAlowOpenPopup = apply_filters('sgpbOtherConditions', array('id' => $popupId, 'popupOptions' => $popupOptions, 'popupObj' => $popup));

        return $dontAlowOpenPopup['status'];
    }

Pour désactiver automatiquement vos popups, vous pouvez ajouter ce code à functions.php

add_filter('sgpbOtherConditions', 'my_sgpbOtherConditions', 10, 1);

// update popin status
function my_sgpbOtherConditions($args = array()) {
    // if popup is already unactive, do nothing
    if (isset($args['status']) && $args['status'] === false) {
        return $args;
    }

    switch ($args['id']) {
        case 17938: // summer holiday active between 2021-07-30 and 2021-08-01
            $now = time() + 2 * 60 * 60; // for time zone, can be improved
            $from = strtotime('2021-07-30 00:00:00');
            $to = strtotime('2021-08-02 00:00:00');

            // if we are not between 2021-07-30 and 2021-08-01 desactivate the popup
            if (($now < $from) || ($now > $to)) {
                $args['status'] = false;
            }           
            break;
        case 16412:  // covid reassurance unactive between 2021-07-30 and 2021-08-01
            $now = time() + 2 * 60 * 60; // for time zone, can be improved
            $from = strtotime('2021-07-30 00:00:00');
            $to = strtotime('2021-08-02 00:00:00');

            // if we are between 2021-07-30 and 2021-08-01 desactivate the popup
            if (($now >= $from) && ($now <= $to)) {
                $args['status'] = false;
            }
            break;
    }
    return $args;   
}

Ainsi la popup 17938 ne sera active qu’entre le 30 juillet et le 1 août 2021 alors que la 16412 ne le sera que le reste du temps.

Sauvegarde automatique sur FTP

Georges Cubas — Wed, 20 Oct 2021 09:31:49 +0000

A force je pense avoir un script de sauvegarde FTP efficace.

Il sauvegarde les bases de données ainsi qu’un dossier du serveur et les envoi sur un serveur FTP. Si le serveur FTP est plein, il supprime les sauvegardes les plus anciennes jusqu’à avoir assez de place pour mettre la nouvelle.

Si une erreur arrive, il envoi un mail d’alerte.

Le script nécessite curlftpfs.

Utilisation :

Modifiez le script dans la partie configuration
Enregistrez le sur le serveur, par exemple dans /opt/scripts/backup.sh
Donnez les droits d’execution au fichier : chmod +x /opt/scripts/backup.sh
Ajoutez une tâche cron : 02 00 * * * /bin/bash /opt/scripts/backup.sh > /var/log/backup.log 2>&1

Also on: GitHub

Autoriser les images avec des longs ID dans PrestaShop

Georges Cubas — Wed, 09 Jun 2021 09:56:37 +0000

Par construction PrestaShop ne peut pas gérer les images avec des ID supérieurs à 9 999 999 (7 chiffres). C’est déjà beaucoup et on a pas souvent besoin de plus mais j’ai eu affaire à un script d’import qui impose les ID d’images et donc ça arrive.

Pourquoi PrestaShop ne les gèrent pas ?

En fait, PrestaShop n’a pas de soucis avec les ID de 8 chiffres ou plus, tant que la base de données l’accepte, lui aussi. Le problème vient de la façon d’accéder aux images.

L’URL d’une image est https://example.com/123-large/mon-image.jpg soit [url de la boutique]/[ID de l'image]-[format à afficher]/[texte pour le référencement].jpg et le fichier .htaccess explique au serveur que quand on a une url de ce type, il faut aller chercher le fichier qu’il faut dans le dossier des images /img/p/

Le fichier .htaccess de PrestaShop ressemble à ça

RewriteRule ^([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$1$2$3.jpg [L]
RewriteRule ^([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$1$2$3$4$5.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg [L]Code language: JavaScript (javascript)

Donc quand le serveur reçoit l’URL https://example.com/123-large/mon-image.jpg il affiche le fichier /img/p/1/2/3/123-large.jpg. C’est rapide et ça ne demande pas de ressource, PrestaShop n’est même pas appelé quand on veut afficher une image produit.

Mais on ne peut pas utiliser $10 dans un fichier .htaccess, il est interprété comme $1 puis le caractère 0. Comme dans la dernière ligne de l’extrait ci-dessus on utilise $9, on ne peut pas aller plus loin.

Ma solution

Si on appelle l’URL https://example.com/123456789-large/mon-image.jpg, le serveur ne reconnait pas ce format et essaye simplement d’afficher le fichier /123456789-large/mon-image.jpg qui n’existe pas et renvoie donc une erreur 404. PrestaShop affiche donc une jolie page pour dire que le fichier n’a pas été trouvée.

L’astuce consiste à utiliser cette page pour afficher l’image demandée en complétant le controller PageNotFound.

<?php
class PageNotFoundController extends PageNotFoundControllerCore
{
    public function initContent()
    {
        list($filename) = explode('?', $_SERVER['REQUEST_URI']);
        if (preg_match('/([0-9]+)(\-[_a-zA-Z0-9-]*)?\/.*\.jpg/', $filename, $matches)) {
            $path = _PS_ROOT_DIR_.'/img/p/'.implode('/', str_split($matches[1], 1)).'/'.$matches[1].$matches[2].'.jpg';
            if (file_exists($path)) {
                header('Content-Type: '.mime_content_type($path)?:'image/jpg');
                readfile($path);
                die();
            } else {
                header('HTTP/1.1 404 Not Found');
                header('Status: 404 Not Found');
                header('Content-Type: image/gif');
                readfile(_PS_ROOT_DIR_.'/img/404.gif');
                die();
            }
        }
        return parent::initContent();
    }
}

Code à placer dans /override/controllers/front/PageNotFoundController.php

Le principe est le suivant :

quand le controller PageNotFound est appelé, on regarde si l’URL correspond à celle d’une image produit,
si oui on regarde si elle existe,
- si oui on l’affiche et c’est terminé
- si non on affiche une image d’erreur
si non on laisse le controller gérer

Sources :