Solved SP Page Builder

Critical SP Page Builder layout corruption issue on multilingual production website

Asked by Jean-Marie Putz 2 months ago Last activity 1 month ago

Dear JoomShaper Support Team,

I am reporting what appears to be a serious stability issue affecting SP Page Builder pages on a large multilingual Joomla production website.

My website contains several thousand pages distributed across three languages (French, English and Dutch), and all pages are published through SP Page Builder.

However, it is important to clarify that these are not typical native SP Page Builder pages built using complex addon structures, nested layouts or visual page design workflows.

The Joomla article itself remains essentially empty and all content is managed through SP Page Builder.

In practice, SP Page Builder is used primarily as a publication container and layout manager for externally generated HTML content.

My publishing workflow relies almost entirely on HTML content generated externally in a local FileMaker database and then injected into Joomla through a very limited set of SP Page Builder addons, essentially:

Raw HTML addons
Joomla Module addons
Occasionally simple Text addons

I deliberately avoid complex addon structures and use very few native SP Page Builder components.

The issue I am experiencing concerns pages rebuilt and republished using this simplified architecture.

Some newly republished pages immediately exhibit broken column layouts on the frontend. Entire columns disappear or collapse even though the backend structure appears perfectly normal.

The most surprising aspect is that the following procedure immediately restores the correct layout:

Delete the Joomla article.
Empty the Joomla trash.
Create a completely new Joomla article.
Republish exactly the same content using the same SP Page Builder template.
Recreate multilingual associations.
Restore metadata, images and links.
Carefully preserve the original alias to avoid URL and SEO issues.

The page then renders correctly again.

I compared the SP Page Builder JSON exported from the broken page and from the rebuilt page.

The two JSON files are strictly identical.

This strongly suggests that the issue is not caused by the SP Page Builder content itself but rather by metadata, cache entries, database records or internal state associated with the Joomla article, the SP Page Builder record or generated frontend assets.

The operational impact is extremely severe because rebuilding a multilingual page requires restoring not only the content itself but also multilingual associations, SEO metadata, images, links and aliases.

This procedure is manageable for one isolated page but becomes completely unacceptable if the issue spreads to a significant number of pages.

The broader context makes this situation even more concerning.

During the past months I have been conducting a major editorial migration involving several thousand multilingual pages. This migration was a deliberate editorial and technical decision intended to modernize and simplify my publishing workflow.

During this migration I encountered major issues affecting HTML editing capabilities within the JoomShaper ecosystem.

What concerns me is that the issue did not affect one specific editor integration.

TinyMCE became unusable for my workflow.

JCE became unusable as well.

The problem therefore appeared to affect all available HTML editors rather than one individual editor implementation.

This strongly suggests that the underlying issue may exist at framework level rather than inside an individual editor component.

As a consequence, I was forced to completely redesign my workflow and move all HTML generation to my local FileMaker database.

Today all content is generated externally as clean HTML and only then published through SP Page Builder.

This redesign required several hundred hours of additional work that had not been planned when the migration project started.

After absorbing this cost and stabilizing the new workflow, I am now facing layout corruption issues on pages that contain almost exclusively Raw HTML addons and Joomla Module addons.

For additional context, I can provide three versions of the same page:

the original page created in 2020, which worked correctly for years using an older SP Page Builder structure;
the newly republished page using the new simplified template, which exhibits the layout problem;
the rebuilt page created after deleting the article and recreating it, which immediately works again despite using identical content.

The important point is that the broken page and the rebuilt working page generate strictly identical SP Page Builder JSON exports while producing different frontend rendering.

At this point, SP Page Builder itself has effectively become the last major reason for continuing to use the JoomShaper ecosystem for this project.

For completeness, I should also mention that I have not introduced any significant infrastructure changes apart from normal software updates.

The only updates performed recently concern:

Joomla itself (currently Joomla 6.1.2);
Helix Ultimate;
SP Page Builder.

Helix 3 components also still appear to remain installed within the system from earlier versions.

Because these problems appeared within the same general time period, I cannot exclude the possibility that they are related to framework-level interactions involving Joomla, Helix or SP Page Builder.

Possible areas worth investigating could include:

Joomla article IDs;
SP Page Builder database records;
generated CSS or cached layout information;
Helix Ultimate integration;
residual Helix 3 components;
internal metadata not included in JSON exports;
article-specific frontend cache corruption.

