Call for support: WooCommerce users needed

[herrvigg]

hello,
i know many people are using qTranslate-X with WooCommerce and worrying about the support with qTranslate-XT. I'm not using WC but i looked at the add-on plugin and i don't see anything preventing it to work with qTranslate-XT. This add-on plugin is available at wordpress.org or here: https://github.com/qTranslate-Team/woocommerce-qtranslate-x

I'm considering the possibility to integrate completely this add-on plugin in qTranslate-XT but before i need to have a better understanding of the current status.

Please could some WooCommerce users do the following?

• install qTranslate-XT (see instructions in the README)
• disable qTranslate-X
• enable qTranslate-XT
• test WooCommerce, validate as much as you can and report issues here.

As written in the FAQ, qT-X and qT-XT can still live together. They share both the same options but you should only have one active at a time to avoid conflicts.

For the long-term support I think there is a clear need to specificy a real API but let's take one step at a time.

[spleen1981]

Hi there,
here's my feedback:
woocommerce-qtranslate-x plugin seems to be working with qTranslate-XT as it was with qTranslate-X.
Bugs I found (still there with qTranslate-X):

FRONTEND:

• "Products widget": Product names not being translated (entire string with square brackets is shown). Workaround: wrapping "$product->get_name()" inside __() function in woocommerce "content-widget-product.php" template, row 29, via child-theme override, will do the job.
• "Cart widget": seems to be stored in sessionStorage, so a change of language won't be applied to this widget content, which will be still shown in the previous language. Modifying the cart content fixes the content language to current.

BACKEND:

• Products list: "Categories" column not translated (entire string with square brackets is shown); "Languages" column: styles to be fixed.

May also be worth mentioning that "shop_coupon" post type should not be translatable, otherwise coupon codes will not work (even if qtranslate setting to disable translation of this type is available, it can take some time to figure out that's the reason why coupons are not working...)

Other stuff (limitated to my use of woocommerce) seems to be working fine.

My configuration:

• Wordpress 4.9.8
• Woocommerce 3.4.5
• qTranslate-XT 3.5.1
• WooCommerce & qTranslate-X 1.3
• qTranslate slug 1.1.18 (definitely another plugin to reanimate!!)

Thanks,

[LC43]

Hi, i'm one of the contributors of qtranslate-slug.

I have a pending release ( 2 years! ). If you enjoyed it, could you help me testing this branch?

https://github.com/not-only-code/qtranslate-slug/tree/pcarvalho/fix/130-unique-slug

much appreciated.

[spleen1981]

@LC43 Hi,
my feedback for 130-unique-slug release:
Here follows what happens following the different kind of links.

• Categories and posts translated+translated slug: 404 (both primary and secondary language)
• Categories and posts translated+unique slug: 404 (both primary and secondary language)
• Categories and posts not translated: 404
• Pages translated+translated slug: OK primary language, 404 for secondary language
• Pages translated+unique slug: OK (both primary and secondary language)

Tried to update permalink structure and applied the "Rebuild all slugs" tool (link to settings in this page to be fixed), with same results as above.

[herrvigg]

Many thanks for feedbacks!
Yes translate slugs is one of the main feature it would be great to have in qTranslate. There are 3 main mini-projects: slugs, woocommerce and gutenberg.

About the slugs, there is currently a "dev/slugs" folder that i inherited from qTranslate-X but i have no clue about its status or if it has something to do with the project from @LC43. We have to find a way to test it properly and in a convenient way. I don't know yet if it's best to do it in a separate branch or to make it optional in the master branch here. I have to check a bit more in details.

About woocommerce it should be the easiest to fix. I'll probably have to install a small environement to test it. I think i saw something about a trick with some cookie but yes it has certainly to be adjusted for SessionStorage.

For Gutenberg it's another project and i would at least manage to get an idea of how feasible it is, so it's my current priority right now.

But it's great you start using this plugin so we can make it live again after 2 years of complete freeze! All feedbacks are always useful.

[herrvigg]

hello folks,

i have now integrated the legacy add-on plugin "WooCommerce and qTranslate-X"!
As this requires more tests it's in a separate branch at the moment called woo-commerce. You should simply git checkout woo-commerce from this git repo. Ask me if any doubt. If it goes well we can then merge it to master soon.

Integration

I have mostly done some cleaning but no deep change on the code. The integration is minimal at the moment, i only check if woo-commerce is activated before loading all this extra stuff. It will only work for very standard installations (as previously).

I also check that the legacy add-on plugin (QWC) is not activated because i still use the same function names so QWC cannot be used at the same time. The best solution would be to use namespaces but this require some work as we start from scratch (this good practice seems to be ignored by many wordpress developers who use nasty global functions everywhere...).

Anyway for now i have simply adapted the admin notices to be consistent. There will only be a nasty message if you ever try to activate the legacy add-on plugin later on, on top of qTranslate-XT, but you shouldn't do that anyway ;)

Fixes

Nevertheless this branch should be already very interesting for WooCommerce users as it brings some fixes that were only available on github (1.4) and never released to wordpress.org (1.3)! Among those, the translation of Category mentioned here by @spleen1981 should now be fixed. I tried on a simple installation and it looks fine.

There is also something about the product variations also mentioned by @wywarren in #612 but i'm not sure it solves all you need as i didn't have time for more tests. Let's check that better now!

Changelog 1.4 (legacy!)

• Improvement: Mini-Cart cached in browser now changes the display language, when user changes the active language. Other browser's tabs will now also show mini-cart in new language regardless to what language they were originally displayed. Woocommerce shares single mini-cart object between all the tabs of browser in the same session. That is why mini-cart will be shown the same on all tabs in the last language chosen by user.
• Improvement: Filters are disabled if DOING_CRON is defined. This enables Woocommerce API to send information in raw ML format.
• Improvement: PayPal site to depend on active language locale if no billing country field is available.
• Improvement: ML fields on e-mail admin pages are now configured with "jquery" single entry.
• Improvement: Field "Purchase Note" on "Advanced" tab of Product editting page is now multilingual.
• Improvement: Translation of column "Category" in product list on page '/wp-admin/edit.php?post_type=product'.
• Fix: Variable product variations at front-end Issue Cannot translate the values of "Custom Product Attributes" of "Variable Product" in Woocommerce #277.

Enjoy and please let me know how it goes.
And finally we should be able to improve this more easily from now :)

