BoldMinded

All add-ons currently require PHP 7.4 or greater.

On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.

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: Unwanted automatic redirects

Status Resolved
Add-on / Version Publisher 1.6.20
Severity
EE Version 2.10.2

Dennis Frank

Jan 05, 2016

Description:

After switching to a non-default language in the front-end(via {exp:publisher:switcher style="links"}) I can no longer load the default language in another browser tab or window.

On our site a URL should always point to the same content/language. Automatic redirects could also influence search engine crawlers.

Detailed steps to reproduce the issue:
1. On http://publisher-debug.df-pro.de/ switch the language to German.
2. Open another browser tab or window and load http://publisher-debug.df-pro.de/
3. It will automatically be redirected to http://publisher-debug.df-pro.de/index.php/de

#1

Dennis Frank

Don’t know if this related:

I created the template entry/index with this exp:channel:entries element:

{exp:channel:entries channel="test"}
   <h1>{title}</h1>
   url_title: {url_title}
{/exp:channel:entries}

For non-default languages (de) it works as expected. Only the current entry is being displayed:

http://publisher-debug.df-pro.de/index.php/de/entry/test-1-de

For the default language (en) all entries getting listed:

http://publisher-debug.df-pro.de/index.php/entry/test-1-en

#2

BoldMinded (Brian)

What are your persistence settings set to? Are all entries translated to German? Sounds like persistence is off and you’re missing German translations.

I won’t be able to look into the redirect issue until tomorrow.

#3

Dennis Frank

All persistence settings are off and every entry has translations in both languages.

#4

BoldMinded (Brian)

Well, it looks like if dynamic=”no” is added to the tag it works. I’m trying to replicate it locally so I can debug it.

#5

BoldMinded (Brian)

I guess the point is dynamic=”yes” means it should load 1 entry via the url title, not show them all. So ignore my dynamic=”no” comment

#6

BoldMinded (Brian)

So far I’m unable to replicate this locally. I’ll look into it more tonight or tomorrow night.

#7

Dennis Frank

Thanks!

The second issue is not that important to me. I noticed it only in the demo. Should I send you DB and files as ZIP?

The automatic redirects are a real bummer for us. There were no issues with 1.6.8.

#8

BoldMinded (Brian)

I believe the first issue is working as intended. index.php is included in the URL b/c its defined in your config as the index page, and you don’t have an htaccess rule to remove index.php from the URL.

#9

BoldMinded (Brian)

I think I found the issue with the entries not loading. Upon saving an entry the exp_channel_titles table is updated with whatever was saved last. So if you create an entry in English, then save it in German, the German text will be in that table briefly, but Publisher reverts it back to the default text near the end of the save process. That part of the code was updated a few versions ago to grab the default language id differently, and it may have been a less reliable way to get it (I recently reverted another usage of this as well elsewhere). Looking at the native table you’ll see this:

https://www.dropbox.com/s/fq8b95a2ln3oc4b/Screenshot 2016-01-06 19.50.01.png?dl=0

The German translations in the native EE tables, thus when EE was trying to find the entry to load on http://publisher-debug.df-pro.de/index.php/en/entry/test-2 it wasn’t able to find a url_title of “test-2” because “test-2-de” was in the db. You can see a working version by going to http://publisher-debug.df-pro.de/index.php/en/entry/test-8, which was created after I made a fix.

This explains why your demo site wasn’t working correctly. If you have issues with your real site you may want to check the channel_titles table for incorrect url_titles and fix them manually.

The fix is to models/publisher_entry.php line 397. The line is changed to this:

->where('publisher_lang_id', ee()->publisher_lib->default_lang_id)
#10

Dennis Frank

Thanks Brian for fixing the second issue! 😊

The first issue wasn’t about the index.php but about the automatic redirecting.

I just removed the index.php and enabled “Hide the prefix for default language” in the demo.

Try this:

  1. open http://publisher-debug.df-pro.de/ (A)

  2. open http://publisher-debug.df-pro.de/ in another browser window/tab (B)

  3. in B: switch the language to German

  4. in A: reload

