[#3293] Language-spefic URLs do not work

Hi,

I have a multilibgual site with Joomla 2.5.1 and CB 1.8 RC2.

As I have noticed, URLs to other extensions like the link to PMS in the profile menu and the CB login module have been changed from unreadable links to components with parameters to readable URLs based on data from the menu database table => good idea, and with CB own stuff it works, e.g. the links to users in the CB online module.

But the link to PMS in cb_login module and the CB user profile menu do not work.

I use uddeIM, but I am sure others are affected, too, and maybe this problem exists almost everywhere where creating URLs has been changed.

For example in line 313 of mod_cblogin.php:
This gives multiple results, because I have for each language one main menu with one uddeIM page.

CB uses only the first result, and so for 2nd and 3rd language URLs are wrong, e.g. de/gästebuch.html => OK, en/gästebuch.html => error.

I helped myself by making one global uddeIM menu item on a hidden menu (like requred for the CB profile page) and make the others being menu item aliases to them.

But menu item aliases do not have associations, and so when I am on the uddeIM inbox for example and change language, I get to the home page of the selected language => not nice.

It should be possible to fix this, because with its own stuff CB does it correctly: beside the one and mandatory CB profile page with public access to make registration work correctly, I have one with restricted access for every language, and e.g. the link to a user's profile in the CB online module sends me allways to the correct, language-specific URL, depending on the current language.

Please check if this can be corrected.

I will meanwhile try myself to correct for the PMS links I mentioned above, but I have no idea wherelse creation of URLs has been changed with CB 1.8 RC, and so I cannot know where else such thing should be corrected.

Thanks for reading.

Best regards,

Richard

Hello again,

for the PMS link in the cb_online module I meanwhile have the solution:

At the beginning of the "if ($pms != 0)" I have adde following line number 285:
The database query for udeeIM menu items in former line 313, now 314, I have extended by a language restriction:

This works for me, so I have to extend the link in the CB user profile's menu in the same way.

But this works only reliable if there is either one menu item with language ='*' or one for each language, but not both.

Some correction should be found in general when selecting information from the menu table to create URLs.

Can this be fixed in the final CB 1.8?

Best regards,

Richard

Again it's me,

I have checked my solution proposed above within pms.mypmspro.php and mod_cblogin.php: It works, even if there is both one global PMS menu item with language tag '*' and another one with the tag equal to the current site language.

And I have fixed another error in the same SQL queries in the same files:

The "where published>=0" should be a "where published>0"!!!

See changed files in the attached zip container:


Which one of the two menu items (one with language '*' = all and one with current site language, e.g. 'de-DE') will be used, this decision is not really reliable, because it depends on in which order the database query returns them, but both URLs are at least valid and will be found, and it seems they are returned in the same order as in the "IN" list of the condition, so the current site language menu item would be found first, if there, this seems to be ok.

And if there is either a global menu item for all languages or one for each language but not both together, then it perfectly works.

So I suggest to extend all database queries for menu item paths used when building URLs by this additional condition I mentioned within my previous post.

Please give me some feedback what you think about it.

Best regards,

Richard

Was able to confirm your issue and have created the below bug ticket for further investigation.

forge.joomlapolis.com/issues/3293

Hi,

thanks for your work.

But as I wrote above, the mod_cblogin.php has the same problem.

Is there a bug ticket for this, too?

I haven't found yet.

Best regards,

Richard

Is there a bug ticket for this, too?

No, it's same bug; will be adding a patch when time permits to also fix the module.