[herrvigg]

I've added a new feature to automatically disable the legacy add-on plugin for easier integration. This approach could be generalized for other add-ons, it should be easier to handle them inside the main project, as optional modules (with very minimal overhead as those were already binded to another main plugin such as WooCommerce).

If people using WooCommerce could try qTranslate-XT on this branch i can merge it and send a new release. It should bring some fixes for some of the issues already being reported.

[floopyzicer]

Back in the day John wanted q-translate-x to use it's own slugs @herrvigg but apparently he abandoned the project and @LC43 plugin worked with some setups here and there tricks on yoast seo and what not , Also back in the day @LC43 tried to work with John but they did not find a common language.
And this is why there is a folder slugs in q-translate-x cause john wanted to make q-translate x to work with it's own slug option.

[herrvigg]

Yes i'm aware there is this slugs folder that i kept from the legacy repo. But we should try to merge the slugs plugin project especially if the original authors are available for discussions and experiments. At the moment i have many other things going on with WooCommerce, GravityForms, Gutenberg, and more generally a big refactoring that becomes necessary for the future. And i can only spend little of my free time on this project.
But let's talk about the slugs in a different topic, i'd prefer this one to focus on WooCommerce only so we don't mix everything.

[spleen1981]

I tried the qTranslate-XT woocommerce branch, and got a "Call to undefined function is_plugin_active() in qtranslate.php on line 72" error.
Maybe is_plugin_active is called too early; in this case that part may be wrapped in a function to be hooked to an action fired when is_plugin_active is available.

By the way, commenting out that part, everything seems to work fine, and bugs mentioned in my post above seem to be fixed.

As a minor bug, language column in admin product list is out of the table. Maybe a small css rule overide could be implemented to reduce the width for one of the woocommerce default columns to let the language column in the table (es table.wp-list-table .column-sku {width: 5% !important;} )

Wordpress 4.9.8
Woocommerce 3.5.1
qTranslate-XT 3.5.1 woocommerce branch
qTranslate slug 1.1.18

[herrvigg]

Thanks for testing and great it could solve some issues, that's good.

