MevvBlocks — Mevvsoft Documentation

Installation

MevvBlocks needs WordPress 6.0 or newer and PHP 8.1 or newer. There is no other dependency: no external library, no font from someone else’s server, no build step.

Upload and activate the plugin.
Open a page in the block editor and add the Container block.
Put the blocks you want inside it. You will find them in the Design category.
Manage the rest from the MevvBlocks menu in the admin sidebar.

WooCommerce is optional. Installing it adds two blocks.
MevvBridge is optional. If you came from Elementor, MevvBlocks is what makes those pages editable again.
MevvLegal is optional. If it is present, the map block hands its embed to MevvLegal so the map is not loaded before the visitor consents.

Pro is a separate plugin installed alongside the free one, and it declares the free plugin as a hard requirement. Your licence key is entered on the Lisans screen. With Pro absent, MevvBlocks makes no request to our servers at all.

Style per screen size — the gap this closes

Core blocks accept one padding value, one minimum height, one column count. That value applies on every screen. If a section needs 100 pixels of padding on desktop and 40 on mobile, core cannot express it — and that single gap is the most common technical reason people install a page builder.

MevvBlocks stores three values instead of one — desktop, tablet, mobile. The thresholds are fixed:

Desktop: No media query — the base value.
Tablet: Applies at 1024 pixels and below.
Mobile: Applies at 767 pixels and below.

The same two numbers are used everywhere else in the plugin — the menu’s hamburger threshold, the grid’s column counts. A free pixel field was deliberately not offered: someone picking 900 would get a hamburger at 900 while their padding still changed at 1024, and two breakpoint systems mean layouts that disagree with themselves.

Values live in the block’s own attributes, inside post_content — not in a custom table and not in post meta. The CSS is produced on the server, at request time, and printed as a small style block next to the element it belongs to.

Why not save the CSS with the page? Because saved HTML can only carry one breakpoint. Rendering on request is what makes three values possible at all — and it is why a lapsed licence can never darken a published page: there is not a single licence check on that path.

The editor preview — what it shows, and what it still cannot

This page used to say the preview was an approximation. It no longer is, for layout. The canvas now asks the server for the same CSS the page will print, and applies it to the same wrapper classes the front end uses.

What is accurate in the canvas today: container layout (direction, columns, gap, alignment), padding, margin, background, border, radius, shadow, minimum height, typography, transforms, masks and positioning — with the tablet and mobile values applying as you resize, because the canvas is an iframe and media queries work inside it.

Why the CSS comes from the server rather than being rebuilt in JavaScript: there is one style engine, and a second copy would drift out of step with the first. The day someone added a setting to one and forgot the other, the editor would be wrong while claiming to be exact — worse than the old honest approximation.

What is still not exact: rules that target the markup inside a block. In the canvas a block draws its own editing affordances, so a selector written against the front-end structure has nothing to match. Closing that means making the editing markup identical to the published markup for every one of the hundred and ten blocks; it is real work and it is not done.

Measured, not asserted: the same section was rendered twice under the same stylesheet — once as the front end prints it, once as the canvas builds it — and sixteen layout properties compared on each element. The old canvas differed in twenty-four of them. It is now zero out of sixty-four. The tool that measures it is in the plugin source (tools/onizleme-esitlik.js), and it was first pointed at the old markup to prove it was not blind.

The blocks

A hundred and ten blocks, or eighty-seven without WooCommerce. All of them are in the free edition except the three marked Pro below; no other block is Pro-only. They live in the Design category of the inserter, and the setting keys each one stores are listed in docs/BLOK-AYARLARI.md inside the plugin — a generated file, so it cannot drift away from the code.

The groups below are the same five the plugin uses for its own showcase pages.

