Erreur 404 sur toutes les pages en raison d’un problème d’évaluation du contenu

Cet article fournit un correctif pour le problème d’infrastructure de cloud d’Adobe Commerce on-premise et d’Adobe Commerce où vous obtenez une erreur 404 lors de l’accès à une page de storefront ou à Commerce Admin.

Produits et versions concernés

  • Adobe Commerce on-premise 2.2.x, 2.3.x
  • Adobe Commerce sur l’infrastructure cloud 2.2.x, 2.3.x

Problème

NOTE
Cet article ne s’applique pas à la situation dans laquelle vous obtenez une erreur 404 lorsque vous essayez de prévisualiser la mise à jour d’évaluation. Si vous rencontrez ce problème, ouvrez un ticket de support.

L’accès à n’importe quelle page de storefront ou à l’administrateur génère l’erreur 404 (la page "Oups, our bad…") après avoir effectué des opérations avec des mises à jour planifiées pour stocker des ressources de contenu à l’aide de Content Staging (mises à jour pour stocker des ressources de contenu planifiées à l’aide du module Magento_Staging). Par exemple, vous avez peut-être supprimé un produit avec une mise à jour planifiée ou supprimé la date de fin de la mise à jour planifiée.

Une ressource de contenu de magasin comprend :

  • Produit
  • Catégorie
  • Règle de prix du catalogue
  • Règle de prix du panier
  • Page CMS
  • Bloc CMS
  • Widget

Certains scénarios sont abordés dans la section Cause ci-dessous.

Cause

La table flag de la base de données (DB) contient des liens non valides vers la table staging_update.

Le problème est lié à l’évaluation de contenu. Vous trouverez ci-dessous deux scénarios particuliers. Notez qu’il peut y avoir d’autres situations qui déclenchent le problème.

Scénario 1 : Suppression d’une ressource de contenu de magasin qui :

  • a une mise à jour planifiée avec l’évaluation de contenu
  • la mise à jour a une date de fin (c’est-à-dire la date d’expiration à laquelle la ressource mise à jour revient à sa version précédente).
  • la date de fin de la mise à jour se situe dans le passé.

En même temps, le problème peut ne pas se produire si une ressource supprimée n’a pas de date de fin pour la mise à jour planifiée.

Scénario 2 : Suppression de la date/de l’heure de fin d’une mise à jour planifiée.

Déterminer si votre problème est lié

Pour déterminer si le problème que vous rencontrez est celui décrit dans cet article, exécutez la requête DB suivante :

   SELECT f.flag_data >'$.current_version' as flag_version, (su.id IS NOT NULL) as update_exists
   -> FROM flag f
   -> LEFT JOIN staging_update su
   -> ON su.id = f.flag_data >'$.current_version'
   -> WHERE flag_code = 'staging';

Si la requête renvoie une table dont la valeur update_exists est "0", un lien non valide vers la table staging_update existe dans votre base de données et les étapes décrites dans la section Solution aideront à résoudre le problème. Voici un exemple du résultat de la requête avec la valeur update_exists égale à "0" :

update_exists_0.png

Si la requête renvoie une table dont la valeur update_exists est "1" ou un résultat vide, cela signifie que votre problème n’est pas lié aux mises à jour intermédiaires. Voici un exemple du résultat de la requête avec la valeur update_exists égale à "1" :

(mises à jour_existent_1.png

Dans ce cas, vous pouvez vous reporter à l’outil de dépannage de Site Down pour obtenir des idées de dépannage.

Solution

  1. Exécutez la requête suivante pour supprimer le lien non valide vers la table staging_update :

    code language-sql
    DELETE FROM flag WHERE flag_code = 'staging';
    
  2. Attendez que la tâche cron s’exécute (jusqu’à cinq minutes si configurée correctement) ou exécutez-la manuellement si cron n’est pas configuré.

Le problème doit être résolu immédiatement après avoir corrigé le lien non valide. Si le problème persiste, soumettez un ticket d'assistance.

Lecture connexe

Bonnes pratiques pour la modification des tables de base de données dans le manuel de mise en oeuvre de Commerce

recommendation-more-help
8bd06ef0-b3d5-4137-b74e-d7b00485808a