If necessary, I can provide:

JSON exports from both the broken and rebuilt versions of the same page;
screenshots of both renderings;
additional technical information regarding the environment and workflow.

The fact that identical JSON content produces different frontend rendering depending solely on the Joomla article instance strongly suggests that the problem lies outside the exported SP Page Builder content itself.

Thank you for your assistance and investigation.

Best regards,

Jean-Marie Putz
travel-video.info
https://www.travel-video.info

Accepted answer

Marked as the solution

Ziaul Kabir Staff

1 month ago

It’s great to hear that your issue has been resolved.
If everything is working fine now, please mark the question as complete by accepting any of our answers.

Thank you!

20 more replies

Ziaul Kabir Staff

2 months ago

Hello,

Thanks for reaching out to us. Could you please share temporary administrator access to your Joomla backend? You can provide the credentials securely in the hidden content section. Also, please take a full backup of your site before we make any changes.

Once I have access, I’ll investigate further and see what’s causing the issue. Let me know once you’ve shared the details!

Best regards,

Jean-Marie Putz Asked this

2 months ago

Hello,

Thank you for your reply.

Before providing administrator access, I would like to clarify that the main issue is not limited to the pages I originally reported. The more serious problem is that editors no longer handle plain text and HTML content reliably across the site.

I first discovered this while working with SEO Glossary, but I later found the same behaviour in other plugins and components whenever they invoked a Joomla editor. Because the editors could no longer be trusted to preserve or update the content correctly, I eventually disabled the WYSIWYG editors in the site settings and converted the affected content to HTML.

The page problems were largely a consequence of this editor malfunction. Under normal circumstances, I could simply have updated the existing pages. Instead, I had to create new templates and, for the production pages already affected, delete and recreate them.

The corruption is frequent but not systematic: it affects more than one page in three. I have not been able to identify any common factor among the affected pages, such as language, creation date or production workflow. Pages created under apparently identical conditions may behave differently. The pages I recreated are now working, so the original corruption may no longer be reproducible on those particular pages.

The circumstances in which the editor problem appeared remain unclear. I had not made general changes to the site at that time. The only significant updates were Helix Ultimate and SP Page Builder, which I installed because of important security issues.

I am also surprised that relatively few users appear to have reported a similar editor problem. This raises the possibility that it may depend on a particular interaction between Helix, SP Page Builder, Joomla’s editor integration, another extension, or the configuration of this site.

Could you therefore confirm whether you would investigate the editor malfunction itself, across components that call a Joomla editor, rather than only the pages that have already been recreated? I would particularly like to know whether you are aware of any compatibility issue of this kind following Helix or SP Page Builder updates.

If access to the production site is still useful for that investigation, please tell me which settings or components you intend to inspect and whether you expect to make any changes. I can then take a complete backup, create a separate temporary administrator account and provide the credentials through the hidden content section.

Best regards,

Jean-Marie

Ziaul Kabir Staff

2 months ago

Hello,

Thank you for the clarification.

Yes, we'd like to investigate the underlying issue, not just the affected pages. To do that, we'll need access to your site so we can inspect the editor configuration, SP Page Builder, Helix Ultimate, and other relevant components to identify the root cause.

Please create a full backup of your site, then share temporary administrator access through the hidden content section. We'll investigate the issue and let you know what we find.

Thanks.

Jean-Marie Putz Asked this

2 months ago

OK.
I have made an Akeeba backup.
The password is in Hidden Content.
Please note I am working on the website daily, so I would appreciate you tell me when you have changed something on it, just in case I would need to run a restore and resyncrhonize with my local data.

Thanks a lot for the support

Jean-Marie Putz

Jean-Marie Putz Asked this

2 months ago

I forgot to give you the username

Jean-Marie Putz Asked this

2 months ago

Any news...?

Ziaul Kabir Staff

2 months ago

Hello,

I apologize for the delay.

I have set up your site on my local machine for testing. Could you please let me know a specific page or article where the issue can be reproduced? This will help me investigate the problem more efficiently.

Thanks.

Jean-Marie Putz Asked this

2 months ago

Hello,

Thank you for your reply and for copying the site locally.

I would like to clarify the situation, because there are actually two separate issues, and they may or may not be related.

