Hi @rogierlankhorst,
I bumped the plugin version to 6.1.4 but still not seeing any new columns in the _amd_zlrecipe_recipes table. I tried deactivating and reactivating the plugin. Either the DB update is not happening, or something else is not happening for me.
I uploaded a new image to an existing recipe to play with. It does seem to have generated the three new format versions. I see their URLs, but I do not see thumbnails for them. This is what I see:
For me, on both my test system and my production system, the saving images issue is pretty consistent. I think I remember being able to update the image through the UI at times, but more than 90% of the time the behavior is as I described in my previous message. I have had to resort to manually poking the image ID into the database to change it.
I tried specifying a 475×475 px image for the 1×1 and I got the too low resolution error and was unable to use the image I chose.
Hey @rogierlankhorst,
Thanks so much!
I loaded up the test plugin on our test system and it seems to work great. I think making it so that Zip Recipes generates the three image formats automatically and then allows the user to override them individually is a great design.
Here are a few questions and comments:
Q: I’m looking in the _amd_zlrecipe_recipes table and I can’t see where / how you are storing the three alternate image URLs. ??
Q: Also, looking in that table I note that there are two columns that seem to independently specify the default recipe image: recipe_image is a URL and recipe_image_id is an ID. Wondering why both are needed and whether this is related to comment 1 below.
1. I have noticed that it is usually difficult / impossible to delete an image from a recipe and/or to replace an existing image. I click the image to choose a new one, or click the “clear image” link and the UI shows me either the newly chosen image or a blank placeholder, but then after clicking the save button, when the page reloads, the recipe shows the original image again. This happens on a test system with no caching enabled, and examining the recipe record in the DB, I can see that the original image ID has not changed even after a save.
2. It would be helpful in determining whether I need to manually override any of the auto-generated images if I could see a proportionate thumbnail of the auto-generated image. Failing that, I have to copy paste the URL into a new browser window to see what the image looks like which is kind of clunky.
3. I noticed in trying to manually replace some of the additional images that there is a validation on the image resolution that was disallowing most of the alternate images that I was trying to specify. What is the minimum required resolution, and how did you determine what that should be?
Thanks, that’s great.
I think that Zip Recipes automatically generating 3 images in those ratios is likely to give pretty much the same results that I’m trying to avoid. The problem is exactly that Google is algorithmically resizing an image in one format to another format.
What I think would be best is the ability for the user to specify three different images. Probably for most images I’ll just crop a single image three different ways. But I can also imagine that some images might only work 1×1 or 16×9 and in those rare cases to get attractive results on Google Recipe Cards you might need to use a totally different image for one format from another.
I know that generating the LD-JSON is going to be trivial but monkeying around with the recipe editor UI to make a provision to specify multiple images will be a PITA so THANK YOU for your willingness to consider it.
Got it. Thanks.
Yes, that is pretty unintuitive for a migrated list of conditions. I have several duplicates that were created for whatever reason, but now I understand how to clean them up.
Thanks. How can I tell the difference between the ruleset for one zone or another?
I have three separate shipping zones and UPS, as an example, is in all three. After migrating from 1.x -> 2.x, I have 6 rulesets on the shipping conditions page that are all called “UPS”. There is no visible distinction between any of them. Nowhere does it say anything in any of the new rulesets about what zone it applies to.
If I wanted to create a ruleset that applies only to a particular zone, how would I do that? When I click on “add ruleset” there is no way that I can see to specify a zone.
Not sure why you marked this as resolved, but for other’s reference, this is still broken in your plugin in version 1.4.
No errors – it’s working well as far as I can tell.
I mainly wasn’t sure if it would be more comprehensive to do something with the $document_type argument. My client’s use-case only includes invoices at the present time, so since that’s the only document they are generating, I ignored it.
Is there any documentation for the wpo_wcpdf_custom_attachment_condition filter anywhere? I only found it by digging through the plugin code.
It’s a very nice plugin.
I think I may have figured out how to do this for my purposes. Is there any problem with the following snippet?
add_filter('wpo_wcpdf_custom_attachment_condition', 'ms_no_invoice_failed_orders', 10, 4);
function ms_no_invoice_failed_orders ($attach, $order, $email_id, $document_type){
if ($order->get_status() == 'failed') {
return false;
}
return $attach;
}
