ReactorShop

Just to clarify, the redirect query strings need to be added when either the Purchase History, the Edit Profile or the Downloads “tab” is selected inside “Your Account” page.

Your Account tab selection.

I get to see those tabs until I remove the IF conditional to let the filter always set the taxonomies language. With the IF clause, I always see the wpsc-products posts (when viewing a CPT page) instead, as indicated in my previous post image.

Hi Chouby,

I still have the wpsc-products posts from the current language showing every time I click a CPT page, instead of its regular content.

Please look at the top link in this image.

“Your account” information should be shown here (same as it was shown in spanish in my previously posted image), instead of those 2 wpsc-products posts.

EDIT: I just took a second look at the image, and saw that the permalink’s redirect query string is missing when I apply your modification which includes the IF condition.

This is what I had to do to fix URLs in order to avoid losing the redirect query strings that WP e-Commerce uses:

function p4we_translated_product_url($url = '', $lang_slug = '') {
	global $wp_rewrite, $wp_query;

	if ('' != $url && '' != $lang_slug && strpos($url, 'sitemap') === false && (in_array ( $wp_query->post->post_type, array (
			'page',
			'wpsc-product'
	) ))) {
		$translated_page = get_post ( pll_get_post ( $wp_query->post->ID, $lang_slug ) );
		$draft_or_pending = in_array ( $translated_page->post_status, array (
				'draft',
				'pending',
				'auto-draft'
		) );
		if ($translated_page->post_type == 'page') {
			$url = $wp_rewrite->get_page_permastruct ();
			if (! empty ( $url ) && ((isset ( $translated_page->post_status ) && ! $draft_or_pending) || $sample)) {
				if (! $leavename)
					$url = str_replace ( '%pagename%', get_page_uri ( $translated_page ), $url );
					// FIXME Only covers ReactorShop's specific Polylang/WP e-Commerce configuration.
				$url = home_url ( $lang_slug . '/' . $url );
				$url = user_trailingslashit ( $url, 'page' );
				if (isset ( $_SERVER ['REDIRECT_QUERY_STRING'] ))
					$url .= '?' . $_SERVER ['REDIRECT_QUERY_STRING'];
			} else
				$url = home_url ( '?page_id=' . $translated_page->ID );
		} else {
			$request_uri = $_SERVER ['REQUEST_URI'];
			if (substr ( $request_uri, 0, 1 ) == '/')
				$request_uri = substr ( $request_uri, 1, strlen ( $request_uri ) - 1 );
			$request_uri = untrailingslashit ( $request_uri );
			$request_parts = explode ( '/', $request_uri );
			// FIXME Only covers ReactorShop's specific Polylang/WP e-Commerce configuration.
			$translated_url [0] = $lang_slug;
			$translated_url [1] = p4we_translated_name_from_name ( $request_parts [1], $lang_slug );
			if (isset ( $request_parts [2] )) {
				$term = get_term_by ( 'slug', $request_parts [2], 'wpsc_product_category' );
				$term = get_term_by ( 'id', pll_get_term ( $term->term_id, $lang_slug ), 'wpsc_product_category' );
				$translated_url [2] = $term->slug;
			}
			if (! (strpos ( $_SERVER ['REQUEST_URI'], p4we_translated_name_from_name ( $translated_page->post_name, $request_parts [0] ) ) === false))
				$translated_url [3] = p4we_translated_name_from_name ( $translated_page->post_name, $lang_slug );
			$url = implode ( '/', $translated_url );
			$url = home_url ( '/' . $url );
			$url = user_trailingslashit ( $url, 'single' );
			if (isset ( $_SERVER ['REDIRECT_QUERY_STRING'] ))
				$url .= '?' . $_SERVER ['REDIRECT_QUERY_STRING'];
		}
	}
	return $url;
}
add_filter ( 'pll_translation_url', 'p4we_translated_product_url', 10, 2 );

I don’t know if this could be causing any conflicts (after applying your mod I no longer see the server redirect_query string at the end of the permalink).

HI Chouby,

The $polylang object it’s only instantiated at the Front End, so I had to add an “is_admin” check.

function p4we_wpsc_parse_query($query) {
	if(!is_admin()) {
		global $polylang;
		$polylang->choose_lang->set_lang_query_var($query, $polylang->curlang);
	}
}
add_action('parse_query', 'p4we_wpsc_parse_query');

I’m still getting the menu entries shown in all languages just like before, but this eliminates an error I had when entering the admin side.

Hi, Chouby.

The WP e-Commerce developer community is evaluating replacing the short code approach to detect their CPT pages, in favor of using the CPT pages’ page_name slugs. That would require to fix the WPML interfacing plugin too.