Text and action: Container, Heading, Text, Button, Divider, Spacer, Anchor, Image, Shortcode, Quote, Checklist, Code, Call to Action, Icon, Icon Box, Icon List, Animated Heading, Alert, Toggle, Nested Tabs with Tab Panels, Tabs, Accordion, FAQ, Steps
Data and pricing: Counter, Progress Bar, Data Bar, Pie Chart, Number Box, Pricing Table, Price List, Testimonial, Star Rating, Testimonial Carousel, Team Member, Countdown, Badge, Logo Strip, Content Switcher and Switcher Panel (Pro)
Portfolio and map: Timeline, Table, Comparison, Table of Contents, Map, Content Grid, Sitemap, Portfolio (Pro)
Media and forms: Video, Audio, Playlist, Gallery, Before / After, Flip Box, Banner, Hotspot, Tooltip, Social Feed, Social Icons, Social Sharing, Slider, Slides, Text on a Path, Off-canvas Panel, Contact Buttons, Announcement Bar, Reading Progress, Reading Time, Back to Top, Form, Login Form, Registration Form, Newsletter, Search Form, Navigation Menu, Lottie (Pro)
Design and motion: SVG Animation, Image Box, Copyright, and the eight block styles described below. Motion is not a block: an entrance animation, sticky position and parallax panel is added to every MevvBlocks block.
Site and theme templates: Site Logo, Site Title, Site Tagline, Page Title, Breadcrumbs, Post Info, Author Box, Comments, Previous / Next, Archive Title, Archive Description
WooCommerce (23): Products, Product Categories, Product Images, Product Title, Product Price, Product Rating, Short Description, Product Description, Product Meta, Additional Information, Product Tabs, Add to Cart, Stock Status, Related Products, Upsells, Cross-sells, Mini Cart, Cart, Checkout, My Account, Order Tracking, Product Sorting, Result Count — added only when WooCommerce is active

A note on the ones added most recently, because each carries a decision you can see on the page:

Toggle: A native <details> that takes any blocks inside it and can be nested inside another toggle. Settings: baslik (the summary text) and acik (open on load). No id is needed, so two toggles on the same page cannot collide.
Nested Tabs and Tab Panel: A tab group whose panels are ordinary inner blocks, so a panel can hold anything — including another tab group. Group settings: yon (horizontal or vertical) and acik (the tab open on load); each panel has a baslik. The tab strip carries the ARIA tab pattern with arrow keys, Home and End, and ids are made unique per group so nesting is safe. Only direct child panels belong to a group. A vertical strip turns horizontal on a narrow screen.
Pie Chart: Pie or donut (tur), rows written as “label | value | optional colour” in satirlar, plus a baslik. The circle is drawn with stroke-dasharray and carries role="img"; the same values are printed underneath as a text list with their percentages, because a chart nobody can read is a decoration. It does not animate.
Playlist: Audio or video (tur), with a baslik and a repeater of tracks: dosya, baslik, sure, poster and altyazi (a WebVTT track). Every track is printed as an ordinary link, so the list is usable before any script runs; with the script, choosing a track swaps the source in place.
Social Feed: Posts you choose by hand, laid out in sutun columns. Each item has adres, metin, tarih and gorsel. There is no API adapter, no token and no request to any network — this is a list of links, and the plugin says so rather than implying a live feed.
Tooltip: metin is the word in your sentence, ipucu the explanation, konum the side it opens on. It is a real button with role="tooltip" on the bubble: hover and focus are handled in CSS, tap in script, and Escape closes it. The bubble is hidden with visibility rather than removed, so the described-by relationship stays in the accessibility tree.
SVG Animation: dosya is the SVG, durgun a still frame, alt the alternative text and genislik the width. The file is rendered inside an <img>, deliberately: script inside an SVG cannot reach your page that way. A <picture> swaps in the still frame when the visitor has asked for reduced motion.
Alert, Animated Heading, Timeline, Table, Flip Box: The alert can be given a dismiss button (kapatilabilir) and moves focus to the next element when dismissed; its type and title are editable. The animated heading picks its tag (baslik_etiketi, h1–h6, p, div or span) and can type its words (etki) — the first word is always printed, and both effects stop under reduced motion. The timeline takes a horizontal layout (yon) that returns to vertical on a narrow screen without changing the reading order. Table header cells carry scope="col" and an empty cell prints a dash with a screen-reader label. The flip box turns on tap, Enter and Space, and Escape turns it back.
Content Switcher (Pro): A tab strip — typically monthly and yearly — over Switcher Panels that hold any blocks. Settings: etiket (the strip’s accessible name), rozet (a badge such as a saving) and acik; each panel has a baslik.
Portfolio (Pro): gonderi_turu, taksonomi, terimler, adet, sutun, suzgec (show the filter) and arsiv_bag (link to the archive). The cards are rendered on the server and the filter only hides and shows them in the browser, so no request leaves the page. There is no modal and no pagination.
Lottie (Pro): adres, alt, baslik, durgun (a still frame), onay and onay_metni. LottieFiles is an outside service, so the block takes the same consent path as the map and the video: it shows the still image until the visitor agrees, and under reduced motion it never plays. The player library is still not bundled.

