BoldMinded

Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Problem with {translated_url} in custom language switcher

Status Resolved
Add-on / Version Publisher 1.2.3
Severity Critical
EE Version 2.8

Es Kay

Jun 12, 2014

Hi,

I have built a custom language switcher using the {exp:publisher:languages} tag loop.
Then I bulit the required links as: {long_name}

The problem is that the links that Publisher generates, even though they include the correct language prefix, they attach only the last url segment on the generated href disregarding all the intermediate segments that may exist for a given page.
For example, when I am on the page “http://www.domain.com/en/blog/view/article-title” and switch the language to Greek, the href generated by Publisher is “http://www.domain.com/gr/article-title” which is incorrect.

I know I’m a little bit behind on the version of Publisher I’m using but I haven’t found the time to update/test/deploy until now as my client’s production server is a total mess.
Am I doing something wrong or is this some kind of bug probably fixed in more recent Publisher versions?

Thanks in advance

#1

BoldMinded (Brian)

The first thing you’ll need to do is upgrade to version 1.4 before I can assist. There have been updates to the switching code since 1.2.3, this issue might already be fixed.

#2

Es Kay

Unfortunately your support system has made some html tags dissappear on my above post and the “Edit Ticket” function seems not to be working. So at the 2nd line above I wrote: Then I bulit the required links as: a href = {translated_url} > {long_name} a

#3

Es Kay

Just updated Publisher to v1.4.0 Unfortunately the problem persists.

#4

BoldMinded (Brian)

Is blog/view an actual template group and template name? Do you have the Translated URLs feature turned on? Is it only that URL or are other URLs not translating either? Is this a new issue with this URL or has it always been occurring? Have you tried setting up a new EE install with only Publisher installed to re-create the issue in a clean environment?

#5

Es Kay

Yes, blog/view is an actual template group & name. This behavior happens on any template group & name combination. Not specifically to the blog/view pair. It always ignores the intermediate url segments and just adds the correct url language prefix + the last url segment of the requested page.

I don’t use the Translated URLs feature so I have it set to off.

I can’t really say if this is a new issue as I didn’t have a language switcher until now. My client had to prepare all the trasnlations first. So, while developing, I was manually adding the language prefix to the url to test the templates out until now.

I have not tried setting up EE with only Publisher installed on a clean environment as I didn’t have the time, and more importantly, even if this worked it would mean nothing to me as the task is to make it work in the current context/server/environment & EE architecture setup.

You can take a look at the behavior I’m describing at http://www.emver.gr

Also, my code that generates the custom language switcher depends on a jQuery dropdown (http://ixtendo.com/polyglot-language-switcher-jquery-plugin/) that transforms a select option list containing anchors, to a ul > li > anchor list

The code is:

<div id="polyglotLanguageSwitcher">
  <form acti>
    <select id="polyglot-language-options">
    {exp:publisher:languages}
    <option id="{short_name}" value="{short_name}"{if is_active} selected{/if}>
      <a href="http://{translated_url}%22rel=%22alternate" rel="alternate">{long_name}</a>
    </option>
    {/exp:publisher:languages}
    </select>
  </form>
</div>

I don’t beieve that the javascript has anything to do with the href generation as it uses whatever Publisher passes to it and then it transforms the html tags (not the actual href attributes) just for presentation purposes.

#6

BoldMinded (Brian)

even if this worked it would mean nothing to me as the task is to make it work in the current context/server/environment & EE architecture setup

This means everything. I see from your html that it looks like you’re using Polyglot as well? The point of setting up a clean environment is to remove other potential conflicts, simplify the issue, and then narrow it down to the actual cause of the issue. I have no clue what other add-ons are installed that could be conflicting. The issue needs to be recreated in an environment with ONLY Publisher installed to prove that it is indeed a Publisher issue. I can’t spend time going down a rabbit hole and debugging issues in everyone’s environments only to discover its not an issue with one of my add-ons, or its an implementation issue (trust me, I’ve seen this more times than I care to mention). You need to help me help you. Backup your db, then start uninstalling add-ons until nothing is left but Publisher. If the issue suddenly corrects itself, then we know what add-on might be causing a conflict. If you uninstall everything to where only Publisher is left, then we know it is 100% a Publisher issue and I’ll look into it.

Sorry for asking you to do this, but lately I’ve spent a lot of time debugging issues that turn out to not even be Publisher’s fault, and I do this a few times a week. Regarding the switcher itself, I have seen a few bugs when it comes to URL switching, but it has been awhile, and none similar to this.

#7

BoldMinded (Brian)

I also can’t replicate this in 3 dev environments, and my Selenium test suite passes without errors, which tests issues such as this. Just asking that you try to narrow down the issue before I look into it. I don’t know what Polyglot is doing, but that is a red flag to me (having another multi-lingual module installed with Publisher). So, simplification is necessary to find the source of the issue.

#8

BoldMinded (Brian)

So Polyglot language switcher isn’t the EE Polyglot module? Regardless, since I can’t replicate locally I still ask that you take steps I mention above first.

#9

BoldMinded (Brian)

Did you try {switch_language_url} instead of {translated_url}?

#10

Es Kay

Hi again and please excuse me for wasting your time on such a rediculous bug (as it turned out to be) that had nothing to do with Publisher.

First I should mention that Polyglot is not an EE module/addon. It is a simple jQuery plugin that creates language switching dropdowns with flags and some prebuilt animations. It is supposed to be a js plugin just for visuals creation.

The {switch_language_url} and the {translated_url} gave the exact same result. But I ended up using {switch_language_url} on my final solution.

Secondly, you were absolutely right once again 😊. I wouldn’t have found the culprit without simplifying the app environment first. Even though I’m a developer myself and have spent enormous amounts of time chasing problems and debugging, I was negative to such an idea on my previous post just because I’m very busy developing on other projects currently that are soon to be due. I work under huge pressure and the last thing on earth I needed was to setup a test environment for such a minor issue.

The problem turned out to be the damned jQuery plugin Polyglot. The js code was messing with the urls. Specifically, it ignored the passed href and it was trying to recreate the language switching link on its own by combining [removed] elements in a very “inelegant” way. I had to manually override its code and use the Publisher passed hrefs.

Publisher has proven to be rock-steady once more. Again, sorry for delegating such a rediculous situation to you.

Cheers!

#11

BoldMinded (Brian)

No worries 😊 Glad you figured it out. Lately a lot of bug reports I’ve gotten have been due to conflicts with other add-ons, so the first thing I have people do with bugs I can’t replicate is to simplify, like you did, to narrow down the cause.

Login to reply