Critical SP Page Builder Layout Corruption Issue On Multilingual Production Website
Jean-Marie Putz
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
Ziaul Kabir
Accepted AnswerHello,
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
Accepted AnswerHello,
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