Nothing here is hidden when JavaScript does not load. Tabs show every panel, the toggle and the accordion are native details elements, the slider scrolls, the playlist is a list of links, and the arrows are printed hidden until the script can drive them — showing a button that does nothing is showing a broken interface. Hidden content is inaccessible content. Buttons and action links have a 44-pixel minimum target size.

Block styles

Eight styles are registered through WordPress’s own register_block_style, so they appear in the Styles panel the editor already shows for a selected block. There is no new control to learn, and the choice is stored as an is-style-… class in your markup rather than as a setting in a table of ours.

Gradient overlay: Container, Image, Image Box, Banner, Slider
Grayscale, colour on hover: Image, Image Box, Team Member, Logo Strip, Gallery
Blur until hover: Image, Image Box, Banner
Circle mask / Rounded mask: Image, Image Box, Team Member — and, for the rounded one, Banner and Gallery
Lift on hover: Container, Icon Box, Image Box, Pricing Table, Team Member, Testimonial, Call to Action, Banner
Zoom image on hover: Image, Image Box, Banner, Gallery
Tilt on hover: Icon Box, Image Box, Banner, Number Box

Every hover transform is switched off when the visitor’s system asks for reduced motion. Applying a style needs the block’s wrapper to carry the class, which is why the render layer now cleans core’s className attribute off the inner markup and prints it on the wrapper instead; pages converted with MevvBridge never carried that attribute, so they are unaffected.

The newsletter block

An address field, an optional name field (ad_alani), a consent checkbox and a submit button. The texts are yours: baslik, metin, dugme_metni, onay_metni and basari_metni.

It is a plain POST signed with an HMAC, not a nonce. A nonce is tied to the session and to twelve hours; behind a full-page cache an expired nonce kills the form silently. The signature is the same one the form engine uses.
A honeypot field is swallowed in silence. Showing an error would teach the next bot to skip the trap.
A rate limit applies per address.
The consent rule is read from the block’s own content, never from the submitted form — reading it from a hidden field would put the setting in the visitor’s hands.
Addresses are stored with your other form submissions, under a bulten: key. There is no list of ours and no request to a third party.

To hand a confirmed address to whatever you already use, hook the action:

add_action( 'mevvblocks_newsletter_subscribe', function ( $eposta, $ad, $blok_kimligi ) {
    // $eposta       : the confirmed address
    // $ad           : the name, or an empty string when the field is off
    // $blok_kimligi : which newsletter block it came from
}, 10, 3 );

The action fires after the address has been validated and stored, so a failure in your handler cannot lose the subscription.

Dynamic text and custom fields

Heading, Text, Button and Image blocks can take their value from the post rather than from what you typed. The panel is called Dynamic, and the sources are a fixed list: post title, excerpt, author, date, first category, tags, comment count, archive title, search term, site name and tagline, the current year, the WooCommerce price, SKU and stock — and a custom field by key.

With Advanced Custom Fields active the field is read through get_field(), so you get the formatted value rather than the raw one. Without ACF it falls back to plain post meta, and nothing breaks either way.
Keys beginning with an underscore are refused. Those are WordPress’s internal fields; printing them would leak what the page never meant to show.
There is no “run this expression” field. That would hand code execution to anyone who can edit a page.

While you edit a loop card template there is no post context, so a dynamic binding shows its static fallback instead of a value. That is the template, not the page.

Content grid and the loop builder