The first issue, which is the most important one for me, concerns the Joomla editors. On my site, I currently cannot edit text in HTML anymore when using the Joomla editors. This happens with the standard TinyMCE editor, with JCE Editor Pro, and also when editing Joomla content through the SP Page Builder backend editor.

At the moment, I have switched to “No Editor / Non WYSIWYG” as a workaround, because this is the only way I can safely edit the raw HTML. However, when using TinyMCE or JCE, the HTML/source editing option and the preview option are missing on my side.

Since you now have a local copy of the site, I think the easiest way to reproduce this would be to switch my current “No Editor” setting back to TinyMCE or JCE and check whether the HTML/source editor and preview are available when editing an article or Joomla text element. On my installation, these functions are not available anymore.

The second issue concerns the column layout after republishing pages. This problem seems to happen roughly once every three pages, but I have not yet found a fully reliable pattern. It appears to be independent of the language, the length of the page, or the amount of content. The only common factor I have noticed so far is that it seems to happen only on pages that begin with a 1 + 10 + 1 column structure.

This column issue is difficult for me to document with stable examples, because when it happens I usually need to apply a workaround. The workaround is quite unpleasant: I often have to delete the affected page and recreate it. For that reason, I cannot always keep broken examples available on the live site.

For the column issue, I can continue using this workaround for the moment. The more urgent problem is the editor issue, because it affects my daily work and forces me to edit everything in raw non-WYSIWYG mode.

I should also mention that I did not perform any other major update around the date when the problem started, apart from the updates to Helix and SP Page Builder. The problem first appeared with an extension from another vendor, but I later noticed that it also affects SP Page Builder, at least when using the Joomla backend editor with SP Page Builder content.

So, to summarise my priorities:

The missing HTML/source editor and preview in Joomla editors is the main issue I would like to solve first.

The column layout problem after republishing pages is secondary for now, because I have a workaround, even though it is not convenient.

Please let me know if you need specific access details, screenshots, or a short list of pages where the 1 + 10 + 1 column structure is used.

Best regards,

Jean-Marie

Ziaul Kabir Staff

2 months ago

Hello Jean-Marie,

Thank you for your patience while we investigated on the local copy of your site.

Regarding the missing HTML/source editor and preview options in JCE: we were able to confirm this on our end, but it appears to be a JCE-side issue rather than something related to SP Page Builder or Helix Ultimate. When JCE is set as the default editor, its toolbar does not load at all for the article content field, independent of any SP Page Builder or Helix component. Since JCE is a third-party editor extension and not one of our products, we'd recommend raising this directly with the JCE team or checking the Joomla forum, as it's likely a JCE compatibility issue with your current Joomla version rather than something on our side.

For SP Page Builder specifically: we tested the Text Block and Raw HTML addons, and in both cases the code editor option is available and working correctly on our end.

Regarding the column layout issue, we were not able to reproduce the broken layout using a 1+10+1 column structure with Raw HTML content on our local copy, even after republishing multiple times. Since this issue seems to depend on specific conditions we may not be replicating exactly, could you share a screencast showing the issue step by step, from a working page through to the point where the layout breaks after republishing? That would help us pinpoint exactly what triggers it.

Looking forward to your screencast so we can continue investigating the layout issue.

Best regards

Jean-Marie Putz Asked this

2 months ago

Hello,
Thank you for checking the local copy of my site.

However, I would like to clarify an important point: I do not think this issue can be reduced to a JCE-only problem.

JCE does indeed show an available update on my site. But that is precisely why I mentioned it: JCE has not been updated for a long time. The installed version is still 2.9.81, while the available update is 2.9.99.9. Since I have not updated JCE recently, there is no obvious reason why its behaviour would suddenly change on its own.

The problem appeared after the recent Helix Ultimate and SP Page Builder updates, which were the only significant changes made around that time. That does not prove that Helix or SP Page Builder is necessarily responsible, but it makes it difficult to conclude that the issue is only on the JCE side.

I should also add that, in my normal workflow, I do not really use JCE as a full editing environment. Since I build and edit my pages mainly with SP Page Builder, I do not need most of the advanced JCE Pro features. That is precisely why I suspended my JCE Pro subscription some time ago.

However, JCE Pro is still set as my default Joomla editor, and I suspect that it may be used by the Expand Editor or by some expanded editing views. This is why the issue may still appear through JCE, even though I am not actively using JCE itself as my main working tool.

