MevvBridge Documentation

Installation

MevvBridge needs WordPress 6.0 or newer and PHP 8.1 or newer. It is completely free and there is no Pro edition — no feature is locked.

Install it while Elementor is still active. The frozen lane is captured from Elementor’s own rendering; run the takeover with Elementor switched off and you get an empty result.

Upload and activate the plugin. Do not remove Elementor yet.
Open MevvBridge in the left admin menu and read the report.
Press Devral (Take over). Nothing is deleted and no page is edited — only the look of the frozen elements is captured.
Deactivate Elementor and walk through your pages.
If everything is in place, you can uninstall Elementor.
Optionally press Bloklara çevir (Convert to blocks). After that step the content is native WordPress and MevvBridge itself can be removed too.

If something looks wrong after step 4, re-activate Elementor: MevvBridge steps aside on its own.

How it works

MevvBridge reads the _elementor_data post meta — your original data, which it never deletes — and splits every element into one of two lanes.

Live lane: Elements it recognises are rebuilt from your data on every request, markup and CSS alike. They stay editable and they stay responsive.
Frozen lane: Everything else is captured once, while Elementor is still installed: the element’s rendered HTML plus only the CSS rules that address it. It is printed back exactly as it was — not editable, but not broken either.

The rule is a whitelist, not a blacklist. A wrong “I recognise this” breaks the page; a wrong “I do not recognise this” only costs editability. Third-party widgets are deliberately outside the whitelist, because their control schemas are closed to us.

Until you convert to blocks, your post_content is not touched at all. MevvBridge joins in at the_content and produces the page live. It only does that while no source page builder is active — reinstall Elementor and the bridge withdraws.

The report — read it before you leave

MevvBridge has one admin screen, under MevvBridge in the left menu. It needs the administrator capability. Everything happens there.

The scan looks for published content carrying Elementor data, whatever its post type. That matters: headers, footers and template libraries are stored as their own post types, and a scan limited to pages and posts loses them.

Summary: How many pages, how many elements, and how many of them will freeze.
The table: One row per piece of content: İçerik · Tür · Canlı · Donacak · Ne donacak. The last column names the widget types that will freeze and how many of each.
Dinamik içerik uyarısı: Marked ⚠. Content that changes on every request — a product grid, a post list. Frozen, it is pinned to whatever it showed at capture time.
Çevrilemeyecek içerik: Marked ⛔. Elements that would stop working if frozen — checkout forms, contact forms, logins, sliders. Pages containing them are refused by the block conversion and left with Elementor.

Two different problems, deliberately separated: dynamic means it goes stale, dangerous means it stops working.

The status chip at the top says Devrede when MevvBridge is producing your pages, and Kaynak eklenti açık while a source page builder is still active.

Step 1 — Devral (take over)

This step does not remove Elementor and does not edit a single page. It captures.

The rendered HTML of every frozen element, taken from Elementor’s own frontend rendering.
Only the CSS rules that address that element, with the page-scope prefix stripped so the rules keep applying after the switch.
The SVG of icon and icon-box elements — those stay in the live lane, but their icon only exists in rendered output. If the SVG is missing nothing is printed; an invented icon would be worse.
The stylesheets the source plugins actually printed on the front end, copied into your uploads folder and re-enqueued afterwards.
Elementor’s global colours and typography from the active kit, re-emitted as the same CSS variables your pages already reference.
Inline CSS your theme prints only while Elementor is active.

Captured elements are stored in a table of their own rather than in post meta, so they are not loaded on every request.

The whole site is captured in a single request. On a very large site that can hit the PHP time limit — this is a known limit, not a silent failure: the result notice tells you how many elements were captured and lists the first errors.

Step 2 — Bloklara çevir (convert to blocks)

Optional, and unlocked only after step 1 has run. It writes standard block markup into post_content, so the content becomes native WordPress and MevvBridge can be uninstalled.

