gresakg

Thanks for the update, the explanation and the warning of a potential caveat in my solution.
I will now have to figure out what will work best for my usecase.
I think you can safely close this ticket now.

Thanks alot and all best! Greg

Just for the record: I solved this problem too by hooking into woocommerce_checkout_fields, after the VAT field has been created, that is at priority 41.

add_filter('woocommerce_checkout_fields', function($fields) {

  if(wc()->customer->get_billing_country() == wc()->countries->get_base_country()) {
    $fields['billing']['vat_number']['required'] = true;
  }
  return $fields;
},45);

Hi, thanks, this works. However, it only affects the backend. On the form, the field remains marked as optional. How could I change this?

Thanks again, Greg

Update: there are no errors and the warning reappears regardless if I dismiss it using central or on the site.
The adblocker is now turned off.

The warning disappears after dismiss but then reappears after the next scan.

Regards, Greg

Hi,
I have not noticed any error in the browser console. I noticed however that I had my adblocker turned on. I turned it off and tried again to see if that makes any difference.

All other things I have marked as fixed never reapeared though. Just this particular one.

Regards, Grergor

I had the same experience. My CPU load went to the skies, so I though I was experiencing an attack. After tailing access log, I discovered the IP “attacking” my server was my own: I forgot to close my woocommerce administation. After closing this one tab, loads went back to normal.

Hi,
it took some time but I dug deeply into it. Steps to reproduce:
Latest WordPress (5.2)
Latest Simmer 1.3.11
Theme Twentynineteen

Enable Gutenberg on recipe post type by enabling REST either in child theme or using plugin with following code:

function recipe_rest_support() {
		global $wp_post_types;

		//be sure to set this to the name of your post type!
		$post_type_name = simmer_get_object_type();
		if( isset( $wp_post_types[ $post_type_name ] ) ) {
			$wp_post_types[$post_type_name]->show_in_rest = true;
			// Optionally customize the rest_base or controller class
			$wp_post_types[$post_type_name]->rest_base = $post_type_name;
			$wp_post_types[$post_type_name]->rest_controller_class = 'WP_REST_Posts_Controller';
		}
	}
add_action('init','recipe_rest_support',25);

Add a new recipe and save it.
Add a new ingredient.
Save as draft
Preview

You should see the new ingredient twice.

Add another ingredient. Save as draft again and click preview:
The first ingredient is saved four times, the last one twice …
Etc.

I can resolve that by disabling REST and Gutenberg, but it is a temporary hack, because I want to use Gutenberg when writing recipes.

Thanks and best regards, Greg

I get php warnings on php 7.3

PHP Warning: “continue” targeting switch is equivalent to “break”. Did you mean to use “continue 2”? in wp-content/plugins/contact-form-by-supsystic/modules/supsystic_promo/mod.php on line 524

It is a php 7.3 compatibility problem. Can you please fix it for the next version?

Thanks, and best regards, Greg

I have the same issue and would also be glad if the proposed patch would make it into the next update of the plugin.

Thanks and best regards, Greg

Hi @wfdave, thanks for your answer.
Something very strange must have happened. I run the “corrupted” and the backed-up filesistem through Meld (diff viewer) and there were no difference except for the files in the wflogs directory, namely the files config-livewaf.php, config-livesync.php and config-transient.php
I am the only (unix) user allowed to write to the filesystem and I was not touching it, I never do. The wflogs and uploads folders are the only exceptions where www-data is allowed to write.

The problem was obviously in the database or the cache (I use nginx fastcache) or object cache (?) I am using php 7.3

Regarding the database, this is an example: in wp_options the option name _transient_plugin_slugs has the following value