There is another important point: the problem is not limited to JCE. I also experience editor-related issues when using the standard Joomla editor, TinyMCE. This is why I believe the issue may be related to how editor fields, editor buttons, toolbar options, modal windows or expanded editor views are now being loaded or initialised after the updates.

Regarding SP Page Builder, I understand that the Text Block and Raw HTML addons may show a working code editor in your tests. However, in practice, the Text Block addon is not a usable replacement for my workflow. Many of my articles are long, often more than 1,000 words, and the standard addon editing area is too small for comfortable work.

There is also a formatting issue when text is copied from an external source. The first paragraph often keeps the correct paragraph formatting, but the following paragraphs may receive a different paragraph style. This is not a new issue: I already reported this problem two years ago in a support ticket titled “Issues Encountered With SP PageBuilder 5.1.18 On Joomla”, under the same JoomShaper account. At that time, I explained that pasted text blocks could receive unexpected inline styles from the second paragraph onwards, making manual correction necessary.

This makes the Expand Editor essential, because it is the only practical way to inspect, correct and clean the content properly. The problem is that the Expand Editor no longer works as expected.
So the core problem is not simply “JCE does not load”. The core problem is that the normal editor workflow, including source/HTML editing, preview and expanded editing, is now broken or unreliable in places where it worked before.

Could you please test the following on the local copy of the site:
Set TinyMCE as the default Joomla editor and check whether HTML/source editing and preview work normally in a Joomla article content field.

Set JCE as the default editor and check whether the toolbar, source editor and preview options load correctly.

In SP Page Builder, test the Text Block addon with a long article copied from an external source, then open the Expand Editor and check whether source editing, preview and paragraph formatting behave correctly.

Check whether Helix Ultimate or SP Page Builder is loading JavaScript, CSS, overrides or modal/editor scripts that could interfere with Joomla editor initialisation, toolbar rendering or expanded editor windows.

For the column layout issue, I understand that you could not reproduce it. Since the problem appears randomly, I cannot easily provide a useful screencast at this stage. The next time it happens, I will inspect the generated code before correcting the page and will send you the relevant details.
For now, the editor issue remains the central problem, because it affects my daily workflow across many long multilingual articles.
Best regards,
Jean-Marie

Ziaul Kabir Staff

2 months ago

Hello Jean-Marie,

Thank you for your detailed explanation and for sharing more information about your workflow.

We understand your point that this may not be only a JCE-related issue, especially since you are also experiencing similar behavior with TinyMCE. We have shared your feedback and the suggested test scenarios with our development team for further investigation.

We will check the interaction between SP Page Builder, Helix Ultimate, and the Joomla editors. Please allow us some time to review this properly.

Thank you for your patience and understanding.

Best regards,

Jean-Marie Putz Asked this

2 months ago

Hello,
Thank you for your reply and for forwarding the details to your development team.

I appreciate that the issue is now being investigated more broadly, including the possible interaction between SP Page Builder, Helix Ultimate and the Joomla editors. This is indeed the point that seems important to me, since the problem does not appear to be limited to JCE only.

Please take the time you need to review this properly.

For the moment, I can continue working thanks to my current workaround, which consists of preparing and publishing my pages directly in HTML. This allows me to keep my production workflow moving without accumulating delays.

Of course, this is only a workaround and not a long-term solution, because the normal editor workflow remains important for maintaining and editing long multilingual articles more comfortably.
Thank you again for taking this seriously.

Best regards,
Jean-Marie

Jean-Marie Putz Asked this

2 months ago

Additional finding regarding the SP Page Builder frontend column layout issue

Hello,
I would like to add an important observation to my existing ticket regarding the SP Page Builder frontend layout issue.

I have a recurring problem where some SP Page Builder pages display incorrectly on the frontend. In the backend editor, the layout is correct: the affected section is clearly a two-column section. However, on the frontend, the same section sometimes appears incorrectly, as if the layout had collapsed into a single-column display.
I compared an affected English page with the corresponding French page, which was displaying correctly. In the SP Page Builder backend, both pages use the same template and show the same structure.
I also checked the frontend HTML source of the problematic English page. The two SP Page Builder column elements were present in the generated HTML, so the page structure itself did not seem to be missing from the source.

The important point is this:
The affected page was loading this CSS file:
/media/com_sppagebuilder/css/article-2472.css
After purging only this CSS file in Cloudflare, the frontend layout returned to normal. I did not purge the whole Cloudflare cache, and I did not recreate the page.

