Web Surfer

I actually figured it out.

The site was built prior to Woo 2.6 coming out, and all of the shipping methods and calculations were defined in a custom shipping class in PHP files.

It seems that the issue was with cart-shipping.php, which was custom to the theme. Once I replaced cart-shipping.php, removed the custom shipping calculator and methods from the code, and changed review-order.php to the default, the issue is resolved.

Now, to start setting up all the complex logic again.

Looks like the 2.2.7 issue did fix the issue! Thank you!!!!

To reference the above user’s mention of reverting: if anyone does not know, there is a plugin called WP Rollback. If you still have dashboard access like I did, go to Dashboard > plugins after installing WP Rollback. A Rollback option will appear beneath each plugin. You can use this to roll back to a previous plugin version in the GUI.

Yes, absolutely! This would be at https://www.speedeeoil.com/locations.

So zero-result reports are coming to the admin email for each center. These are reports that show zero people made a booking and zero people used the booking. Centers that aren’t even using this plugin are getting these emails.

Currently, I am testing this and it works that way for me- however, one issue I’ve run into is that when you’re on the main domain, the login to any of your subsites will go fine. Trying to login to one of the other subsites from that subsite without logging into it from the main site first will generate an error.

Edward, I have another update:

I tried disabling all the plugins except Broadcast, User Role Editor and Broadcast Premium pack. When I tried to do a User Role Sync via Broadcast Premium Pack, it goes through, but the user roles do not show up or sync to the site I broadcast to. What else can I do to fix this problem or diagnose what could be happening? This was working about a month ago, and when we went to try it today it doesn’t go through.

Hey Edward, did you have any ideas for me on this? I did use the Health Check plugin made by the WordPress team, it says this plugin is made for PHP 5.6- but it works sometimes for us. Should our PHP version be set to 5.6 to use your plugins?

Okay. So I am able to Broadcast the Options pages and actual Page that I need if I do it this way:

Go to Template site (broadcasting from)
Go to Broadcast > ACF and broadcast options pages to selected blog
Go to Plugins in Network and disable Premium Pack across the Multisite network
Go back to Template site, and go to Pages then Broadcast page to the selected blog

So this will work if I do it this way, but not with Premium Pack enabled when I go to do it from the actual Page editor interface.

Thank you for the reply, Edward!

So I did disable all plugins on the multisite one by one. I got to Divi, ACF Pro, ACF Options Admin, ThreeWP Broadcast and ThreeWP Broadcast Premium Pack. It is still erroring out.

PHP Warning: Invalid argument supplied for foreach() in /www/wp-content/plugins/threewp-broadcast-premium-pack/src/acf/ACF.php on line 1479

That is what I get when I go to “Broadcast Options Pages” which is essential to the broadcast that’s failing, as the Page has Options Pages attached to it using ACF. I also see this error in the error log.

I should mention I verified all user roles are the same on the site being broadcasted from and the site being broadcasted to. I turned on ThreeWP Broadcast Debugging, but got little in the way of information there.

• This reply was modified 4 years, 4 months ago by Web Surfer.
• This reply was modified 4 years, 4 months ago by Web Surfer.

Sorry, I just saw this.

So we’re using the Broadcast plugin. In the Broadcast interface, we go to Center > Services > State Inspection > Edit. There’s a Rule area where we can put a second shift, etc for the State Inspection service. When clicking “Remove” (red button in the rule) it would just duplicate the rule and create another blank rule.

Another thing you could try is setting the PHP version to 7.2, if it’s on anything later than that now. 7.2 is very stable for WP, and if the errors go away that might point to something there as well.

Also- if you’re having any sort of error 500 code, I would check your .htaccess file in your WordPress directory, if you have one. Sometimes, the regex stuff in there can throw everything off.

Hey there! If you can get into an SSH session and WP-CLI is installed on your server there, you can try running a wp core verify-checksums and seeing if your core files match what the WordPress repository shows- I would start there, blocks.php is in wp-includes.

Alright, so I can’t 100% sure say I can help you fix this, but let’s try some steps here that might allow you to at least gain access to the dashboard. Can you get file access, and rename the folder “photocrati-pro” in /wp-content/themes/ to “photocrati-pro-back” and then try to load WordPress? That will disable the theme for now, which seems to throw your errors there.