Some page URL lookups behaving strangely about nlingual HOT 12 CLOSED

Sweet. Thanks for all the detailed info, really appreciate it.

from nlingual.

That's strange, I had noticed this issue yesterday while testing it on a few dev sites, but it should be resolved. I'm so far unable to recreate the issue, even with a fresh install using nLingual + WooCommerce + TwentyTwenty. So far the home URL isn't redirected to the page's normal name, nor does the home link break on other pages.

Can you give me an outline of what setup you're using?

from nlingual.

Haha, we have a pretty extreme plugin count and a lot of custom code, so it could well be some bad interaction there. This time I didn't reproduce with a fresh installation like I did the last time I bugged you, so it may just be our environment. I did confirm that it doesn't happen without nLingual enabled, and that it doesn't happen with 2.8.10. We are still on 5.4, not 5.5, [edit: of Wordpress, that is] if that matters or is known to cause problems, though I bumped to latest WooCommerce on our testing instance to see if that was the culprit (it wasn't).

If I get a chance today I'll try to reproduce the issue on a fresh, blank 5.4 installation, and if the behavior crops up there I'll try going to 5.5 and see if that resolves it. If it doesn't show up in either case then I've got some digging to do, I guess. Thanks for checking it out.

from nlingual.

I don't think 5.5 has anything to do with it, though I'm wondering if it has something to do with the change I made to Rewriter::localize_here() where it first checks if it's the homepage, then checks if it's some kind of post/page/etc.

Regarding issue 2, it sounds like the link is in fact printing an empty string; can you confirm that the actual markup is printing the current page link.

My next guess is that something is causing page_on_front to return 0/null and so get_permalink is simply using the current post's URL. I'll do some digging to see what could've changed that affects that.

from nlingual.

OK, here's what I just tried:

• Fresh wp 5.4 (since it what my testing docker file was set to from last time and 5.5 shouldn't make a difference)
• nLingual 2.9.0 from git, added via mapped directory, so the only plugins I see after initial site set-up are that and Akismet (both disabled initially)
• Add a page called "test homepage" with a header reading the same.
• Set my home page to a static page, and to "test homepage", which happens to have an id of 5.
• Note: my permalink settings are at WP default
• Visit homepage. Shows my static page, URL does not change from /
• Enable nLingual. Do nothing else. No changing settings, no adding languages.
• Visit homepage. URL now shows ?page_id=5&nl_language=en

These show up as 302 redirects (from /) in my logs.

Then I tried setting URLs for the default language will be unmodified., with the result that the redirect dropped the nl_language part but retained the rest (/?page_id=5)

Then, enabled proper permalinks in WP settings. Redirect still happens, but now to /test-homepage/, as seen on our site.

Disable nLingual, behavior reverts to default (no redirect).

Now here's something odd:

• nLingual deactivated
• Visit homepage
• Observe that there are two entries in the default "pages" menu at the top, "Sample Page" and "Test Homepage"
• Observe that these link to /sample-page and / respectively.
• Enable nLingual
• /sample-page is unchanged, but Test Homepage now links to /test-homepage

This is all under theme Twenty Twenty (the default).

So it does seem to be happening with vanilla WP, unless I've done something wrong here.

HOWEVER I was not able to find a way to reproduce links intending to point at the homepage linking instead to the current page. I haven't dug far enough into Twenty Twenty's header code to tell how they're generating those links, yet.

from nlingual.

Okay that's just maddeningly strange. I'll do somet further testing tonight to see if I can recreate it.

from nlingual.

Just tried WP 5.5, same behavior. Under PHP 7.2 in both cases. Just bumped up to 7.4.9 just to cover all my bases. Same behavior.

from nlingual.

version: '3.1'
# Default mysql user: root
services:

  db:
    image: mysql
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: nlingual
    ports:
      - 3306:3306

  adminer:
    image: adminer
    restart: always
    ports:
      - 8091:8080

  wordpress:
    image: wordpress:5.5.0-php7.4-apache
    depends_on:
      - db
    restart: always
    environment:
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: nlingual
      WORDPRESS_DB_HOST: db
      WORDPRESS_DEBUG: 1
    volumes:
      - ./plugins:/var/www/html/wp-content/plugins:rw,z
    ports:
      - 8090:80

Quick & dirty docker-compose.yml I've been using to test, in case it's useful. You have to go through WP setup on first run, but as long as you don't rm the database container it shouldn't make you do that again. Just dropping nlingual in that mapped ./plugins directory straight from git, as in ./plugins/nlingual, so there's no need to install it after WP is up, should already be there if you put the plugin in place ahead of time.

The :rw,z permissions mods on the end of that directory mapping may not be necessary on macOS, but were on Linux. No clue how to make it work if you're on Windows, as I've never used Docker there.

WordPress is served on port 8090 with this file, unless you change it.

from nlingual.

Okay, got a docker instance spun up (holy crap I need to start using this more), and was able to recreate the issue.

Digging into the cause now but as far as the nl_language=en bit that's technically intended, due to the default permalink "structure" being via GET params, and the default handling being to localize URLs for the default language. It's not an outright issue but I'm debating changing some of the defaults in the next release.

from nlingual.

Right, I get that nl_language=en is working as intended, and that part's fine. Just included observations about its behavior under different settings for completeness. The way it dropped off the redirect to page #5 with default permalink structure maps just fine to how it works with page-slug redirects, I think, and it was (correctly) absent from default lang permalinks when default language redirects were disabled.

Let me know if I can do anything else to help out. Thanks a bunch for looking at this.

from nlingual.

Okay I found the culprit:

When I rewrote the current_language_post hook to check and make sure it wasn't returning an unpublished post, I didn't include logic to handle get_post_translation returning false (for un-assigned/translated posts). This caused is_front_page() to return false because it's comparing page_on_front (which was rewritten to false/0) to the current page. Technically this didn't break anything until WP_Query finishes setup and sets the $post global, which means any later attempts to rewrite page_on_front cause it to compare the queried post (the real homepage) to itself (the default post when passing null/false/0 to a function like get_post_status) rather than a non-existent one.

It's fixed now, as for the other issue with the homepage links pointing to the current page, not sure what could be happening there but might be tangentally related to page_on_front getting set to 0.

from nlingual.

Just tried out master on our testing site. All issues appear to be resolved, including the weirdly-broken home links.

Quickly kicked the tires on client language preference redirection and that still seems to be good, no regression.

Awesome. Thanks again.

from nlingual.