Please make sure to update to WPML 4.3.5 and check our list of Known Issues before reporting

Hi, Amit here, I am the WPML Support Manager, our current ticket queue is high, update your WPML plugins and make sure you meet the minimal requirements for running WPML before reporting an issue please - many tickets are resolved doing that

Please look at our updated list of Known Issues and you can also use our support search to find helpful information and of course review our documentation before opening a ticket.

If you do need to open a ticket please make sure to provide us with all the needed information as described in this page

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.

Tagged: 

This topic contains 2 replies, has 3 voices.

Last updated by George Botsev 4 years, 1 month ago.

Assigned support staff: George Botsev.

Author Posts
October 25, 2015 at 12:18 am #732058

Richard

I believe a new bug has been introduced.

private function pre_option_page( $type ) {
		global $switched;

		$cache_key = 'wpml_pre_option_page';
		$results   = wp_cache_get( $cache_key );
		$results   = $results ? $results : array();

		if ( ( ! isset ( $results[ $type ] ) && ! $switched )
		     || ( $switched && $this->get_setting( 'setup_complete' ) )
		) {
			$results[ $type ] = array();
			// Fetch for all languages and cache them.
			$values = $this->wpdb->get_results(
				$this->wpdb->prepare(
					"	SELECT element_id, language_code
						FROM {$this->wpdb->prefix}icl_translations
						WHERE trid =
							(SELECT trid
							 FROM {$this->wpdb->prefix}icl_translations
							 WHERE element_type = 'post_page'
							 AND element_id = (SELECT option_value
											   FROM {$this->wpdb->options}
											   WHERE option_name=%s
											   LIMIT 1))
						",
					$type
				)
			);

			foreach ( $values as $lang_result ) {
				$results [ $type ] [ $lang_result->language_code ] = $lang_result->element_id;
			}
			
			wp_cache_set( $cache_key, $results );
		}

		return isset( $results[ $type ][ $this->this_lang ] ) ? $results[ $type ][ $this->this_lang ] : '';
	}

You can see above that this method only uses 1 key to cache the results of the query. The query though, takes in a $type parameter. This parameter is used in the query. I believe the cache key should be using the $type parameter as part of its key so that that correct result is looked up from the cache for the $type.

This means when 'page_on_front' is passed in first, the results for that $type are cached. When 'page_for_posts' is passed in as the $type, it gets back the 'page_on_front' results. I think this is incorrect.

Rich

October 26, 2015 at 9:16 pm #733080

Bruno
Supporter

Languages: English (English ) Portuguese (Brazil) (Português )

Timezone: America/Sao_Paulo (GMT-03:00)

Hello Richard,

Thank you for contacting us.

I will contact the 2nd tier support and soon we will contact you.

Thank you.

October 30, 2015 at 9:27 am #736156

George Botsev
Supporter

Languages: English (English )

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

Hello and thank you for reporting this issue.
A fix for this issue will be included in the final version of WPML 3.3 when released.

The topic ‘[Closed] Bug in caching code’ is closed to new replies.