i apologize, but i do not know how to reproduce the problem as it just happened all sudenly and it is easier to fix the issue than to find on what had changed.
symptoms:
router does not recognize paths and thus doesn't create proper variables for the SEF path and always uses the default menu item.
we have a manu structure with thousands of records - ecommerce system is synchronized with joomla manu system. The urls within #__menu look like this (path/route):
Airsoft-5/Zbrane/Kratke_manualy
but joomla does comparison with LOWER CASE values and thus doesn't select proper menu.
ORIGINAL CODE:
if ($length > 0 && JString::strpos($route_lowercase.'/', $item->route.'/') === 0 && $item->type != 'menulink' && (!$app->getLanguageFilter() || $item->language == '*' || $item->language == $lang_tag))
UPDATED CODE (may not support utf8 chars)
if ($length > 0 && stripos($route_lowercase.'/', $item->route.'/') === 0 && $item->type != 'menulink' && (!$app->getLanguageFilter() || $item->language == '*' || $item->language == $lang_tag))
as you can see above:
JString::strpos
does case sensitive comparison on two values (current URL and db's path) of which one is LOWERCASE and thus should always return negative results !
SECOND ISSUE:
Running on
Perconna Mysql5.6.15
Php5.5.12 + mysqldn
Joomla 2.5.18 and 2.5.20 share the same code here
Our #__menu definition
CREATE TABLE IF NOT EXISTS udx46_menu
(
id
int(11) NOT NULL AUTO_INCREMENT,
menutype
varchar(24) NOT NULL COMMENT 'The type of menu this item belongs to. FK to #__menu_types.menutype',
title
varchar(255) NOT NULL COMMENT 'The display title of the menu item.',
alias
varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT 'The SEF alias of the menu item.',
note
varchar(255) NOT NULL DEFAULT '',
path
varchar(1024) NOT NULL COMMENT 'The computed path of the menu item based on the alias field.',
link
varchar(1024) NOT NULL COMMENT 'The actually link the menu item refers to.',
type
varchar(16) NOT NULL COMMENT 'The type of link: Component, URL, Alias, Separator',
published
tinyint(4) NOT NULL DEFAULT '0' COMMENT 'The published state of the menu link.',
parent_id
int(10) unsigned NOT NULL DEFAULT '1' COMMENT 'The parent menu item in the menu tree.',
level
int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The relative level in the tree.',
component_id
int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'FK to #__extensions.id',
ordering
int(11) NOT NULL DEFAULT '0' COMMENT 'The relative ordering of the menu item in the tree.',
checked_out
int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'FK to #__users.id',
checked_out_time
timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'The time the menu item was checked out.',
browserNav
tinyint(4) NOT NULL DEFAULT '0' COMMENT 'The click behaviour of the link.',
access
int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The access level required to view the menu item.',
img
varchar(255) NOT NULL COMMENT 'The image of the menu item.',
template_style_id
int(10) unsigned NOT NULL DEFAULT '0',
params
text NOT NULL COMMENT 'JSON encoded data for the menu item.',
lft
int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set lft.',
rgt
int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set rgt.',
home
tinyint(3) unsigned NOT NULL DEFAULT '0' COMMENT 'Indicates if this menu item is the home or default page.',
language
char(7) NOT NULL DEFAULT '',
client_id
tinyint(4) NOT NULL DEFAULT '0',
PRIMARY KEY (id
),
UNIQUE KEY idx_client_id_parent_id_alias_language
(client_id
,parent_id
,alias
,language
),
KEY idx_componentid
(component_id
,menutype
,published
,access
),
KEY idx_menutype
(menutype
),
KEY idx_left_right
(lft
,rgt
),
KEY idx_alias
(alias
),
KEY idx_path
(path
(255)),
KEY idx_language
(language
)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=5236 ;
hello, thank you, i will try to do that
since i must have fixed this very fast this, this is further information:
the URLs within the path column of the menu are created with 3rd party extension and they don't follow the default router's logic such as /component/virtuemart/SEF_ADDRESS
but with a usage of 3rd party SEF extension, it's possible to use addresses like /SEF_ADDRESS
the above bug is that if you manually (with a 3rd party ext) create the link within the #__menu, joomla does not do exact comparison of the URL (it does lowercase vs stored).
the prefered logic of the core router would be:
1. do an exact check (current url vs stored menu path) -> stripos(current url, stored path ) === 0
2. do stripos(stored path, current url) === 0 && max length(stored path) -> in this case core sef router could call the detected component's router
stored within #__menu: /SEF_URL
current url: /SEF_URL/FURTHER
so even when SEF_URL/FURTHER is not part of the menu it still can get parsed by component's sef without using a plugin or /component/virtuemart/FURTHER
best regards, stan
You may blame the J!Tracker Application for transmitting this comment.
Category | ⇒ | SEF |
Status | New | ⇒ | Information Required |
I have to disagree with the assumption that this is a bug and the proposed solution. First of all, Joomla works with lowercase URLs. If you inject mixed-case URLs into the system, you have to modify Joomla yourself to acommodate for that. As you correctly noted, the solution that you are proposing is not UTF8 safe.
Regarding the second proposal of looking up the data via a DB query: While it might be okay to do so for the parsing of a URL, we are also using the menu data to build the URLs. So if we don't load it all during parsing, we have to load it all during building a URL. This is necessary, because we don't have a normalized structure for the query data of a component against which we search the right Itemid for each link. And even if we had that, we would have to query the DB for each link that we build on a page. With a simple dropdown menu with 30 entries, that would mean 30 additional queries. So instead of having 31 queries, we have one query that loads all menu data at once and then processes it in PHP. Except for a very few edgecases, this is a lot faster than doing the searching via DB.
That said, I would classify this as not a bug and ask it to be closed.
Status | Information Required | ⇒ | Closed |
Set to "closed" on behalf of @Hackwar by The JTracker Application at issues.joomla.org/joomla-cms/3726
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-11-17 21:55:02 |
Labels |
Added:
?
|
Since you already propose a code change, can you do a Pull Request?
The easiest way to do it would be to use the GitHub UI as explained here: http://docs.joomla.org/Using_the_Github_UI_to_Make_Pull_Requests