In my Cloudflare configuration, I use a long cache TTL, currently 30 days. This may explain why an outdated version of this CSS file could remain active on the frontend.
I do not know whether the problem is caused by SP Page Builder, cache-busting, CSS file refresh, Joomla integration, Cloudflare caching, or something else. But for the page I was examining, purging only /media/com_sppagebuilder/css/article-2472.css in Cloudflare solved the layout issue immediately.
This seems important because my previous workaround for this issue was to delete the affected page, empty the trash, recreate the page, and recreate the language associations. That usually fixed the issue, but it is obviously not a practical workflow.

Could you please investigate whether the CSS files used by SP Page Builder pages are always properly refreshed or cache-busted when a page layout is saved, updated, duplicated, or associated in a multilingual Joomla site?
I would prefer not to manually purge SP Page Builder CSS files each time I publish or update a page. It would be very helpful to know whether this is expected behavior, a cache configuration issue, or something that SP Page Builder can handle more safely.

Also, could you please let me know if there is any progress regarding my other issue, namely the disappearance of the editor functionality?

Thank you for your help.

Best regards,
Jean-Marie Putz

Jean-Marie Putz Asked this

2 months ago

Additional evidence regarding SP Page Builder article CSS and broken frontend column layout

Hello,

I would like to add new evidence to my existing ticket regarding the SP Page Builder frontend column layout issue.
I have now been able to reproduce the problem again on another page.

The frontend layout was incorrect: a section that should display as a two-column SP Page Builder section was not rendered correctly on the frontend. This is the same recurring issue I reported earlier.

The affected page was loading the following SP Page Builder article CSS file:
/media/com_sppagebuilder/css/article-1260.css

Before purging the specific CSS file, I checked it in Chrome DevTools. The response headers showed:

Cf-Cache-Status: HIT
Age: 21808
Last-Modified: Wed, 22 Jul 2026 05:47:42 GMT
Status Code: 304 Not Modified
Earlier today, before making the later modifications to this page, I had already purged in Cloudflare all URLs matching this prefix:
/media/com_sppagebuilder/css/article-

So the Age value may correspond to that earlier prefix purge and is not necessarily unexpected.

The CSS file may simply have been cached again later when the page was visited, either by me, by another visitor, or by a crawler. That part is normal caching behavior.

However, the important point is the Last-Modified date. The CSS file was still reported as last modified on 22 July 2026, although the page had been modified later.

In other words, the issue does not seem to be that Cloudflare cached the file again. Cloudflare can only cache what the origin provides. The problem seems to be that the origin still provided an article-specific CSS file that appeared old or unchanged after the SP Page Builder page had been modified.

After purging only the specific CSS file in Cloudflare:
/media/com_sppagebuilder/css/article-1260.css
the frontend layout returned to normal immediately.

This seems to confirm that the issue is linked to the article-specific SP Page Builder CSS file. The HTML structure of the page itself appears to be present, but the frontend layout remains broken until the corresponding article CSS file is purged.

This points to a possible issue with the way SP Page Builder updates, regenerates, timestamps, or cache-busts article-specific CSS files after page changes. A visit after a purge should not cause an outdated or incorrect CSS file to be cached again if the page has been modified.

For reference, the relevant observations are:
The page layout was broken on the frontend.
The page loaded /media/com_sppagebuilder/css/article-1260.css.
Earlier the same day, before later modifying the page, I had already purged all URLs matching /media/com_sppagebuilder/css/article- in Cloudflare.

Before purging the specific CSS file, Chrome DevTools showed:Cf-Cache-Status: HIT
Age: 21808
Last-Modified: Wed, 22 Jul 2026 05:47:42 GMT
Status Code: 304 Not Modified

After purging only /media/com_sppagebuilder/css/article-1260.css in Cloudflare, the layout was immediately fixed.

I did not delete or recreate the Joomla article.

I did not recreate the language associations.

I did not purge the whole Cloudflare cache.

Previously, my workaround for this problem was to delete the affected article, empty the trash, recreate the page, and recreate the language associations. The new test shows that this heavy workaround is not necessary: purging the affected SP Page Builder article CSS file is enough to restore the layout.

Could you please investigate whether SP Page Builder correctly regenerates and updates the article-specific CSS files when a page is saved, modified, duplicated, or associated in a multilingual Joomla site?
In particular, could you check whether the file modification time, ETag, or cache-busting mechanism is reliably updated for files such as:

/media/com_sppagebuilder/css/article-1260.css

I use a long Cloudflare cache TTL by design, and this caching strategy has been stable on my site for a long time. I do not intend to change the general cache policy to work around this issue.

If SP Page Builder updates page-specific CSS files without changing their URL, modification time, ETag, or any reliable cache-busting mechanism, then any long-lived cache can eventually expose the problem. Purging Cloudflare can only be a temporary workaround if the origin continues to serve an article CSS file that appears old or unchanged after the page has been modified.

I have kept screenshots showing the broken layout, the Chrome DevTools headers, and the corrected layout after purging the CSS file.

Also, could you please let me know if there is any progress regarding my other issue, namely the disappearance of the editor functionality?

Thank you for your help.

Best regards,

Jean-Marie Putz

PS: I have screenshots showing the broken layout, the Chrome DevTools headers, and the corrected layout after purging the CSS file. However, the support form appears to accept links only, not file attachments. I prefer not to upload these screenshots to a public or third-party image hosting service, so I am including the relevant technical details directly in the message instead.

Ziaul Kabir Staff

2 months ago

Hello Jean,

Thank you for the detailed investigation and the additional technical information. The screenshots would be very helpful for our developers to better understand and reproduce the issue.

Since you are facing issues on support file attachments, could you please upload the screenshots using https://prnt.sc/ and share the generated links in your reply? In particular, screenshots of the broken layout, the Chrome DevTools response headers, and the layout after purging the article CSS file would be very useful.

Thank you!

Jean-Marie Putz Asked this

2 months ago

Hello,

Thank you for your reply.

Unfortunately, I no longer have the screenshots I mentioned earlier. They showed the same page displayed correctly in one situation and incorrectly in another, as well as the Chrome DevTools response headers for the article-specific CSS file.

However, I think the technical description I provided should already be sufficient to understand the secondary issue I reported.

The problem was that the CSS file generated for each SP Page Builder article, for example files under:

/media/com_sppagebuilder/css/article-

did not appear to be refreshed or cache-busted properly after editing a page. The filename remained the same, and after Cloudflare cached that CSS file, the edited page could display an outdated layout.

The behavior seemed slightly more complex than a simple cache issue: older pages were displayed correctly, but after modifying a page and then letting Cloudflare cache the article CSS file again, the layout problem could appear. This suggests that the article-specific CSS generation, timestamping, or cache invalidation mechanism may not always be reliable after page edits.

I reported this mainly to help your developers investigate a possible SP Page Builder CSS regeneration/cache-busting issue, especially for users who use Cloudflare or another external cache.

For my own site, I have already implemented a workaround by adding a Cloudflare rule that bypasses cache for:

/media/com_sppagebuilder/css/article-

So this CSS cache issue is not currently my highest priority.

My main unresolved problem remains the central one I reported earlier: the editors are still not functioning properly. This is much more important for me, because it directly affects my ability to maintain and update the site.

Could you please give me an update on the investigation of that editor issue? Has it been reproduced by your team, and is there any progress or suggested fix?

Thank you.

Ziaul Kabir Staff

2 months ago

Thank you for the update.

Please allow me some time to investigate the issues you've reported. I'll get back to you as soon as I have more information.

Thank you for your patience and understanding.

Best regards,

Ziaul Kabir Staff

2 months ago

Hello,

I have identified the issue related to the Article CSS not being cache-busted in Production Mode and have forwarded it to our development team for further investigation.

Thank you for your patience and understanding. We appreciate it and will keep you updated on the progress.

Best regards,

Jean-Marie Putz Asked this

2 months ago

Thank you, but is there any news about my actual problem which is I cannot use any editor anymore...?

Ziaul Kabir Staff

2 months ago

Thank you for your reply.

Based on your description, this does not appear to be related to SP Page Builder. Since the issue seems to occur with the editor, we recommend contacting the JCE Pro or other provider support forum for further assistance.

You may also want to create a staging environment to test whether the issue persists there, as this can help identify whether it's caused by your current site configuration or a third-party conflict.

Thank you.

Jean-Marie Putz Asked this

2 months ago

Hello,

