This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

This topic contains 34 replies, has 5 voices.

Last updated by Sumit 1 year, 8 months ago.

Assigned support staff: Sumit.

Author Posts
July 28, 2017 at 9:13 am #1329508

Pau

Hi,
already solved the issue by using ids instead of slugs, but I guess this would solve it too, didn't know it, thanks. Then I guess that what happened was that when not logged in the get_term_by in ajax was in another language and didn't work because of this bug, but when logged in there was a cookie for the user language and it worked.
Thanks and sorry
Pau

August 2, 2017 at 7:11 am #1332880

Paul

@pau,

Please hook into this thread aswell.. https://core.trac.wordpress.org/ticket/41373 to get the wp core team responding.

@Andrés Any progress or news on this. It seems that the wp core team is not responding at all to the created thread on the core.trac website. Did you have more luck getting them to respond?

August 2, 2017 at 7:24 am #1332890

Andrés
Supporter

Languages: English (English ) Spanish (Español ) French (Français )

Timezone: Europe/Paris (GMT+02:00)

Hello @paul,

I just checked and the sprint is set for WPML 3.8, however I can't give you more information than that. Were you able to contact our Compatibility team? It may help to speed this situation.

Best regards,
Andrés

August 2, 2017 at 11:14 pm #1333735

Paul

Hi Andrés,

I got a reply from wordpress core team. They want help from you.

https://core.trac.wordpress.org/ticket/41373

On slack they wrote this to me in a private message (see image):

Reply from John Blackbourn to me.

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.

Could you please reply and hook into the thread on the core track? Or on slack and create a message to

@johnbillion regarding #41373 https://core.trac.wordpress.org/ticket/41373

I want to melt the iron while it is hot, now we have attention to the problem.

Thank you !
Best regards,
Paul

August 3, 2017 at 6:52 am #1333835

Andrés
Supporter

Languages: English (English ) Spanish (Español ) French (Français )

Timezone: Europe/Paris (GMT+02:00)

Hello Paul,
I totally agree, I have passed this information to our devs. I'll keep you updated.
Thanks again for your help.

August 3, 2017 at 7:28 am #1333854

Andrés
Supporter

Languages: English (English ) Spanish (Español ) French (Français )

Timezone: Europe/Paris (GMT+02:00)

Hello Paul,

This is the feedback I got from our devs:

"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."

Have you contacted our Compatibility team? I'm pretty sure it would help with this situation or get a direct channel with our devs.

Regards

August 3, 2017 at 8:46 am #1333911

Andrés
Supporter

Languages: English (English ) Spanish (Español ) French (Français )

Timezone: Europe/Paris (GMT+02:00)

However it needs to be handle directly by our devs. Don't forget to contact our compatibility team, they may can help you faster with this situation.

August 3, 2017 at 2:13 pm #1334225

Paul

Hi Andrés

How do i contact them? Cant they hook into this thread?

Thank you !

Note : our theme is already listed https://wpml.org/theme/striking-multiflex/

Best regards,
Paul

August 3, 2017 at 2:51 pm #1334275

Andrés
Supporter

Languages: English (English ) Spanish (Español ) French (Français )

Timezone: Europe/Paris (GMT+02:00)

Hey Paul,

You can use the regular channel that you use for communicating with them and pointing them out the situation on this ticket.

Best regards,
Andrés

August 3, 2017 at 2:54 pm #1334280

Sumit
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Hi, Paul,

I am Sumit from 2nd tier support.
Andres escalated this ticket to me. I hope it is fine for you!

I understand that this theme is compatible but I would like to know the code that is affected by WordPress changes is the actual code from the theme? Or the custom code in your child/parent theme?
I will forward the details to our compatibility team if the original theme is effected without any modification else I will try to help you on my level!

Also, I would like to know your objective! Are you looking for a workaround or a permanent fix? As we've already escalated this issue to our development team and it is being discussed!

Thanks

August 4, 2017 at 7:02 am #1334845

Paul

Hi Sumit

This is the actual code from the theme. There is a folder called

/striking_r/framework/shortcodes where there is a portfolio.php that calls, after doing some prep work for the ajax sorting, /striking_r/sections/portfolio_list.php

portfolio.php is using get_term_by

		$terms = array();
		if ($cat != '') {
			foreach(explode(',', $cat) as $term_slug) {
				$terms[] = get_term_by('slug', $term_slug, 'portfolio_category');
			}
		} else {
			$terms = get_terms('portfolio_category', 'hide_empty=1');
		}

portfolio_list.php is using wp_query

	if($cat != ''){
		global $wp_version;
		if(version_compare($wp_version, "3.1", '>=')){
			$query['tax_query'] = array(
				array(
					'taxonomy' => 'portfolio_category',
					'field' => 'slug',
					'terms' => explode(',', $cat)
				)
			);
		}else{
			$query['taxonomy'] = 'portfolio_category';
			$query['term'] = $cat;
		}
	}

