t.schwarz

Thanks for your reply! Turns out, my analysis was a bit wrong – I based by conclusion that $_POST was missing at the specific hook on the fact that the “checkout-process-nonce” will not verify in case a new customer is registered, while it will verify in case of guests and previously logged-in users. $_POST is available after all. But the nonce verification will still fail in the described case.

Since I also read elsewhere that I don’t really need to check the nonce at that point (for some reason, because WPCS will flag it, and usually even within admin the admin screens custom functionality is told to do proper nonce-checking?), so that solves my specific problem, but it still feels a bit like a bug (because it makes no sense for the checkout nonce verification to be dependent on user creation), so I may open a ticket about this. Thanks again for your help!

• This reply was modified 9 months, 1 week ago by t.schwarz.

Thanks for your reply, I have opened a support ticket!

Hi Krystian, I didn’t get a notification that there was a reply. Thanks for your reply, including the link, which absolutely helps decide the matter at hand.

To follow up on my question specifically – is it correct that cookies and scripts for the paypal smart-buttons are set/loaded on every page on which the buttons are displayed even *if they are not actually shown* because, eg. a different payment method is chose by default? If so, is it technically inevitable to do it that way and not only load the scripts and set cookies once a user clicks on paypal payments to choose this payment method, thus indicating specifically their intent to use paypal?

Good to know, thanks!

Thanks for your reply! Actually, all of them, but mostly for quick access for editing without having to go to another page, and for reordering (which, alas, didn’t always work).

The standard WP system is horrible for managing content in sites with hierarchical structures and more then 10 pages, and the quick access to the tree, including basic management, in the main admin menu thus was immensely useful, and it also looked good.

I can’t speak to the DOM jitters you mention when changing it with AJAX, but functionality-wise it’s basically a “deal breaker”. Now I can’t really see a difference between “CMS tree page view” and “Admin tree page view”, except that the former doesn’t have a top level menu entry but gives access to the trees under the respective post type label, which I find more intuitive.

So, again, I’m sure you have good reasons, including code hygiene, to remove the apparently hacky functionality, but to me that hacky functionality was the real reason for using this plugin over others. Wihtout that, as mentioned, I find the post-type-based-treee-access approach of CMS Tree Page View more intuitive, so I’ll probably switch to using that plugin.

Whatever you decide, thanks for offering and supporting this plugin for so long!

You may have had your reasons, but the quick access to pages within the admin bar – *without* having to access another page – was, to me, the main point of using this plugin. I’ve used it in all WP installations for the last 10 years. Will be difficult to explain to clients that this functionality is gone. Hope you’ll reconsider. Managing page content in WP just became harder again, apparently. Thanks anyway.

Super, thanks for the update =

Thanks for this thread – I’ve experimented with headlessWP and was also wondering about the GDPR compliance aspect – I suppose there’s two levels with headless as opposed to one level in standard templating: the wp-post/s and plugin/rest content and the headless site templating itself.

I suppose your filter parsing approach could work for the wp-posts / plugins aspect of the template, and I suppose it would also be possible to request the current consent status when rendering aspects of the site that aren’t handled by WP.

My first “real” decoupled/SPA WP-App won’t require compliance, but when I’m done with it I will try this to see if it works.

Thanks, great, that’s good to know! Thanks for your efforts =)

I found this answer, and the newly introduced filter to disable SSL for the purpose of the optimization.

https://www.ads-software.com/support/topic/omgf-ist-beim-holen-des-frontend-html-dieser-website-auf-einen-fehler-gestosen/

to repeat, the latest version contains a filter that suppresses SSL whiel optimizing. Adding this to functions.php worked for me.

add_filter('omgf_admin_optimize_verify_ssl', '__return_false');

I would like to join this question:

To which extent is “Jetpack Protect” a part of the Jetpack plugin and requires extensive syncing. It would seem that the list of plugins and versions installed and maybe a site ID would be sufficient information for a vulnerability scan.

Instead the plugin’s dashboard links to the document above that explains the Jetpack sharing process, in which, among other things

User-Related Data
Jetpack syncs miscellaneous bits of user information, such as:
The user IDs, usernames, email addresses, roles, and capabilities of registered users. This does not include passwords.
The user ID of any users that make changes to the site and the time that changes are made (e.g. ID of the user that added a new user, modified the site icon, or trashed a comment)."

