Module LanguageLocalizedURL

[ryan]

I'm not sure about the implementation side in this module, or whether this is a good idea for the module or not. But on the ProcessWire PageList side, the client would have to lack view access to the pages in order for them not to see them in the tree. That could also be handled on the fly by the module with a hook to Page::viewable. There may be other ways too I'm not yet thinking of.

[thijs]

Thanks for your reply! I think the client (and guests) need to be able to have access to the pages anyway because they need to be accesible on the website itself. But some css does the trick for now!

[Soma]

I'm not sure about the implementation side in this module, or whether this is a good idea for the module or not. But on the ProcessWire PageList side, the client would have to lack view access to the pages in order for them not to see them in the tree. That could also be handled on the fly by the module with a hook to Page::viewable. There may be other ways too I'm not yet thinking of.

This should be possible to add to the module. Though don't know how. ProcessPageList can't be used, but Page::viewable I remember using but doesn't work.

Page::viewable does hook, but then setting $event->return = false to hide certain pages doesn't do anything.

[landitus]

Hi all! I've been eager to try this module and now I've got 2 projects in the works. I've been having problems with the latest PW (2.2.7). Once activated, I check the 'Disable sub-folder for default language' and now, my original site gets random 404's o some pages (most of them, but not all) while the new translated url work perfectly. I've tried this same logic on another site yesterday running PW 2.2.3 and this worked perfectly.

Maybe I missed something, but maybe you can help me out!

[landitus]

Oh! I found what's bugging me.

The pages that give me 404's are pages that have differences between the name (url) and title. So it seems that, with the module on, the urls on the anchor links are constructed using the title and not using the name field? I was getting 404's because indeed that page didn't exist. So the problem lies in the anchor link. Do I make any sense?

[Soma]

Yes, the url is generated by slugging the language titles.

So something in that direction it must be, but even if the title and name is different it doesn't matter cause it only takes the title and never the name to brute force to the page. It's a little more complicated and quite a lot of things going on already. Can you look at the module PageName inputfield. And see if you entered all cyrillic chars convertion you'll need. This should always be the first thing to prepare when installing PW first time. I'm not sure it is in your case.

I can't reproduce any 404 like you mention, and it works ever since 2.2.3 and I got it running locally since then. It still works with 2.2.7.

Ok, one thing I recognize now is the option to hide the default language segment. When I turn that on it doesn't switch language to the default anymore. I'm still investigating and don't see a simple solution yet, and I think best is to leave that option out and stick with language segment for all.

Also I still recommend to take care with this module and once you set it up, never try to change anything once live. It is still "beta" and should be not used in serious bigger projects unless you really know what you're doing.

[landitus]

Thanks for the reply Soma. I didn't understand you correctly, thought, I'm sorry The main problem I get is that translated urls are generated with titles and not by reading the page name. I guess this is the one issue I'm getting. Other than that, the disable the default language segment seems useful, at least to me and it's been working for me.

By what you're saying, the translation URLs can't be generated from the page name, is this correct? So my only solution is to always match the name and titles, it seems. I'm guessing, by the thread that it's not an easy thing to do It seems more logical to use the page name (that is the url) and not the title as sometimes, SEO practices tend to make small differences between them. This is why I'm asking.

Please tell me if I understood your response correctly!

[landitus]

Thanks for the reply Soma. I didn't understand you correctly, thought, I'm sorry The main problem I get is that translated urls are generated with titles and not by reading the page name. I guess this is the one issue I'm getting. Other than that, the disable the default language segment seems useful, at least to me and it's been working for me.

Edit: I recently noticed that changing a url slug (name) in a page after the module is activated won't index the link correctly.By what you're saying, the translation URLs can't be generated from the page name, is this correct? So my only solution is to always match the name and titles, it seems. I'm guessing, by the thread that it's not an easy thing to do It seems more logical to use the page name (that is the url) and not the title as sometimes, SEO practices tend to make small differences between them. This is why I'm asking.

Please tell me if I understood your response correctly!

[Soma]

Can you make any examples or show?

I'm sorry you don't understand. I don't even understand myself sometimes. You only need to know so much...