The portfolio shortcode was just the simple example to get this explained to you. But all code within the theme f.e. the striking page options striking where one can select sliders based on category slugnames for sliders, posts, portfolio's or custom posts. They all now have the same problem. The blog shortcode actually any of our shortcodes. They all have selectors that select slugnames for categories that build the shortcode.

The problem is that all users over 15.000 websites have build their content and have either generated shortcodes using the slugnames and or generated settings in all their pages using the slugnames for sliders that are presented in the featured header.

And since i get null on retrieving id's for these slugnames in the translated pages they all don't work anymore.

I need a permanent solution. A interim solution is no option.

My question is is WPML gonna fix this? Or is this something WP has to fix? That is not clear to me.

Best regards,
Paul

August 4, 2017 at 3:19 pm #1335395

Sumit
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Hi Paul,

Let me explain to you what is the problem.
We never provided feature it was working because WordPress was using a direct SQL to get the ID of the term using a slug. And we were just translating that ID and we are still doing it right now.
Now WordPress changed its code and now using Term query which does not return the results.

WordPress will not fix it as that is not the problem for them. We will fix it but it is up to our developers what they decide.

Now about your problem, I have tried my best to overcome from this problem for now without changing existing code.
If you can add the below code to theme functions.php or can make a separate plugin then it will make the existing code work again.

/**
 * get_term_by function from older version of WP
 * @global type $wpdb
 * @param type $field
 * @param type $value
 * @param type $taxonomy
 * @param type $output
 * @param type $filter
 * @return boolean
 */
function get_term_by_deprecated( $field, $value, $taxonomy = '', $output = OBJECT, $filter = 'raw' ) {
	global $wpdb;

	// 'term_taxonomy_id' lookups don't require taxonomy checks.
	if ( 'term_taxonomy_id' !== $field && ! taxonomy_exists( $taxonomy ) ) {
		return false;
	}

	$tax_clause = $wpdb->prepare( "AND tt.taxonomy = %s", $taxonomy );

	if ( 'slug' == $field ) {
		$_field = 't.slug';
		$value = sanitize_title($value);
		if ( empty($value) )
			return false;
	} elseif ( 'name' == $field ) {
		// Assume already escaped
		$value = wp_unslash($value);
		$_field = 't.name';
	} elseif ( 'term_taxonomy_id' == $field ) {
		$value = (int) $value;
		$_field = 'tt.term_taxonomy_id';

		// No `taxonomy` clause when searching by 'term_taxonomy_id'.
		$tax_clause = '';
	} else {
		$term = get_term( (int) $value, $taxonomy, $output, $filter );
		if ( is_wp_error( $term ) || is_null( $term ) ) {
			$term = false;
		}
		return $term;
	}

	$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" );
	if ( ! $term )
		return false;

	// In the case of 'term_taxonomy_id', override the provided `$taxonomy` with whatever we find in the db.
	if ( 'term_taxonomy_id' === $field ) {
		$taxonomy = $term->taxonomy;
	}

	wp_cache_add( $term->term_id, $term, 'terms' );

	return get_term( $term, $taxonomy, $output, $filter );
}



add_filter('get_terms_args', 'wpmlsupp4378_translate_term_slug', 10, 2);
/**
 * Translate term slug for WPML
 * @param type $args
 * @param type $taxonomies
 * @return type
 */
function wpmlsupp4378_translate_term_slug($args, $taxonomies){
    if (!empty($args['slug']) && !is_array($args['slug']) && !empty($taxonomies[0])) {
        $term = get_term_by_deprecated('slug', $args['slug'], $taxonomies[0]);
        if (!empty($term->slug)) {
            $args['slug'] = $term->slug;
        }
    }
    return $args;
}

You can make a backup of the site or can try on a test site to see the results. If you are not willing not make these changes then please wait for some time and I will update you when there is any update about this issue!

Thanks

August 5, 2017 at 10:00 am #1335769

Paul

Hi Sumit

That fixes my issue perfectly.

Big Thanks!

Pls keep me posted if any further developments are to be taken on this or when its released. ( i did not close the issue yet because of that)

Best regards,
Paul

August 8, 2017 at 4:28 pm #1337730

Sumit
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Hi Paul,

Thanks for the feedback! I will keep you posted about the issue.

Thanks

August 26, 2017 at 9:59 am #1351549

thomask

Found this thread by accident when debugging a similar (technically the same) problem with get_cat_ID( 'Category' ) and tried get_category_by_slug( 'category' ) as replacement. Both return 0 or nothing in non-default languages since 4.8 update as well.

Adding this here, so others will find this thread when looking for problems with get_cat_ID() and get_category_by_slug().

Using hardcoded category-id from default language and wpml_object_id filter now as workaround, works fine.