I have now updated to the latest version and re-uploaded all files and am again having problems logging in.
I know this might sound silly, but can you ensure you have entered the correct email and password?
At the moment, the error message can be confusing as it can default to “Network error. Please try again.” even though an incorrect password was entered.
I tried logging in with the username and password you sent us last week and after inspecting the network requests saw an “Invalid email or password” message (even though the message on the page is “Network error”).
Are you 100% sure you have entered the correct email and password?
I haven’t changed my email and password so is it the same as last time. I can try to request a password change.
I have changed the password, but I’m still getting the same error.
then I’m going to need more info, any chance we can get the error logs?
Error_log.txt
error_log.txt (31.6 . KB)
@ben Did you find out anything from the log?
Hi @mrTablet
This looks like an issue with your server. The license check is failing because your server’s PHP install does not have the sodium extension enabled (some shared hosts disable it even though it ships with PHP ≥ 7.2).
The license check requires the sodium extension to be enabled, this is why you are getting the error when trying to sign in.
Can you check with your hosting provider if the sodium extension is enabled?
quick follow up here with more info on why your hosting provider should enable the sodium extension.
Sodium is a modern cryptography library that’s been bundled as a core part of PHP since version 7.2 (released in 2017). It’s not an optional add-on, it ships with PHP itself, and the PHP project considers it the recommended library for cryptographic operations going forward, replacing older alternatives like mcrypt.
Disabling it on a shared host isn’t really justifiable in 2026. It has no meaningful performance or security cost to leave enabled (it’s actually the more secure option), and modern PHP applications increasingly rely on it for things like secure password hashing, signed tokens, and encrypted data handling. Disabling Sodium is roughly equivalent to disabling json or mbstring — technically possible, but it breaks a significant portion of the modern PHP ecosystem.
We’d recommend opening a support ticket with your host and asking them to enable the Sodium extension. Any reputable host will do this on request. If they refuse, it’s worth considering whether the host is keeping pace with current PHP standards! Running modern web applications on a host that disables core extensions tends to cause problems beyond just our software.
Hi @mrTablet
Just a follow-up from @ben’s above post, I know you are a bit hesitant to switch hosting providers, however if I recall correctly you’ve had several hosting related issues that have caused a lot of unnecessary hassle. 
If you are open to exploring a switch over to our hosting, I’d be more than happy to walk you through it over a one-on-one Zoom call. I can answer any questions or concerns you might have. 
Feel free to send me a DM here on the forum if you’d like to explore what we can provide you with our hosting service. 
Hi. I have received this report from my hosting provider.
"We checked the server configuration and confirmed that the Sodium PHP extension is enabled and loaded correctly on the server.
We also verified this directly within the active PHP 8.4 environment, where the Sodium module is shown as enabled and compiled successfully.
Based on these checks, the hosting server is already providing Sodium support correctly. We would recommend asking the software provider to further investigate the application configuration or license validation process from their side."
Hi @mrTablet
Thanks for following up with your host. There’s one thing worth checking before we go further though, because the error log you sent us is pretty unambiguous about what’s happening at the moment the sign-in fails. PHP is reporting SODIUM_CRYPTO_SIGN_PUBLICKEYBYTES as an undefined constant, and that constant only becomes undefined when the sodium extension isn’t loaded in the specific PHP process that’s actually serving the request. So even though sodium is showing as enabled somewhere on the server, something is still off in the environment that’s running the editor itself.
The usual reason for this kind of mismatch is that the host’s check was run in a different PHP environment than the one your domain is actually using, for example via the command line, or under a different PHP version/SAPI. On cPanel-style hosts it’s common to have several PHP versions and handlers running side-by-side, and sodium can be present in one and missing from another.
To pin this down for certain, could you drop the following code into a .php file in the same folder as the editor (e.g. /rw/elements/com.elementsplatform.cms/editor/sodium-check.php) and then load it in your browser?
<?php
header('Content-Type: text/plain');
echo 'PHP version: ', PHP_VERSION, "\n";
echo 'SAPI: ', PHP_SAPI, "\n";
echo 'sodium loaded: ', var_export(extension_loaded('sodium'), true), "\n";
echo 'constant defined: ', var_export(defined('SODIUM_CRYPTO_SIGN_PUBLICKEYBYTES'), true), "\n";
echo 'disable_functions: ', ini_get('disable_functions'), "\n";
echo 'loaded php.ini: ', php_ini_loaded_file(), "\n";
echo 'scan dir files: ', php_ini_scanned_files(), "\n";
Paste back what it prints out in the browser and we’ll know exactly what PHP is seeing in the same environment that’s failing. (Feel free to delete the file afterwards.)
If sodium really is loaded and the constant really is defined in that output, then we’ll know to look elsewhere, however, my strong suspicion based on the log is that the host checked a different environment than the one actually handling your editor requests. Showing them the output above should make it very easy for them to spot which PHP version/handler is missing the extension.
Out of curiosity, who are you hosting with?
PHP version: 8.4.21
SAPI: litespeed
sodium loaded: false
constant defined: false
disable_functions:
loaded php.ini: /opt/cpanel/ea-php84/root/etc/php.ini
scan dir files: /opt/cpanel/ea-php84/root/etc/php.d/02-pecl.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-bcmath.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-calendar.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-ctype.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-curl.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-dom.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-exif.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-fileinfo.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-ftp.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-gd.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-iconv.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-intl.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-mbstring.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-mysqlnd.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-pdo.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-phar.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-posix.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-simplexml.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-soap.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-sockets.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-sqlite3.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-tokenizer.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-xml.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-xmlwriter.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-xsl.ini,
/opt/cpanel/ea-php84/root/etc/php.d/20-zip.ini,
/opt/cpanel/ea-php84/root/etc/php.d/30-mysqli.ini,
/opt/cpanel/ea-php84/root/etc/php.d/30-pdo_mysql.ini,
/opt/cpanel/ea-php84/root/etc/php.d/30-pdo_sqlite.ini,
/opt/cpanel/ea-php84/root/etc/php.d/30-xmlreader.ini,
/opt/cpanel/ea-php84/root/etc/php.d/i360.ini,
/opt/cpanel/ea-php84/root/etc/php.d/zzzzzzz-pecl.ini
That output confirms sodium is not loaded in the PHP process that’s running the editor, it says sodium loaded: false.
Reading that output tells us:
- PHP 8.4.21 running under the LiteSpeed SAPI is what’s actually serving your site.
sodium loaded: falseandconstant defined: falsetells us the sodium extension simply isn’t available.disable_functions:is empty, so nothing is blocking it programmatically. It’s genuinely not loaded.- The “scan dir files” list is the real giveaway. That’s every extension
.iniPHP loads on startup, and you can see entries forbcmath,curl,gd,intl,mbstring,mysqli,xml,zipand so on — but there is nosodium.inianywhere in that list. So whoever checked on the host’s side was looking at a different PHP install. For this PHP (ea-php84), sodium hasn’t been installed.
Your server is cPanel / EasyApache 4 (you can tell from the /opt/cpanel/ea-php84/... paths). On EA4, sodium ships as a separate package called ea-php84-php-sodium that has to be explicitly installed for each PHP version. If it’s not installed, it never appears under php.d/ and the extension never loads, which is exactly what we’re seeing.
You can send the following to your host more or less verbatim (you could also include the output of php from above):
Could you please install the
ea-php84-php-sodiumpackage for the PHP 8.4 environment serving my account? On WHM that’s EasyApache 4 → Customize → PHP Extensions → tick “Sodium” for ea-php84 → Review & Provision, or from the command lineyum install ea-php84-php-sodium. Aphpinfo()-style check run from within my account is currently reporting sodium as not loaded under PHP 8.4.21 / LiteSpeed, even though it may be enabled for other PHP versions on the server. The output ofphp -min my account confirms there is no sodium entry.
Once they install that package, no changes are needed on your site or in the editor as sodium will be available on the next request and sign-in should start working straight away. You can re-run sodium-check.php to verify (you’ll see sodium loaded: true) and then delete it.
I’ll be adding them to my list of “hosting companies I’d rather not work with” 
From domene.no
We investigated the issue further and identified that the Sodium extension package was not previously loaded in the active PHP 8.4 LiteSpeed environment serving the website requests.
The Sodium extension has now been installed and enabled successfully for PHP 8.4, and we have verified that it is loading correctly within the active PHP environment.
Please find the verification screenshot attached showing the Sodium module loaded successfully for PHP 8.4. See the screenshot below for refernce.
I have now tested and everything seems to be working 
Sorry that you have spent a lot of time on this when the error was with domene.no
2 days of back and forth when it just works on our hosting (and if it hadn’t we could have solved it in minutes, not days).
Something to consider perhaps when it comes time to renew your hosting account with them.
I’m just glad to hear that you’ve got it sorted. Hope you enjoy the Online Editor! 