I will try my best to lay down the issue. First and foremost, I have to say that I use Gantry 5 and call the function / method via TWIG over some kind of facade. But it has to be said that it is a direct Joomla call in the end why I assume a bug within ContentHelperRoute::getArticleRoute(articleId, catId)
. I have strong evidence that it isn't the facades issue but rather the getArticleRoute(...)
method and the result returned from the call.
1.) For me it only occured on the root page e.g. HOME - On all sub paths everything is working fine
2.) ContentHelperRoute::getArticleRoute(articleId, catId)
calls do not return the valid route. It is simply nothing returned for either all or some of the articles.
I will now show you a comparision to demonstrate what does not work and what does work (based on TWIG facade).
Does not work on HOME but on all other pages
joomla.route(joomla.call('ContentHelperRoute::getArticleRoute', articleId, catId))
Does always work because no ContentHelperRoute involved
joomla.route("index.php?option=com_content&view=article&id=" ~ articleId ~ "&catid=" ~ catId)
Sorry for not transfering the actual code to PHP but it's obvious what happens for a developer.
On all pages the correct route should be returned if a valid articleId
and catId
pair is passed to ContentHelperRoute::getArticleRoute(articleId, catId)
When calling the method ContentHelperRoute::getArticleRoute(articleId, catId)
from a page located on the root path at least for some articles it happens that no route is returned. I had the case where getArticleRoute
didn't return any route for any catId
/ articleId
pair but also another install were I verified that always the first queried route didn't get resolved correctly.
Joomla 3.8.11
Gantry 5.4.24
Something must be messed up with this routine. I rolled back 3.8.10 were the issue does already occur so it might be dating back a few revisions. I also got input from another person which strongly indicates that it worked some time back in history. Because I have written a Particle which does use this routine for quite some time and I'm also pretty sure that it worked a few revisions ago because I did test it the time I made the last Particle build.
Labels |
Added:
?
|
Category | ⇒ | Router / SEF |
It also needs to be confirmed that the Gantry facades are actually calling the right method and passing all arguments correctly, as well as actually using the method results and not ignoring them.
ContentHelperRoute::getArticleRoute()
is used in the core category blog layout to generate the "read more" links. If there were a fatal core bug with this method, https://developer.joomla.org/news.html would have broken links and we probably would've heard more about it than this report.
So not trying to discount that you have an issue, but my immediate reaction is the abstraction layers between your template and the core method might be causing an unintended side effect.
@ggppdk No multi language
@mbabker I can not 100% guarantee that the facade is really passing the parameter correctly through and the correct result also back. This is something I actually haven't tested but I will try to do this. I have no knowledge on how and in what setting the method is typically used. I'm just able to lay down the issue that I experience and what the issue is most likely indicating without inner knowledge on the dependencies. But let me execute the same commands on the same site in PHP to cross check the issue.
I will also now attach @mahagr @newkind to reference the issue back to Gantry.
@mbabker I tried to replicate the same method calls within a module in PHP. After this I can say that the issue is probably the facade. So you were right. As soon as I attach the module with the same calls to ContentHelperRoute::getArticleRoute()
to the site it does work on both module and the facade. As soon as there is no PHP access on the article route method it stops again from working.
So if you're sure that there isn't any cause within Joomla please close this issue. I will create an issue in the Gantry repository.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-08-21 20:39:54 |
Closed_By | ⇒ | brianteeman |
A very important information is if this is a multi-language website