Month: June 2015

Be aware about some plugins when creating multilingual WordPress website…

Around 6 years ago, when xili-language was started, to resume only two plugins (WPML, qTranlate) were available with very different data architectures. Neither of them respected the architecture of WordPress core since the first added many tables and the second changed the content of posts by compacting the different languages in each field. It is true that taxonomies had appeared with WP 2.3. Today, the offer is bloated as the ongoing attempts to show the comparison .
Two extensions have recently emerged and their architecture, once installed will compromise more or less seriously the database. “Multi language” adds tables to put the translations of posts thus without extension, can not be recovered.
WPGlobus “Multilingual everything” as it modifies like qTranslate (and its successors qTranslateX) content as shown in the database tables below:

Post #1 n'is not yet multilingual
Post #1 n'is not yet multilingual

and when it makes multilingual (via tabs), we note the significant change of the field of post table … here each field containing the three languages in {}! How then will be queries ? At least not according to the rules WP_Query 🙁

WP Globus modifies irreversibly the content of fields
WP Globus modifies irreversibly the content of fields

“Babble” does not use taxonomies but the custom post type to store posts according to language. Not easy for queries … to follow because by yet officially in filing plugins (repository).

Working with a content management system (CMS) such as WordPress requires some principles, the first is to preserve data integrity before and after adding “tag” that specifies the language (taxonomy) or links to articles in other languages (custom field). This is the basic principle of Xili-language trilogy established since its creation and enduring the version of WP 2.3 to 4.3, which will be out soon.

Michel

Multisite and custom taxonomy… quid ?

In multisite context and WordPress version 4.2.2, with this function in blog_id #3:

switch_to_blog( 2 );

have we really switched in blog_id #2 to fire a query (new WP_Query ( $query ) ;) including a custom taxonomy here (‘domain’) ?

// extract of the query
'tax_query'   => array(
'relation' => 'AND',
	array(
	'field'    => 'term_id',
		'taxonomy' => 'category',
		'terms'    => array ('publication', 'evenement'),
		'operator' => 'IN'
	),
array(
	'field'    => 'slug',
	'taxonomy' => 'domain',
	'terms'    =>  array( 'aerien', 'sous-marin'),
	'operator' => 'IN'
	)
)

In fact NO, because interpreting $query needs the taxonomy to be declared in blog_id #3 where this code is.
A workaround ?
The plugin registering this new taxonomy must not be ‘network activated’ but one by one in #2 and #3 and in properties of this taxonomy, define where the taxonomy must be visible (here #2)
'show_ui' => ($current_blog->blog_id == 2 ) ? true :false,

With this workaround, the deficiency of switch_to_blog( 2 ); is “fixed” and it now possible to display with a custom function (including complex query) in theme of website #3 a list of posts coming from #2.