Čo sa mení

Od verzie 6.9, WordPress Toto urýchľuje zavádzanie hlavných funkcií plánovaných v pláne na rok 2026. Prioritou je úplná kompatibilita s PHP 8.2+, zavedenie „jednotného“ editora stránok pre všetky témy, zastaranie niekoľkých starších hookov a kompletná revízia správy natívnych médií. Agentúry a blogeri používajúci buildery ako Divi 5, Elementor alebo Avada sa budú musieť prispôsobiť: niektoré hooky a vstupné body sa menia, klasické šablóny sa stávajú zastaranými a správa vyrovnávacej pamäte sa upravuje.

Niekoľko Trac ticketov a poznámok od vývojárov podrobne popisuje tieto zmeny:

Stretol som sa s nekompatibilitami na stránkach, ktoré používajú vlastné mediálne pluginy alebo zastarané hooky v podradenej téme. Chyby sú zriedkavo explicitné; často funkcia jednoducho zmizne. sans výstražná správa.

Rýchle zhrnutie

  • WordPress zavádza jednotný editor stránok pre všetky témy (vrátane klasických) od verzie 6.10.
  • Redesign mediálnej knižnice: nové API, natívne súbory WebP/AVIF, premiestnené mediálne hooky.
  • Znehodnotenie niekoľkých historických háčikov vrátane the_content v určitých kontextoch.
  • Podradené témy používajúce klasické šablóny musia migrovať na blokové alebo hybridné šablóny.
  • Divi 5, Elementor a Avada: vlastné moduly musia byť zamerané na nové hooky a editor API.
  • Minimálne odporúčané PHP: 8.1+, ukončenie podpory pre verzie 7.4 a 8.0 je plánované na koniec roka 2026.
  • Vylepšená správa vyrovnávacej pamäte, lepšie oddelenie skriptov a CSS, priorita udelená modulárnym prostriedkom.

Pred/Po v kóde

Šablóna vlastnej stránky (predná strana)


// Ancienne façon (avant WP 6.10)
add_filter('the_content', 'custom_page_template');
function custom_page_template($content) {
    if (is_page('contact')) {
        return '<div class="custom-contact">Contact form ici</div>' . $content;
    }
    return $content;
}

Blok šablóny/hybrid (po)


// Nouvelle façon (WordPress 6.10+)
add_filter('render_block', 'custom_contact_block', 10, 2);
function custom_contact_block($block_content, $block) {
    if ($block['blockName'] === 'core/post-content' && is_page('contact')) {
        return '<div class="custom-contact">Contact form ici</div>' . $block_content;
    }
    return $block_content;
}

Háčik the_content sa už nevolá vždy v závislosti od štruktúry stránky alebo šablóny (najmä s novým zjednoteným editorom). Hook render_block umožňuje vám presne pôsobiť na cielené bloky.

Manažment médií (predtým)


// Ancienne façon
add_filter('wp_handle_upload_prefilter', 'check_custom_upload');
function check_custom_upload($file) {
    // Vérifie la taille, le type, etc.
    return $file;
}

Manažment médií (po)


// Nouvelle API (WP_Media_Manager)
add_action('media_file_upload', 'check_custom_upload_modern', 10, 1);
function check_custom_upload_modern($media_object) {
    // $media_object est une instance avec méthodes de validation
    if ($media_object->get_size() > 5 * 1024 * 1024) {
        $media_object->add_error('Fichier trop volumineux');
    }
}

Rozhranie API pre médiá sa stáva objektovo orientovaným. Historické filtre zostanú dočasne dostupné, ale sú zastarané. Rozšírenia je potrebné migrovať, inak sa chyby už nebudú spracovávať.

Náraz betónu

Blogeri, ktorí vo svojich témach používali shortcode alebo klasické hooky, môžu po verzii 6.10 zistiť, že niektoré úpravy sú neaktívne. Vývojári pluginov by mali migrovať svoje hooky a overiť kompatibilitu svojich JS/CSS prvkov. Podradené témy založené na klasických PHP šablónach už nie sú v zjednotenom editore štandardne podporované.

