Helix update wrecks website

WTF??????????

Excuse me if I sound a little frustrated, but why the hell would you roll out a new Helix verion if it's not compatible with any of your damn templates?

That's a serious misjudgement in the software release schedule.

Also, your own bloody blog post here states that helix 2.0 is Joomla 4 compatible and ready to use on live websites.

Which is it? It's not compatible or it is? It can't be both????

Telling paying clients to reinstate a backup of a site isn't good enough when you release documentation stating the release candidate is stable and ready to use on live websites, then when your code base breaks loads of sites (I noticed there are many many posts in the forum about this) - you scramble and tell people to run backups.

Surely you would have tested the latest version of helix on your templates before you released it? And if not, why the hell was it released?

The main issue is that the helix ultimate 2 update comes through as an available update through the Joomla update centre.

Considering many web developers have clients that manage their own websites, they're going to simply click on this update and completly ruin their websites.

Judging by the amount of posts you've had in the forum about this very issue, my guess is many, many other people have done the same.

I've just spent the better part of an entire day backing up clients websites on the offchance they go in and make this update themselves.

Any word on when the current templates will be compatible with both Joomla 3.10 + and helix 2?

I share your frustration, pain, and disappointment. I wish I could get back to the previous version. Restoring a backup is not a great option for a busy ecommerce site.

Hello.

As an FYI, some of the changes I've experienced since upgrading to the latest version (Joomla v3.10.1 with Helix Ultimate v2.0.4):

1. "Custom Presets" does not work in template options. I had a black background for my menu bar and the upgrade changed the non-active menu title to "body text" color (found this using web developer tool in Safari Technology Preview), rather than using the color selected in Custom Presets. When I tried experimenting with different colors in Custom Presets, no color changes were dispayed/took effect. I had to turn off "Custom Presets" and use a template preset in order for my entire menu to display.

2. In addition to the hamburger also displaying "body text" color (invisible on black menu background), the off-canvas menu was not displaying the sub-menus. I played around, changing the menu and then changing it back again, to get it to work.

Glad I found this post....Im using J4 and just updated Helix to 2.0.18. And for some reason it still breaks all my preset styling and reverts back to the default styling...especially in my Header section and offcanvas menu. I have to make a backup of my css files before every update just to make sure I dont lose my custom styling.

If there is a workaround or a solution for this...Id love to know.

One possible solution:

Greetings,

I have made several customizations to the template files, and it's crucial for me to preserve these changes. To ensure that my customizations are not overwritten during future updates, I kindly request you to implement a mechanism that checks for the existence of custom files before loading the default ones.

Here's an example of how this could be achieved:

$prefix = 'custom_';
$defaultFileName = 'options.xml';
$customFileName = $prefix . $defaultFileName;

// Check if the custom file exists
$customFilePath = JPATH_ROOT . '/path/to/' . $customFileName;
if (file_exists($customFilePath)) {
// Load the custom file
require_once $customFilePath;
} else {
// Load the default file
$defaultFilePath = JPATH_ROOT . '/path/to/' . $defaultFileName;
require_once $defaultFilePath;
}

In this code snippet, the script first checks if a file with the prefix 'custom_' exists (e.g., 'customoptions.xml'). If the custom file is found, it will be loaded; otherwise, the default file ('options.xml') will be loaded.

By implementing this approach, my customizations will be preserved, and I can continue to benefit from future updates without worrying about losing my changes.

I would greatly appreciate your assistance in incorporating this mechanism into the template files. Please let me know if you need any further information or have any questions.

Thank you for your understanding and cooperation.

Best regards,

Expanding on the post above,
Please simply extend your use of 'custom' much like you use custom.css.
Automatically use headers/custom/header.php
And ANY file or folder with 'custom' or 'custom_' as a prefix.

Also, if possible, NEVER overrite options.xml.