The Content Grid block queries posts, pages or products and lays them out. Pagination is plain links, so it works with JavaScript switched off.

Ordering is a fixed list — date, modified, title, menu order, random — because the value reaches the database.
Card headings run from h2 to h6. h1 is not offered: a grid of cards on a page that already has an h1 would break the heading order.
One link per card. Making the image, the title and the “read more” all links means a screen reader announces the same target three times.
The grid caches the post ids it found, never the rendered HTML, and the cache is invalidated by any post being saved — so “I published a post and it is not showing” cannot happen.

The loop builder lets you draw the card yourself instead of using the built-in one. You create a template of type Loop card, build it out of ordinary blocks with dynamic bindings, and pick it in the grid’s settings.

While you edit a card template there is no post context, so dynamic bindings show their static fallbacks. And if the template is empty, deleted, left as a draft or refers back to itself, the grid falls back to the built-in card rather than printing nothing. Loop nesting is capped at two levels.

The form engine

Sixteen field types, with server-side validation. The form is the one part of a page that actually does something, so it works without JavaScript: a plain POST submission gets the same validation and the same messages as a scripted one.

Field types: Text, Email, Phone, Address (URL), Number, Date, Time, Hidden, Long text, Dropdown, Multiple choice list, Single choice, Multiple checkboxes, Checkbox, Consent text (KVKK) and Subheading. Pro adds a file upload field.
Where submissions go: Both to a table of their own and to email. The record is written first and the mail sent second, because mail delivery fails far more often than a database write.
Reading them: MevvBlocks → Form Submissions. Pro adds a CSV export there.
Notification email: The sender is your site, never the visitor. Using the visitor’s address as the sender is the single most common reason form mail never arrives — SPF and DMARC reject it. Their address becomes the Reply-To instead.

Spam is handled by three layers and no CAPTCHA: a signature that does not depend on a session, a minimum fill time, and a honeypot field. A submission that fills the honeypot is silently accepted and discarded — showing an error would tell the bot it was caught, and the next attempt would skip that field.

Why a signature rather than a WordPress nonce? A nonce is tied to a session and a twelve-hour window. On a cached site the same HTML is served for hours or days, the nonce inside it has long expired, and the form silently stops working. That is the most common field failure of form plugins. The signature here is valid for seven days and does not depend on who is browsing.

The IP address of a submission is never stored in readable form — only a digest, salted with your own site’s key, so records from two different sites cannot be matched against each other.

Submission storage is not tied to the licence. If it were, the day a payment lapsed would be the day the customer started losing data.

Theme templates

Seven template types, built in the WordPress editor you already use — Header, Footer, Single content, Archive, Search results, Not found (404) and Loop card. A second editor would be one more thing to keep in step with WordPress core.

The type and the conditions sit in a plain sidebar box, not a React panel — a classic box also saves with JavaScript off, and it does not break when the editor API changes.

Conditions: Whole site, home page, post type, category, or a single piece of content. Leave them empty for the whole site.
When several match: The narrowest condition wins.
Malformed conditions: Discarded on save and stored empty, rather than kept as invalid text that would make the template silently never appear.

Header and footer templates are placed only on Astra and GeneratePress. If your theme has no recipe, they are not printed at all and the screen says so — attaching a header to a theme we cannot lift means two headers, guaranteed. Singular, archive, search and 404 templates keep working on any theme, because they replace the loop and leave the theme’s own header and footer in place.

A Loop card template never places itself anywhere. A grid block chooses it.

Pattern library and block presets

Seventy-six ready-made patterns: sixty-four sections and twelve full pages. They are registered as ordinary WordPress patterns, so you insert them the way you already know — the + button, the Patterns tab, then the MevvBlocks sections or MevvBlocks pages category. The sections run across hero, feature, testimonial, FAQ, pricing, call-to-action, contact, about, pre-footer and statistics families; the pages add three home-page variants, an FAQ page, a campaign page, a story page and a thank-you page.

No custom modal was written for this. Core’s inserter already gives preview, search, keyboard navigation and translation for free, and what it inserts is plain block markup — nothing to be locked into.