The change of behavior I described is really difficult to track for me, because I would reach the end of the parse_query filter with all the wpsc-product CPT posts in all languages selected, without knowing what didn’t happened which would select the current language posts to be shown on this CPT page only. That’s why I had to ask.

I’ll add this to my Polylang/WP e-Commerce plugin to test later on. I’m currently hooked to the wpsc_get_the_post_id_by_shortcode filter hook, switching the CPT pages post ID using pll_get_post to send the translated post ID, so I think that I have to enter it like this:

<?php
/*
Plugin name: Polylang WP E-Commerce Compatibility
*/

if (function_exists('pll_get_post')) // test a Polylang function to avoid ugly fatal error at Polylang upgrade
	add_action('parse_query', 'pll_wpsc_parse_query');

function pll_wpsc_parse_query($query) {
	if (is_page( wpsc_get_the_post_id_by_shortcode( '[productspage]' ) )) {
		global $polylang;
		$polylang->choose_lang->set_lang_query_var($query, $polylang->curlang);
	}
}

Thank you, Chouby.

Hi Chouby. I just updated to PL 1.3 and the issue I have might be related to this.

I already had this issue before, during 1.2 Beta testing

Please check the images from the first post in this topic:

https://www.ads-software.com/support/topic/polylang-12-beta-is-ready-for-tests/page/3?replies=82

I remember your correction was fast.

Thank you in advance!

Well, I only have the WordPress SEO, Site Title and Blog Description strings showing at the Strings Translation table, so the copy/paste job is fast and easy.

I’ll mark this as solved, but if someone else reads this post, tries the paste bin and has something to comment, please feel free to do so.

Thank you, Chouby.

Yep, that solved it!

Thank you, Chouby!

1.2dev58 is ok.

Never mind.

I just hooked my filter to ‘option_rewrite_rules’ and it’s doing exactly what I was looking for.

Have a nice weekend!

Hi Chouby!

So I reached a point in which I have to either add (preferred) or modify the rewrite rules in order for the translated permalinks to be matched by them.

I added this filter in my plugin:

// create rewrite rules with a filter 'something_rewrite_rules'
add_filter('generate_rewrite_rules', 'p4we_translated_rules');
function p4we_translated_rules($wp_rewrite) {

        .
        .
        .

        $rules = $myrules;               // Processing removed for simplicity.
	$rules = apply_filters('p4we_translated_rewrite_rules', $rules);
	$wp_rewrite->rules = array_merge(rules, $wp_rewrite->rules);
}
//add the filter (without '_rewrite_rules') to the Polylang list
add_filter('pll_rewrite_rules',
			create_function('$rules','return array_merge($rules, array(\'p4we_translated\'));'));

And I see that it’s being added as the last item of PLL_Links_Directory->rewrite_rules as ‘p4we_translated’ when PLL’s prepare_rewrite_rules filter applies the ‘pll_rewrite_rules’ filter.

The thing is that my filter, even though registered by PLL, is never applied. I’ve looked for filters being applied by ‘generate_rewrite_rules’ during my debugging tests, and none of them are being applied either.

The problem here is that the rules need to be updated (either appended or modified in $wp_rewrite, no flushing needed) every time the language is changed, so that the translated permalinks may match the newly selected language AND the rewrite rules.

I already did this about 2 weeks ago, but I did it modifying the WordPress source code directly, which I found it wasn’t the recommended approach (I now know that’s what filters are for).

I’ve looked for information on generate_rewrite_rules and I only found that it triggers after all rewrite rules have been created, but I don’t get when/why/how this happens.

Can you recommend an approach to tackle this issue?

Thank you in advance, Chouby!

EDIT: I need to finish this in order to move on to testing PLL 1.2dev58. I’m still at PLL 1.2dev57.

EDIT 2: To exemplify my situation:

This is one default language rewrite rule:

products-page/([^/]+)/?$

For Spanish, I need to add another rule or modify it to say:

pagina-de-productos/([^/]+)/?$

(3) # wpsc-core/wpsc-functions.php

'add_new_item' => __( 'Add New Variation' , 'wpsc' ),

The translation for “Add New Variation/Set” exists, so it’s not found.

I’m ok with the move. I understand, Chouby.

Regarding my previous comments, the situation it’s cookie related, so it goes here.

What happened is that I was always being forced into Spanish, as if it were my one and only “preferred language”. Every time I switched to English, the cookie information was not rewritten.

What I did is to delete 3 Polylang cookies I had.
1 set on October 9 (had host instead of domain information)
1 set on October 20 (had host instead of domain information)
1 set on October 30 (this one was ok)

After doing this, the language information I received was synchronized as expected.