Pre staviteľov:

  • Divi 5 Vlastné moduly musia používať nové vstupné body JS poskytované rozhraním API editora. Zálohovací systém Divi sa teraz spolieha na hooky. WordPress domorodci (save_block); staršie moduly si už nemusia správne ukladať nastavenia.
  • Elementor Vlastné widgety musia deklarovať svoju kompatibilitu s editorom stránky. Hooky elementor/frontend/after_register_scripts sú nahradené hookmi blokového editora.
  • Avada Nástroj Fusion Builder je potrebné aktualizovať, aby používal nové rozhranie API pre médiá a šablóny blokov. Tradičné krátke kódy už nemusia fungovať v závislosti od štruktúry šablóny.

Už som videl problémy, kde kód fungoval perfektne v 6.8, ale nie v 6.9.4, jednoducho kvôli háčiku ako the_content sa už nevolal v predvolenom bloku šablóny.

Riziká, kompatibility a body, na ktoré treba dávať pozor

  • Niekoľko starších funkcií hookov je zastaraných alebo už nemajú žiadny účinok v zjednotenom editore: the_content, get_the_excerpt, wp_head v určitých kontextoch.
  • Kompatibilita podradených tém založených na klasických šablónach PHP už nie je zaručená.
  • Pluginy, ktoré manipulujú s knižnicou médií prostredníctvom starých filtrov, budú pravdepodobne „tiché“: žiadne ďalšie chyby, žiadne ďalšie úpravy, nič v protokoloch.
  • Správa aktív (CSS/JS) sa mení. Aktíva nie sú deklarované prostredníctvom wp_register_script ou wp_enqueue_block_script sa už nemusí načítať v editore alebo na frontende.
  • Kód, ktorý používa funkcie nekompatibilné s PHP 8.2+ (napr. určité funkcie) create_function) spúšťajú varovania alebo sú ignorované.
  • Bežné problémy: súbory umiestnené na nesprávnom mieste, zabudnutie na vymazanie vyrovnávacej pamäte, trvalé odkazy neresetované po prepnutí na šablónu bloku, vlastné hooky nedeklarované v functions.php detskej témy.
  • Podpora pre PHP 7.4 a 8.0 bude odstránená s WordPressom 6.11 (4. štvrťrok 2026).

Diagnostická tabuľka pre bežné problémy:

symptóm Príčina pravdepodobná overenie Riešenie
Prispôsobenie obsahu nefunguje háčik the_content viac nazývané Ladenie aktívnych hookov na stránke použitie render_block ou save_block
Chyba pri nahrávaní obrázka Plugin používa starý mediálny filter. Skontrolujte protokoly, otestujte s vypnutým pluginom Prispôsobenie pluginu novému mediálnemu API
JS/CSS sa nenačítal v editore Nesprávne zaradenie do frontu alebo nesprávny názov handleru Skontrolujte editor, konzolu prehliadača použitie wp_enqueue_block_script
Modul Divi/Elementor už neukladá Zastaraný hook alebo nekompatibilné API Zobraziť nástroj na tvorbu zoznamu zmien Migrácia na nové JS/API hooky
Závažná chyba na stránke Zastaraná funkcia PHP (create_functionAtď). Povoliť WP_DEBUG, skontrolovať PHP logy Prepíšte kód pomocou moderných uzáverov

