L'éditeur en masse WooCommerce n'enregistre pas les modifications : cause et remède

Quand les modifications de l'éditeur en masse WooCommerce ne s'enregistrent pas, quatre situations différentes sont possibles : une valeur saisie dans une cellule disparaît après un rechargement, la modification liée (binded editing) ne change que la ligne dans laquelle vous avez saisi la valeur, une modification en masse se termine par produits traités : 0 (products bulked: 0), ou bien les valeurs ont été enregistrées puis sont revenues aux anciennes quelques heures plus tard. Chaque cas a sa propre cause, et l'éditeur vous indique laquelle si vous savez où lire. Voici d'abord cette lecture, puis le remède pour chaque cas.

Ce que le symptôme vous apprend

Après la modification d'une cellule, BEAR affiche Enregistrement ... (Saving ...) pendant l'exécution de la requête et Enregistré (Saved.) lorsque le serveur a répondu ; la cellule est ensuite redessinée avec ce que le serveur a renvoyé. Après une modification en masse, l'onglet Historique (History) reçoit un enregistrement avec son état et le nombre de produits modifiés. Ensemble, ces indices désignent la cause :

Les modifications en ligne s'enregistrent avec Entrée

Les cellules de texte et de nombre de l'Editeur de produits (Products Editor) (titre, UGS, prix, quantité en stock, poids, dimensions, champs méta) ouvrent un champ de saisie au clic. La valeur n'est envoyée au serveur que lorsque vous appuyez sur Entrée, qui enregistre et ouvre la même cellule dans la ligne suivante, ou sur Flèche haut / Flèche bas, qui enregistrent et se déplacent vers le haut ou vers le bas. Échap annule. La touche Tab et un clic en dehors de la cellule n'envoient rien, et cliquer sur une autre cellule ferme le champ ouvert sans l'enregistrer. Flèche gauche et Flèche droite déplacent seulement le curseur dans le texte. Une fois que vous en avez l'habitude, remplir une colonne devient rapide : saisir, Entrée, saisir, Entrée, jusqu'en bas de la page.

Les listes déroulantes, les interrupteurs et les éditeurs en fenêtre contextuelle, comme la description, enregistrent dès que vous choisissez une valeur ou confirmez la fenêtre ; ils n'ont donc pas besoin d'Entrée.

Pour les champs méta, une modification qui « ne tient pas » peut aussi venir d'une clé saisie autrement que la vraie : BEAR enregistre sous la clé que vous avez configurée, alors que le produit continue d'afficher la valeur stockée sous la vraie clé. Comparez la clé de l'onglet Champs méta (Meta Fields) avec les champs personnalisés du produit.

La modification liée ne change qu'un seul produit

La modification liée (binded editing) est un interrupteur du panneau d'outils. Lorsqu'elle est activée, une valeur enregistrée dans une ligne cochée est répercutée sur toutes les autres lignes cochées de la page ; cette répercussion s'exécute comme une petite opération en masse, ce qui explique qu'elle ait son propre enregistrement dans l'Historique. Voici les raisons habituelles pour lesquelles seule la ligne où vous avez saisi la valeur change :

• L'interrupteur s'est désactivé tout seul. Il se désactive dès qu'une répercussion démarre, si bien que le champ suivant que vous modifiez n'est enregistré que sur une seule ligne. Réactivez-le avant chaque modification liée.
• Pas assez de lignes cochées. Cochez au moins deux produits, dont celui dans lequel vous allez saisir. Le cochage fonctionne sur la page en cours ; pour un ensemble plus grand, utilisez un filtre et l'onglet Modifier en bloc, comme décrit dans définir la même valeur pour plusieurs produits.
• Le champ n'est pas disponible pour la modification liée. L'info-bulle à côté de l'interrupteur liste les champs que la version gratuite peut répercuter ; pour les autres, une alerte indique que le champ est désactivé pour la modification en masse.
• La requête de répercussion n'a pas reçu ses données. Elle utilise le même stockage côté serveur et les mêmes requêtes admin-ajax.php que l'onglet Modifier en bloc ; tout ce qui figure dans la section sur les pare-feu et les caches plus bas s'applique donc aussi. Une erreur JavaScript dans la console du navigateur (F12) l'arrête également ; testez dans une fenêtre privée et dans un autre navigateur pour écarter un script ancien resté en cache ou une extension du navigateur.

