MevvBridge Documentation

Installation

MevvBridge exige WordPress 6.0 ou plus récent et PHP 8.1 ou plus récent. Il est entièrement gratuit et il n’existe pas d’édition Pro — aucune fonctionnalité n’est verrouillée.

Installez-le pendant qu’Elementor est encore actif. La voie figée est capturée à partir du rendu propre d’Elementor ; lancez la reprise avec Elementor désactivé et vous obtiendrez un résultat vide.

Téléversez l’extension et activez-la. Ne supprimez pas encore Elementor.
Ouvrez MevvBridge dans le menu d’administration de gauche et lisez le rapport.
Appuyez sur Prendre le relais. Rien n’est supprimé et aucune page n’est modifiée — seule l’apparence des éléments figés est capturée.
Désactivez Elementor et parcourez vos pages.
Si tout est en place, vous pouvez désinstaller Elementor.
Si vous le souhaitez, appuyez sur Convertir en blocs. Après cette étape, le contenu est du WordPress natif et MevvBridge lui-même peut aussi être supprimé.

Si quelque chose semble anormal après l’étape 4, réactivez Elementor : MevvBridge s’efface de lui-même.

Comment ça marche

MevvBridge lit la meta d’article _elementor_data — vos données d’origine, qu’il ne supprime jamais — et répartit chaque élément dans l’une des deux voies.

Voie vivante: Les éléments qu’il reconnaît sont reconstruits à partir de vos données à chaque requête, balisage comme CSS. Ils restent modifiables et ils restent responsives.
Voie figée: Tout le reste est capturé une seule fois, pendant qu’Elementor est encore installé : le HTML rendu de l’élément et seulement les règles CSS qui le visent. Il est réimprimé exactement tel qu’il était — non modifiable, mais pas cassé non plus.

La règle est une liste blanche, pas une liste noire. Un « je reconnais ceci » erroné casse la page ; un « je ne reconnais pas ceci » erroné ne coûte que la modifiabilité. Les widgets tiers sont délibérément hors de la liste blanche, parce que leurs schémas de contrôle nous sont fermés.

Tant que vous ne convertissez pas en blocs, votre post_content n’est pas touché du tout. MevvBridge se greffe sur the_content et produit la page en direct. Il ne le fait que tant qu’aucun constructeur de pages source n’est actif — réinstallez Elementor et le pont se retire.

Le rapport — lisez-le avant de partir

MevvBridge possède un seul écran d’administration, sous MevvBridge dans le menu de gauche. Il exige la capacité d’administrateur. Tout s’y passe.

L’analyse cherche le contenu publié qui porte des données Elementor, quel que soit son type de publication. C’est important : les en-têtes, les pieds de page et les bibliothèques de modèles sont stockés dans leurs propres types de publication, et une analyse limitée aux pages et aux articles les perd.

Résumé: Combien de pages, combien d’éléments, et combien d’entre eux vont se figer.
Le tableau: Une ligne par contenu : Contenu · Type · Actifs · Sera figé · Ce qui sera figé. La dernière colonne nomme les types de widgets qui vont être figés et combien il y en a de chaque.
Avertissement sur le contenu dynamique: Marqué ⚠. Du contenu qui change à chaque requête — une grille de produits, une liste d’articles. Une fois figé, il est épinglé sur ce qu’il montrait au moment de la capture.
Contenu qui ne peut pas être converti: Marqué ⛔. Des éléments qui cesseraient de fonctionner une fois figés — formulaires de paiement, formulaires de contact, connexions, carrousels. Les pages qui en contiennent sont refusées par la conversion en blocs et restent avec Elementor.

Deux problèmes différents, délibérément séparés : dynamique veut dire qu’il se périme, dangereux veut dire qu’il cesse de fonctionner.

La pastille d’état en haut affiche Actif lorsque MevvBridge produit vos pages, et Extension source active tant qu’un constructeur de pages source est encore actif.

Étape 1 — Prendre le relais

Cette étape ne supprime pas Elementor et ne modifie pas une seule page. Elle capture.

Le HTML rendu de chaque élément figé, pris dans le rendu front-end propre d’Elementor.
Seulement les règles CSS qui visent cet élément, avec le préfixe de portée de page retiré pour que les règles continuent de s’appliquer après la bascule.
Le SVG des éléments icône et boîte à icône — ceux-là restent dans la voie vivante, mais leur icône n’existe que dans la sortie rendue. Si le SVG manque, rien n’est imprimé ; une icône inventée serait pire.
Les feuilles de style que les extensions source ont réellement imprimées sur le front-end, copiées dans votre dossier uploads puis rechargées ensuite.
Les couleurs et la typographie globales d’Elementor issues du kit actif, réémises sous forme des mêmes variables CSS que vos pages référencent déjà.
Le CSS en ligne que votre thème n’imprime que tant qu’Elementor est actif.

