SimonGiddings

Thank you, the problem was the merchant ID.

Now that I have replaced it with the right value, all is working.

One last question though – does this mean that a paypal account can either be in sandbox mode or normal mode and not both at the same time ?

Wow, the quantity of help proposed here is overwhelming !
(Ok, that was a bit sarcastic, born from frustration)

Here is the solution to this problem, should anyone come across this.

During a major version change, Customizr objects which had been prefixed with TC_ were changed to be prefixed to CZR_.

Making this adjustment corrected the problem.

Of course not! That’s considered spam.

It should not be if the person has requested it, surely.

That looks good !
However, I would like to be get the user to simply check a checkbox when creating their account in the woocommerce site.
Once their account details validated (clicking a link in an email), I would need to “call” mailpoet in the blog site once the woocommerce has validated the account.

Is this possible ?

After having done some tests on my dev server (WC version 2.6.0), I can confirm that this does NOT work.

To be clear, I enter the registered email address of the user in question ?
I know this sounds dumb, but I want to be sure before making an error.

Great, this has worked … at least on my test systems.
Will keep an eye on things and come back to you if necessary.

For anyone else having this problem, I changed to “force download only” within the settings.
I then tested it with the android browser “Dolphin”, the one which complains the most.

Hope this will help others also.

Will give this a go …

Hi Mike,

I am getting them via a WP_Query call, using the following args :
‘post_type’ => ‘shop_order’,
‘posts_per_page’ => -1,
‘post_status’ => ‘completed’,
‘date_query’ => array( … date specifics here … ),
‘order’ => ‘ASC’,
‘orderby’ => ‘date’

Should I be expanding the post_type to include ‘shop_order_refund’ ?
If so, how do I link it to the original order ?

As is quite often the case when we develop, we are absolutely certain that “new” problems cannot be in our code !
Yep, you guessed it, I found the source of the problem.

I had to filter translations to eliminate the # sign before order numbers.
Could not see how to do this other wise.
So I hooked into “gettext_with_context”.
This takes the following parameters :
$translations, $text, $context, $domain

where $translations is the translated text.
My bug ? I returned $text (the original untranslated text).

My error, sorry to have wasted your time.
Perhaps this aspect of putting something before the order number could be a configurable parameter ?

The strings I am testing are indeed confirmed and have been for quite a while now – they are even in the .po file.

Followed your instructions –

1. Downloaded .mo stable file
2. renamed to woocommerce-fr_FR.mo
3. Copied into wp-content/languages\plugins
4. Tested = no change
5. Saw that instructions said to put it into wp-content/languages/woocommerce
6. Created this directory and copied .mo into it
7. Tested = no change
8. Stopped and restarted Apache
9. Tested = no change !

Can’t see what to do now !

Ok, granted.
However, these are strings which have existed for a long time.
I wanted to see where they are referenced in code, without success.

I then went to the translation project and downloaded the latest stable version. This gave me “wp-plugins-woocommerce-stable-fr.po”

When I looked in the languages/plugins directory, I found
“woocommerce-admin-fr_FR.po”
“woocommerce-fr_FR.po”
with the corresponding .mo files.

When I looked at the contents of woocommerce-admin-fr_FR, I found the missing definition :
#: includes/admin/class-wc-admin-permalink-settings.php:68
msgctxt “slug”
msgid “product-category”
msgstr “categorie-produit”

I then searched in wp-plugins-woocommerce-stable-fr where I found
#: includes/admin/class-wc-admin-permalink-settings.php:68
#: includes/class-wc-post-types.php:86
#: includes/updates/woocommerce-update-2.0.php:46
msgctxt “slug”
msgid “product-category”
msgstr “categorie-produit”

So, it would appear that the language files are not the source of the problem.
Next, I took a look at the referenced line in class-wc-admin-permalink-settings.php where I found
<input name=”woocommerce_product_category_slug” type=”text” class=”regular-text code” value=”<?php if ( isset( $permalinks[‘category_base’] ) ) echo esc_attr( $permalinks[‘category_base’] ); ?>” placeholder=”<?php echo esc_attr_x(‘product-category’, ‘slug’, ‘woocommerce’) ?>” />

So, where the string to translate is correctly specified, along with the context, wordpress does not find it in the translation file.

Something has definitely been changed in code.
What can you suggest ?

Why ?
It worked fine in the version prior to v2.5.2 !

Hi Caleb,

This seems obvious, however, simply with the French translation file for woocommerce the default was “categorie-produit”.

This is why I feel that there is a problem with the translation files.

In addition, there are other strings which are now nolonger translated, for example in the WooCommerce menu within the admin panel “Orders” instead of “Commandes”.