Les produits cochés restent cochés tant que vous continuez à travailler sur la page, et l'onglet Modifier en bloc leur donne la priorité sur le filtre : sa ligne La modification en masse sera appliquée à (Bulk editing will be applied to) nomme alors les produits sélectionnés et leur nombre. Décochez-les avec le bouton de décochage du panneau d'outils avant une modification en masse qui doit couvrir tout le filtre, faute de quoi elle ne change que les produits cochés.

Modifications refusées par les rôles et les capacités

BEAR s'ouvre pour les utilisateurs qui possèdent la capacité WooCommerce manage_woocommerce, et chaque enregistrement vérifie que l'utilisateur a le droit de modifier ce produit précis. Un rôle sans edit_others_products ne peut enregistrer que ses propres produits ; pour les autres, la requête est refusée et la cellule affiche 0.

Les rôles autres qu'administrateur sont en outre limités champ par champ. Dans l'onglet Paramètres (Settings), un administrateur coche visible pour le gestionnaire de la boutique (visible for the shop manager) sous chaque colonne qu'un gestionnaire de boutique peut voir et modifier, puis enregistre avec Enregistrer tous les réglages (Save all settings). Les colonnes sans coche ne sont pas du tout affichées pour ce rôle. Le piège est l'installation toute neuve : tant qu'un administrateur n'a pas enregistré une fois l'onglet Paramètres, aucun champ n'est encore marqué, si bien qu'un gestionnaire de boutique voit toutes les colonnes et que chaque modification répond interdit (forbidden). Enregistrer l'onglet Paramètres en tant qu'administrateur règle le problème. La FAQ sur la limitation du rôle de gestionnaire de boutique montre la configuration.

Pour les règles que les cases à cocher ne peuvent pas exprimer, deux filtres décident dans le code. woobe_user_can_edit décide champ par champ pour les rôles autres qu'administrateur : renvoyez 1 pour autoriser, 0 pour refuser.

// Child theme functions.php or a code snippets plugin.
// BEAR: let non-administrator roles edit prices and stock whatever the Settings checkboxes say.
add_filter( 'woobe_user_can_edit', function ( $can_edit, $field_key, $visibility ) {
    if ( in_array( $field_key, array( 'regular_price', 'sale_price', 'stock_quantity' ), true ) ) {
        return 1;
    }
    return $can_edit;
}, 10, 3 );

woobe_permit_special_roles fait compter un rôle comme administrateur à l'intérieur de BEAR. Utilisez-le avec parcimonie : un tel rôle voit et enregistre aussi les réglages de toute la boutique, dont ceux du serveur MCP.

add_filter( 'woobe_permit_special_roles', function ( $roles ) {
    $roles[] = 'shop_manager';
    return $roles;
} );

Quand un compte administrateur ne peut pas enregistrer alors qu'un autre le peut, c'est le compte lui-même qui pose problème. BEAR décide d'après le premier rôle du compte : un administrateur qui porte aussi un second rôle issu d'une extension d'adhésion ou d'édition de rôles peut donc être traité comme cet autre rôle, et un éditeur de rôles peut retirer des capacités à un seul compte. Créez un nouvel administrateur, refaites la modification, et comparez les rôles et les capacités des deux comptes.

Pare-feu, extensions de cache et « products bulked: 0 »

Pare-feu du serveur. Les règles ModSecurity, y compris le pare-feu d'applications web de Plesk, répondent souvent 403 Forbidden à une requête qui contient du HTML ; les descriptions et autres textes avec balisage restent donc sur Enregistrement ... (Saving ...). Le journal du pare-feu nomme la règle ; désactivez cette règle pour le site plutôt que tout le pare-feu. La FAQ Le contenu de la description n'est pas enregistré présente un cas de ce genre.