a:19:{i:0;s:36:"a/k/i/s/m/e/t//a/k/i/s/m/e/t/./p/h/p";i:1;s:32:"c/a/s/t/e/o//c/a/s/t/e/o/./p/h/p";i:2;s:64:"c/l/a/s/s/i/c/-/e/d/i/t/o/r//c/l/a/s/s/i/c/-/e/d/i/t/o/r/./p/h/p";i:3;s:48:"c/l/o/u/d/f/l/a/r/e//c/l/o/u/d/f/l/a/r/e/./p/h/p";i:4;s:70:"c/o/n/t/a/c/t/-/f/o/r/m/-/7//w/p/-/c/o/n/t/a/c/t/-/f/o/r/m/-/7/./p/h/p";i:5;s:114:"c/o/n/t/a/c/t/-/f/o/r/m/-/7/-/t/o/-/d/a/t/a/b/a/s/e/-/e/x/t/e/n/s/i/o/n//c/o/n/t/a/c/t/-/f/o/r/m/-/7/-/d/b/./p/h/p";i:6;s:24:"g/g/g/a//g/g/g/a/./p/h/p";i:7;s:76:"u/k/-/c/o/o/k/i/e/-/c/o/n/s/e/n/t//u/k/-/c/o/o/k/i/e/-/c/o/n/s/e/n/t/./p/h/p";i:8;s:64:"w/o/o/-/p/o/l/y/-/i/n/t/e/g/r/a/t/i/o/n//_/_/i/n/i/t/_/_/./p/h/p";i:9;s:44:"l/o/c/o/-/t/r/a/n/s/l/a/t/e//l/o/c/o/./p/h/p";i:10;s:56:"n/g/i/n/x/-/h/e/l/p/e/r//n/g/i/n/x/-/h/e/l/p/e/r/./p/h/p";i:11;s:40:"p/o/l/y/l/a/n/g//p/o/l/y/l/a/n/g/./p/h/p";i:12;s:52:"r/e/d/i/s/-/c/a/c/h/e//r/e/d/i/s/-/c/a/c/h/e/./p/h/p";i:13;s:38:"s/s/s/w/p//s/s/s/l/i/d/e/r/w/p/./p/h/p";i:14;s:52:"w/o/o/c/o/m/m/e/r/c/e//w/o/o/c/o/m/m/e/r/c/e/./p/h/p";i:15;s:144:"w/o/o/c/o/m/m/e/r/c/e/-/a/d/v/a/n/c/e/d/-/f/r/e/e/-/s/h/i/p/p/i/n/g//w/o/o/c/o/m/m/e/r/c/e/-/a/d/v/a/n/c/e/d/-/f/r/e/e/-/s/h/i/p/p/i/n/g/./p/h/p";i:16;s:96:"w/o/o/c/o/m/m/e/r/c/e/_/p/a/y/u/n/i/t/y/c/w//w/o/o/c/o/m/m/e/r/c/e/_/p/a/y/u/n/i/t/y/c/w/./p/h/p";i:17;s:44:"w/o/r/d/f/e/n/c/e//w/o/r/d/f/e/n/c/e/./p/h/p";i:18;s:46:"w/o/r/d/p/r/e/s/s/-/s/e/o//w/p/-/s/e/o/./p/h/p";}

This could be the root of the problem, but how could this have happened?

Thank you for your assistance and best regards, Gregor

Yes, the problem is solved now.

Thanks a lot for your assistance and best regards,
Greg

Happy to say you nailed it this time ??

I suggest that you review the way you are managing acl in this plugin and make it a bit more sophisticated. You could actually use the function current_user_can() to check if the user is allowed to use the gallery, and this should be true for any user that can handle media, not just for people allowed to manage options, which are typically only admins.

Also, plugins should never die. You can’t just abort the whole wordpress, because your plugin doesn’t like something. You should find a way to abort only your plugins functionality in such cases, and give the user an appropriate feedback.

Anyway, thank you for your help and happy coding.
Greg

I commented it out. Sorry to say it didn’t work. The behavior didn’t change a bit. However, I did this to help you a bit. It looks like your script loves to die ??

$ grep -r Denied .
./Includes/Total-Soft-Pricing.php:		die('Access Denied');
./Includes/Total-Soft-Gallery-Video-Install.php:	// 	die('Access Denied');
./Includes/Total-Soft-Products.php:		die('Access Denied');
./Includes/Total-Soft-Gallery-Video-Settings.php:		die('Access Denied');
./Includes/Total-Soft-Gallery-Video-New.php:		die('Access Denied');
./Includes/Total-Soft-Gallery-Video-Media.php:		die('Access Denied');

Thanks for your patience. G.

Pretty sure I have. I am a dev myself ??

View post on imgur.com

Regards, G.

P.S. The patch was applied, please see two posts above. Thanks!