tonydjukic

All of my 'supports' => have always been set as arrays and this issue keeps persisting. If it’s I’m in a block editor screen I get this foreach() error within the script-loader.php, but if it’s in the classic editor I get this same error in the class-wp-editor.php.

The site in question has two custom post-types, both made by me in their own unique plugins. If I deactivate both plugins, the error is still there.

Jeff,

I think I found the issue – we migrated from dev to staging and that’s when the problems started up – like with other areas it appears that some of the settings didn’t migrate and the Shipping Zone for Canada was set for ‘everywhere’ instead of just Canada – so it was applying the Canadian Fall Back Rate to every shipment that didn’t report a rate.

I just ran a test and it worked. I’m going to go back and double check all of the zones. I apologize for the confusion – when I was troubleshooting I was checking the WooCommerce Services area and only double-checked the USA Zone because that was the rate that was failing to return. In fact, it was as I went to capture a screenshot for you that I noticed the setting hadn’t migrated properly and that Canada was set incorrectly.

Thanks for steering me in the right direction.

• This reply was modified 7 years, 1 month ago by tonydjukic. Reason: Flag as resolved

Here you go everyone:

jQuery Accordion Menu Plugin – New version GitHub

Anyone interested in forking this can do so and I’ll add all changes to the main file. Maybe we can find a way to get this fixed once and for all and commit the entire thing to the repository.

The last error is the one I’ve fixed multiple times but my fixes always render the plugin useless – not sure what’s happening but what good is an errorless plugin if it doesn’t work, right?

@gus0074

You know this line doesn’t actually existing in this plugin, right?

function spacious_service_widget_pp()

@pwi1000, unfortunately once I put it into production, the entire thing just imploded – no idea why. I intend on revisiting to seeing if I can find where it all went wrong, but I haven’t had the time lately. To avoid the errors I made a simplified shortcode within the theme I was building that does exactly what the specific site needed. Sorry. If I can swing the time to re-work the plugin, I will and I’ll post here.

I had to make additional changes to the ones listed above – any chance we can get these committed to the plugin?

I didn’t note them all because they were numerous, but if we can get access to this plugin we should be able to put all of these in place.

It worked on all but one… …one of them I had to log into cPanel, upload the ZIP archive using file manager and then extract with file manager.

I think the previous failed updates caused all sorts of issues/corruption in the JetPack directory itself, so when I tried via FTP I kept getting errors about files not existing, etc.

I’m pretty surprised at how difficult this ended up being.

Ok… …so I was searching for a potential alternative for this plugin, but instead found this plugin on GitHub. Thought that maybe I could fork it, find the lines throwing errors, change them up and then maybe the devs would commit the ‘fixes’ to an update.

What I discovered actually appears to be a lot simpler.

1) All of the errors above listing the use of ‘resource’ as a keyword reserved by PHP7, turns out it’s not being used by the code itself, instead, it’s a directory in a file path that points to vendor resources on AWS. So I believe this is a false positive by WP Engine’s compatibility checker.

2) The final error regarding the ‘footer.php’ file and
"No PHP code was found in this file and short open tags are not allowed"
…there is no PHP code and short open tags aren’t being used – it’s simply a footer file with a closing div tag, i.e.:
</div>

I think it’s safe to say that this plugin isn’t throwing any actual compatibility errors. I’ve been wrong before and if it is, please, someone correct me, but from what I can see, there was no ill effect on our PHP7 test site when utilizing it and I can’t find anything in the GitHub repository for the plugin that would indicate it is using ‘resource’ in a manner that would result in a conflict.

So is this just not going to be commented on at all? 4 months in and not so much as a mention from the development team?

@ahappy1

I think the other posters, like myself, are considering a potential PHP upgrade/migration from 5.6 to 7 and seeing these errors come up is making us all give pause. I’ve got little option however as WPEngine is going to be moving a client’s site to a PHP7 powered Google service in a couple of weeks and this plugin is the only one throwing a major error.

Do we have a timeline on re-write/update? Basically there’s a class named ‘resource’ that PHP7 won’t allow because it’s reserved. The class is listed 9 times in the plugin and it’s name and all references to it would need to be changed.

@mikejolley

That’s going to have to wait until the wee-wee hours of the night as we have customers trying to order – going to try again after midnight EST and will gather as much data as I can.

@mikejolley

Thanks Mike. After sending my message we tried it again (TRS is at 3.0.1) and we pushed the update button for WooComm from 2.5.x to 2.6. End result is the same as before, just doesn’t work.

Currently using ManageWP to roll it back again.

@mikejolley The notion that following along with the appropriate procedure and methodology for updating will prevent errors is false – we did everything as instructed and each of the Table Rate Methods was applied to each of the zones we had set-up, that worked for years now… …but this didn’t really make any difference – whenever customers order, they’re informed that there is no method available to them. It’s really quite frustrating.

We spent countless hours setting up complex table rates to accommodate all the different postal codes in Canada and ZIP Codes in the US. Almost 30 zones in total, each with methods for weights from 1KG to 35KG. Not only do we not want to have to copy all that information over, but even when we did for a test zone, it didn’t solve anything.

We have a current license that we renew annually and even that didn’t offer us any ‘update’ notifications – it’s only because we thoroughly read through the documentation of each update (major or minor) that we even knew to go looking for a new update for the Table Rate plugin.

Thankfully we use ManageWP and have restored our site back to it’s state prior to WooCommerce 2.6 and Table Rate Shipping 3.0.

Is there any sort of documentation that could explain why the published update process doesn’t work?

@jameskoster I’m extremely comfortable doing this directly in code, so the Theme Customizations plugin is exactly what I’m after.

The site is for my wife and I was looking for a quick solution – I’ve got client work I should be doing on so I didn’t want to invest more than a day or so into building her something. If it starts to take off, I’ll put more time into it.

I used Storefront and Galleria and reviewed all of the free and paid plugins on the “About This Demo” page – I wasn’t entirely sure that I’d be able to accomplish everything I want with them – but that may just be because I’m used to simply writing it all myself in my own themes and child themes.

I’ll give this plugin a run and see how it goes. Thanks @jameskoster.

@michael Shinosky

Unfortunately no.

I just disabled the plugin on that site.

I’m building a site for my wife (she wants to sell some kids clothing – https://dragonmama.ca) but I’ve just got the one sample product in place as I build it, so I don’t actually know if it’s working on her site or not. I do have it enabled but it’ll be a day or so before I am able to tell if the same issue appears.

I would have hacked into it and tried to figure it out but the project was flat rate and the feature was something I threw in because it looked cool – wasn’t something the client specifically asked for and I was already over budget on the hours I’d set aside, so I just disabled it and waited for a response. (As you can tell, there hasn’t been one yet.)

Sorry man.