Vinobe

Heey @postnl

Dat is niet het geval, straat + nr staan weldegelijk tesamen in “adresveld_1”.
We ontdekten echter gisterenavond de oorzaak van dit issue.
Het adres van de besteller stond zoals vermeld in het standaard woocommerce veld “adresveld_1” opgeslagen, terwijl – zoals je zegt – wij effectief wel de “PostNL adresvelden” gebruiken en deze front-end ingeschakeld hebben.

Echter werkt deze webshop met recurring bestellingen, die automatisch elke 3 maanden hernieuwen. De persoon in kwestie was al sinds 2020 klant met recurring bestellingen. Mogelijks werden adressen vroeger in het algemene “adresveld_1” opgeslagen en zijn de “PostNL” velden pas later ingeschakeld of werkte jullie plugin vroeger op een andere manier en verondersteld deze dat bij elk order de adresgegevens “vers” zijn? Het agency waarvoor ik werk heeft deze webshop slechts ~ 5 maanden geleden overgenomen en op dat moment stond het vinkje “PostNL velden” al ingeschakeld, maar we weten dus helaas niet of dat iets recent was en dat de oorzaak is, en/of er een uitgebreider issue is waarbij jullie plugin vroeger de velden anders opsloeg ofzo.

Op zich is er dus een oplossing voor de klant: zij moeten gewoon even het adres zelf opsplitsen in het order van het “adresveld_1” naar de “straat” en “nummer” velden en dan werkt het aanmaken van een label inderdaad terug.

Ps. ik had jullie ook een email gestuurd al op dat emailadres dat je opgeeft. Vanuit mijn @onlyhumans.com email adres, maar die mag je dus verder negeren.

• This reply was modified 2 years, 9 months ago by Vinobe. Reason: Ps added
• This reply was modified 2 years, 9 months ago by Vinobe. Reason: Typo fixed
• This reply was modified 2 years, 9 months ago by Vinobe.

Ik heb bijna exact hetzelfde probleem, met exact dezelfde melding.

Error in MyParcel API request:
0 – data.shipments[0].recipient.street Must be at least 1 characters long – Failed validation against JSON – SCHEMA shipment / post_shipments_request – v1 .1.json(request_id: 1644839180.6916620 a410ca8e00) Url: https: //api.myparcel.nl/shipments

Is mogelijk de hotfix van 2022.02.02 die hier omschreven wordt relevant? Aangezien jullie plugin extensief gebruik maakt van de myparcel code?

De business van onze klant ligt still als zij geen labels kunnen aanmaken! Gelieve hier urgent naar te kijken.

M.v.g.
Vincent N.

@tinypng That is correct! ??

I ran the command “wp media regenerate” –> yes
I did not yet regenerate thumbnails through back-end after that.
After that de negative savings was visible.

FYI: We use a plugin (WP media folders – by joomunited) which has an easy button for that, and that does seem to trigger the tinyPNG plugin correctly (so probably the same for other plugins that support this trigger), it’s only through CLI that your functions do get not triggered and therefore are undone/untinied.

Thanks for taking this feature in consideration. We use WP CLI for a lot of things as it is powerfull and fast.

I was here just to request the same functionality, with a good argument i.m.h.o.

Why: I added a new image size while developing a custom theme for a client.
Therefore I needed to regenerate thumbnails fast for this new image format.
I used WP CLI for that as that is the fastest method. But now none of my cropped images are tiny anymore. I will have to run it through back-end again which is slower, AND I will have to use extra tinyPNG credit to “re-tiny” the images that were already tiny before, but were undone by the WP CLI command.

This feature is highly requested for me, I work for an agency and we are planning to implement tinyPNG on all future client websites from now on. Under the condition that WP CLI is supported.

EDIT:
For the fun of it, check this image:
https://imgur.com/a/9fjt5YY -36.2% savings (yes, minus)

Thanks

• This reply was modified 4 years, 4 months ago by Vinobe. Reason: Added screenshot

Me and my colleague spend some more time testing and researching this and we’ve seemed to have found the solution.

We simply added the following 3 lines to the .htaccess of the apache2 backend.

<IfModule mod_headers.c>
    Header append Vary "content-type"
</IfModule>

Restart varnish service after that and you’ll see it in the headers too.

Now varnish consistently serves webp images in Chrome and other compatible browsers and jpg’s in IE and other incompatible browsers.