Les éléments capturés sont stockés dans une table qui leur est propre plutôt que dans les metas d’article, afin de ne pas être chargés à chaque requête.

Tout le site est capturé en une seule requête. Sur un très grand site, cela peut atteindre la limite de temps de PHP — c’est une limite connue, pas un échec silencieux : l’avis de résultat vous indique combien d’éléments ont été capturés et énumère les premières erreurs.

Étape 2 — Convertir en blocs

Facultative, et débloquée seulement une fois l’étape 1 exécutée. Elle écrit du balisage de blocs standard dans post_content, si bien que le contenu devient du WordPress natif et que MevvBridge peut être désinstallé.

Les éléments reconnus deviennent des blocs mevvsoft/* — les blocs MevvBlocks.
Les éléments figés deviennent un bloc core/html avec leur CSS intégré à l’intérieur, si bien qu’ils survivent même une fois toutes les extensions parties.
Le post_content d’origine est sauvegardé dans la meta d’article _mevvbridge_onceki_icerik avant que quoi que ce soit ne soit écrit.

La conversion est du tout ou rien, page par page. Si un élément figé n’a pas d’instantané capturé, cette page est ignorée plutôt qu’écrite à moitié — une demi-page est pire que rien. Les pages portant un élément qui cesserait de fonctionner sont ignorées elles aussi, et l’avis les nomme.

Après cette étape, modifier ces pages nécessite MevvBlocks. Les consulter, non : le balisage est standard et les parties figées sont des blocs HTML natifs.

Pourquoi pas des blocs natifs ? Parce que jusqu’à WordPress 7.1 inclus, les attributs des blocs natifs n’ont toujours aucune notion de point de rupture. Sur la page d’accueil de référence, 23 des 35 éléments vivants portaient des valeurs tablette ou mobile ; les écrire en core/group aurait jeté soit la réactivité, soit la fidélité au pixel près.

Ce qui reste modifiable

Ces types d’éléments Elementor sont reconstruits à partir de vos données et restent dans la voie vivante :

containerheadingtext-editorbuttondividerimagetestimonialiconicon-boxicon-listshortcode

Les codes courts sont exécutés en direct plutôt que figés — figer un code court épinglerait sa sortie au moment de la capture.

Trois widgets tiers ont un équivalent natif et sont mis en correspondance plutôt que figés :

uael-woo-products: Devient le bloc produits, en portant le nombre d’articles, les nombres de colonnes ordinateur/tablette/mobile, le tri et le filtre de catégorie.
uael-woo-categories: Devient le bloc catégories de produits, en portant la mise en page, les colonnes, la position du titre et la règle de filtrage.
wpforms: Devient un bloc de code court contenant le code court WPForms. Ce n’est pas un moteur de formulaires de notre part — le widget ne faisait qu’appeler WPForms, et le code court fait de même.

Un type reconnu sans équivalent en bloc est figé plutôt qu’imité. Une correspondance approximative, c’est de la casse silencieuse.

Ce que figer signifie réellement

Un élément figé a l’air identique et continue de fonctionner en tant que balisage, mais :

il ne peut pas être modifié dans MevvBridge ni dans l’éditeur de blocs, au-delà du HTML brut ;
s’il affichait du contenu dynamique, il affiche désormais ce qu’il affichait le jour de sa capture ;
s’il avait besoin de JavaScript — un carrousel, un diaporama, un accordéon —, la copie figée imprime son contenu empilé, car le script qui le rendait interactif a disparu.

C’est ce dernier cas qui met les carrousels et les diaporamas sur la liste des éléments dangereux : MevvBridge ne convertit pas les pages qui en contiennent. Emporter le script de l’extension source a été écarté — il dépend du runtime front-end propre au constructeur et de sa configuration page par page.

Pour reprendre le contrôle d’un élément figé, soit réinstallez l’extension source, soit supprimez-le et reconstruisez-le avec un bloc.

Modèles d’en-tête et de pied de page

Une migration qui n’emporte que le corps de la page perd le pied de page en silence. MevvBridge imprime à leur place les modèles d’en-tête et de pied de page de la source, en les lisant dans les réglages propres à Header Footer Elementor.

Des recettes de thème existent pour Astra, GeneratePress et Storefront. Si votre thème n’a pas de recette, rien n’est imprimé du tout — boulonner un en-tête sur un thème que nous ne pouvons pas soulever, c’est deux en-têtes garantis. Si MevvBlocks a déjà un modèle correspondant, MevvBridge lui cède la place.

Les noms de classes d’origine sont reproduits, si bien que le CSS hérité de l’ancienne configuration continue de s’appliquer.

Revenir en arrière

Rien n’est supprimé à aucun moment. Vos _elementor_data restent exactement là où elles étaient ; MevvBridge les lit et n’y écrit jamais.

Avant la conversion en blocs: Réactivez Elementor. MevvBridge le détecte et se retire du filtre de contenu, du magasin de styles, des variables globales et de la reprise de l’en-tête et du pied de page. Il n’y a rien à annuler.
Après la conversion en blocs: Le contenu d’origine se trouve dans la meta d’article _mevvbridge_onceki_icerik de chaque page convertie. Il n’y a pas de bouton pour cela ; restaurez-le avec WP-CLI.

Une restauration comporte un piège : wp_update_post() attend une entrée échappée par des antislashs et les retire elle-même. Réécrivez la sauvegarde sans wp_slash() et les séquences d’échappement dans les attributs de blocs perdent leur antislash — les SVG s’affichent alors littéralement à l’écran sous la forme u003csvg.

wp eval '
foreach ( get_posts(["post_type"=>"any","numberposts"=>-1]) as $p ) {
  $y = get_post_meta( $p->ID, "_mevvbridge_onceki_icerik", true );
  if ( $y ) wp_update_post([ "ID"=>$p->ID, "post_content"=>wp_slash($y) ]);
}'

Videz ensuite le cache de page. Sur LiteSpeed : wp litespeed-purge all.

Free et Pro

Il n’y a aucune séparation à expliquer. MevvBridge est entièrement gratuit, y compris l’étape de conversion. Aucune fonctionnalité n’est bridée, il n’y a pas de clé de licence et il n’y a pas d’édition Pro.

C’est une position délibérée : cette extension existe pour vous sortir d’un abonnement. Faire payer la sortie serait le même piège d’une autre couleur.

Quand quelque chose ne fonctionne pas

Le rapport est vide: Aucun contenu publié ne porte de données Elementor. Les brouillons ne sont pas analysés.
La reprise n’a rien produit: Elementor était déjà désactivé. Réactivez-le, relancez la reprise, puis désactivez-le.
« Convertir en blocs » est grisé: L’étape 1 n’a pas encore été exécutée. Le verrou porte sur le fait que la reprise a bien eu lieu — pas sur le fait que quelque chose ait gelé, car un site avec zéro élément figé est le meilleur des cas et ne doit pas être exclu.
Certaines pages ont été ignorées par la conversion: Soit un élément figé n’avait pas d’instantané, soit la page porte un élément qui cesserait de fonctionner une fois figé. L’avis les compte ; le tableau du rapport les nomme avec ⛔.
La typographie ou les espacements ont bougé après la désactivation d’Elementor: Relancez la reprise avec Elementor actif. La capture des styles mesure ce que votre site a réellement imprimé sur le front-end : elle doit donc s’exécuter sur une requête front-end, pas depuis l’administration.
La page ressemble toujours à l’ancienne version: Un cache de page entière sert du HTML périmé. Videz-le — sur LiteSpeed, wp litespeed-purge all. Ajoutez une chaîne de requête aléatoire à l’URL pour vérifier la page non mise en cache.
Deux pieds de page sont apparus: Votre thème n’a pas de recette, ou un modèle de pied de page MevvBlocks est également actif. Vérifiez qu’un seul des deux produit le pied de page.
La reprise ou la conversion a expiré: Les deux s’exécutent en une seule requête. Sur un grand site, augmentez la limite de temps de PHP pour cette requête ou exécutez-les sur une machine moins chargée.

Limites

La liste ci-dessous, c’est le produit qui est honnête sur lui-même. Rien de tout cela n’est un bug.

Elementor uniquement. Beaver Builder est reconnu comme extension source pour pouvoir s’effacer, mais il n’existe pas de lecteur Beaver dans cette version.
Les widgets tiers gèlent toujours. Reproduire un schéma de contrôle fermé a été mesuré et a échoué dans chaque cas essayé ; figer est le résultat honnête.
Les éléments figés ne sont pas modifiables et ne le deviennent jamais d’eux-mêmes. Les promouvoir dans la voie vivante reste un travail à venir.
Le contenu dynamique est épinglé au moment de la capture. Une grille de produits figée ne suit pas votre catalogue.
Les pages comportant des formulaires, des pages de paiement, des connexions, des carrousels ou des diaporamas ne sont pas converties du tout — elles restent avec Elementor.
Seuls les modèles d’en-tête et de pied de page sont repris. Les vues uniques, archives et pop-ups du constructeur de thème d’Elementor Pro ne le sont pas.
Pas de moteur de formulaires. La correspondance WPForms porte l’appel ; c’est toujours WPForms qui imprime le formulaire.
Pas d’interface d’édition. MevvBridge effectue le rendu ; modifier les pages converties est le rôle de MevvBlocks.
La reprise de l’en-tête et du pied de page se limite à trois recettes de thème et aux réglages propres à Header Footer Elementor.
Les instantanés capturés vivent dans leur propre table : un export WXR de WordPress ne les emporte donc pas. La récupération reste sûre : réinstallez l’extension source et capturez de nouveau, car vos données d’origine n’ont jamais été supprimées.
Les deux opérations s’exécutent en une seule requête, sans découpage.

Désactiver Elementor sans casser le site.