About is_plugin_active i'm surprised because this function should be available before any plugin file is loaded. It is defined in plugin.php which is loaded in wp-settings.php. Here is the sequence:

// standard htdocs/wp-settings.php

define( 'WPINC', 'wp-includes' );

// Include files required for initialization.
require( ABSPATH . WPINC . '/load.php' );
require( ABSPATH . WPINC . '/default-constants.php' );
require_once( ABSPATH . WPINC . '/plugin.php' ); <-- this should load "is_plugin_active"

... // lots of WP core stuff loaded 

// Load active plugins.
foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
	wp_register_plugin_realpath( $plugin );
	include_once( $plugin ); // <--- the main plugin files are loaded here
}

... 

do_action( 'plugins_loaded' );

... // instanciate WP globals such as wp_query, wp ...

do_action( 'init' );

Do you have a standard WP installation? Otherwise it's some other plugins messing this function up. But it should not be altered by anyone since it is a core WP function. It could be possible to delay the handling of the qtranslate-XT modules on plugins_loaded but before that can you check your WP installation again?

[herrvigg]

What you could do for debugging is to check that the function is loaded as expected. If you don't use a debugger, duplicate your wp-settings.php and add something like this to better understand where the problem is:

[21] require_once( ABSPATH . WPINC . '/plugin.php' );
if (! function_exists('is_plugin_active')) throw new BadFunctionCallException('Missing is_plugin_active after require plugin.php');
...
[302] // Load active plugins.
if (! function_exists('is_plugin_active')) throw new BadFunctionCallException('Missing is_plugin_active before include_once(plugin)');
foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
	wp_register_plugin_realpath( $plugin );
	include_once( $plugin ); // <--- the main plugin files are loaded here
}

[spleen1981]

I gave it a look, my understanding is that the require_once( ABSPATH . WPINC . '/plugin.php' ); in wp-settings.php is loading wp-includes\plugin.php, while is_plugin_active is defined in wp-admin\includes\plugin.php, which is loaded later.

[herrvigg]

Good catch, my bad!
I was also confused because it worked for me. Now i understand why: it's the plugin "disable Gutenberg auto-save" that loads this file much earlier! If i disable this plugin then i reproduce the same error so i will fix this.

[herrvigg]

So after checking better, here is how i see the module manager to work:

• admin side: detect the plugins and the incompatibilities, show notices. Load the modules because some of their hooks also concern the admin side. Save the valid modules in the options.
• front side: simply load the list of valid modules from the options. The front part should not have to deal with all the setup.

About the wp-admin\includes\plugin.php it seems that other plugins also have to load it before WP does. I'll see if i can delay it but if it's not possible it will be loaded explicitly.

[herrvigg]

@spleen1981 I've sent new changes on the woo-commerce branch. So you're welcome to check with this.

It's not very easy to know when to check and load this stuff and qTranslate is quite complicated to read. I think the right moment is on plugins_loaded because at this point all active plugins should be ready. But waiting for later could be problematic if the modules defined some early hooks.

So I have integrated the module manager in the main init function which is qtranxf_init_language. The loading holds for both admin and front parts. But the plugin checks are only done for the admin side. I needed to load the plugin.php file for the admin side, it should be safe since it only defines a bunch of functions.

[spleen1981]

Ok, seems to be working.
Few other bugs I found:

• Breadcrumbs: given the following breadcrumb structure "item1/item2/item3/product", when accessing the product page in one language, changing to another language would result in "item3" remaining stucked in the previous language in the breadcrumbs, while the rest is translated correctly.

• Products widget: for products with untranslated title, nothing is shown as title inside the widget for missing translation language.

• Products widget: stucked in the previous language when changing, maybe is the same bug as it was for Cart widget.

• Woocommerce settings>Accounts & Privacy: "Registration privacy policy" and "Checkout privacy policy" are supposed to be translatable fields (anyway the qtranslate square brackets syntax is working).

Also, adding qtranslate-xt to a WP installation with qtranslate-x and the former woocommerce add-in, in q-translate-XT settings under Integration>Configuration files a new row is added with this file: .t-woo-commerce/i18n-config.json , which cannot be found. Anyway removing this line everything seems to be fine.

[mwie1409]

Hi all,

I'm new to GitHub besides downloading one or the other .zip file...
Hoping everything I do is correct that way :-)

