Wizara Develop Guide

Mobirise is a visual site builder with a real code layer underneath. The win is speed. The risk is editing the wrong layer, or editing the right layer in a way that strips Mobirise’s editing hooks. This cheat sheet is written for anyone who opens a Rayova project: marketers tweaking copy, designers adjusting layout, and developers pasting custom sections.

1. Mental model: project vs published site

Treat Mobirise as two related worlds:

• Project source — the working site inside Mobirise, stored as project files (notably project.mobirise). This is the durable source of truth.
• Published / exported HTML — the files that go live on the host. Useful for checking, not for permanent edits.

2. Builder map: what you are looking at

Most day-to-day work happens in these places:

• Pages panel — add, rename, reorder, and open pages. Keep filenames short, lowercase, hyphenated (example: website-accessibility-compliance.html).
• Site settings — site name, favicon, fonts, global / Dynamic Styles, plugins.
• Block insert — add Headers, Content, Footers, Forms, and custom Code blocks.
• Block gear / parameters — padding, background, show/hide toggles, counts, alignment.
• Inline edit — click text, buttons, and images on the canvas.
• Code Editor — HTML on the left, CSS/LESS on the right for that one block.
• Publish / Preview — verify on desktop and mobile before you trust a change.

Global items such as menus and footers are often marked as shared. Edit them carefully: one change can appear on every page.

3. Blocks and parameters

A Mobirise “block” is one section on the page. Custom sections usually start with a real <section>, include an <mbr-parameters> panel, then the visible markup.

Keep these attributes whenever you redesign a block. They are how Mobirise keeps content editable:

• mbr-theme-style, mbr-fonts-style, data-app-selector
• mbr-if for show/hide toggles
• mbr-buttons around button groups
• mbr-icon on icon spans
• mbr-class for container width switches
• Bootstrap layout classes: container, row, col-*

4. Where CSS lives (and why it matters)

Rayova work is smoother when CSS ownership is deliberate:

Section CSS often uses Mobirise LESS helpers such as @paddingTop, @bg-value, and & when (@gradientBg). That is expected. Do not wrap section CSS in a <style> tag when pasting into the CSS pane.

Comments in the Section CSS Editor are frequently stripped on save. Keep human notes in your library README, not as the only documentation inside the CSS pane.

5. Code Editor: HTML left, CSS right

Open a block’s Code Editor when you need structure beyond the gear panel. The modal is usually two panes:

• HTML Editor — the block markup, including <mbr-parameters> and the visible content.
• CSS Editor — LESS/CSS for that block only.

Bottom controls typically include discard, undo, and apply/save. Always apply, then preview the page. Do not assume the canvas alone proves publish success.

For Rayova paste-ready sections, paste HTML first, then CSS. Confirm the opening line is a real <section ...>, not a comment.

6. Code Editor shortcuts (Mobirise Quick Help)

These shortcuts come from Mobirise’s Code Editor Quick Help. On Windows they use Ctrl. On Mac, use Cmd in place of Ctrl for most of these.

Lines and selection

Brackets, find, and multi-cursor

Bookmarks

7. Code Editor quirks (read this before you paste)

These quirks cause most “it looked fine in the editor, then broke” moments.

Quirk A — HTML comment at the top of the block

Never start the HTML pane with an HTML comment. A leading <!-- ... --> can error the section or confuse the parser.

A related failure mode looks like this in the Code Editor:

<!-- data-bs-version="5.1" class="ray-colour-checker" group="Content" -->
    <mbr-parameters>
        ...

That usually means the opening <section ...> was turned into a comment. Fix it back to a real section tag:

<section data-bs-version="5.1" class="ray-colour-checker" group="Content">
    <mbr-parameters>
        ...

Safe comments can live deeper inside the section if needed. Prefer none at the very top.

Quirk B — Ampersands not escaped

In Code Editor HTML, a raw & can break attributes, titles, or validation. Prefer & in markup, or rewrite the phrase with “and”.

• Safer: Transportation & Logistics
• Also fine in many Rayova body sentences: use the word “and”
• Brand exception cases exist for some client sites; for Rayova generic copy, escape or reword

Quirk C — Section CSS cannot target “itself” the way Dynamic Styles can

In the Section CSS Editor, writing .ray-article-section { ... } is unreliable because Mobirise already scopes the pane to that block. Prefer child selectors such as .ray-mcs-table or .ray-cc-grid.

Quirk D — Mobirise may rewrite your markup on save

After Apply, Mobirise can normalize tags, drop some attributes, or reshape wrappers. Always re-open the Code Editor and compare critical parts: IDs used by scripts, mbr-* attributes, and the opening <section>.

8. Scripts, IDs, and interactive tools

Custom tools (forms helpers, colour checkers, calculators) can live inside a section, but Mobirise is not a neutral HTML host.

• IDs on <p> tags can be stripped. Prefer <div id="..."> for script targets, or query by class with null checks.
• Avoid naming a helper $ in page scripts. Mobirise pages often load jQuery. Use a clear name such as byId.
• Assets must publish. If a script fetches assets/..., that file must exist on the live host after Publish. Embedding small JSON in the section is safer for critical data.
• Editor canvas ≠ browser. Some scripts only prove themselves in Preview or on the published page.

9. Images and assets

• Prefer project assets under assets/images/ with stable filenames.
• Decorative parameter-driven images often publish more reliably as CSS background-image: url(@paramName) than as <img src="}">.
• Content photos should use normal <img> tags with meaningful alt text.
• SVGs are excellent for logos and UI marks when kept simple and accessible.

10. UX and accessibility checklist (Rayova)

Every block should survive this quick pass before publish:

• One job per section: One headline purpose. Do not turn an article into a dashboard of competing boxes.
• Brand first: Rayova colour and type hierarchy stay clear. Avoid soft rounded “generic SaaS” chrome unless a product UI requires it.
• Contrast: Text and controls meet WCAG AA whenever practical. Use the colour contrast checker on the accessibility page when unsure.
• Keyboard: Links, buttons, and custom controls are reachable and visible on focus.
• Alt text: Informative images have useful alt. Decorative images are marked appropriately.
• Mobile: Check narrow widths. Tables should scroll horizontally if needed, not crush the layout.
• Canadian English: colour, centre, organisation when brand voice applies.

11. Safe workflow

1. Identify the active project folder by recent activity, not only by the date in the folder name.
2. Prefer paste-ready HTML/CSS while Mobirise is open.
3. If you must edit project.mobirise directly: close Mobirise first, make a timestamped backup, then edit carefully.
4. After Code Editor changes: Apply, Preview desktop, Preview mobile, then Publish.
5. On the live page, hard-refresh and verify scripts, images, and CSS.
6. Keep a library copy of settled sections outside the project so you can restore them later.

12. Quick reference

This cheat sheet is intentionally dense. When a topic grows (Code Editor only, publishing only, custom sections only), split it into its own article and leave this page as the index.