Nine of them need WooCommerce: eight product and category sections and one shop landing page. They live in their own file and are registered only while WooCommerce is active, so a store-less site is never offered a pattern that would insert a block it cannot draw. The products in them come from a query — new, featured, on sale, best selling — rather than from a category id written into the pattern, because the same id lands on an empty or simply wrong category in another shop.

The patterns ship with no images. Pulling images from elsewhere is a copyright question, a privacy question, and it ties how your page looks to somebody else’s server staying up. The image blocks are in place with their alt text filled in; choose your own.

Block presets save a block’s appearance settings under a name and apply them to another block of the same type. Content is deliberately not saved — text, links, images and list items are stripped out, so applying a preset never overwrites what you wrote.

Patterns are not registered on the front end at all. Generating their markup on every page view was measured at 109 KB and 3,59 ms — paid for nothing, since nobody inserts a pattern while reading.

Popups

Built in the block editor like anything else; the triggers, conditions and frequency live in the same screen’s sidebar. Managed under MevvBlocks → Popups.

Triggers: On page load with a delay, at a scroll percentage, on exit intent, on a click matching a CSS selector, or after a period of active time. The activity timer stops while the tab is in the background.
Conditions: Whole site, home page, specific pages, post type or category; logged in, logged out or everyone; and per device.
Frequency: Every time, once per session, or once every N days.
Appearance: Position, width, whether the title shows, whether clicking outside closes it, and the opening animation.

The “do not show again” counter is kept in the visitor’s own browser, not on the server. Counting it server-side would mean minting a durable identity for every visitor just to avoid showing them a box twice.

Device targeting is decided by the browser, not by sniffing the user agent. A user agent cannot reliably tell a tablet from a phone, and behind a full-page cache it would serve the first visitor’s device to everyone. If no trigger is selected the popup falls back to page load; if no device is selected it falls back to all three — a popup that silently never appears is worse than one that appears too often.

The site palette

One screen for colours and typography, reachable both from the MevvBlocks menu and from Appearance, because that is where people look for it. Every entry shows its own variable name, and blocks refer to those names rather than to literal values.

That is what lets a page built before the switch pick up a new palette instead of losing its references — the variable names are kept the same ones your pages already use.

There is no delete. A colour or typography set can be left empty, but removing it would leave every block that referred to it pointing at nothing. Emptying is reversible; deleting a reference is not.

The accessibility audit

MevvBlocks → Accessibility scans your published pages, posts and templates and reports what each block left out: an image with no alt text, an empty heading, a button with no name or no target, a broken heading order, contrast that is too low.

The same audit is available as a sidebar panel while you are still editing, which is where a finding is cheapest to fix.

This is deliberately not an overlay. Layers that bolt an “accessibility menu” onto a page fix nothing: an image with no alt text still has none, and low-contrast text is still unreadable. Carrying the claim “this site is accessible” without it being true is a worse position than making no claim — sites using overlays have been sued over exactly that. This tool measures and tells you; the fixing is yours.

Contrast is only reported when both colours are actually known. Guessing at an inherited colour would produce warnings you cannot act on.

Speed — element caching and images

Two separate things, both in the free edition.

Element caching. Block output is stored instead of being rebuilt on every request. Measured: block render time down 33–72%. It uses a persistent object cache (Redis, Memcached) when one exists, and transients when it does not.

A block whose output varies by visitor, by query or by moment is never stored: forms, login, registration, mini cart, product grid, search, cart, checkout, my account, shortcode. Shortcode is on that list because we do not know what is inside it — we froze a WPForms token on a live site once, and the rule has been enforced from source ever since.

Image optimisation. A WebP (optionally AVIF) copy of every uploaded image is written next to the original; the original is never touched. Measured: 39–78% smaller. A file that does not shrink is not kept — small flat PNGs usually grow as WebP.

Images are served inside a <picture> element: every format's address is in the HTML and the browser chooses. Deciding on the server from the Accept header was deliberately not used — when the same address varies by visitor, every cache in the path can hand the wrong file to the wrong person.