Ako migrovať

  1. Identifikujte použité háčiky Hľadať všetko add_filter, add_action vo vašich témach/pluginoch. Uprednostnite render_block ou save_block pre obsah.
  2. Skontrolujte podradené šablóny Prepnite na blokové alebo hybridné šablóny. Pre klasickú šablónu:
    
    // Ancien template enfant
    get_header();
    the_content();
    get_footer();
    
    Prejsť na:
    
    // Nouveau template block (template-parts/content-contact.html)
    
        
        

    Ce qui change

    Depuis la version 6.9, WordPress accélère le déploiement de fonctionnalités majeures prévues dans la roadmap 2026. La priorité est donnée à la compatibilité totale PHP 8.2+, l’introduction de l’éditeur de site "unifié" pour tous les thèmes, la dépréciation de plusieurs hooks historiques et la refonte de la gestion des médias en natif. Les agences et blogueurs qui utilisent des builders comme Divi 5, Elementor ou Avada devront s’adapter : certains hooks et points d’entrée changent, des templates classiques deviennent obsolètes, et la gestion du cache est modifiée.

    Plusieurs tickets Trac et dev notes détaillent ces changements :

    J’ai déjà rencontré des incompatibilités sur des sites qui utilisaient des plugins de médias personnalisés ou des hooks obsolètes dans leur thème enfant. Les erreurs sont rarement explicites : souvent, une fonctionnalité disparaît sans message d’alerte.

    Résumé rapide

    • WordPress impose l’éditeur de site unifié à tous les thèmes (classiques compris) dès 6.10.
    • Refonte du Media Library : nouvelle API, fichiers WebP/AVIF nativement, hooks médias déplacés.
    • Dépréciation de plusieurs hooks historiques dont the_content dans certains contextes.
    • Les thèmes enfants utilisant des templates classiques doivent migrer vers les templates block ou hybrides.
    • Divi 5, Elementor et Avada : modules personnalisés doivent cibler les nouveaux hooks et l’API éditeur.
    • Minimum PHP recommandé : 8.1+, abandon du support 7.4 et 8.0 prévu pour la fin 2026.
    • Gestion du cache affinée, scripts et CSS mieux séparés, priorité aux assets modulaires.

    Avant / Après en code

    Template de page personnalisée (avant)

    
    // Ancienne façon (avant WP 6.10)
    add_filter('the_content', 'custom_page_template');
    function custom_page_template($content) {
        if (is_page('contact')) {
            return '<div class="custom-contact">Contact form ici</div>' . $content;
        }
        return $content;
    }
    

    Template block/hybride (après)

    
    // Nouvelle façon (WordPress 6.10+)
    add_filter('render_block', 'custom_contact_block', 10, 2);
    function custom_contact_block($block_content, $block) {
        if ($block['blockName'] === 'core/post-content' && is_page('contact')) {
            return '<div class="custom-contact">Contact form ici</div>' . $block_content;
        }
        return $block_content;
    }
    

    Le hook the_content n’est plus toujours appelé selon la structure de la page ou du template (notamment avec le nouvel éditeur unifié). Le hook render_block permet d’agir précisément sur les blocs ciblés.

    Gestion des médias (avant)

    
    // Ancienne façon
    add_filter('wp_handle_upload_prefilter', 'check_custom_upload');
    function check_custom_upload($file) {
        // Vérifie la taille, le type, etc.
        return $file;
    }
    

    Gestion des médias (après)

    
    // Nouvelle API (WP_Media_Manager)
    add_action('media_file_upload', 'check_custom_upload_modern', 10, 1);
    function check_custom_upload_modern($media_object) {
        // $media_object est une instance avec méthodes de validation
        if ($media_object->get_size() > 5 * 1024 * 1024) {
            $media_object->add_error('Fichier trop volumineux');
        }
    }
    

    L’API média devient orientée objet. Les filtres historiques restent temporairement mais sont dépréciés. Les extensions doivent migrer sinon les erreurs ne seront plus gérées.

    Impact concret

    Les blogueurs qui utilisaient des shortcodes ou des hooks classiques dans leur thème pourront voir certaines personnalisations inactives après la 6.10. Les développeurs de plugins doivent migrer leurs hooks et vérifier la compatibilité de leurs assets JS/CSS. Les thèmes enfants basés sur des templates PHP classiques ne sont plus supportés par défaut par l’éditeur unifié.

    Pour les builders :

    • Divi 5 : Les modules personnalisés doivent utiliser les nouveaux points d’entrée JS fournis par l’API de l’éditeur. Le système de sauvegarde côté Divi s’appuie désormais sur des hooks WordPress natifs (save_block) ; les anciens modules risquent de ne plus sauvegarder correctement leurs paramètres.
    • Elementor : Les widgets personnalisés doivent déclarer leur compatibilité avec le site editor. Les hooks elementor/frontend/after_register_scripts sont remplacés par des hooks block editor.
    • Avada : Le Fusion Builder doit être mis à jour pour utiliser la nouvelle API médias et les templates block. Les shortcodes classiques peuvent ne plus fonctionner selon la structure du template.

    J’ai déjà observé des problèmes où un code fonctionnait parfaitement en 6.8 mais plus en 6.9.4, simplement parce qu’un hook comme the_content n’était plus appelé dans le template block par défaut.

    Risques, compatibilités et points de vigilance

    • Plusieurs hooks historiques sont dépréciés ou n’ont plus d’effet dans l’éditeur unifié : the_content, get_the_excerpt, wp_head dans certains contextes.
    • Les thèmes enfants basés sur des templates PHP classiques ne sont plus garantis compatibles.
    • Les plugins qui manipulent la Media Library via les anciens filtres risquent d’être "silencieux" : plus d’erreur, plus de modification, rien dans les logs.
    • La gestion des assets (CSS/JS) change. Les assets non déclarés via wp_register_script ou wp_enqueue_block_script peuvent ne plus charger dans l’éditeur ou en frontend.
    • Les codes qui utilisent des fonctions non compatibles PHP 8.2+ (ex : certaines fonctions create_function) déclenchent des warnings ou sont ignorés.
    • Problèmes classiques : fichiers placés au mauvais endroit, oubli de vider le cache, permaliens non réinitialisés après passage à un template block, hooks personnalisés non déclarés dans le functions.php du thème enfant.
    • Le support PHP 7.4 et 8.0 sera supprimé avec WordPress 6.11 (Q4 2026).

    Tableau de diagnostic pour les problèmes courants :

    Symptôme Cause probable Vérification Solution
    Personnalisation du contenu inopérante Hook the_content plus appelé Debugger les hooks actifs sur la page Utiliser render_block ou save_block
    Erreur sur téléchargement d’image Plugin utilise vieux filtre media Vérifier les logs, tester avec le plugin désactivé Adapter plugin à la nouvelle API médias
    JS/CSS non chargé en éditeur Mauvais enqueue ou nom de handle erroné Inspecter l’éditeur, console du navigateur Utiliser wp_enqueue_block_script
    Module Divi/Elementor ne sauvegarde plus Hook obsolète ou API non compatible Consulter changelog builder Migrer sur nouveaux hooks JS/API
    Fatal error sur page Fonction PHP obsolète (create_function, etc.) Activer WP_DEBUG, consulter logs PHP Réécrire le code avec closures modernes

    Comment migrer

    1. Identifier les hooks utilisés : Recherchez tous les add_filter, add_action dans vos thèmes/plugins. Privilégiez render_block ou save_block pour les contenus.
    2. Vérifier les templates enfants : Passez aux templates block ou hybrides. Pour un template classique :
      
      // Ancien template enfant
      get_header();
      the_content();
      get_footer();
      
      Passez à :
      
      // Nouveau template block (template-parts/content-contact.html)
      
          
          
      
      
    3. Adapter la gestion des médias : Remplacez les hooks wp_handle_upload_prefilter etc. par la nouvelle API objet.
    4. Mettre à jour les modules Divi/Elementor/Avada : Déclarez explicitement la compatibilité avec l’éditeur site et les nouveaux hooks (voir la doc respective).
    5. Tester sur une copie locale : Jamais en production sans sauvegarde complète. Vérifiez la sauvegarde des modules personnalisés, le rendu des templates, la gestion des médias.
    6. Vérifier la compatibilité PHP : Passez vos serveurs/stacks à PHP 8.1 ou 8.2, vérifiez que tous les plugins/thèmes sont compatibles.

    Pièges fréquents : code copié d’un ancien tutoriel, snippet collé dans le mauvais fichier (functions.php parent au lieu d’enfant), oubli du purge cache, confusion entre actions et filtres.

    Faut-il agir maintenant ou attendre ?

    Si vous utilisez un thème enfant ou un plugin personnalisé qui touche au contenu, aux médias ou aux assets, il faut agir dès maintenant. Les hooks historiques sont déjà dépréciés (WP 6.9.4) et certains ne sont plus actifs en 6.10 bêta.

    Pour les sites purement FSE ou blocks natifs, la transition est quasiment transparente. Mais si vous avez des shortcodes, des templates PHP classiques ou des modules page builder custom, la migration est nécessaire pour garantir la pérennité de vos personnalisations.

    Je recommande de tester sur une copie locale, de consulter la dev note de chaque extension majeure, et de surveiller les logs PHP. Si votre builder (Divi/Elementor/Avada) publie un patch de compatibilité, appliquez-le sans attendre.

    Conseils de maintenance

    • Planifiez un audit complet de vos hooks et templates avant la sortie de WordPress 6.10 stable.
    • Mettez en place des tests automatiques pour les hooks personnalisés et la gestion des médias.
    • Utilisez WP-CLI pour scanner les hooks dépréciés et les fichiers de template classiques.
    • Consultez régulièrement les changelogs de vos plugins page builder. Divi 5, Elementor et Avada publient leurs propres guides de migration.
    • Passez vos serveurs à PHP 8.2 au plus tôt, testez la compatibilité de tous les plugins actifs.
    • Programmez des sauvegardes automatiques et des points de restauration avant chaque mise à jour majeure.
    • Déployez sur staging avant production, et purgez toujours le cache (serveur + navigateur) après migration.
    • Vérifiez la génération des permaliens et régénérez-les après modification du template ou migration FSE.

    Ressources

    FAQ

    1. Mon shortcode ne s’affiche plus, que faire ?
      Vérifiez si le template utilise encore do_shortcode ou si le contenu est désormais rendu via un block. Migrez votre logique sous forme de block personnalisé.
    2. Je vois des erreurs de type "hook non défini", normal ?
      Oui, de nombreux hooks (the_content, get_the_excerpt) sont dépréciés dans certains templates block. Passez sur render_block ou save_block.
    3. Divi 5/Elementor me dit que mes modules custom sont obsolètes
      Vos modules doivent cibler les nouveaux hooks JS/API du site editor. Consultez la doc officielle du builder utilisé.
    4. Mon plugin de gestion média ne bloque plus les mauvais fichiers
      Il doit utiliser la nouvelle API objet. Les anciens filtres sont ignorés dans la nouvelle Media Library.
    5. Mes CSS/JS ne chargent plus en éditeur
      Enregistrez-les avec wp_enqueue_block_script ou enqueue_block_editor_assets. Ne vous fiez plus aux anciens hooks globaux.
    6. Les permaliens sont cassés après migration
      Régénérez les permaliens dans Réglages > Permaliens après toute migration de template.
    7. Je vois encore des erreurs PHP 7.4
      Mettez à jour votre version PHP (min 8.1). Les extensions non compatibles doivent être remplacées.
    8. Puis-je continuer à utiliser des templates enfants PHP classiques ?
      Non, la compatibilité sera supprimée avec la sortie stable de 6.10. Passez aux templates block/hybrides.
    9. Comment vérifier la compatibilité de mon site ?
      Utilisez WP-CLI ou des plugins comme Query Monitor pour détecter les hooks dépréciés et surveiller les logs.
    10. Les mises à jour automatiques sont-elles sûres ?
      Toujours tester sur staging avant production. Les changements structurels peuvent casser le site si un plugin ou un thème n’est pas prêt.
  3. Prispôsobenie správy médií Vymeňte háky wp_handle_upload_prefilter atď. prostredníctvom nového objektového API.
  4. Aktualizujte moduly Divi/Elementor/Avada Explicitne deklarujte kompatibilitu s editorom stránky a novými hookmi (pozri príslušnú dokumentáciu).
  5. Otestujte na lokálnej kópii Nikdy nenasadzujte v produkčnom prostredí bez úplnej zálohy. Skontrolujte zálohu vlastných modulov, vykresľovania šablón a spracovania médií.
  6. Skontrolujte kompatibilitu s PHP Aktualizujte svoje servery/stacky na PHP 8.1 alebo 8.2 a overte, či sú všetky pluginy/témy kompatibilné.