Recognised elements become mevvsoft/* blocks — the MevvBlocks blocks.
Frozen elements become a core/html block with their CSS inlined inside it, so they survive even after every plugin is gone.
The original post_content is backed up to the _mevvbridge_onceki_icerik post meta before anything is written.

Conversion is all-or-nothing per page. If a frozen element has no captured snapshot, that page is skipped rather than half written — half a page is worse than none. Pages carrying an element that would stop working are skipped too, and the notice names them.

After this step, editing those pages needs MevvBlocks. Viewing them does not: the markup is standard, and the frozen parts are core HTML blocks.

Why not core blocks? Because through WordPress 7.1 core block attributes still have no breakpoint concept. On the reference homepage 23 of 35 live elements carried tablet or mobile values; writing them as core/group would have thrown away either the responsiveness or the pixel fidelity.

What stays editable

These Elementor element types are rebuilt from your data and stay in the live lane:

containerheadingtext-editorbuttondividerimagetestimonialiconicon-boxicon-listshortcode

Shortcodes are run live rather than frozen — freezing a shortcode would pin its output to the moment of capture.

Three third-party widgets have a native equivalent and are mapped instead of frozen:

uael-woo-products: Becomes the products block, carrying the item count, the desktop/tablet/mobile column counts, the ordering and the category filter.
uael-woo-categories: Becomes the product categories block, carrying the layout, columns, title position and filter rule.
wpforms: Becomes a shortcode block holding the WPForms shortcode. This is not a form engine of ours — the widget did nothing but call WPForms, and so does the shortcode.

A recognised type with no block equivalent is frozen rather than imitated. Approximate mapping is silent breakage.

What freezing actually means

A frozen element looks identical and keeps working as markup, but:

it cannot be edited in MevvBridge or in the block editor beyond raw HTML;
if it showed dynamic content, it now shows what it showed on the day it was captured;
if it needed JavaScript — a slider, a carousel, an accordion — the frozen copy prints its contents stacked, because the script that made it interactive is gone.

That last case is why sliders and carousels are on the dangerous list: MevvBridge does not convert pages that contain them. Carrying the source plugin’s script over was rejected — it depends on the builder’s own frontend runtime and its per-page configuration.

To get a frozen element back under your control, either re-install the source plugin, or delete it and rebuild it with a block.

Header and footer templates

A migration that only carries the page body loses the footer silently. MevvBridge prints the source header and footer templates in their place, reading them from Header Footer Elementor’s own settings.

Theme recipes exist for Astra, GeneratePress and Storefront. If your theme has no recipe, nothing is printed at all — bolting a header onto a theme we cannot lift means two headers, guaranteed. If MevvBlocks already has a matching template, MevvBridge yields to it.

The original class names are reproduced, so CSS inherited from the old setup keeps applying.

Going back

Nothing is deleted at any point. Your _elementor_data stays exactly where it was; MevvBridge reads it and never writes to it.

Before the block conversion: Re-activate Elementor. MevvBridge detects it and withdraws from the content filter, the style store, the globals and the header/footer takeover. There is nothing to undo.
After the block conversion: The original content is in the _mevvbridge_onceki_icerik post meta of each converted page. There is no button for this; restore it with WP-CLI.

A restore has one trap: wp_update_post() expects slashed input and unslashes it itself. Write the backup back without wp_slash() and escape sequences inside block attributes lose their backslash — SVGs come out on screen as literal 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) ]);
}'

Clear the page cache afterwards. On LiteSpeed: wp litespeed-purge all.

Free and Pro

There is no split to explain. MevvBridge is entirely free, including the conversion step. No feature is gated, there is no licence key and there is no Pro edition.

That is a deliberate position: this plugin exists to get you out of a subscription. Charging for the way out would be the same trap in a different colour.

When something does not work

The report is empty: No published content carries Elementor data. Draft pages are not scanned.
Take over produced nothing: Elementor was already deactivated. Re-activate it, run the takeover again, then deactivate it.
“Bloklara çevir” is greyed out: Step 1 has not been run yet. The gate is on the takeover having run — not on whether anything froze, because a site with zero frozen elements is the best case and should not be locked out.
Some pages were skipped by the conversion: Either a frozen element had no snapshot, or the page carries an element that would stop working when frozen. The notice counts them; the report table names them with ⛔.
Typography or spacing shifted after switching Elementor off: Run the takeover again with Elementor active. The style capture measures what your site actually printed on the front end, so it has to run on a front-end request, not from the admin.
The page still looks like the old version: A full-page cache is serving stale HTML. Purge it — on LiteSpeed, wp litespeed-purge all. Add a random query string to the URL to check the uncached page.
Two footers appeared: Your theme has no recipe, or a MevvBlocks footer template is also active. Check that only one of them is producing the footer.
The takeover or the conversion timed out: Both run in a single request. On a large site, raise the PHP time limit for that request or run them on a quieter machine.

Limits

The list below is the product being honest about itself. None of it is a bug.

Elementor only. Beaver Builder is recognised as a source plugin for the purpose of stepping aside, but there is no Beaver reader in this version.
Third-party widgets always freeze. Reproducing a closed control schema was measured and failed on every case tried; freezing is the honest outcome.
Frozen elements are not editable and never become editable on their own. Promoting them to the live lane is future work.
Dynamic content is pinned at capture time. A frozen product grid does not follow your catalogue.
Pages with forms, checkouts, logins, sliders or carousels are not converted at all — they stay with Elementor.
Only header and footer templates are carried over. Elementor Pro theme-builder singles, archives and popups are not.
No form engine. The WPForms mapping carries the call; WPForms still prints the form.
No editing UI. MevvBridge renders; editing converted pages is MevvBlocks’ job.
Header/footer takeover is limited to three theme recipes and to Header Footer Elementor’s own settings.
Captured snapshots live in their own table, so a WordPress WXR export does not carry them. Recovery is safe anyway: reinstall the source plugin and capture again, because your original data was never deleted.
Both operations run in one request, with no chunking.

Switch Elementor off without breaking the site.