Raysn

@designextreme thanks for your reply! ?? But I don’t quite understand this. As long as the option “avatar” is set to “true”, for example, the avatars of the reviewers are loaded via img src from the server of googleusercontent.com. And at that very moment, isn’t the visitor’s IP address transmitted to googleusercontent.com? To my knowledge this is exactly a DSGVO / GDPR specific problem. Especially for this there are workarounds with PHP proxy (see e.g. https://www.woltlab.com/community/thread/268348-dsgvo-einbindung-von-externen-bildern-erlaubt/).

• This reply was modified 1 year, 8 months ago by Raysn.

@designextreme: But isn’t it the case that by integrating the external sources, the IP address of the site visitor is passed on to Google’s non-European servers without being asked (without opt-in)? The ECJ has stated in the past that the IP address of a website visitor is personal data that may not be passed on without being asked, see https://www.datenschutz.org/ip-adresse-datenschutz/#:~:text=The%20Europe%C3%A4ic%20Court%20(ECJ)%20has,it%20special%20protection%C3%BCtzt%20become%20m%C3%BCssen.

Okay nevermind – WP All Import natively provides the ability to import data as a serialized array. That’s what made it work.

I’m thinking this is because the data is stored as a serialized array. I just want to store 1 keyword per imported page. Is this somehow possible?

Even if @paulinho_rus temporary solution works, it would be great if this bug would be fixed as soon as possible, as this has a direct impact on the SEO performance of all affected pages!

Thank you in advance team @soflyy & team @yoast!

• This reply was modified 3 years, 2 months ago by Raysn.
• This reply was modified 3 years, 2 months ago by Raysn.

Is it possible that for some reason something in your setup only allows for one attachment at a time? Are you using a third party plugin for email delivery?

I can’t rule that out, but it worked about a month ago. There were 3 PDFs attached per e-mail: 2 via the filter in functions.php and 1 pdf invoice via the plugin. I deactivated all plugins one by one and tested in each case whether the code in the functions.php works. Only after I had deactivated “PDF Invoices & Packing Slips”, the code was executed and the respective files were attached.

What version of WooCommerce PDF Invoices & Packing Slips did you downgrade to?

When I wrote this, I thought it could work that way. But when I downgraded to the plugin version of October 13th, it unfortunately didn’t work anymore either. Then I suspected a change in the latest WooCommerce update and downgraded WooCommerce to the version of 10/13/2020 ( my last backup) – also unfortunately without success.

As I said, my current workaround is to send out the PDF invoice with the order confirmation and manually attach the additional PDFs to the “Order Complete” e-mail template. But of course it would be nicer if all PDFs could be attached in one e-mail.

Maybe we’ll get to the solution of the mystery.

Best Regards
Ray

Hey Ewout,

just tried to hook the function later, but with the change only the attachment specified in the functions.php was sent, the PDF invoice was apparently no longer attached. strange…

My current workaround is to attach the invoice to the customer processing order email so that the attachments for the customer_completed_order are not “blocked”. But there is certainly a better solution.

Nice! I’m glad to hear that. I am looking forward to the update ??

Hey Stefano, nice work! I’ll check it out these days and get into that contribution-thing to share my german translation with the community!

Greets
Raysn

@scottopolis: no solution for this so far?

Hey Donnie,

actually I have already added the following CSS, which hides the problem at least for the visitor:

.rpt_features {
	border-bottom-left-radius: 8px;
	border-bottom-right-radius: 8px;
}
.rpt_plans .rpt_plan .rpt_foot {
	display: none;
}

But I think this is more of a technical problem, which Google in particular is less happy about. ??

The audit in the developer tools of Google Chrome complains about the following under “Best Practice”:

Links to cross-origin destinations are unsafe
Warnings:
Unable to determine the destination for anchor (<a target="_blank" rel="noopener noreferrer">). If not used as a hyperlink, consider removing target=_blank.
(etc.)

Anyways, thanks for your quick response! I would be happy if you could fix this bug in a future update.

Greets
Raysn

• This reply was modified 4 years, 9 months ago by Raysn.

Hey Timo,

just wanted to thank you for this quick fix! Now everything works fine for me ??

Greets
Raysn

Thanks for your quick response, Timo!

The fastest solution is not to leave the shortcode empty.

I also thought about that. But since I want to work with post templates in which I only have to enter the correct ASINs, it would of course be nicer if the error did not even occur. Indeed, I would be very happy if the bug was fixed in the next update.

Anyways – ASA is a great plugin! Keep up your work ??

Greets
Raysn

Hi Stefano,

thanks for your response! Please keep me updated here ??

Have a nice day,
Raysn