Make WordPress Core

Opened 7 years ago

Closed 6 years ago

#41373 closed defect (bug) (wontfix)

WordPress 4.8 and WPML returns NULL on retrieve of translated slugname. Only ID works

Reported by: backups's profile BackuPs Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.8
Component: Taxonomy Keywords: needs-testing needs-unit-tests reporter-feedback
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Hi

There are mayor issues with wp 4.8 and wpml, polylang or any other multilanguage plugin.

Since wp 4.8 the shortcode executed in the translated page is not calling the translated category anymore

I have one category for my custom post type "portfolio" called "gallery" the category is translated to "gallerij" for the dutch language. They both have 3 posts attached. Each for their own language.

I have this in my english page. [portfolio category="gallery"] calling the posts from the category gallery and it is showing 3 posts.

The page is duplicated into Dutch but the shortcode is the SAME. So the dutch page also has [portfolio category="gallery"] and NOT [portfolio category="gallerij"]. So the dutch page is calling the English category.

Now in wp 4.7.x this works perfectly and the dutch page shows the dutch portfolio items, or if you use a blog shortcode the blog items for each language.

But the moment wp 4.8 is installed the dutch pages with shortcodes are empty and i need to set the Dutch page with the shortcode to translated independently and change the shortcode manually to [portfolio category="gallerij"] so that it is calling the dutch category called "gallerij"

What changed in the wp code? The theme i am using did not change the theme code. Moreover it happens in any theme i try. The return is NULL when calling a slugname.

I tested this 3 x times now in a clean wp install on my local host and i get similar results all the time.

The moment i revert to wp 4.7 there is no issue. If i activate wp 4.8 the issue occurs and the translated page is empty not showing any portfolio or blog items.

Note : i tested this in my local host and was able to reproduce the same issue over and over again by reverting back and forth to wp 4.7.4 and 4.8.

Note : the categories are synchronized !! There is no issue in using the settings wrong or whatever.

in wp 4.7.x this


<?php
$term_slug='gallery';
$term_data = get_term_by( 'slug', $term_slug, 'category' );
$term_id = (int) $term_data->term_id; 
echo 'term-id :'.$term_id;

returns the id of the translated category in the translated page.

in wp 4.8 and above it returns 0 for that category in the translated page but the correct id in the page with primary original language.

So there are two faillures here.

The get_term_by fails but also the query fails... see previous reply. They both return nothing when wp 4.8 is used. $cat a list of category slugnames in the original default language

<?php
$query['tax_query'] = array(
    array(
        'taxonomy' => 'category',
        'field' => 'slug',
        'terms' => explode(',', $cat)
    )
);
 
$r = new WP_Query($query);

$cat has the slugname(s) selected separated by a ','

I reported this to wpml, https://wpml.org/forums/topic/translated-category/ but further testing learned that it happens in any multilanguage plugin so it must be a wp issue.

As said it does not happen in wp 4.7.x or below.

The solution provided for wpml does not work for me as all users have already generated shortcodes that use the slugnames, but more over these slugnames are used to filter the items by ajax filtering.

its a big problem and serious bug.

Pls provide a fix.

Change History (16)

#1 @BackuPs
7 years ago

Is it possible to get some feedback on this or at least acknowledgement of the problem?

#2 follow-up: @BackuPs
7 years ago

Is it possible to get some feedback on this or at least acknowledgement of the problem? I dont understand why this issue is ignored by the core team or confirmed or at least some response.

#3 @diegocanal
7 years ago

I have the same issue. Is there any solution at hand? 4.8.1 is going to be released today...I guess nothing is fixed.

This ticket was mentioned in Slack in #core by paaljoachim. View the logs.


7 years ago

#5 @johnbillion
7 years ago

  • Component changed from General to Taxonomy
  • Keywords needs-testing needs-unit-tests reporter-feedback added

This needs testing and verifying, but from the report it appears there is a change in behaviour of get_term_by() between 4.7 and 4.8.

@diegocanal @BackuPs Are you able to produce (or ask the WPML folks to produce) a concise explanation of the bug? What exactly is WPML doing in order to translate terms?

This needs some concise steps to reproduce this bug outside of WPML.

#6 in reply to: ↑ 2 @johnbillion
7 years ago

Replying to BackuPs:

I dont understand why this issue is ignored by the core team or confirmed or at least some response.

Please remember that everyone working on WordPress is a volunteer. Unfortunately there isn't always somebody around who can provide a response in a short amount of time, especially with such a complex bug report that involved third party plugins.

#7 @BackuPs
7 years ago

Hi John,

Thanks for the reply.

I reported this to wpml, https://wpml.org/forums/topic/translated-category/ they confirmed the bug. Further testing learned that it happens in any multilanguage plugin so it must be a wp issue.

It also happens in polylang.

Create a category and a translated category. Create a post and assign it to the category. Create a translated post and make sure its assigned to the translated category. In wpml this is done automically.

Then if you would add this code to the archive.php or single post.php you will see the term id in the original default language. But in the translated page it is empty or null.

<?php
$term_slug='gallery';
$term_data = get_term_by( 'slug', $term_slug, 'category' );
$term_id = (int) $term_data->term_id;
echo 'term-id :'.$term_id;

I will ask WPML to hook into this.

Version 0, edited 7 years ago by BackuPs (next)