The URL in A changes to http://publisher-debug.df-pro.de/de. Bug or feature?

It is not possible to browse different languages parallel.

Can you reproduce this?

#11

BoldMinded (Brian)

I don’t think it was ever an option to browse different languages in parallel in different tabs. Language is saved to the session, which is persistent across tabs. Besides, what is the use case for needing to do that other than for development testing and/or QA? I can’t imagine an instance in which a normal web user would need to do that.

#12

Dennis Frank

Sorry it took me so long to answer…

It’s big problem for one of my clients. He get a lot of feedback from visitors and especially from the receivers of a recent mailing. When a visitor previously visited the non default language of the site links to a default language page results in 404s. This could be links in mails or external links in general. On some pages my client links to pages from the other language. Again: 404. For my client it’s hard to understand that the same URLs sometimes work and sometimes not.

It used to work exactly as we wanted with {alternate_url}:

{exp:publisher:languages}
  {if {publisher:current_language_id} != {id}}
    <a href="http://{alternate_url}" title="{phrase:switch_language}" class="language-switch">
  {/if}
{/exp:publisher:languages}
{exp:publisher:languages}
  <span class="language-switch__{if ">{long_name}</span>
{/exp:publisher:languages}
</a>

But since the Publisher 1.6.8 or 1.6.9 update {alternate_url} seems gone.

I switched to {switch_language_url} but since then I get weekly mails and calls from my client about broken links. I understand why this is, but for this site and my client and his customers it’s just a bad experience. There is no need to remember the last visited language or to be smart about URLs. Every URL should always show the same page and language regardless the language the visitor viewed the last time.

I found a workaround for now:

{translated_url} seems to work when “Force default language” is enabled. But this feels a bit hacky (and buggy?).

I don’t know, what I should wish for. May be an option to disable or ignore Publisher session cookies?

#13

BoldMinded (Brian)

{alternate_url} still exists. {translated_url} is the same value.

https://www.dropbox.com/s/i565h1uqx3fogip/Screenshot 2016-01-27 10.24.55.png?dl=0

Can you please be more descriptive with this paragraph please? Include steps to replicate. Also, give example steps to replicate with the live site.

“When a visitor previously visited the non default language of the site links to a default language page results in 404s. This could be links in mails or external links in general. On some pages my client links to pages from the other language.”

#14

Dennis Frank

Comment has been marked private.

#15

BoldMinded (Brian)

Since the link does not have a language prefix in it, there is no good or reliable way to know what language that URL links to. E.g. I have no idea if the word “zeichnung” is German, French, English, or Italian. If you turn on the prefix for all languages and add a prefix to that URL then it’ll work. One alternative is to add ?lang_id=1 to the end of the link and it should work.

https://www.brain-biotech.de/investor-relations/zeichnung?lang_id=1

#16

Dennis Frank

“Add URL prefix” and “Hide the prefix for default language” are both enabled.

I don’t understand. Every URL should habe a language prefix except the default language. All languages and language codes are known because they are defined in Publisher’s “Languages” tab. Wouldn’t it be a logical to assume that a URL without one of the defined language codes as prefix should link to the default language?

Adding language prefixes to the default language is not an option. URLs have been printed and linked for years. (And having an /de in every URL isn’t very pretty).

?lang_id=1 would work is you know about this option. But there are people who just copy the URL from the browser’s address bar… and a printed(!) letter with normal URLs letter was sent out last week.

What do you think of my workaround?

using {translated_url} with enabled “Force default language”.

It’s working for me.

#17

BoldMinded (Brian)

Using force default language means the site won’t be viewable in English.

” Wouldn’t it be a logical to assume that a URL without one of the defined language codes as prefix should link to the default language?” - I see your point on this. I’ll take a look to see if I can make it work.

#18

Dennis Frank

“Using force default language means the site won’t be viewable in English.”

It is viewable. Only {switch_language_url} does not change the language any more.

“I see your point on this. I’ll take a look to see if I can make it work.”

😊

#19

BoldMinded (Brian)

