Hi Cor
Looks like there's been a series of people coming with issue using sh404SEF and SPSPageBuilders in the last few days so after that first round of fixes on sh404SEF side, we had to dig further and find the actual source. It turns out most issues come from a series of bugs in SPPagebuilder itself. I'm going to copy/paste here the response I made to another user who provided us with a backup of their site, so that we could actually debug the real issue:
Quoted from other ticket --------------------------------------------------------------------------------------------------------------
Hi again,
So I finally got around to looking into this. Took a bit of time, not so much to find the actual cause but rather to make the site copy works on my local machine (fight the geoip fencing and redirects first, then debugger would not work on the site when using my default PHP 7.3 and quite a few other things).
Then I was able to step through the code and found that the problem is a bug in SPPagebuilder. They've tried to put some complex code to handle sh404SEF specifically (which is not needed, at least in the case of front end editing) and introduced a bug due to that. The bug is only causing an issue when sh404SEF is enabled because they put it in a section of code that's only activated when sh404SEF is installed.
Problem is in /administrator/components/com_sppagebuilder/helpers/sppagebuilder.php, at line 335 and below.
Current code is:
public static function generateEditUrl ($item, $menuid) {
// generate language
$lang = '';
if (isset($item->language) && $item->language != '*') {
$lang_array = explode('-',$item->language);
$lang = '&lang='.$lang_array[0];
}
// if sh404sef is enabled
if( JComponentHelper::isEnabled('com_sh404sef', false) && JPluginHelper::getPlugin('system', 'sh404sef') ) {
$jconf = JFactory::getConfig();
$sh404sef_params = JComponentHelper::getParams('com_sh404sef');
if($sh404sef_params->get('Enabled') == 1 && $jconf->get('sef') == 1) {
$iframe_url = 'index.php?option=com_sppagebuilder&view=form&id=' . $item->id .'&layout=edit-iframe&Itemid='.$lang.$menuid;
$iframe_sef_url = self::generateSefUrl(JFactory::getApplication()->getRouter(), $iframe_url);
} else {
$iframe_url = JURI::root(true) . '/index.php?option=com_sppagebuilder&view=form&id=' . $item->id .'&layout=edit-iframe&Itemid='.$menuid.$lang;
$iframe_sef_url = JRoute::_($iframe_url);
}
} else {
$iframe_url = JURI::root(true) . '/index.php?option=com_sppagebuilder&view=form&id=' . $item->id .'&layout=edit-iframe&Itemid='.$menuid.$lang;
$iframe_sef_url = JRoute::_($iframe_url);
}
return $iframe_sef_url;
}
Replace it with:
public static function generateEditUrl ($item, $menuid) {
// generate language
$lang = '';
if (isset($item->language) && $item->language != '*') {
$lang_array = explode('-',$item->language);
$lang = '&lang='.$lang_array[0];
}
$iframe_url = JURI::root(true) . '/index.php?option=com_sppagebuilder&view=form&id=' . $item->id .'&layout=edit-iframe&Itemid='.$menuid.$lang;
return $iframe_url;
}
The code they use even when sh404SEF is NOT used is wrong:
$iframe_url = JURI::root(true) . '/index.php?option=com_sppagebuilder&view=form&id=' . $item->id .'&layout=edit-iframe&Itemid='.$menuid.$lang;
$iframe_sef_url = JRoute::_($iframe_url);
This serves no purpose, calling JRoute::_($iframe_url) will have no effect on the URL, it does not build a SEF URL because $iframe_url starts with the site root URL. JRoute::_() will reject any URL that does not start with "index.php" or "&" so they are basically using the non-SEF URL which is totally fine and should be used whether sh404SEF is there or not.
So in short:
- when sh404SEF was not there, they are using a non-SEF URL to load the article to edit (in an iframe), which always works and is 100% fine
- when sh404SEF was present, they made a special case for it, trying to build a SFE URL but failing.
There's no need for that special case, loading he iframe article preview with non-SEF is always fine and faster. This is what the code above is doing.
While I was at it, I was curious why this would not work anyway, even when trying to load the article preview iframe by SEF URL with sh404SEF, so I also looked for the bug in their sh404SEF-related code. It at line 347 of the same above file:
if($sh404sef_params->get('Enabled') == 1 && $jconf->get('sef') == 1) {
$iframe_url = 'index.php?option=com_sppagebuilder&view=form&id=' . $item->id .'&layout=edit-iframe&Itemid='.$lang.$menuid;
$iframe_sef_url = self::generateSefUrl(JFactory::getApplication()->getRouter(), $iframe_url);
} else {
$iframe_url = JURI::root(true) . '/index.php?option=com_sppagebuilder&view=form&id=' . $item->id .'&layout=edit-iframe&Itemid='.$menuid.$lang;
$iframe_sef_url = JRoute::_($iframe_url);
}
is wrong and should be:
$iframe_url = 'index.php?option=com_sppagebuilder&view=form&id=' . $item->id . '&layout=edit-iframe&Itemid=' . $menuid . $lang;
if($sh404sef_params->get('Enabled') == 1 && $jconf->get('sef') == 1) {
$iframe_sef_url = self::generateSefUrl(JFactory::getApplication()->getRouter(), $iframe_url);
} else {
$iframe_sef_url = JRoute::_($iframe_url);
}
There are 3 errors:
1 - They are making a difference between sh404SEF and Joomla SEF when computing the non-SEF URL which is not needed
2 -
When computing the non-SEF URL, $menuid and $lang were inverted, resulting in an invalid non-SEF URL. The funny thing is they are only feeding sh404SEF with invalid data, making it appear sh404SEF is causing the problem
3 - When computing the non-SEF URL for Joomla SEF (when sh404SEF is not present or disabled), they add the site root URL at the front and so the Joomla router does not make a SEF URL anyway, it keeps the URL non-SEF.
End of quote from other ticket --------------------------------------------------------------------------------------------------------------
This other user will forward that to JoomShaper and hopefully they can integrate the fixes. Couple of remarks:
1 - I just looked into solving one particular set of issues here, namely front end editing for SPPB. If they use the same code in other parts of SPPB, trouble may ensue elsewhere. I leave it to them to figure it out.
2 - The way those bugs were added, they would cause issues even if sh404SEF was disabled
3 - After the fixes are in place, you'll need to delete 2 URLs and all their duplicates:
sppagebuilder and/or
sppagebuilder.html
Best regards
Yannick Gaultier
weeblr.com
@weeblr