#8 follow-up: @adrianosilva
7 years ago

Hi @BackuPs I'm a WPML developer. I wanted to let you know that I've fixed it already, it will pass through some tests + QA and will be most likely available in the next version. Thanks for reporting that!

#9 in reply to: ↑ 8 @BackuPs
7 years ago

Replying to adrianosilva:

Hi @BackuPs I'm a WPML developer. I wanted to let you know that I've fixed it already, it will pass through some tests + QA and will be most likely available in the next version. Thanks for reporting that!

Thank you Adriano for the feedback. It is appreciated.

#10 follow-up: @SergeyBiryukov
7 years ago

Per reply from WPML developers, appears to be a regression in [38677]:

"So the problem is confirmed and coming from get_term_by() function
In WP 4.7 it was a direct SQL

$term = $wpdb->get_row( $wpdb->prepare( "SELECT t.*, tt.* FROM $wpdb->terms AS t INNER JOIN $wpdb->term_taxonomy AS tt ON t.term_id = tt.term_id WHERE $_field = %s", $value ) . " $tax_clause LIMIT 1" );

Which means if you pass the slug you will get the ID and WPML will convert it later.

Now in WP 4.8 it is a tax query

switch ( $field ) {
        case 'slug' :
            $args['slug'] = $value;
            break;
        case 'name' :
            $args['name'] = $value;
            break;
        case 'term_taxonomy_id' :
            $args['term_taxonomy_id'] = $value;
            unset( $args[ 'taxonomy' ] );
            break;
        default :
            return false;
    }
 
    $terms = get_terms( $args );

Which return false. Which mean ID is not converted and results are same in both languages."

#11 in reply to: ↑ 10 @BackuPs
7 years ago

Replying to SergeyBiryukov:

Which return false. Which mean ID is not converted and results are same in both languages."

No get_term_by() is returning only false or NULL when a slugname is called set to the original language value in the translated page. In the original page (default language) it is returning the correct ID for the slugname used and one can retrieve all required info for that category.

Let me explain again.

Suppose i have a category called 'gallery' and translated into 'galleria' for italian....

if i call get_term_by( 'slug', 'gallery', 'category' ); in both pages (the original language page and the translated language page).

I get in the original language page the ID for the slugname 'gallery' and in the translated page i get NULL/false returned !

But in wp 4.75 we got the ID for 'galleria' although we were calling 'gallery'. It could be that there was a filter active from wpml to do that trick that i do not know. I doubt it though as it was working in other language plugins as well.

So in 4.80 and above we get NULL/false returned only in the translated pages and because of that we are not able to retrieve the translated category ID or any other information (posts attached to the category).

In wp 4.8 one has to actually call get_term_by( 'slug', 'galleria', 'category' ) in the translated page.

Now that is stupid as now one has to physically create a translated page and alter its content in order to get the correct information.

In 4.7.5 or below one could use just one page, create a translated copy and without editing anything one was able to present the correct overview of attached translated posts for each language.

In wp 3.8.x they are all just empty except for the original language page that calls the category by slugname and when that slugname is set to original language.

WP is creating the issue here because of its changes. The fix WPML presented is restoring the old get_term_by function. You can find more details in the link i supplied to you pointing to the issue on the wpml support forum.

Last edited 7 years ago by BackuPs (previous) (diff)

#12 @SergeyBiryukov
7 years ago

  • Description modified (diff)
  • Summary changed from Wordpress 4.8 and WPML returns NULL on retrieve of translated slugname. Only ID works to WordPress 4.8 and WPML returns NULL on retrieve of translated slugname. Only ID works

#13 @adrianosilvaferreira
7 years ago

@BackuPs I may be wrong, but per my debugging it looks like it is not a problem with WP. Other plugins that modify term queries will need to do some workaround to fix that like I did.

In WPML we modify term clauses queries in order to fix the query for translations. I had to avoid some of them when get_term_by is in the call stack.

Basically WP from now on is getting term with get_terms when we add as field argument slug or name. For ID it works because get_term is called which calls a query directly returning ID we can filter.

#14 @BackuPs
7 years ago

@adrianosilvaferreira

@adrianosilva

I tried wpml 3.80 and the issue still exists. In what version is this fixed? I still need to add a filter with old get_term_by to get this to work.

Can you advice please.

Last edited 7 years ago by BackuPs (previous) (diff)

#15 @adrianosilvaferreira
7 years ago

@BackuPs the fix has been implemented after 3.8.0 was released. I will see with the team whether we can include it in a next minor release.

#16 @boonebgorges
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

It's unfortunate that [38677] caused this unexpected change in behavior, and especially unfortunate that it wasn't caught before the 4.8 release. This points to two things:

  • the need for the core team to be more thorough about canvassing possible regressions of this sort when making this kind of internal change - I personally hadn't thought about the sort of case described here when working on #21760 - and then communicating them clearly to plugin devs well in advance.
  • Developers of major plugins should be testing beta, and ideally alpha, versions of major WordPress releases for regressions of this sort.

All this being said: While the changes to get_term_by() were implemented in a way that caused some unintended fallout, the changes themselves were good ones. WPML, and presumably other plugins, have since updated their uses of get_term_by() to mitigate any problems. As such, I think that no further action is appropriate on this ticket. Apologies to those affected, especially for the lapses in communication.

Note: See TracTickets for help on using tickets.