lolitsjohnnyboy

hello,

sorry but this is not the answer to my question! Please read it again! I was asking for the technical field names inside a license product! Like the meta key behind the changelog and version field of a product. Please give them to me since I need them for customization… otherwise I will use a different tool.

Hi!

Glad you fixed it. With the current version, the WC product import via a CSV file badly ended when importing variable products. A lot of times, the checkbox “Use for variations” was unchecked, which caused bad issues. Now it’s working again!

Cheers.

Or add a check within parse_allergenic() to check if the exploded array is empty and skip the parsing?

• This reply was modified 2 years, 9 months ago by lolitsjohnnyboy.

I think you should add a check for the $name variable because using the returned error as result might be a bad idea:

[17-May-2022 09:58:58 UTC] Name: 
[17-May-2022 09:58:58 UTC] Texanomy: product_allergen
[17-May-2022 09:58:58 UTC] WP_Error Object
(
    [errors] => Array
        (
            [empty_term_name] => Array
                (
                    [0] => Für diesen Begriff ist ein Name erforderlich.
                )

        )

    [error_data] => Array
        (
        )

    [additional_data:protected] => Array
        (
        )

)

What do you think?

Another error:

[17-May-2022 00:05:04 UTC] PHP Notice: Undefined property: WP_Error::$term_id in /home/wp/disk/wordpress/wp-content/plugins/woocommerce-germanized/includes/import/class-wc-gzd-product-import.php on line 339

Hi!

I just saw your 3.8.5 update. Sadly, this fix seems to be missing. Do you have any information about the release date? Currently, I’m not able to release my plugin because otherwise a lot of people will have issues regarding an important function.

Cheers

Awesome! This works. I’ve left a comment with a suggestion ?? Thanks a lot!

Hi,

actually, the includes I’m talking about are included within this file:

wp-content/plugins/woocommerce-germanized/woocommerce-germanized.php

Since I’m including the importer from WooCommerce within my plugin, all extensions to the importer should be included automatically. If I do this within a backend function which gets not called via the admin dashboard, your includes are failing and I’m getting an WooCommerce importer without your export columns.

Cheers

Hey,

sorry for getting back to this topic. I’ve found another issue! Now the timing works perfectly, but when I use the WooCommerce exporter class within a Cron job or backend function for example, your exporter class don’t gets loaded because it’s within an is_admin() check within the woocommerce-germanized.php file.

Any chance you can move the exporter & importer include out of this check?

include_once WC_GERMANIZED_ABSPATH . 'includes/export/class-wc-gzd-product-export.php';
include_once WC_GERMANIZED_ABSPATH . 'includes/import/class-wc-gzd-product-import.php';

is_admin() only resolves when you are actually on an admin page, which is not the fact at a backend function :/

Otherwise, when I get the default exports columns for WooCommerce within my plugin (used by over 100 people for Collmex WaWi) during a Cron job for an automatic product import, your columns are missing and an error occurs during the import.

Since my plugin supports Germanized, it would be very bad, if the columns are missing in this case.

If there is no chance you can move the includes out of the check, please let me know. In this case, I need to do the include during the Cron job by myself. But I think, this case can happen more often and not only within my plugin.

• This reply was modified 2 years, 11 months ago by lolitsjohnnyboy.
• This reply was modified 2 years, 11 months ago by lolitsjohnnyboy.

Hi,

seems to be working now! Can you ship it within the next update?

Cheers

My current workaround is to call the init function above my code but I think you can just register the export columns a bit earlier directly within a constructor. I see no need for a admin_init hook here…

$gzd_product_csv_exporter = new WC_GZD_Product_Export();
$gzd_product_csv_exporter->init();

Hello @webtoffee,

we have now another user which complains about the same issues! As I told, it’s not possible for us to use a different hook. Is there any way you can ensure that the new order number is set at the above hook?

Hi@webtoffee,I see no sense sharing this with you since all you need to do is to copy the hook from my initial contact and just do some logging since this will show you the problem – not the system report. Correct me if I’m wrong but that’s my point of view as a WordPress developer..

Hi @webtoffee,

do you have any news regarding this topic? We are under pressure because both plugins are necessary for the business to work!

Hello,

I’ve tested setting the hook execution priority to 100 without any success! For me, it looks like there is a process running asynchronously in the background which generates and sets the new order number, which takes some time.

To be sure, I’ve logged it at the beginning of the hook and 3 seconds later in an asynchronous timeout. In the asynchronous timeout, the new order number was returned. So somehow there is a latency which is not good for other plugins at all!

Please fix this issue somehow so that my client can use his shop again since the order number is exported within this hook to several systems like printers, WaWi systems and a lot of other services which are connected over our plugin.