Regarding the cookies, I was talking about creating an additional cookie to monitor the language widget selection, but since I already found the solution to my situation, that’ll be no longer necessary.

Thank you, Chouby!

If no other alternative is found, I could recommend to store the language change request in a cookie.

If there’s no cookie or the information is not found in this cookie, you could fallback to checking the URL for this information instead.

I found where the current language is first set back to spanish near the beginning of “the 2nd execution loop”, as I described those loops:

…polylang/frontend/choose-lang-url.php

public function set_language_from_url() {
		// home is resquested
		// some PHP setups turn requests for / into /index.php in REQUEST_URI
		// thanks to Gon??alo Peres for pointing out the issue with queries unknown to WP
		// https://www.ads-software.com/support/topic/plugin-polylang-language-homepage-redirection-problem-and-solution-but-incomplete?replies=4#post-2729566
		if (str_replace('www.', '', home_url('/')) == trailingslashit((is_ssl() ? 'https://' : 'https://').str_replace('www.', '', $_SERVER['HTTP_HOST']).str_replace(array($this->index, '?'.$_SERVER['QUERY_STRING']), array('', ''), $_SERVER['REQUEST_URI']))) {
			// take care to post & page preview https://www.ads-software.com/support/topic/static-frontpage-url-parameter-url-language-information
			if (isset($_GET['preview']) && ( (isset($_GET['p']) && $id = $_GET['p']) || (isset($_GET['page_id']) && $id = $_GET['page_id']) ))
				$curlang = ($lg = $this->model->get_post_language($id)) ? $lg : $this->model->get_language($this->options['default_lang']);

			// take care to (unattached) attachments
			elseif (isset($_GET['attachment_id']) && $id = $_GET['attachment_id'])
				$curlang = ($lg = $this->model->get_post_language($id)) ? $lg : $this->get_preferred_language();

			else {
				$this->home_language();
				add_action('setup_theme', array(&$this, 'home_requested'));
			}
		}

		elseif ($slug = $this->links_model->get_language_from_url())
			$curlang = $this->model->get_language($slug);

		elseif ($this->options['hide_default'])
			$curlang = $this->model->get_language($this->options['default_lang']);

		add_action('wp', array(&$this, 'check_language_code_in_url')); // before WordPress redirect_canonical

		// if no language found, check_language_code_in_url will attempt to find one and redirect to the correct url
		// otherwise 404 will be fired in the preferred language
		$this->set_language(empty($curlang) ? $this->get_preferred_language() : $curlang);
	}

These are the values I have when reaching the if statement:

$_SERVER['QUERY_STRING']) == 'wpsc_user_dynamic_js=true&ver=3.8.12.1.55f8cfa0d7';
$_SERVER['REQUEST_URI']) == '/es/?wpsc_user_dynamic_js=true&ver=3.8.12.1.55f8cfa0d7';

That request belongs to WP e-Commerce.

Before reaching the last function line, pll_current_language() evaluates as false.

After evaluating the last function line, pll_current_language() evaluates as ‘es’, instead of ‘en’. I can see that the server ‘REQUEST_URI’ is the one causing this function to select Spanish as the current language.

Is there something that could be done to fix this situation?

Thank you for your support, Chouby.

EDIT: I found that WP e-Commerce adds it using an action:

if ( isset( $_GET['wpsc_user_dynamic_js'] ) && ($_GET['wpsc_user_dynamic_js'] == 'true') )
	add_action( "init", 'wpsc_user_dynamic_js' );

and that they enqueue this script:

wp_enqueue_script( 'wp-e-commerce-dynamic', home_url( '/index.php?wpsc_user_dynamic_js=true', $scheme ), false, $version_identifier );

during their own theme loading process (their own theme overrides certain functionality found in the WordPress theme).

I’m debugging WordPress using Eclipse.

As I see it, a WordPress execution loop starts when processing the first line of WordPress’ index.php file, continues while traversing through all the WordPress and plugins php files and ends right before reaching this index.php file again.

What I see is that each loop loads and setups certain WordPress requirements in an incremental manner.

I selected “The language is set from the directory name in pretty permalinks. Example: https://www.reactorshop.loc/en/my-post/”

Regarding Ajax, I’m not doing any Ajax on my own. I’m talking about the WordPress cron job which loads and executes the …wp-admin/admin-ajax.php file. This causes WP e-commerce to execute a specific function my filter is hooked to.

I’m not sure if this answers your questions.

EDIT: I’m not redirecting with my filter. As I said, I only check pll_current_language() against pll_default_language() and use pll_get_post() to grab translated posts IDs and then get_post() to get the post names and then I return a set of translated pages slugs.