If another plugin is genuinely doing this job (LiteSpeed, ShortPixel, Imagify, Smush, EWWW, Optimole, Converter for Media), MevvBlocks stands down on its own and says why. The question is not "is it installed" but "can it actually run": LiteSpeed with image optimisation switched on but no cloud key does nothing at all.

Core Web Vitals — measured on your visitors

Core Web Vitals is field data by definition: measured in the browsers of real visitors, reported as the 75th percentile over a 28-day window. A Lighthouse run is a different thing — one machine, one network, one time. Knowing which is which is what settles the “PageSpeed says 98, Search Console says red” confusion.

The Web Vitals screen shows three numbers per device class:

LCP: How long the main content takes to appear. Good is 2.5 seconds or less.
CLS: How much the page moves while it settles. Good is 0.1 or less.
INP: How long the page takes to respond to a tap or click. Good is 200 ms or less.

The measuring script is about a kilobyte and loads no library — the browser’s own PerformanceObserver does the work. Sampling defaults to 10% of visits and the browser decides, not the server: if the server decided, the same URL would produce two different HTML documents and a full-page cache would serve whichever it saw first to everyone.

Nothing personal is collected: no IP, no cookie, no identifier. Three values, a device class and the page path, stored on your own server as bucketed counts. Nothing is sent anywhere.

Below a hundred samples the screen shows no number at all — it says how many it has instead. A percentile from a dozen measurements is noise, and a wrong number is worse than no number because someone will act on it. The percentile is read from a histogram, so it is approximate to the bucket width, and the screen says so.

Transforms and masks

Any block can be translated, scaled, rotated (Z and 3D X/Y), skewed and flipped — each with separate desktop, tablet and mobile values. A separate hover transform and a transition duration can be set.

Masks can be a circle, triangle, hexagon, blob, flower, freehand shape or your own image, with size, position and repeat controls.

The shapes are embedded in the CSS, not shipped as separate SVG files. A wrong file path makes a mask vanish silently and nobody sees the 404; behind a CDN the plugin folder address can change too.

Site-wide custom code

HTML, CSS and JavaScript can be placed in the head, at the start of the body or at the end: verification tags, measurement snippets, small style fixes. Position, priority and a session condition are configurable.

It does not run PHP. Putting a PHP runner inside a page builder would turn a designer's permission into permission to run code on the server.

The capability required is unfiltered_html: someone who cannot put a raw script in a post cannot put one site-wide either. With MevvLegal installed, tracking scripts placed here are also held until cookie consent is given.

WooCommerce blocks

Twenty-three blocks: product title, images, price, add to cart, rating, stock, meta, short description, description, data tabs, additional information, related products, upsells, cross-sells, cart, checkout, my account, order tracking, sorting and result count — plus products, product categories and a mini cart.

None of them redraws WooCommerce. They all call its own template functions and shortcodes. Your theme changes those templates and your plugins hook into them — shipping, instalments, stock notifications, size charts. Drawing our own markup would drop all of it silently.

Cart, checkout, my account and order tracking are visitor-specific: full-page caching is switched off and they are never element-cached. If WooCommerce is not active, these blocks are registered neither on the server nor in the editor.

Editor notes

You can pin a note to any block: who wrote it, when, and whether it is resolved.

Notes are NEVER printed on the page. There is not a single front-end hook in that file and a test enforces it. Notes are internal conversation; a visitor seeing them would be worse than a broken layout.

A note is tied to the block’s identity. Duplicating a block gives the copy a NEW identity, so it does not inherit the note — and as a side benefit it gets its own CSS scope.

Notes live in the post’s own data: delete the post and the notes go with it, leaving no orphaned rows.

AI in the editor — with your own key

Write, rewrite, shorten, generate image alt text and translate. Anthropic and OpenAI are supported.

You enter YOUR OWN API key and the request goes from your site DIRECTLY to the provider. Your text never reaches us; the quota and the bill stay with you. We did not build our own cloud service: your text would then pass through our servers and the data responsibility would become ours.

The key never reaches the browser — the request is made from the server. It is not returned by any endpoint either; even the settings form does not print the value back.

We do NOT encrypt the key, and we say so plainly: in WordPress the encryption key has to sit on the same server, so an attacker with database access gets both. Calling it "encrypted" would promise a protection that does not exist.

