[#31798] - [4.0] Menu item of type URL does not correctly handle external requests
- Closed
- 21 Aug 2023
- Medium
- Build: 4.0.0-beta5
- # 31798
In Joomla 3.x (and below), the alias for a menu item of type URL can be used by an external request. For example, if you create a URL menu item with an alias of "fred" and a URL of index.php?option=com_my_component, you can make a request to http://my_site.com/fred and the component will run and deliver its default output. Any extra parameters on the external URL are correctly added to the URL defined in the menu item. So for example if the URL defined in the menu item is index.php?option=com_my_component&task=product_info&format=xml and the external request is http://my_site.com/fred?product=xyz the component is executed with ?option=com_my_component&task=product_info&format=xml&product=xyz
In Joomla 4, such a menu item works correctly when manually clicked on a menu, but an external request for http://my_site.com/fred results in a 404 component not found error.
404
Component not found.
#0 .../libraries/src/Application/SiteApplication.php(206): Joomla\CMS\Component\ComponentHelper::renderComponent(NULL)
#1 .../libraries/src/Application/SiteApplication.php(245): Joomla\CMS\Application\SiteApplication->dispatch()
#2 .../libraries/src/Application/CMSApplication.php(233): Joomla\CMS\Application\SiteApplication->doExecute()
#3 .../includes/app.php(63): Joomla\CMS\Application\CMSApplication->execute()
#4 .../index.php(36): require_once('/Applications/X...')
#5 {main}
[tested in Joomla! 4.0.0-beta5 Beta [ Mañana ] 27-October-2020 19:41 GMT]
The response has Content-Type:application/xml; so the format=xml parameter is correctly handled, but not the option parameter. It doesn't matter what component is used. You can reproduce this error with any of the built-in components.
Votes
joomla-cms-bot
- 
Hackwar
- | Labels |
Added:
No Code Attached Yet
bug
Removed: ? |
||
Thanks for the analysis particthistle. Yes, this can be closed. I implemented a different solution.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-08-21 06:25:24 |
| Closed_By | ⇒ | richard67 |
Closing as expected behavior.
In encountering a similar scenario today, and then looking for similar issues, I've found that this currently is by design.
Though I also thought @xjdfhbv logic was initially sound, I soon realised I'd been creating redirects all along and this was the first time I'd been trying the scenario of creating URL items to do what the redirects were doing.
Testing both Redirects and URLS, parsing additional URL parameters does not work. This also appears by design, and when you debug the 404 error, comes at the moment back to an error triggered when the non-SEF URL does not include an option parameter.
Workaround
To create a System Link > URL menu item type that is relying on the alias of an item to redirect or otherwise accept parameters, you need to:
Future Option
A new menu item type would need to be developed to create the redirect as a menu item type directly. The functionality here would then use the redirect functionality to make the URL use the Alias, and then redirect to the destination URL.
Use scenarios: