Tarindel

In case it’s helpful, here’s some of the results from logging I did last night to try and debug the issue:

Here’s the top of my log file when running the default theme:

PLL_Frontend::__construct()
PLL_Frontend::init()
PLL_Choose_Lang_Url::__construct()
PLL_Choose_Lang_Url::set_language_from_url()
PLL_Choose_Lang::home_language()

You can see that set_language_from_url() and home_language() are called pretty immediately.

When running Atahualpa logged in, here’s the top of the log file:

PLL_Frontend::__construct()
PLL_Frontend::init()
PLL_Choose_Lang::__construct() PLL_AJAX
PLL_Choose_Lang::set_language():hi_IN (sets pll_language_defined)
PLL_Frontend::pll_language_defined()
PLL_Frontend_Links::pll_language_defined()
— add_action(check_canonical_url)
PLL_Choose_Lang_Url::__construct()
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi

PLL_Frontend::__construct()
PLL_Frontend::init()
PLL_Choose_Lang_Url::__construct()
PLL_Choose_Lang_Url::set_language_from_url()
PLL_Choose_Lang::home_language()

Atahualpa is a 3 column theme, which may explain why PLL_Frontend gets initialized multiple times. You can see that the second construction goes through the same path.

In the third log case, where I’m running Atahualpa logged out, here’s the full log:

PLL_Frontend::__construct()
PLL_Frontend::init()
PLL_Choose_Lang::__construct() PLL_AJAX
PLL_Choose_Lang::set_language():hi_IN (sets pll_language_defined)
PLL_Frontend::pll_language_defined()
PLL_Frontend_Links::pll_language_defined()
— add_action(check_canonical_url)
PLL_Choose_Lang_Url::__construct()
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi

PLL_Frontend::__construct()
PLL_Frontend::init()
PLL_Choose_Lang::__construct() PLL_AJAX
PLL_Choose_Lang::set_language():hi_IN (sets pll_language_defined)
PLL_Frontend::pll_language_defined()
PLL_Frontend_Links::pll_language_defined()
— add_action(check_canonical_url)
PLL_Choose_Lang_Url::__construct()
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi
PLL_Frontend_Links::home_url() url: https://test.learncpp.com/
— curlang: hi

PLL_Frontend::__construct()
PLL_Frontend::init()
PLL_Choose_Lang::__construct() PLL_AJAX
PLL_Choose_Lang::set_language():hi_IN (sets pll_language_defined)
PLL_Frontend::pll_language_defined()
PLL_Frontend_Links::pll_language_defined()
— add_action(check_canonical_url)
PLL_Choose_Lang_Url::__construct()
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi
PLL_Frontend_Links::home_url() url: https://test.learncpp.com
— curlang: hi

In this case, set_language_from_url() and home_language() are never called, which is why I suspect it’s not working.

https://test.learncpp.com.

It’s a test site so I can do any experiments necessary to figure out what the issue is.

I am using a static front page and the Atahualpa theme.

I spent a couple hours last night trying to debug the issue. It looks like in the case where it’s not working, set_language_from_url() is not being called, nor is check_canonical_url().

This morning, I realized that it’s not working when I’m logged out, but it is working when I’m logged in. That points to a theme issue, maybe. So I reverted the theme to the default theme on my work computer and now it’s working in both cases.

So it looks like this might be an incompatibility with the Atahualpa theme.

And just to follow up on this some more:
* The browser language redirection works on my test site
* The browser language redirection does not work on my live site

The two sites are configured more or less identically, as I try to keep them in sync.

The mystery deepens.

Just to be more explicit about my settings:
* your permalinks settings: /%category%/%postname%/
* if you are using a static front page: Yes
* your Polylang settings:
Default language: English
URL Mod: The language is set from the directory name in pretty permalinks
Hide URL language information for default language (checked)
Remove /language/ in pretty permalinks
The front page URL contains the language code… (checked)
Detect browser language: When the front page is visited, set the language according to browser preference (checked)
Media: Activate languages and translations for media (checked)

I have a test site, and am somewhat familiar with PHP. I’m willing to work with whomever to help debug the issue.

Yes, that is the first thing I tried since I know Polylang saves a cookie after it sets the initial language. Thanks for the thought.

Just installed today, working in Chrome for me, but not Firefox.

Tried clearing the Firefox cache (and tried in incognito mode, which shouldn’t be pulling from the cache) and no dice.

Not a huge deal since I primarily use Chrome, just wanted to note that there may still be a weird issue here.

Thanks Clayton, that’s exactly what I needed to know (but couldn’t find). Much appreciated!

Nope, I’m using the standard WP functionality to show a static page as the front page of a wordpress site. Everyone sees it regardless of who they are.

The only plugin I’m running that seems like it could be remotely relevant to a problem like this is SEO_Wordpress:

https://www.utheguru.com/seo_wordpress-wordpress-seo-plugin

Just as a followup, I told eaccelerator not to cache kses.php and my site has been up all morning… so looks like that was definitely it.

I wonder why some people experience this and others don’t. Peculiar…

I think I have a resolution to this one. Doubt most of you care, but I’ll post it here in case anybody in the future runs across this while doing a google search for a similar problem.

Since copying new files over the old ones somehow temporarily fixed my site, I decided to take one of the “broken” directory structures and do some trial and error to see if I could track exactly which file was causing the problems. I figured it would probably be something in wp-content, like a caching plugin. I was wrong (but not too far wrong). It turns out the problem file is kses.php. When I copy over kses.php with a new (identical) version of kses.php, my site begins working again for a period of time.

All of those seg faults in the apache error log are correlated with my site breaking. So something is happening that causes kses.php to suddenly start seg faulting after a while. After a little research on the google, it looks like there are reported issues of this file not playing nicely with eaccelerator:

https://www.ads-software.com/support/topic/137937?replies=5

I’m pretty sure that this issue is a manifestation of that problem. It’s the only thing so far that makes all the symptoms make sense.

Incidentally, the problem with wp-stats is the same as is posted here:

https://www.ads-software.com/support/topic/167625?replies=12

which I just fixed. My old server had php4, the new one is php5.

Yup, same theme. No configuration changes at all between the one that works and one that doesn’t.

Hmm, I checked /var/log/httpd/error_log and there are some errors in there (segmentation faults — could be unrelated to wordpress) and something about an error with the wp-stats plugin (which coincidentally I note no longer displays anything on my dashboard — that used to work). Not sure whether they’re relevant, as the working blog2 directory seems to work fine anyway.

Mistressemilie, I released a fix for Tiga that corrects the blogroll issue under 2.3. It incorporates Ottos’s 2.2 fix as well.

https://www.learncpp.com/wordpress/wordpress-tiga-22-23-upgrade/

Glad to hear you got it sorted out.

The widgets seem to be working fine for me. I can rearrange their order within a given sidebar, or move them from the left to right sidebar or vice versa. I am running Firefox 2.0.0.7 under WinXP.

Can you give me some more information about what exactly you are seeing?