The result is not written straight into the block; it arrives as a suggestion and you apply it. That is our real defence against a sentence buried in your content being read as an instruction — a human approves.

Reading the theme’s theme.json

A block theme already declares its palette and typography in theme.json. MevvBlocks can read that file and use it to fill the empty slots in its own site palette, so the colours you pick in a block are the colours the theme already uses instead of a second, competing set.

The bridge is one-way and stays that way. Nothing is ever written back into theme.json. A plugin that edits the theme’s own file leaves you with a file the theme update will overwrite — and no way to tell which of the two was right. It also only fills slots you have left empty: a colour you set by hand is never replaced.

It is off until you switch it on, because a site that already has a palette does not want it quietly re-pointed at the theme’s.

The mega panel

A submenu can open as a full-width panel of up to four columns instead of a narrow dropdown. It is not a new block — it is a setting on the navigation block you are already using, so the menu keeps its markup, its keyboard behaviour and its mobile layout.

Switch the panel on for a menu item that has no submenu and the accessibility check says so. An empty panel is not a small cosmetic problem: it is a control that announces itself to a screen reader and then contains nothing.

A first draft of a page, from a sentence

Describe the page you want and the model chooses sections from the plugin’s own pattern library. It never writes markup: it returns a list of section keys, and MevvBlocks renders those sections itself. What lands on the page is therefore ordinary blocks you can edit, not generated HTML you have to clean up.

A section key the model invents does not exist in the library, so it is dropped — and the screen tells you it was dropped rather than silently producing a shorter page.
The page is always created as a draft. There is no code path that publishes it.
It uses the same key you entered for the editor’s AI tools: your own Anthropic or OpenAI key, stored on your site, with the request going straight from your server to the provider.

Free and Pro

The free edition is the whole product: a hundred and seven of the hundred and ten blocks, the eight block styles, theme templates, the grid and loop builder, the form engine with its submission store, the newsletter form, dynamic text including ACF fields, the menu, search, popups, the pattern library, block presets, the global palette, image optimisation, block caching, site-wide custom code, editor notes, the Core Web Vitals screen and the accessibility audit.

Pro adds editing capabilities, not output:

Breakpoints — the desktop / tablet / mobile tabs, with minimum height, content width, width and the four padding values per breakpoint.
Custom CSS per block, where the token selector stands for that block itself.
Form extras — conditional fields, an automatic reply to the sender, a webhook, and a file upload field.
CSV export of form submissions.
Three blocks — the content switcher with its panels, the portfolio with a taxonomy filter, and the Lottie embed. Their rendering never checks the licence either: a page that already carries them keeps printing them.

The breakpoint and custom-CSS panels appear today on the core blocks — Container, Title, Text, Button, Separator, Image, Testimonial, Icon, Icon Box, Icon List, Shortcode, Form, Products and Product Categories. Several per-breakpoint controls are free wherever they exist: the grid’s tablet and mobile column counts, the menu’s hamburger threshold, the image box’s mobile position and the sticky-position device choice.

When a licence expires or is absent:

Your site looks exactly the same. Every saved tablet and mobile value keeps being printed, and so does every per-block custom CSS rule. This is not a promise, it is an architectural rule: no file on the render path asks about the licence, and a test checks that on every release.
Forms keep submitting, keep saving and keep sending mail.
Existing popups keep showing.
What you lose is the Pro panels in the editor — and only those.

If our servers are unreachable, an active licence keeps working for seven days. An installation that never verified successfully gets no grace at all: blocking our address is not a way to get Pro.

When something does not work