It doesn't matter what the name is, it will only chose the titles to parse the url generated by title field. But without knowing/seeing or even sitting in front of it makes it hard to tell what's wrong.

This is in the nature of how it is done for now. There's no way around it for currenlty and implementing further additions like a name field for each language would be a good way, but not as easy as first seems.

[landitus]

I get what you mean Soma

I'm trying to mold the site to work like the module does, and changed some page names to match the page titles. I had a page name of "featured" (/products/featured/) and a page title of "Featured products". I realize that to make things work I should edit the page name to (/products/featured-products'). Now the problem is those links are no longer generated by the module and are blanc/useless. Tell me if you need some further explanation.

[landitus]

Sorry Soma, but It was a cache thing!! Disregard my last post. I'll try to mold some page titles to see if the plugin works for me.

[Soma]

Ok I'll try again. Maybe I'm wrong here I'm not sure anymore. There's also mcmorry having his fingers on this..

Ah ok , with the option to hide the default language segement in url, I can reproduce hte 404 and it tries to load the real page url somehow. Well with this option turned off it's working. And the name (real url) isn't really playing a role.

Well that's what I am looking at anyway. So I might be able to fix this.

[Soma]

Took me quite some time to find a good solution to this issue, but I think I found one.

Just updated module to 0.0.9.

1. It works now, and works much better with "Disable sub-folder for default language" option.

2. Improved some code also with the "Enable multi-langauge domains." setting, which also was suffering similar issue.

It might be obvious but these two module options can't be used together. Also added notes in admin to be aware.

[nikola]

When editing homepage I get the following error (it doesn't happen when editing other pages):

Unknown Selector operator: '' -- was your selector value properly escaped?

[Soma]

Sorry, I can't reproduce this.

[nikola]

Neither can I on a fresh install of PW... it was some glitch apparently.

EDIT:

It happens if you add field language_published to home template. And if you delete it from home template, the error persists.

[nikola]

I also found a bug when I check "Disable sub-folder for default language". Everything works fine and "default" (english) is hidden in the url, but I can't get no longer to admin, it throws 404 page not found. I need to uncheck this option through phpmyadmin and I can use admin again...

[Soma]

Sorry I again can't reproduce this.

Have you installed processwire in a subdir?

[nikola]

Yes I have, it's in processwire subdir under the root. That might be the problem?

Edit:

That was the problem, I've moved it into the root and it solved the problem

[Soma]

I don't know if it was this, but when I moved PW to a subfolder and access to admin didn't work and just show homepage, though no 404.

I commited an update. Let me know if that fixes the issue for you.

[nikola]

Thanks Soma, routing did the trick, now it works from subfolder too,

[landitus]

Hey all! I'm having trouble using the module with templates that support pagination. Once the module is activated, pagination stops working.

This is my pagination code:

// Pagination
$pagination = $proyectos->renderPager(array(
 'nextItemLabel' => 'Siguiente',
 'previousItemLabel' => 'Anterior'	
));

But the urls are generated ok, but I'm stuck on page 1. The url shows "http://site/pt/proye...s/page2/page2".

I must be missing something, right?

[Michael Murphy]

Hey landitus, I also have the same issue with pagination (no solution though!)

[Wanze]

Hi folks.

I've almost finished a site using this module, it works fantastic so far ;-)

One thing I noticed AND solved (temporary):

When enabling caching on templates, then the cache file gets generated only for the language of the first request. Switching between languages does not work anymore, always the same language is loaded. That make sense, because PW stores a cacheFile per ID.

Solution:

PageRender module in the method "getCacheFile", add after line 118:

//Check the language
if ($this->user->language->title != 'default') {
$lang = $this->user->language->title;
$lang = $this->sanitizer->pageName($lang);
$secondaryID .= $lang;
}

This code adds a secondary Cache-ID per language resulting in a cache file per language.

How to implement this correctly?

I think the getCacheFile method should be hookable so this module can modify the returned CacheFile name.

[Soma]

Hey guys. I don't have the time to look into it currently and pagination works for me in my testinstall.

Thanks Wanze, never used caching, so good to know.

If anyone want to help , just feel free.