⚙Setup and troubleshooting

In the settings of Aurora Hive Sites. When the inline editor is active, texts and images can be changed directly on the finished live page, without going through the admin — you see the end result immediately.

For a one-pager from Aurora Hive Sales, it works via the CMS access with a customer password; there, Aurora Hive Live is the way the customer changes texts themselves.

Four causes, in this order:

1. Aurora Hive Live is not switched on for this site. Check in the settings of Aurora Hive Sites.
2. The page has not been republished since it was switched on. That is the most common case — see the next question.
3. The browser is showing an old version. Hard reload with Ctrl+Shift+R.
4. A browser extension is blocking scripts. Cross-check in a private window.

As a workaround, editing mode can also be opened by adding ?aw_edit=1 in the address bar.

There is a known reason for this: the Aurora Hive Live file is written when publishing, not delivered fresh with every request. After a system update, the old version — or none at all — may therefore still be on the page.

The way back is simple: republish the website. That delivers the current version along with it.

If it is still missing afterwards, it is worth a report — with the address of the page.

Yes — that is the second type of set-up, and it does not need a content management system in the background.

It is installed with two files and one line:

1. Put the two files into the directory where the HTML pages are.
2. Add one line to the page’s source code that loads one of the files.
3. Open the page, click the pen and go through the initial setup: enter the licence key, choose a name and password.

After that, this website has accounts, sign-in and saving — without any server on our side.

The prerequisite is a web space with PHP and HTTPS; details are in the separate question on this. A checklist tells you whether everything fits: open the save file directly in the browser once, and it shows point by point what is fine and what is missing.

If saving happens from a subfolder, that folder needs its own copy of the save file.

The access is limited to the one website and can be restricted in scope — in translator mode, only texts, with the structure protected. Every person has their own account with their own password.

What works in your favour:

• Passwords are not stored in plain text, and they appear nowhere in the page’s source code.
• After five failed attempts, an account is locked for a quarter of an hour. So guessing does not help.
• Nothing works without encryption: over an unencrypted connection, you can neither sign in nor save.
• If an account is deleted or its password changed, its session ends immediately — on other devices too.

What you should still bear in mind:

• Anyone with Aurora Hive Live publishes immediately. There is no approval step in between.
• Changes are visible, not anonymous — but Aurora Hive Live is not a four-eyes principle.

For pages where a wrong sentence would be expensive — prices, legal texts, commitments — the route via Aurora Hive Sites with a draft and publishing is the right one.

Two explanations:

• The browser is showing an old version. Hard reload — Ctrl+Shift+R.
• You were in the live editor of Aurora Hive Sites, not in Aurora Hive Live. There, saved does not yet mean published; the real website stays unchanged until you publish.

The second case is the more common one, because both tools show the page as it looks.

Everyone can change their own password themselves — on the page under “Accounts”. A new password needs at least 12 characters.

For other people’s accounts:

• On your customer’s web space, an administrator resets the password under “Accounts”.
• For a website from Aurora Hive Sites, this is done where the account was created.

Change a password when someone leaves or when there is a suspicion that it has been passed on. After the change, all sessions of this account are ended.

In most cases, a deleted account is better than a changed password: anyone who leaves no longer needs one.

No — the account is limited to the one website. Anyone who is to maintain two sites gets two accounts.

That is a feature, not a shortcoming: it allows a customer to change their own page without being able to get at another one.

Via the CMS access for the one-pager: the customer gets a customer password, clicks the pen on their page and changes texts themselves — without access to Aurora Hive Sales.

Give them two sentences to go with it: that every change is public immediately, and that they see the original text when they click — so that they can find their way back if they make a mistake.

Two causes:

• The browser is showing the old image from its cache. Hard reload with Ctrl+Shift+R.
• The image has not been saved. Check whether the change went through — if your sign-in has expired, saving fails.

If an image appears for you but not for others, it is almost always the first.

Because Aurora Hive Live is tied to the page’s blocks: if a section is replaced in Aurora Hive Sites, the old text is no longer there — not even as a field.

That is the usual course of events and not an error. Anyone who uses both in parallel should know: the rebuild belongs in Aurora Hive Sites, the fine-tuning afterwards in Aurora Hive Live — not the other way round.

Directly on the page, in editing mode under “Accounts”. There are two roles:

• Editor — may change content and change their own password. They see only themselves in the accounts.
• Administrator — may also create and delete accounts, reset passwords and enter the licence key.

Two safeguards are built in: the last administrator cannot be deleted, and nobody deletes their own account. Otherwise you would end up with a website that nobody can get into any more.

What to bear in mind when creating accounts:

• One account per person. Only then can one be revoked without having to give everyone else a new password.
• At least 12 characters — shorter ones are rejected.
• Delete when someone leaves, do not just change the password. A deleted account is thrown out immediately at the next save.

Anyone who looks after many customer sites keeps the list of which account belongs to which website in the password manager — not in a spreadsheet on the drive.

Two things, and both are available with every usual provider:

• PHP, in a version that is not ancient — at least PHP 7.4 is required, plus the built-in encryption extension, which is included there as standard.
• HTTPS, i.e. an encrypted connection. Without it, you can neither sign in nor save. The only exception is a trial run on your own computer.

Then there is the obvious: the files must be writable, otherwise nothing can be saved.

You do not have to guess. Open the save file directly in the browser once — it shows a checklist in plain words: PHP, encryption, HTTPS, write permissions, page, accounts, licence. Anything missing is shown with a note on what to do.

Pure HTML web spaces without PHP are not an option. For such cases, the route via Aurora Hive Sites is the right one.

On your customer’s web space, Aurora Hive Live runs without any connection to us. The licence key is therefore what covers the use — and at the same time the proof of ownership during the initial setup.

What you should know about it:

• One key applies to one domain. The same files under a second address need a second key. Whether with or without www. in front makes no difference.
• A further key is issued for every further domain. It is issued by us; you give us the domain for it.
• Without a valid key, you can sign in and read, but not save. A notice says why.
• A new key is entered by an administrator on the page under “Accounts”.

If a message appears during setup saying that the key does not belong to this address, it is almost always the domain that is meant: the key was issued for a different one.

That no longer exists — and it was the most important change to this type of set-up.

In the first version, the password sat in the page itself. Anyone who looked at the source code could read it; a password in the source code of a public website is not a password.

Today:

• Every person has their own account with a name and password.
• The password is stored only in unreadable form, in a file on the web space that cannot be retrieved in the browser.
• There is no longer any password in the page’s source code.

If you are converting a page from the old version: sign in once with the old password — you then land in the initial setup and choose a name and a new password. The old one cannot be reused in the process. At the next save, the old entry is removed from the page.

Until that has happened, the old password counts as known. So convert promptly.