Using the Editor

Your Stelae WordPress is a full WordPress installation. Anything you can do in WordPress, you can do here. This page covers the things that are specific to Stelae.

Accessing Your WordPress

From your dashboard, click “Open Editor” on your site card. This opens your private WordPress in a new tab. The URL is a random path under the Stelae domain (e.g. stelae.eu/site/abc123def456). This is your editing URL, not your public site URL.

Access is protected by a unique editor link that you can find on your site card in the dashboard. Share this link with anyone who should be able to edit the site. You can regenerate the link at any time from the dashboard, which immediately invalidates the old link and revokes any active editor sessions.

Themes

You can install and use any WordPress theme. All visual output (HTML, CSS, JavaScript, fonts, images) is captured during export. The theme’s PHP code runs only during editing and export; it’s never exposed to visitors.

A few tips for choosing themes that work well with static export:

• Prefer themes that render content at build time. Most modern themes do this by default. If a theme shows all content when you preview a page in WordPress, it will survive the export.
• Be cautious with themes that lazy-load content via AJAX. Some themes load content by making requests to admin-ajax.php or the WP REST API when the page loads in the browser. This content won’t be available on the static site because there’s no WordPress backend running. You can usually spot this by viewing a page’s source: if content sections are empty in the HTML and filled in by JavaScript, that content relies on AJAX.
• Block themes (Full Site Editing) work well. They render everything as HTML in the page source.

Plugins

You can install any WordPress plugin, but only plugins whose output is baked into the HTML will have visible effects on the static site. See the compatibility guide for a detailed breakdown.

The short version:

• Visual plugins (Elementor, Beaver Builder, Gutenberg blocks, etc.): work perfectly.
• SEO plugins (Yoast, Rank Math, etc.): work perfectly. Meta tags, sitemaps, and structured data are all generated at build time.
• Form plugins (Contact Form 7, WPForms, Gravity Forms): will not work. The forms will render visually but submissions have nowhere to go. Use a third-party form service instead.
• Caching plugins: unnecessary. Your live site is already static.
• Security plugins: unnecessary for the live site (there’s no PHP or database to attack). May be useful inside the editor to limit login attempts.

Page Builders

Page builders generate their output as HTML and CSS, which is exactly what the export captures. Elementor, Beaver Builder, Bricks, GenerateBlocks, WPBakery, Divi: all produce static output that exports cleanly.

One caveat: some page builders (notably WPBakery/Visual Composer) load certain content via AJAX calls to admin-ajax.php. Content loaded this way won’t appear on the static site. If you notice empty sections after export, this is likely the cause. Check the troubleshooting guide for how to diagnose this.

Media and Uploads

Upload images, videos, PDFs, and other media through the WordPress media library as normal. All media files are included in the static export archive.

Your container has a disk quota. Large media libraries (hundreds of high-resolution images) will consume disk space. Optimize images before uploading where practical. This also makes your static site load faster for visitors.

WordPress Version

Each site is pinned to a specific WordPress version when it’s provisioned. The version is shown on your site card in the dashboard. You can change it from the site card overflow menu → Change WordPress version, which opens a picker listing every WordPress image ≥ 6.0 available on Docker Hub.

Changing the version stops the container, rewrites its Docker compose configuration, and restarts on the new image. Your database, themes, plugins, and uploads are preserved. WordPress handles any required database migration automatically on first boot, the same as a normal WordPress upgrade. Give the container 10–15 seconds to come back up after a version change.

phpMyAdmin

For direct database access, start a phpMyAdmin instance from the site card overflow menu → phpMyAdmin. Stelae spins up an ephemeral phpMyAdmin container on your site’s network, wired to your WordPress database with the correct credentials already filled in. Click “Open phpMyAdmin” and you’re in.

The phpMyAdmin container is ephemeral. It stops automatically when you close the modal or after a period of inactivity, and gets a fresh instance on next start. No state is preserved between sessions. Useful for: one-off queries, bulk updates to post metadata, fixing a broken plugin migration, or exporting specific tables. Not a substitute for regular backups.

Permalinks

Stelae automatically sets your permalink structure to /%postname%/ (pretty permalinks) when your site is provisioned. This is important because query-string URLs like ?page_id=2 don’t work on most static hosts.

If you change your permalink structure in WordPress settings, the export will use whatever structure is currently active. Stick with /%postname%/ unless you have a specific reason to change it.

Container Lifecycle

Your WordPress container is a real Docker container with allocated CPU, memory, and disk resources. To keep costs low and density high, containers follow a sleep/wake lifecycle:

• Running: Your container is active and you can access WordPress normally.
• Sleeping: After 60 minutes of inactivity (no HTTP requests), the container is stopped. It uses zero CPU and minimal disk.
• Waking up: When you access your editor URL, the container starts automatically. This takes about 5 seconds.

Your WordPress files, database, themes, plugins, and uploads are all preserved across sleep/wake cycles. Nothing is lost when the container sleeps.