Extensions de cache et d'optimisation. Chaque enregistrement et chaque étape d'une modification en masse est une requête vers /wp-admin/admin-ajax.php. Les caches de pages avec mise en cache de l'administration ou d'AJAX activée, les fonctions « optimiser pour les utilisateurs connectés », la minification et la combinaison des scripts d'administration, ainsi que les caches d'hébergeurs sur les plateformes à mise à l'échelle automatique ont tous déjà intercepté ces requêtes. WP-Optimize et LiteSpeed Cache en sont des exemples typiques, et dans les deux cas le remède est d'exclure /wp-admin/ de la mise en cache des pages et de l'optimisation ; le nettoyage de la base de données et la compression des images peuvent rester actifs. Pour tester, désactivez l'extension de cache, videz le cache du serveur, refaites la modification, puis réactivez les éléments un par un.

Le stockage des données de la modification en masse. L'onglet Modifier en bloc stocke l'opération sur le serveur et chaque lot la relit. Si le stockage la perd, chaque lot ne trouve rien à écrire et l'Historique affiche terminé (completed) avec produits traités : 0 (products bulked: 0). Réglez Stockage du plugin (Plugin memory storage) dans Paramètres sur Option (recommandé) (Option (recommended)) et supprimez tout ancien extrait woobe_storage_type ; les raisons sont expliquées dans le filtre de l'éditeur en masse ne fonctionne pas, car le même stockage conserve le filtre.

Si rien de tout cela ne s'applique, une extension accrochée à l'enregistrement des produits peut encore bloquer ou annuler une écriture. Isoler les extensions pendant les modifications en masse montre comment la trouver et comment la tenir à l'écart des requêtes de BEAR.

Valeurs qui reviennent en arrière plus tard

BEAR n'écrit dans les produits que lorsque quelqu'un enregistre dans son éditeur, restaure un enregistrement de l'Historique, ou travaille via son serveur MCP lorsque celui-ci est activé. Chacune de ces actions laisse un enregistrement dans l'Historique, qui indique qui a fait la modification et si elle a été faite à la main ou par un agent d'IA. Si des prix, du stock ou des attributs reviennent en arrière à un moment qui n'a aucun enregistrement dans l'Historique, ce n'est pas BEAR qui l'a fait.

Cherchez ce qui d'autre écrit dans les produits selon un calendrier : extensions d'import et de synchronisation de produits, connecteurs de caisse (POS) et d'inventaire, intégrations ERP et places de marché, flux de fournisseurs, et extensions multilingues qui copient les champs de la langue d'origine vers les traductions. Leurs journaux, ou l'heure de leurs tâches planifiées dans Outils > Actions planifiées (Tools > Scheduled Actions), correspondent généralement au moment où la valeur a changé.

Comment confirmer qu'une modification a été enregistrée

1. La cellule. Après Entrée, elle affiche la valeur enregistrée, et non interdit (forbidden) ou 0, et Enregistré (Saved.) apparaît.
2. L'Historique. L'enregistrement existe, son état est terminé (completed), et produits traités (products bulked) correspond au nombre attendu.
3. Le produit lui-même. Ouvrez-le dans Produits (Products) dans wp-admin. La base de données fait foi ; si la page de la boutique affiche encore l'ancienne valeur, c'est le cache de pages, ou le cache propre à un constructeur de pages, qui sert une ancienne copie (voir le cas d'Elementor).
4. Les journaux. Avec WP_DEBUG_LOG activé, wp-content/debug.log montre les erreurs PHP survenues pendant l'enregistrement, et l'onglet Réseau (Network) du navigateur montre le statut de la requête admin-ajax.php : 403 pour un pare-feu, 500 pour une erreur PHP.

Si la valeur ne s'enregistre toujours pas, ouvrez un sujet sur le forum d'assistance de BEAR en indiquant le champ, ce que la cellule affiche après Entrée, l'enregistrement de l'Historique et le statut de la requête.