rambo3000

Hi @erdembircan

It’s <i class="icon-default-style icon-ok extra-color-2"></i>

To be clear, the table displays custom html, yet when I open to edit the form, and click on custom html element, it doesn’t display this html. Also, when I save form after edit, all html elements are gone (because they were empty).

• This reply was modified 3 years, 4 months ago by rambo3000.

Quite strange, no errors, all resources are loaded fine, yet I see “If you are seeing this, the page is still loading or there are Javascript errors on this page. View troubleshooting guide” in the popup edit view.

Not sure how to continue from here.

Hmm, it looks like I don’t have Popup settings available.
I’ve got General, Subscriptions, Privacy, Misc.

Hi,

Yes, still happening on 2.4.7.
Direct Checkout for WooCommerce: 2.4.7
Woocommerce: 5.5.1
WooCommerce Direct Checkout PRO: 2.2.1

It’s pretty basic:

if(is_user_logged_in()) {
	setcookie("somecookie", "true", time() + (86400 * 10), "/");
}

In one of the scripts I’m using setcookie function. Can this cause a conflict?

It’s more likely it conflicts with some of my own code I assume now. I’ll take a look.

Hi,

Sorry for late reply, somehow missed this.

PHP: 7.2
Wordpress: 5.7.1
Ubuntu, apache 2

GDPR cookie consent plugin version: 1.9.5
Code snippets: 2.14.1 (https://www.ads-software.com/plugins/code-snippets/)

Tried today, still same problem.

So far it looks like it throws error only once during upgrade. Popups seems to be working though.

Thanks. I’m assuming a lot of users will find out about this problem after they see their history. Some general notice to all plugin users would help.

Sure, done.

Perfect, thank you!

Thanks!

Use https://www.ads-software.com/plugins/code-snippets/ instead of functions.php

Note, that when secret_key is forced into URL, this is a slight security hole – as URL requests are visible in web server logs and such.

https://security.stackexchange.com/questions/12531/ssl-with-get-and-post

you generally should not put secret information (passwords) in GET requests even with SSL, but use POST instead. Why? The URL with the sensitive information will generally be logged at both ends; e.g., in your browsers history list (https://www.example.com?user=me&password=MyPassword) as well as the logs on the server. POST information (especially with passwords) is generally not written to webserver logs, though obviously can be configured to be logged–so its best not to reuse (or use similar) passwords at different sites.

So it would be very useful if your plugin would accept secret_key in post content.