Thank you for your reply, but I must say that this answer does not address the actual issue I reported.
I am not asking you to analyse only the editor extension itself. The important point is that several editors became unusable at the same time, shortly after updates to Helix Ultimate and SP Page Builder, which were the only significant changes made before the issue appeared.

This is not a minor inconvenience. The absence of a functional editor is extremely disabling for maintaining the site. It means that normal editing workflows are no longer usable, and that I am effectively forced to publish and maintain content only in raw HTML. For a large multilingual site, this is not a sustainable situation and it has a direct impact on daily site management.

For this reason, I do not think it is reasonable to redirect me separately to JCE Pro or to other editor providers. It would be very unlikely that several editors would suddenly become defective independently, at the same time, just after updates to fundamental site components.

I understand that the problem may not be caused directly by SP Page Builder itself. However, JoomShaper also develops Helix Ultimate, and Helix is a fundamental layer of the site. A JavaScript conflict, admin asset loading issue, template/framework interaction, backend integration problem, or conflict introduced by recent changes could affect editors globally without being caused by the editor extensions themselves.

I would also like to point out that this editor issue is not the only problem that appeared around the same time.

I have already identified another issue related to SP Page Builder: the article-specific CSS files generated by SP Page Builder do not appear to be reliably refreshed or cache-busted after page changes. This caused broken layouts when Cloudflare continued to serve an outdated article CSS file under the same file name.

That issue also appeared after the same period of JoomShaper-related updates.
So from my perspective, there are now at least two separate symptoms affecting global site behavior:

-backend editor usability problems;
-frontend article-specific CSS/cache refresh problems.

This makes it even less convincing to treat the editor issue as an isolated JCE Pro or editor-provider problem. The common denominator is not the editors. The common denominator appears to be the recent changes in the JoomShaper layer, especially Helix Ultimate and/or SP Page Builder.
I am not claiming that SP Page Builder is necessarily the direct cause of the editor issue. But I am asking you to investigate the JoomShaper components involved, including Helix Ultimate, instead of redirecting me to unrelated third-party editor support forums.

Creating a full staging environment for a multilingual site with thousands of pages is also not a simple or neutral request. I understand that staging can sometimes help, but in this case the problem appeared after JoomShaper-related updates, affects several editors at once, and coincides with another SP Page Builder cache/CSS issue. That should be enough to justify a technical investigation on your side.

To clarify the issue again:
-the problem appeared after recent JoomShaper-related updates;
-multiple editors are affected, not only JCE Pro;
-the issue concerns editor usability in the Joomla backend;
-the absence of a functional editor is highly disabling and forces raw HTML editing;
-no comparable editor-specific update explains why all editors would fail at the same time;
-another SP Page Builder-related CSS/cache problem appeared around the same period;
-Helix Ultimate and SP Page Builder were the relevant updated components before the problems appeared.

Could you please escalate this to your developers and ask them specifically to check for possible Helix Ultimate, SP Page Builder, or backend asset conflicts affecting Joomla editor initialization?
Thank you.

Best regards,
Jean-Marie

PS: I also need to mention another practical problem with your support system itself.
While writing my reply, your support form returned an “Invalid Token” message before I could submit the answer. This is not the first time this has happened. It means that after spending time writing a detailed technical reply, the message can simply be rejected by the form.

This makes support communication unnecessarily difficult, especially when the issue requires a precise technical explanation. If the form session expires so quickly, it should at least warn the user before invalidating the token, or preserve the written content.

Ziaul Kabir Staff

1 month ago

For the editor issue, it appears that you are using a JCE version older than v2.9.99.5, which has known security vulnerabilities. Please upgrade to the latest version of JCE Pro or contact their support team for further assistance.

We tested this on our end and found that the issue is related to JCE. You can also check the following resource for more information:
https://mysites.guru/jce-hack/

You can also check these post: https://www.joomshaper.com/forum/question/45846 and https://www.joomshaper.com/forum/question/45107

Regarding the Invalid Token message, this can occur when you have been inactive on the site for a while. This is a Joomla-generated security message and is not caused by our end.

Thank you.

Jean-Marie Putz Asked this

1 month ago

Hello,

Thank you for your reply and for pointing me to the JCE security issue.

You were right: the problem was related to an outdated JCE version. I have now upgraded JCE Pro to the latest version, cleaned up the suspicious JCE profiles and checked the affected files on the server. The editor is working again.

You may close this ticket.

Thank you for your help.

Best regards,
Jean-Marie