Can you do me a favor and open up the Publisher_session.php file and go to line 421 or so. You’ll see this:

// Still no language? Should we use default?
        if ($lang_id === false && ee()->publisher_helper_url->should_add_prefix($lang_id))
        {
            $lang_id = ee()->publisher_language->get_default_language_id();
        }

Remove $lang_id === false and see if that link works as you expect it to.

#20

BoldMinded (Brian)

Sorry, near line 441

#21

Dennis Frank

Okay.

I tried it with following settings:

Force default language? - No Enable URL translations? - Yes Add URL prefix? - Yes Add URL prefix to the homepage? - Yes Hide the prefix for default language?

default language: de alternate language: en

http://example.com/german-page http://example.com/en/english-page

  • switching language from de to en via {switch_language_url} result: http://example.com/english-page

  • entering http://example.com/en/english-page in browser result: http://example.com/english-page

  • {translated_url} is http://example.com/en/english-page (but the link results in http://example.com/english-page too)

Whatever I do the prefix will be removed on loading and the language remain the default language.

#22

BoldMinded (Brian)

Right, the prefix will be removed, but that change should set the language to the default if there is no prefix. You made the change on line 441 to the live site you linked to earlier?

#23

BoldMinded (Brian)

If that last fix didn’t work, try this one. Same file, down a few lines. Add this

if (!ee()->publisher_helper_url->should_add_prefix($lang_id))
        {
            $lang_id = ee()->publisher_language->get_default_language_id();
        }

Add here: https://www.dropbox.com/s/iwcf4xgzqxoyl5s/Screenshot 2016-01-27 12.27.31.png?dl=0

#24

Dennis Frank

With the second fix:

  • switching language from de to en via {switch_language_url} result: http://example.com/en/english-page OKAY

  • switching language from en to de via {switch_language_url} result: http://example.com/german-page OKAY

  • if en is active language and I enter http://example.com/german-page or switch via {translated_url} result: http://example.com/en/german-page NOT OKAY

  • if en is active language and I enter http://example.com result: http://example.com/en NOT OKAY (for me)

I hope I can help you helping me. And sorry if my English is sometimes a bit harsh. I am German. 😉

#25

BoldMinded (Brian)

You still haven’t answered my question about what type of URL that is. Are you using Structure or Pages modules?

#26

Dennis Frank

Sorry. It’s all Structure.

#27

BoldMinded (Brian)

That sends me to an entirely different part of the codebase. Thanks.

#28

BoldMinded (Brian)

Comment has been marked private.

#29

Dennis Frank

Thanks.

With the update linking or entering a default language URL from an alternate language page works nicely.

There is one issue:

When a page shares the same first URL segment for both languages the language does not change (but the URL). If the full URI is the same the non default language version is shown. If only the first segment is the same but the second or third it results in a 404.

#30

BoldMinded (Brian)

Try this build https://www.dropbox.com/s/3w479o2qs3kam45/publisher-1610-38107b3f.zip?dl=0

#31

Dennis Frank

Awesome!

I will have to test a few scenarios but for now it looks like everything works great!

And:

Best. Support. Ever.

#32

Nick Benson

Just ran into this issue on one of my projects (session causing an unwanted redirect when attempting to load page in non-prefixed default language after visiting a page in prefixed non-default language). Resolved it by commenting out the “Returning user? Has valid cookie. Default to said cookie” block around line 410 of Publisher_session.php - if a user hits an English language URL (sans prefix) we want them getting the English content 100% of the time.

Assume this will be fixed in an upcoming release… just wanted to chime in and let you know I ran into it too.

#33

Nick Benson

As another aside, I can see the “edit ticket” and “mark as resolved links” here on the ticket tracker even though this isn’t my ticket (I’m logged in as an EE user).

#34

Dennis Frank

Hi Brian,

will you officially release the build from your comment #30 (https://boldminded.com/support/ticket/1254#comment30)?

#35

BoldMinded (Brian)

Yes, probably early next week.

#36

BoldMinded (Brian)

This is included in the 1.6.11 release.

Login to reply