Edit your WordPress theme's PHP, not a builder's database

A page builder stores your layout as its own data in the WordPress database and renders it back through its plugin. What you edit is the builder's content, and your theme's PHP is largely bypassed. PortBay does the opposite: it edits the template files in your theme, so the change is in your repository and shows up in git. If you already build with Elementor, PortBay is not the tool for those layouts — it refuses to write them, for a reason worth reading below.

Because writing them directly would appear to work and then not work. Elementor's stored layout lives in a postmeta row, but its element cache, page-CSS cache and asset list are all keyed on the post's modified time, which a direct row write does not move. The layout would change and the rendered page would not. PortBay registers that lane purely so it can refuse by name instead of leaving you to debug a save that silently did nothing.

No — change those in the WordPress admin. They are rows in your site's database rather than anything in your theme, and PortBay's page-settings lane does not write them on WordPress, on a classic or a block theme. It is one of two stacks out of twenty-one where that lane is unavailable. What this page describes is a different thing: the text, classes and attributes in the template files you actually wrote.

PortBay's visual editor works on both, but they behave differently enough to have separate pages — this one covers classic PHP themes. On a block theme the editable files are templates/*.html, parts/*.html and theme.json rather than PHP templates, and page content is a further step removed because it lives in the database. If you are on a Full Site Editing theme, read the WordPress block themes page instead.

No, and it is worth being direct about that. Laravel, Rails and Django have stampers that give every element its exact file, line and column. WordPress has none, and is not getting one, so PortBay locates an element by searching your theme source and requires exactly one match before it writes. In practice that is reliable for distinctive markup and refuses on repeated markup — which is the safe failure, but it is a real difference from the stamped stacks.

PortBay's visual editor writes only the bytes that changed. A one-class edit shows up in git diff as one changed token, multi-line attributes keep their indentation, and nothing is inserted into your markup to make the editing work — there are no marker attributes to strip before you deploy. Because the changes are ordinary edits to files in your repo, git is your undo, and PortBay also keeps its own history of every change it made.

No. It is a Pro feature, still in early access behind an opt-in toggle in Settings, and it is not compiled into the open-source build. It is also unavailable on a project while that project is publicly tunneled — the edit bar and its write-back endpoints are never routed onto public traffic. Running WordPress locally, the MySQL database, the .test hostname and trusted HTTPS are all in the free, open-source app.