Support

If you look at this stack trace you will see that somehow SP PageBuilder hijacks the request and tries to handle it. Please contact SP PageBuilder developers and ask them why the heck are they hijacking a request of a third party component that has absolutely nothing to do with content management in the backend of the site.

This is the umpteenth problem we have reported to us regarding SP PageBuilder. The issues we see are very basic. We seriously question the stability and security of that product given the number and nature of the issues we have seen. Our very strong recommendation is to not use SP PageBuilder.

I generally recommend not using a page builder for two reasons: it's not necessary and it does not lead to future-proof content.

Page Builders are a WordPress calamity unfortunately ported to Joomla by people who don't understand that Joomla can already do everything a Page Builder can do without the overhead and precariousness of a Page Builder. On a very basic level, without much knowledge, Joomla lets you create templates in its included TinyMCE editor — or use JCE which exposes an even easier interface to do that. You can publish specific modules or module positions using the load position and load module plugin code. Combining the two you have a Page Builder but into Joomla... since Joomla 1.5, actually. Bam! You can use your template framework's CSS classes or some custom CSS to style your article template. The downside of this solution is the same as using a Page Builder: if you ever decide to change the information or visual design of your pages you will have to edit each and every page. The upside to using a Page Builder is that you are no longer using third party software (lower cost, faster site, faster page rendering — the latter two result in a much better search ranking), you do not have CSS clashes and it's easier for the end user updating the content as they only have access to the editable areas of the content template, not the parts of your design which they should have no control over.

There is another approach which is almost completely future-proof but more involved for the site integrator (but NOT the end user updating the content — it's easier for them!): using Joomla's custom fields and a custom template override. Conceptually, it's about creating custom content types, what we would have called a CCK (Content Creation Kit) a decade ago. The idea is that you are structuring the data that goes on a content item and then you implement the best way to display it coherently. Having the data structured makes it easier for the end user maintaining the content to enter the data in the first place. Moreover, it allows you, the site integrator, to easily change the visual representation and take it to a completely different direction without having to edit the content already published at all. It's the future-proofing that Page Builders can never, EVER, achieve.

My wife is using that in all of the sites she's building for non-profit organisations and I've got to say it's a phenomenal way of building sites. It's easier if I use an example. Let's say you want to make a food blogger site. Each blog post (recipe) typically needs: a list of ingredients, a photo gallery, a featured video, step by step execution, some generic content with background on the recipe and general blah-blah. You need the following custom fields:

1. Repeatable field: ingredients. Each row consists of these fields:
   1. Text field: Quantity e.g. 1, ½, 100 etc
   2. Text field: Unit of measurement e.g. Kg, g, ml etc
   3. Text field: Name, e.g. celery, water, chicken etc
2. Repeatable field: gallery. Each row consists of these fields:
   1. Media field: photo
3. URL field: video
4. Repeatable field: execution. Each row consists of these fields:
   1. Editor field: instructions for this step.

The generic content is your article text area. You can totally avoid the fourth custom field and just have it as part of the content but I've always liked site like https://akispetretzikis.com/en/all-recipe-categories where you can tap / click on a step to "cross it off" while cooking. This is easier to implement if you have each step as its own data item when rendering the page :)

You will of course need to make a template override to render the custom fields in a coherent way. My friend Marc Dechèvre has written https://magazine.joomla.org/all-issues/may-2021/explore-the-core-play-with-custom-fields-to-enrich-your-content-or-your-design last May explaining this. Click on his name on the magazine page, he has an entire series of articles dedicated to custom fields and how to maximise their utility in Joomla. That was one of the reasons the first item I insisted on putting in the Joomla 4 roadmap back in June 2015 when we had our first round table discussion was custom fields. Mad props to Allow Moritz for gracefully contributing his DPFields extension to the core and morphing it into what became Joomla's Custom Fields feature.

For the presentation of those fields in the backend there's d2 Content for Joomla 3 (and soon for Joomla 4, they are working on it). In short, it allows you to create a custom backend editing interface for each article category, displaying core fields and custom fields in the order and tabs that make most sense for your content use case.

So why use a Page Builder or a CCK when Joomla 3.7 and later already includes both in the core? All you need to do is use the core. You will put a little bit more time initially but you will have an easily maintainable site which won't require a complete rebuild in 3 to 5 years when your client asks you for an upgrade to the information architecture and visual identity. An ounce of prevention is worth a pound of cure as the saying goes.