Andis

I’m looking over changes in 0.8dev3 and decided to report one small error in JavaScript which I saw before but didn’t want to bother you;
in core.php on line 410

if (e[i] == '[object HTMLInputElement]') {

this statement would fail in older browsers. In particular IE<7 in which Element.toString() would always return '[object]'.

Instead you should use tagName property to check element type:

if (e[i].tagName.toUpperCase() == 'INPUT') {

the toUpperCase() part is just to make sure comparison succeeds.

I also noticed that you have made few changes to improve performance, like storing taxonomies and post types in polylang object.

I’m glad you found my snippet useful.

Pardon me, but there is another CPT related bug.
Polylang_Core::get_translation_url returns incorrect CPT archive URL if rewrite slug is different from post_type.
By default CPT archive slug is post type, but custom slug can be defined in register_post_type as rewrite['slug']='diferent-slug' or with has_archive option.

I did a mod in include/core.php around line 499:

if (is_post_type_archive())
	$url = esc_url($base.$qvars['post_type'].'/');

and replaced by:

if (is_post_type_archive()){
	$cpt_rewrite = get_post_type_object($qvars['post_type'])->rewrite;
	$cpt_slug = (isset($cpt_rewrite['slug']))? $cpt_rewrite['slug'] : $qvars['post_type'];
	$url = esc_url($base.$cpt_slug.'/');
}

I don’t think str_replace on returned content is right approach for this problem because it is locking on particular strings.
Maybe another filter for $name would be better and introducing an option for that in settings screen would be more user friendly.

Flags in dropdowns could be created with CSS backgrounds, but unfortunately Firefox is the only browser which allows complete styling of option elements. Quick test also revealed that img tags in option elements are ignored entirely by all browsers I have (Chrome 17, Firefox 10, IE 9, Safari 5.1.2). I’d say it’s not worth spending time on.

I have few more ideas for polylang, but it seems that you are trying to slow down on new features and concentrate on code quality for now.

One improvement would be an option to duplicate post content and maybe also title when creating a translation.
Although I could duplicate post content in my own code when I see your $_GET['from_post'] and $_GET['new_lang'].

Just checked and yes, Polylang_admin_filters::save_post returns as expected because $_POST['_inline_edit'] is there.

Polylang_Base::delete_translation is called always – even on quick edit.
added this in beginning of Polylang_admin_filters::delete_translation

error_log("calling ".__CLASS__.'::'.__FUNCTION__."($type, $id)", 0);

and after quick edit line popped up in log file:

calling Polylang_Base::delete_translation(post, 82)

*debugging, debugging, debugging*

using xdebug_get_function_stack revealed that Polylang_Admin_Filters::delete_post is called when deleting old revisions in following order: wp_insert_post -> wp_save_post_revision -> wp_delete_post_revision -> wp_delete_post -> Polylang_Admin_Filters::delete_post.
I skipped calls to do_action, but you get the point.

I usually set post revisions to low number and the older ones are deleted soon enough.
Currently I’ve set them to three in wp-config.php:

!defined('WP_POST_REVISIONS') && define('WP_POST_REVISIONS', 3);

afaik there is no other limit for number of revisions, but at some later point when revisions get deleted this bug could pop up and ruin day for many polylang users.

I’m looking at Polylang_Admin_Filters::delete_post and can’t understand why replace $post_id of revision with id of original post.
That is the point where it fails and deletes translation metadata of valid posts.

I can reproduce this behaviour every time by just clicking Quick Edit and then Update without any modifications in quick edit form. Bulk edit also breaks linking.

All other plugins are disabled, but even if they were not, none of them could interfere with saving of pages. I know because I wrote them.
The only point in which I’m hooking on save_post action is in my theme but there I check if post type is my CPT and if it’s not return immediately.
To prove this I just switched to twentyeleven theme and result is same.

I did direct SQL queries on wp_postmeta table that revealed missing or incomplete _translations values.
For instance – there are two pages linked as translations:
id: 67, language: lv;
id: 82, language: en;
(no tags, no other meta or anything)
before quick editing, query SELECT * FROM wp_postmeta WHERE meta_key='_translations' AND post_id IN(67,82)
gives:

271, 67, _translations, s:34:"a:2:{s:2:"en";i:82;s:2:"lv";i:67;}";
273, 82, _translations, s:34:"a:2:{s:2:"en";i:82;s:2:"lv";i:67;}";

now they are linked and all is right, but after quick editing page with post_id 67:

273, 82, _translations, s:20:"a:1:{s:2:"en";i:82;}";

It seems that Polylang_Base::delete_translation() is the only method where delete_metadata is called for _translations meta key.

Regarding quick edit support – it’s easy, but involves some JavaScript trickery which is exactly the way it’s done in original quick edit.
It is well explained on codex action reference page quick_edit_custom_box.
You could put your language codes as hidden elements in custom columns and then set up form elements in quick edit accordingly.

From PHP coders standpoint it may seem rather awkward to populate form fields from table cell text, but it works and reduces data amount from server.

Thanks for quick response. This solves the glitch.

As for the notices – those happen only when saving posts with tags and with WP_DEBUG set to true.

On development sites I usually define the debug switch based on session variable in wp-config.php which can be turned on and off with simple $_GET variable.

here’s the snippet from my wp-config.php:

/**
 Define sessions name just in case
 and start session
 */
session_name('WP_SESSION');
if(session_id()==''){
	session_start();
}
if(isset($_GET['debug']) && $_GET['debug']!='off'){
		$_SESSION['WP_DEBUG'] = true;
}elseif(isset($_GET['debug']) && $_GET['debug']=='off'){
		unset($_SESSION['WP_DEBUG']);
}

/** Conditional debugging */
if(!defined('WP_DEBUG')){
	define('WP_DEBUG', isset($_SESSION['WP_DEBUG']) );
	// save debug.log in wp-content/
	define('WP_DEBUG_LOG', WP_DEBUG);
}
/** Show errors only if in debug mode */
if(WP_DEBUG){
	ini_set('display_errors','On');
}else{
	ini_set('display_errors','Off');
}

I’m monitoring wp-content/debug.log for new messages because some messages can be obscured if they happen in admin header for instance.

Hope this will come in handy for you or others who read this thread.