I am quite happy that QTranslateXT has come alive and at least some people take care about that faboulus plug-in again!! Using it on our company website together with Woocommerce and I am keen to support with at least testing - my programming skills are basic only.

One issue I have and for which at least I have some findings:
(WP 5.1.1, Woo 3.5.7, QT-XT 3.5.5)

language switching is working fine for the titles, contents, meta data, etc on the product pages. Also the cart shows the titles correctly.
When it comes to the final checkout page though, some titles are shown correct while others have the full QT [:en]XYZ[:de]ABC[:] string >>> as I figured out, products with variations are fine! Simple / non-variant prducts have the messed up title.

Maybe that leads into the right direction to fix it.

Will report further findings and as said - happy to test with real live data.

Cheers,
Michael

[herrvigg]

Hey, thanks for this.

Yes you can simply download the zip files from the repo. Just be aware the versioning on the master branch is not necessarily updated, i change the versions only before the releases but only occasionally with the regular commits when it's necessary (to refresh some browser caches).

Some issues have been reported with the variable products: #612 #645 #523. At least some of the issues were still seen on the last version of the old integration plugin (1.4).

I have just merged the new modules branch into master with this last version of the plugin (see #661). You can now drop the old legacy plugin and try just with qTranslate-XT.

[gm-style]

Hi all,
I'm new in GitHub, I would help with some testing and support if possible.

Actually testing this configuration:
WordPress : 5.1.1 (theme Twenty Nineteen)
WooCommerce: 3.6.2
QT-XT: 3.6.0

I noticed some integrations for translate fields are missing on these links:
/wp-admin/admin.php?page=wc-settings&tab=checkout&section=bacs
/wp-admin/admin.php?page=wc-settings&tab=checkout&section=cheque
/wp-admin/admin.php?page=wc-settings&tab=checkout&section=cod
/wp-admin/admin.php?page=wc-settings&tab=checkout&section=paypal

I discovered the issue into the file "qwc-admin.php" of WC module, where the arrays of fields to be translated refers to pages:
....section=wc_gateway_bacs, ....section=wc_gateway_cheque, etc.
WooCommerce changed these queries in recent versions, cause of settings pages design rework. While these fixes are easy by just adding a new array for new queries, another issue is for the new shipping settings tab, because it can add multiple lines of configurations, where queries are created with line IDs, like: ....tab=shipping&zone_id=1 .
Plus the configuration name has to be inserted into a popup. I'm trying to fix this.

About the new "/wp-admin/admin.php?page=wc-settings&tab=account" settings tab, need to be implemented the integration for new "#woocommerce_registration_privacy_policy_text" and "#woocommerce_checkout_privacy_policy_text" fields.

For "/wp-admin/admin.php?page=wc-settings&tab=advanced" maybe the integration could be useful for every endpoint, but I don't know if it is going to work. I'm gonna try that soon.

Regards,
Giovanni

[herrvigg]

Thanks @gm-style it's good more WC users shake this part and come up with new fixes. Once you have something working the best is to send a PR (Pull Request) if you can.

[IDWeert]

Hi all,

I'm new to GitHub besides downloading one or the other .zip file...
Hoping everything I do is correct that way :-)

I am quite happy that QTranslateXT has come alive and at least some people take care about that faboulus plug-in again!! Using it on our company website together with Woocommerce and I am keen to support with at least testing - my programming skills are basic only.

One issue I have and for which at least I have some findings:
(WP 5.1.1, Woo 3.5.7, QT-XT 3.5.5)

language switching is working fine for the titles, contents, meta data, etc on the product pages. Also the cart shows the titles correctly.
When it comes to the final checkout page though, some titles are shown correct while others have the full QT [:en]XYZ[:de]ABC[:] string >>> as I figured out, products with variations are fine! Simple / non-variant prducts have the messed up title.

Maybe that leads into the right direction to fix it.

Will report further findings and as said - happy to test with real live data.

Cheers,
Michael

@mwie1409 Did you find a solution for "simple"-product titles? I've the problem in the backend when order is viewed.

[herrvigg]

@mwie1409 @IDWeert can you explain me the problem with the title on checkout?