Bežné úskalia: kód skopírovaný zo starého tutoriálu, úryvok vložený do nesprávneho súboru (functions.php rodič namiesto dieťaťa), zabudnutie na vymazanie vyrovnávacej pamäte, zámena akcií a filtrov.

Mali by sme konať teraz alebo počkať?

Ak používate podradenú tému alebo vlastný doplnok, ktorý ovplyvňuje obsah, médiá alebo prvky, musíte konaj terazHistorické hooky sú už zastarané (WP 6.9.4) a niektoré už nie sú aktívne v beta verzii 6.10.

Pre čisto FSE alebo natívne blokové stránky je prechod prakticky bezproblémový. Ak však máte shortcode, klasické PHP šablóny alebo vlastné moduly na tvorbu stránok, migrácia je nevyhnutná na zabezpečenie dlhodobej životaschopnosti vašich úprav.

Odporúčam testovať na lokálnej kópii, preštudovať si poznámky pre vývojárov ku každému hlavnému rozšíreniu a sledovať PHP logy. Ak váš nástroj na tvorbu rozšírení (Divi/Elementor/Avada) vydá záplatu kompatibility, okamžite ju nainštalujte.

Tipy na údržbu

  • Naplánovať audit kompletné vašich hookov a šablón pred vydaním stabilnej verzie WordPressu 6.10.
  • Nastavte automatizované testy pre vlastné hooky a manipuláciu s médiami.
  • použitie WP-CLI na vyhľadanie zastaraných hookov a klasických súborov šablón.
  • Pravidelne kontrolujte zoznam zmien pre vaše pluginy na tvorbu stránok. Divi 5, Elementor a Avada publikujú vlastné migračné sprievodcov.
  • Čo najskôr aktualizujte svoje servery na PHP 8.2 a otestujte kompatibilitu všetkých aktívnych pluginov.
  • Naplánujte automatické zálohy a body obnovenia pred každou väčšou aktualizáciou.
  • Pred produkciou nasaďte do stagingového prostredia a po migrácii vždy vyprázdnite vyrovnávaciu pamäť (server + prehliadač).
  • Skontrolujte generovanie permanentných odkazov a po úprave šablóny alebo migrácie FSE ich regenerujte.

