Richard Vencu

Hi again,

I found the code and I fixed it, here is my result:

add_action( 'after_setup_theme', 'relevanssi_custom_setup' );

function relevanssi_custom_setup(){
    if (defined('ICL_LANGUAGE_CODE'))
	add_filter('relevanssi_hits_filter', 'relevanssi_wpml_filter');
}

// thanks to rvencu
function relevanssi_wpml_filter($data) {
	if (function_exists(icl_object_id)) {
		$filtered_hits = array();
    	foreach ($data[0] as $hit) {
        	if ($hit->ID == icl_object_id($hit->ID, $hit->post_type,false,ICL_LANGUAGE_CODE))
                $filtered_hits[] = $hit;
	    }
	    return array($filtered_hits,$data[1]);
	}
	else {
		return $data;
	}
}

Note that you missed a $hits[1] instead of $data[1].
Also at the time your plugin loads the filter does not get applied. If waiting until after the theme setup is helping the process. At least in my installation it works like this.

Hi, I upgraded to v2.7 but for some reason if I disable my integration code the module behaves just like 2.6 with no integration. Please explain a bit how did you do it maybe I can debug the issue.

also please tell somebody that emails from https://getshopped.org does not reach all audience – I still cannot receive my account password to access the forum you mentioned above

Update: I made another account with my gmail address. I got the password for that one.

If you want to really make the plugin multilingual (to be used in conjunction with plugins such as WPML) then the checkout form is a tricky thing to do.

While if using only the default fields you can do the trick by doing the translation in the .mo file then use this technique such as for line 586 in wpsc-user_log_functions.php where the old code
echo " <tr><td colspan='2'>" . $form_field['name'] . ":</td></tr>";
should be changed to
echo " <tr><td colspan='2'>" . __($form_field['name'],'wpsc') . ":</td></tr>";
I do not know what you can do for custom made fields. Basically they will be only available in one language at the time so the store cannot be multilingual unless the user knows php coding and add lines by himself somewhere into a plugin files to they get scanned and translated too with plugins such as Codestyling Localization.

BTW, your 3.8 version is breaking this plugin due to some javascript error. Please check this issue as well.

and another 2

wpsc-admin/includes/settings-pages/import.php:149
wpsc-theme/functions/wpsc-transaction_results_functions.php:256

Perhaps I missed some but there is plenty to fix there

and those (repeating line means more occurences)

[List moderated as per the Forum Rules. Please use the pastebin]

1. wpsc-core/js/tinymce3/window.php:123 has wpsc-category
2. those lines have default textdomain on them:

[List moderated as per the Forum Rules. Please use the pastebin]

well, yes there is one. nice thinking. thanks

And as a matter of fact I even bought the Gold Card today and I received nothing on my inbox. If this doesn’t get fixed I think I will file a fraud complain with my bank…

Good idea, but to ask there I need my password to login and I never got it!

line 41 of transaction_results.php is incomplete
_e('Sorry your transaction was not accepted.<br /><a href='.get_option("shopping_cart_url").'>'. __('Click here to go back to checkout page.','wpsc') . '</a>');

it should be like this
echo __('Sorry your transaction was not accepted.','wpsc').'<br /><a href='.get_option("shopping_cart_url").'>'. __('Click here to go back to checkout page.','wpsc') . '</a>';

change it then rescan you plugin and edit the translation

This plugin has good functionality unfortunately it is far from perfect or at least good in internationalization. I found many many untranslated strings, then translations against the default textdomain let alone other textdomains from copied and pasted code. This situation makes it very hard for non-english user, the fixing effort is huge and it locks the user from the upgrade to new versions unless another equally effort is expected to fix the problems again.

The bad thing is that people even buy premium upgrades based on this lousy written code… something less expected from a plugin that has some commercial aspect in it

After some good sleep I realized that the function can be wrote much shorter and that WPML guys are going to preserve the icl_object_id function even if they decide at some point to change the database structure.

function relevanssi_wpml_filter_hits($hits) {

    $filtered_hits = array();
    foreach ($hits[0] as $hit) {
        if ($hit->ID == icl_object_id($hit->ID, $hit->post_type,false,ICL_LANGUAGE_CODE))
                $filtered_hits[] = $hit;
    }
    return array($filtered_hits,$hits[1]);
}

Yes, I suppose the DB stuff will work faster… and the code would not depend on the names of the custom post types defined.

My simple solution to return hits only in the current language:

add_filter ('relevanssi_hits_filter','relevanssi_wpml_filter_hits');

function relevanssi_wpml_filter_hits($hits) {

    $filtered_hits = array();
    foreach ($hits[0] as $hit) {
        if ($hit->ID == icl_object_id($hit->ID, 'post',false,ICL_LANGUAGE_CODE))
                $filtered_hits[] = $hit;
        if ($hit->ID == icl_object_id($hit->ID, 'page',false,ICL_LANGUAGE_CODE))
                $filtered_hits[] = $hit;
        if ($hit->ID == icl_object_id($hit->ID, 'customposttype1',false,ICL_LANGUAGE_CODE))
                $filtered_hits[] = $hit;
        if ($hit->ID == icl_object_id($hit->ID, 'customposttype2',false,ICL_LANGUAGE_CODE))
                $filtered_hits[] = $hit;
        if ($hit->ID == icl_object_id($hit->ID, 'customposttype3',false,ICL_LANGUAGE_CODE))
                $filtered_hits[] = $hit;
    }
    $filtered = array($filtered_hits,$hits[1]);
    return $filtered;
}

I noticed that filtering the search this way, the fatal error issue described above has dissapeared.

If more info can be useful to spot the issue, I also noticed that the fatal error happens for unfiltered results in all languages, in any desktop theme. But it works fine with the mobile themes under WPTouch Pro ??

Nice. Filtering on the current language might eliminate this problem too since I noticed all searches with hits in only one language are performed correctly, while those with hits in more languages might just break.

So if you want to add as an option seaching in multiple languages this issue should be addressed.