When it comes to the final checkout page though, some titles are shown correct while others have the full QT [:en]XYZ[:de]ABC[:] string >>> as I figured out, products with variations are fine! Simple / non-variant prducts have the messed up title.

Is that in the admin section or front-end? Please create a new ticket just for this problem and possibly a screenshot.

[herrvigg]

@spleen1981 update about your comment:

FRONTEND:

• "Products widget": Product names not being translated (entire string with square brackets is shown). Workaround: wrapping "$product->get_name()" inside __() function in woocommerce "content-widget-product.php" template, row 29, via child-theme override, will do the job.

Follow-up in #755 (not solved yet)

• "Cart widget": seems to be stored in sessionStorage, so a change of language won't be applied to this widget content, which will be still shown in the previous language. Modifying the cart content fixes the content language to current.

Please could you create a new ticket for this?

BACKEND:

• Products list: "Categories" column not translated (entire string with square brackets is shown); "Languages" column: styles to be fixed.

I can't reproduce, i don't know when it was fixed but it works for me now (current version 3.7.2).

May also be worth mentioning that "shop_coupon" post type should not be translatable, otherwise coupon codes will not work (even if qtranslate setting to disable translation of this type is available, it can take some time to figure out that's the reason why coupons are not working...)

You can select the post type to translate in QTX settings / advanced. If you see any particular problem after that, please could you create a new ticket?

[herrvigg]

@LC43 Hi,
my feedback for 130-unique-slug release:
Here follows what happens following the different kind of links.

• Categories and posts translated+translated slug: 404 (both primary and secondary language)
• Categories and posts translated+unique slug: 404 (both primary and secondary language)
• Categories and posts not translated: 404
• Pages translated+translated slug: OK primary language, 404 for secondary language
• Pages translated+unique slug: OK (both primary and secondary language)

Tried to update permalink structure and applied the "Rebuild all slugs" tool (link to settings in this page to be fixed), with same results as above.

This current ticket was to collect issues in WC so the integration with 130-unique-slug is yet another topic. Though i don't think i will be able to do much here, can you also open a new ticket for this?

[herrvigg]

Few other bugs I found:

• Breadcrumbs: given the following breadcrumb structure "item1/item2/item3/product", when accessing the product page in one language, changing to another language would result in "item3" remaining stucked in the previous language in the breadcrumbs, while the rest is translated correctly.

Please could you create a new ticket for this?

• Products widget: for products with untranslated title, nothing is shown as title inside the widget for missing translation language.
• Products widget: stucked in the previous language when changing, maybe is the same bug as it was for Cart widget.

Follow-up in #755

• Woocommerce settings>Accounts & Privacy: "Registration privacy policy" and "Checkout privacy policy" are supposed to be translatable fields (anyway the qtranslate square brackets syntax is working).

Now fixed in master - see #787

Also, adding qtranslate-xt to a WP installation with qtranslate-x and the former woocommerce add-in, in q-translate-XT settings under Integration>Configuration files a new row is added with this file: .t-woo-commerce/i18n-config.json , which cannot be found. Anyway removing this line everything seems to be fine.

The old integration plugins are made obsolete by the built-in modules since 3.6.0.

[herrvigg]

This ticket is getting too bit so i'm dispatching to see a bit better what is left. Please create new separate tickets for every different topic. Thank you for the help! I still keep this issue open a bit but i lock for now.

[herrvigg]

Many fixes for WooCommerce available in 3.7.3
So i unlock this ticket and close it instead, this was only an initial placeholder. Please create new issues for the remaining problems listed above and for new problems as usual.

[spleen1981]

BACKEND:

• Products list: "Categories" column not translated (entire string with square brackets is shown); "Languages" column: styles to be fixed.

I can't reproduce, i don't know when it was fixed but it works for me now (current version 3.7.2).

@herrvigg
Yes, it seems to be fixed now!

[spleen1981]

May also be worth mentioning that "shop_coupon" post type should not be translatable, otherwise coupon codes will not work (even if qtranslate setting to disable translation of this type is available, it can take some time to figure out that's the reason why coupons are not working...)

You can select the post type to translate in QTX settings / advanced. If you see any particular problem after that, please could you create a new ticket?

@herrvigg
Agreed, that's the current way to solve the problem; my comment was that this kind of post should not be translatable under any circumstances because the translation will break the coupon functioning...