is mentioned.

This is clearly not necessary information to be shared for the purposes of a security scan. And as the OP has mentioned, if this isn’t merely a mistaken link, will prohibit the use of the plugin by everyone subject to the GDPR.

If running the WPScan/Jetpack Protect plugin ineed requires consent to the sharing of data as is the case with the complete Jetpack plugin, it would suggest a strange kind of data grab for a free offer supposedly aimed at increasing the health of the WP ecosystem.

As such, I would think that the link to the JETPACK sharing agreement as part of the JETPACK protect plugin’s setup process is an oversight. Could you confirm this, and maybe fix it? Also, it would be great to get a list of data *actually* shared with Automattic when using this plugin.

Thanks.

Thanks for your reply! The link was helpful, but ultimately didn’t solve the problem.

I now suspect it’s a WPML problem:

For some reason the URL in the cookiebanner’s “var complianz” isn’t translated to “English.com” and instead refer’s to “German.De”, which is why the problem appears to occur in the first place. The Cookie is present using

https:\/\/[English].com\/wp-json\/complianz\/v1\/

so, the domain mapping seems to work, but the request is sent to the wrong domain because the URL variable in the js isn’t translated, as opposed to the other URLs in the cookiebanner.

<script type='text/javascript' id='cmplz-cookiebanner-js-extra'>
/* <![CDATA[ */
var complianz = {"prefix":"cmplz_","user_banner_id":"1","set_cookies":[],"block_ajax_content":"0","banner_version":"25","version":"6.3.1","store_consent":"","do_not_track":"","consenttype":"optin","region":"eu","geoip":"","dismiss_timeout":"","disable_cookiebanner":"","soft_cookiewall":"","dismiss_on_scroll":"","cookie_expiry":"365","url":"https:\/\/[GERMAN].de\/wp-json\/complianz\/v1\/","locale":"lang=en&locale=en_US","set_cookies_on_root":"0","cookie_domain":"","current_policy_id":"16","cookie_path":"\/","categories":{"statistics":"statistics","marketing":"marketing"},"tcf_active":"","placeholdertext":"<div class=\"cmplz-blocked-content-notice-body\">Click 'I agree' to enable {service}\u00a0<div class=\"cmplz-links\"><a href=\"#\" class=\"cmplz-link cookie-statement\">{title}<\/a><\/div><\/div><button class=\"cmplz-accept-service\">I agree<\/button>","css_file":"https:\/\/[ENGLISH].com\/wp-content\/uploads\/\/complianz\/css\/banner-{banner_id}-{type}.css?v=25","page_links":{"eu":{"cookie-statement":{"title":"Cookie-Policy ","url":"https:\/\/[ENGLISH].com\/cookie-richtlinie-eu\/"},"privacy-statement":{"title":"Privacy Policy","url":"https:\/\/[ENGLISH].com\/privacy-policy\/"},"impressum":{"title":"Imprint","url":"https:\/\/[ENGLISH].com\/imprint\/"}},"us":{"impressum":{"title":"Imprint","url":"https:\/\/[ENGLISH].com\/imprint\/"}},"uk":{"impressum":{"title":"Imprint","url":"https:\/\/[ENGLISH].com\/imprint\/"}},"ca":{"impressum":{"title":"Imprint","url":"https:\/\/[ENGLISH].com\/imprint\/"}},"au":{"impressum":{"title":"Imprint","url":"https:\/\/[ENGLISH].com\/imprint\/"}},"za":{"impressum":{"title":"Imprint","url":"https:\/\/[ENGLISH].com\/imprint\/"}},"br":{"impressum":{"title":"Imprint","url":"https:\/\/[ENGLISH].com\/imprint\/"}}},"tm_categories":"","forceEnableStats":"","preview":"","clean_cookies":"1"};
/* ]]> */</script>

That said, the cookie banner on English.com still does appear to save the settings. So I’m inclined to just leave the error as long as it still works.

• This reply was modified 2 years, 2 months ago by t.schwarz.

Thanks @aahulsebos, I will give this a try and report back =)

Saw similar problem below. Solved by updating php to 7.4.