“The form session timed out.”: The cached copy of that page is older than seven days, or your site’s security keys were rotated. Purge the page cache.
The form does not send mail: Check the submission list first — the record is written before the mail, so if it is there the form worked and the delivery did not. Then check the recipient address and your site’s mail setup.
The page looks right in the editor and wrong on the front end: The editor preview is approximate by design; see above. The front end is the truth. If a block carries tablet or mobile values the editor prints a notice saying so.
A block says it is invalid when I try to edit it: Historically this happened to blocks registered on the server but missing from the editor script — they printed perfectly and only failed when opened for editing. A test now guards against it; if you still see it, report the block name.
The countdown shows the wrong time: The markup carries an absolute target instant, never “X seconds remaining”, so a cached page cannot freeze it. The block corrects itself against the server clock; if that request is blocked it falls back to the visitor’s own clock rather than failing.
The header or footer template is not showing: Your theme has no recipe. Only Astra and GeneratePress can be lifted; the screen warns you. The other template types work on any theme.
Two headers appeared: Both MevvBlocks and MevvBridge are producing one. MevvBlocks takes the slot first on purpose — leave the header to one of them.
Containers are wider or narrower than set: A theme rule is winning on specificity. Astra in particular styles its descendants strongly. This has been fixed for the measured cases by raising specificity rather than by using !important; if you hit a new one, say which theme.
A published post is not appearing in a grid: It should. The grid caches only the post ids and any post being saved invalidates it. If it persists, check that the post type and the ordering are what you expect.

Updates

Updates arrive through WordPress itself. The plugin asks our store whether a newer version exists and hands the answer to WordPress’s own update flow, so a new release turns up on the plugins screen with an ordinary Update button instead of waiting for someone to fetch a zip by hand. In the free edition that request carries only the package name and the installed version — no site address, no e-mail address, no licence key and no plugin inventory. Because nothing in it identifies you, trust rests on the signature: the reply is signed with our Ed25519 key, and one that is unsigned, wrongly signed, replayed from an old timestamp or that points the download at any host but ours is discarded without touching the site.

Limits

The editor preview is exact for layout, not for everything. The canvas prints the same CSS the front end does, so spacing, background, borders, typography, transforms and position match. What still differs is any rule written against the markup inside a block, because the canvas draws its own editing affordances there.
Header and footer templates only work on Astra and GeneratePress. Every other theme gets nothing, plus a warning — silence would be two headers.
The map is an OpenStreetMap embed. One marker, no custom marker image, no map styling, no directions. No API key, no billing account, and no key sitting in your page source.
The portfolio has no modal and no pagination. Cards, a filter and a link to the archive — that is the whole block.
The social feed has no API adapter. It is a list of links you pick by hand; nothing is fetched from any network, and no token is stored.
There are no scroll-linked animations and no rule that stops two effects from colliding. Entrance, parallax and hover effects exist, and all of them are silent under reduced motion.
The pie chart does not animate, and it is not interactive: the values are printed as a list beside it rather than shown on hover.
No accessibility overlay. Measuring and reporting only.
No CAPTCHA.
No live search. A request per keystroke is a dependency and a rate-limit surface.
The countdown uses the site’s time zone, not the visitor’s. A campaign ends at one moment worldwide.
The menu offers two breakpoints, not a free pixel value, and has no fly-out or off-canvas mode — a sliding panel with focus management is what the popup block is for.
Grid cards cannot be h1, and loop nesting stops at two levels.
The icon set is 94 stroked icons, all drawn in one 24-pixel box. There is no icon font and no way to add your own to the picker; an SVG of your own goes in through the Image or SVG Animation block.
Dynamic content comes from a fixed list of sources. There is no “run this expression” field: that would hand code execution to anyone who can edit a page.
Global colour and typography sets cannot be deleted, only emptied.
Product cards are drawn by WooCommerce, not by us, so your theme and any third-party hooks keep working.
The interface ships in eleven languages. Turkish, English, Spanish, German, French, Portuguese, Italian, Dutch, Japanese, Russian and Polish, plus country variants such as es_MX and pt_PT. Any other locale falls back to English.
The Web Vitals window resets every 28 days; it does not slide. A sliding window would need daily buckets and twenty-eight times the storage. The screen shows when the current window started.
Uninstalling does not remove the submissions table or the settings. Your block content stays readable either way — it is standard markup in post_content.

No third-party JavaScript or CSS library is loaded, anywhere. Not for the slider, not for the accordion, not for motion, not for the map. Each of those would have cost between forty and a hundred kilobytes on every page that used it.

A hundred pixels on desktop, forty on mobile — in the block editor.