zdroje

Často kladené otázky

  1. Môj krátky kód sa už nezobrazuje, čo mám robiť?
    Skontrolujte, či sa šablóna stále používa do_shortcode Alebo, ak sa obsah teraz vykresľuje prostredníctvom bloku, migrujte logiku do vlastného bloku.
  2. Vidím chyby ako „hook nie je definovaný“, je to normálne?
    Áno, veľa háčikov (the_content, get_the_excerpt) sú v niektorých šablónach blokov zastarané. Prepnite na render_block ou save_block.
  3. Divi 5/Elementor mi hlási, že moje vlastné moduly sú zastarané.
    Vaše moduly musia byť zamerané na nové JS/API hooky editora stránok. Preštudujte si oficiálnu dokumentáciu k nástroju na tvorbu, ktorý používate.
  4. Môj plugin na správu médií už neblokuje nesprávne súbory
    Musí používať nové objektové API. Staré filtre sa v novej knižnici médií ignorujú.
  5. Moje súbory CSS/JS sa už nenačítavajú v editore.
    Uložte ich pomocou wp_enqueue_block_script ou enqueue_block_editor_assetsNespoliehajte sa už na staré globálne háky.
  6. Trvalé odkazy po migrácii nefungujú
    Po akejkoľvek migrácii šablóny znovu vygenerujte trvalé odkazy v časti Nastavenia > Trvalé odkazy.
  7. Stále vidím chyby PHP 7.4.
    Aktualizujte verziu PHP (minimálne 8.1). Nekompatibilné rozšírenia je potrebné nahradiť.
  8. Môžem naďalej používať klasické podradené šablóny PHP?
    Nie, kompatibilita bude odstránená so stabilnou verziou 6.10. Prepnite na blokové/hybridné šablóny.
  9. Ako môžem skontrolovať kompatibilitu mojej webovej stránky?
    Na detekciu zastaraných hookov a monitorovanie protokolov použite WP-CLI alebo pluginy ako Query Monitor.
  10. Sú automatické aktualizácie bezpečné?
    Pred produkciou vždy otestujte v testovacom prostredí. Štrukturálne zmeny môžu poškodiť stránku, ak nie je pripravený doplnok alebo téma.