Help4 Builder WP-CLI Runner Guide
Before the first click
Confirm what you are editing and where each kind of change belongs.
Read the page or template title first, select the exact element in the canvas or Navigator, then use the inspector tab that matches the job. This prevents a content change from becoming an accidental layout change.
Content
Change words, links, images, icons, data sources, shortcodes, and element-specific information.
Design
Change colors, typography, spacing, borders, radius, alignment, states, and desktop, tablet, or mobile values.
Advanced
Change labels, anchors, classes, attributes, visibility rules, motion, and other expert controls.
Page Settings
Use page-wide history, globals, publishing, template assignment, and recovery controls instead of editing one element.
Visual orientation
Match the screen before following the steps.
Open each image at full size. The numbered notes explain what the screen controls and what to confirm before changing customer content.
Screen 1
Page Settings and recovery
Confirm page-level layout, history, preview, and recovery controls before a larger edit.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Screen 2
Settings and launch center
Choose a launch plan, confirm modules, download Help4 Blank, review readiness, and keep the site configuration in one place.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Screen 3
Updates
Confirm the installed version, free update status, manifest URLs, beta or stable channel behavior, and package checks.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Screen 4
Open the correct page
Find the intended page and open Studio without confusing it with a reusable template or similarly named draft.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Screen 5
Builder Pages
Find Builder-enabled pages, open Builder Studio, and keep drafts separate from live customer pages.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Screen 6
Security
Review SSL, headers, login hardening, XML-RPC controls, checkout safety, and production hardening settings.
Confirm: the page title, selected item, plugin version, and intended responsive view match the task.
Watch the real workflow
Watch the clicks before making the change.
Use the narrated walkthrough first, then follow the written steps and verification checks on this page.
Lesson 34
Migration, Import, Export, and Cutover
Move Builder layouts and settings through guarded exports, structural checks, media mapping, and a verified launch sequence.
Read the complete transcript
- Inventory Before Moving
Open the migration and cutover tools only after inventorying pages, templates, global styles, custom fields, menus, forms, media, redirects, SEO metadata, commerce data, users, and addon dependencies. Record the source and target versions. A migration is more than copying page HTML.
- Export a Guarded Bundle
Export the supported Builder bundle and keep its manifest and checksum with the recovery record. Do not place credentials, private customer records, payment secrets, or unrelated uploads in a portable design package. When a script will run through WP CLI eval-file, avoid first-statement assumptions and preserve every host and dry-run guard.
- Import Without Replacing by Accident
Choose style-only, merge, or explicit layout replacement according to the migration plan. Verify the import target and expected current hash before the first write. Preserve stable element identifiers, parent relationships, extension data, and non-pack global tokens unless replacement was approved.
- Validate Then Cut Over
Check block counts, unique identifiers, parent and slot graphs, media URLs, forms, menus, responsive layout, Studio parity, public pages, SEO output, and logs before changing traffic. After cutover, verify redirects, canonical host, sitemap, cache, SSL, checkout bypasses, and the exact rollback path while the recovery window is still open.
Lesson 5
A Safe Builder Editing Workflow
Make one controlled change at a time, inspect the correct element, verify responsive output, and recover cleanly if needed.
Read the complete transcript
- Select by Name
Begin with Navigator and select the element by name. This is safer than deleting a row or replacing raw HTML when you only need to change text, a link, or an image.
- Change One Thing
Change one logical item at a time. After editing content, pause and inspect the preview. Small steps make it clear which change caused a visual problem.
- Check Responsive Design
Review desktop, tablet, and mobile contexts before saving. Watch for clipped text, unexpected wrapping, missing media, and controls that become too small to use.
- Recover, Do Not Rebuild
If the page goes wrong, stop editing and use Page Settings or history. Recover the last good state first, then retry the intended change with the correct element selected.
Runner contract
Compatibility is not permission to remove safety checks.
Omit constructs that require the first physical PHP statement, including declare(strict_types=1). Keep the checks that prevent the correct script from mutating the wrong site, environment, object, release, or publication state.
All runner types
Use the same compatibility rule for seed, migration, launch, repair, audit, and recovery files.
Publication safety
A failed preflight must leave drafts unpublished and the public hold unchanged.
Data safety
Unknown namespaced extension data and existing Builder relationships must survive a round trip.
Operational hygiene
Use a bounded rollback artifact when needed; do not create repeated server backups of the same package.
Guided walkthrough
Make one verified change at a time.
Each step includes the action, why it belongs in this order, and the checkpoint to verify before moving forward.
-
Define the bounded job
State whether the runner seeds, migrates, launches, repairs, audits, or recovers content and list the exact objects it may touch.
Why nowStarting from a confirmed target prevents a correct edit from being applied to the wrong page, template, product, or responsive view.
Done whenThe define the bounded job result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Remove first-statement assumptions
Do not include declare(strict_types=1) or another construct that assumes it runs before the WordPress bootstrap prepended by wp eval-file.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe remove first-statement assumptions result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Keep environment guards
Validate the host, path, WordPress and Builder versions, current user capability, expected object state, and any explicit authorization constant.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe keep environment guards result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Default to a non-public outcome
Use dry run, draft, noindex, and no-publish defaults until a separately authorized launch step passes QA.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe default to a non-public outcome result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Preserve Builder structure
Keep element IDs, parent references, slots, order, extension data, page mode, template conditions, and SEO metadata unless the job explicitly owns them.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe preserve builder structure result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Lint and run a read-only harness
Check PHP syntax, expected counts, duplicate IDs, dangling parents, invalid slots, status, robots state, and intended responsive values before mutation.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe lint and run a read-only harness result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Execute one bounded mutation
Capture created, updated, skipped, and failed counts without printing secrets, customer data, raw logs, or credentials.
Why nowCompleting and checking this step creates a known-good checkpoint before the next control changes the page state again.
Done whenThe execute one bounded mutation result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
-
Verify, recover, and clean up
Compare before/after structure, preview the affected routes, use the defined rollback when needed, and remove temporary runner files.
Why nowThe final verification separates an editor preview from a result that is actually saved, responsive, interactive, and ready for visitors.
Done whenThe verify, recover, and clean up result is visible, remains after reselecting the item, and has not changed unrelated content or styling.
How to know it worked
Verify the edit in Studio and on the real page.
A successful edit stays visible when the element is reselected, matches the intended responsive view, survives publish, and appears on the public URL without clipping or lost styling.
Studio preview
Reselect the element and confirm the saved value and visual result are still present.
Responsive preview
Check desktop, tablet, 390px, and 360px widths for overflow, squeezed controls, and inherited values.
Public page
Open the public route in a new tab after publishing and confirm content, interactions, assets, and spacing.
Recovery
If the result is wrong, stop editing and use History or a known-good revision instead of rebuilding the page.
Avoid the expensive mistakes
Stop when the page stops behaving predictably.
More edits do not repair a bad state. Preserve the evidence, return to a known revision, and reproduce the smallest failing action.
Changing several controls at once
Change one content, design, or responsive value, then confirm it in the preview. A small edit is easier to understand and recover.
Editing the wrong layer
Use Navigator and read the inspector heading. Deleting a parent section can remove every child even when the selected text or image looked harmless.
Checking only desktop
Review tablet, 390px, and 360px before publish. Width, gap, padding, type, alignment, controls, and menus can inherit differently.
Publishing before values persist
Reselect the element and reopen the responsive view. If the value disappears or another tab has a newer revision, reconcile it before publishing.
Continue learning
Use the next guide that matches the work in front of you.
The full tutorial hub remains available without repeating dozens of unrelated cards on this page.
Start here
Install and setup
Download the ZIP, activate Builder Suite, understand the blank-theme path, and run the first clean check.
First page
Build a page safely
Open Builder Pages, launch Studio, build structure first, check mobile, then publish or hand it to Help4.
Editor controls
Know which tab changes what
Use Content for information, Design for appearance and responsive values, and Advanced for identity, attributes, visibility, and motion.
Recovery
Edit without losing work
Replace media safely, recognize stale drafts, and restore a known-good page snapshot from Page Settings History.
Responsive
Control every viewport
Set spacing, widths, columns, alignment, and typography independently for desktop, tablet, and mobile.
Templates
Choose a starter
Pick a starter spec by page job: service, product, support, recent work, local SEO, launch, or checkout recovery.
Need help with this step?
Send Help4 the page, screenshot, or site goal.
Include the URL, what you are trying to build, what looks wrong, and whether this is a draft, staging site, or live customer page.