DocumentationExperience Cloud KCS

Mise à niveau du standard aem.js dans Adobe Experience Manager as a Cloud Service

Dernière mise à jour : 25 octobre 2026

Cet article fournit des conseils pour la mise à niveau du standard aem.js dans Adobe Experience Manager as a Cloud Service, en mettant en évidence les considérations de compatibilité, l’impact des workflows et les bonnes pratiques recommandées.

Description description

Environnement

Adobe Experience Manager as a Cloud Service (toutes les versions), aem.js standard v3.0.0-v3.1.8

Problème/Symptômes

  • Vous souhaitez incorporer des modifications en amont à aem.js dans un projet existant.
  • Vous devez vérifier les effets sur les blocs personnalisés, les scripts, la prévisualisation ou la publication avant de fusionner les modifications.

Cause

Le standard d’AEM est un projet de démarrage. Les modifications apportées au standard en amont ne mettent pas automatiquement à jour un projet existant ; les développeurs examinent et intègrent les modifications dans leur référentiel de projet. Le comportement spécifique au projet appartient aux extensions en dehors de aem.js, et non aux modifications locales apportées à la bibliothèque.

Résolution resolution

Suivez les étapes ci-dessous pour résoudre le problème :

  1. Passez en revue les modifications introduites dans le modèle de aem.js entre les versions 3.0.0 et 3.1.8.

  2. Vérifiez si votre implémentation utilise la version 3.1.0. Cette version a introduit une modification avec rupture qui a supprimé la gestion des métadonnées de section de decorateSections(). La modification a été identifiée comme une régression et a été rétablie dans la version 3.1.1.

  3. Si votre implémentation utilise la version 3.1.0, effectuez une mise à niveau vers la version 3.1.1 ou ultérieure pour restaurer la gestion des métadonnées de section.

  4. Examinez les modifications introduites dans les versions 3.1.1 via 3.1.8. Ces versions incluent des mises à jour de dépendance et des correctifs mineurs, tels que la résolution des blocs d’en-tête et de pied de page en double et la mise à jour de la résolution du chemin de code.

  5. Évaluez l’impact sur votre implémentation et vérifiez qu’aucune modification avec rupture n’affecte les workflows de publication, de prévisualisation ou de rendu par bloc. Outre la régression dans la version 3.1.0, aucune modification avec rupture n’a été identifiée dans ces workflows.

  6. Validez les modifications dans une branche de fonctionnalité avant la mise à niveau. Configurez la branche pour utiliser un environnement de prévisualisation et passer en revue les modifications après avoir envoyé le code mis à jour.

  7. Testez les modifications localement avant de les publier. Utilisez l’interface de ligne de commande AEM pour récupérer le contenu et valider les mises à jour. Les commandes suivantes peuvent vous aider à vérifier les modifications avant de les publier :

    code language-none 
    aem content clone
aem up
aem content diff
aem content push --dry-run

  8. Configurez les règles de protection de branche pour la branche principale et exigez des requêtes d’extraction, des vérifications d’état et des branches à jour avant de fusionner les modifications. Cela permet de s’assurer que toutes les modifications sont examinées et validées dans un environnement de prévisualisation avant d’atteindre la production.

  9. Après la mise à niveau, testez minutieusement les blocs personnalisés et les dépendances de script dans les environnements locaux et de prévisualisation pour vérifier la compatibilité.

  10. Vérifiez que la publication, la prévisualisation, le rendu des blocs, la gestion des métadonnées de section, les blocs personnalisés et les dépendances de script fonctionnent comme prévu après la mise à niveau.

recommendation-more-help
experience-cloud-kcs-help-kbarticles