Forum Replies Created

Viewing 15 replies - 1 through 15 (of 20 total)
  • Thread Starter manualsnow

    (@manualsnow)

    I tested it with latest v1.0.16 and the WooCommerce import still downloads the files, so it’s not working. Does EXMAGE need a custom code added to functions.php to address this issue?

    Thread Starter manualsnow

    (@manualsnow)

    Good. You can also consider removing features from the banner that Orbit Fox does not include anymore, ex. uptime monitor, Google analytics integration, etc.

    I’m talking about this image:

    Thread Starter manualsnow

    (@manualsnow)

    Just to confirm, I looked at the database again and seeing that each image has 2 identical records when using EXMAGE. Is this right or should there only be 1 record (maybe 2 if it’s a duplicate)?

    Please advise.

    Thread Starter manualsnow

    (@manualsnow)

    A new version has just been released, please update it then add below PHP snippet:

    Yes, the code you provided works for WordPress posts and pages, thank you! For WooCommerce it probably needs to be:

    add_filter( 'exmage_get_supported_image_sizes', function ( $image_sizes, $url ) {
    
    	return array(
    	'woocommerce_gallery_thumbnail'    => 100,
    	'woocommerce_thumbnail'            => 350,
    	'woocommerce_single'               => 640,
    	);
    }, 10, 2 );

    Just need to adjust the sizes, in pixels, to match your theme (ex. 100, 350, 640)

    Thread Starter manualsnow

    (@manualsnow)

    Another comment, I noticed in the database, there are identical values (image file URL) for:

    _wp_attached_file
    and
    _exmage_external_url

    Is there a need for _exmage_external_url entry then? It means the wp_postmeta database table will be bigger, and with a lot of images, it could become an issue.

    Thread Starter manualsnow

    (@manualsnow)

    Existing support for thumbnails is good news. In my testing, it didn’t work, unfortunately, I provided an URL where the thumbnails were already generated, but EXMAGE didn’t pick it up, it just listed all sizes as original file.

    However, inspecting the database, if I edit _wp_attachment_metadata in postmeta table related to the image, and change woocommerce_gallery_thumbnail value from product-123-photo.jpg to product-123-photo-100×100.jpg, then WooCommerce picks it up just fine.

    So, for now, I can just run SQL search / replace code to address this issue, and hopefully, you will release a newer version that does it automatically.

    Thank you for releasing such a useful plugin!

    Thread Starter manualsnow

    (@manualsnow)

    But that’s my point! Bulk editing will damage (erase) data it’s not supposed to touch!, namely, the sale dates fields. That’s a bug, not a feature!

    As stated previously, going into individual products to reset something that bulk editing damaged, defeats the purpose of using bulk editing (for sale price anyway), as you might as well just update the sale price individually in the first place and keep the schedule intact!

    Do you understand what I’m saying?

    P.S. Missing field “priceValidUntil” (optional) warning can be viewed after bulk editing sale price on any WooCoomerce product here:

    https://search.google.com/test/rich-results

    It seems the plugin uses regular price and ignores the sale price field even if it contains a value?

    Plugin help section for “Facebook Price ($)” says: “If blank, product price will be used.” But logic should should be: “If Facebook price field is blank, product sale price will be used. If product sale price is blank, regular product price will be used.”

    It’s a server configuration issue. To use Google Listings & Ads plugin, you should be running PHP 7.4.x or 8.0.x

    Consult your web host or server administrator to make sure you are running a supported version of PHP, and the error should go away.

    Thread Starter manualsnow

    (@manualsnow)

    Looks like the duplicate GTINs were fixed in GLA v1.12.5

    But, it seems the link between GLA and Yoast SEO was lost, so now all products are once again set to use default GTIN (whatever that is), instead of Yoast. Which means GTIN is not sent to Google and they are likely to penalize (lower the rating / exposure) of products that should have a GTIN (UPC/EAN).

    Is it possible to batch update them somehow, without manually updating many products or creating custom MySQL queries in postmeta table (_wc_gla_gtin = yoast_seo)? Maybe there is a way to change the “default GTIN” to be associated with Yoast SEO in settings?

    Thread Starter manualsnow

    (@manualsnow)

    Furthermore, submitting products one by one at https://domain.com/wp-admin/admin.php?page=connection-test-admin-page sometimes works, and sometimes doesn’t.

    Error looks like this: 0 products successfully submitted to Google

    There are pages and pages of rules explaining why an account can be suspended. “Misrepresentation” is a very vague one, which basically means Google thinks your potential customers will be confused or misled due to poor website design or missing information.

    More info: https://support.google.com/merchants/answer/6150127?hl=en

    Here are some popular ones:

    1. Show the following contact methods on your online store / website: business address, phone number, e-mail or contact form, social media business profile (ex. Facebook or Twitter). This must be machine readable on all pages, so in the header or footer of the WordPress theme.

    2. All links to legal documents should be present as well, so “terms and conditions of use”, “privacy policy”, “shipping policy”, “return / refund / exchange policy”, “payment methods accepted” pages must be present and easily accessible, typically in the theme footer.

    3. Taxes and shipping rules for all destinations you “advertise / ship to” must be configured in the Merchant Center.

    4. Also add your business name, address and phone number on the “Business information” page in Merchant Center.

    Hope this helps!

    Thread Starter manualsnow

    (@manualsnow)

    It seems the sync command on diagnostics page doesn’t work either. Error description:

    Error submitting products to Google: Error updating Google products: {“statusCode”:413,”error”:”Request Entity Too Large”,”message”:”Payload content length greater than maximum allowed: 1048576″}

    Thread Starter manualsnow

    (@manualsnow)

    And the error is back!

    So, I guess whatever fix was applied is not a permanent one.

    It could indeed be the plugin’s fault indeed! It allows submitting a feed to Google without setting up the company contact info, taxes and shipping first, which Google Merchant Center promptly labels as “Misrepresentation”.

    What’s the big deal? Well, you are blacklisted and there is no easy way to fix it! I’ve been trying for 3 months now to make requested changes, then e-mail, live chat & call the Google Merchants support team. 0 results! They just say everything is fully automated, no way for a human to override the review process. Basically, once you are suspended for this misrepresentation, it’s “too bad, so sad”. Go start a new company!

    Ridiculous on Google’s part to handle it this way, but also super bad on the default WooCoomerce Google Merchant integration plugin to allow submitting incomplete data that instantly leads to “guilty until proven innocent” type of suspension that is almost impossible to undo!

Viewing 15 replies - 1 through 15 (of 20 total)