Matt Cromwell

Hi @wfrank94 – thanks for your feedback, that is an issue we identified for those on Windows computers. The most recent update, version 2.1.2 fixed that issue. Please update and you’ll be all set again.

@mferraz That is not true at all. Firstly, forms do not use this plugin at all. This plugin implements SMTP instead of PHPmail in your WordPress website. What you do with your forms is up to you and the form plugin you use.

Hi folks, we were finally able to replicate the issue as you all experienced it. This is what we found:

1. Install 1.2.7 and configure
2. simulate auto-update to 2.0.0
3. simulate auto-update to 2.1.0

That resulted in the breakage that you’re all reporting. We have a release that’s going through QA now to fix this.

Of course, fixing this in the new release won’t give you your time back you spent this past weekend, or reverse any of that work that you did over the past few days. We wish we were able to perfectly predict these situations every time, but we’re fallible just like you are. Nevertheless, your reports and feedback helped us identify this issue to prevent it going forward.

Watch for that update coming soon. Thank you!

HI all,

I oversee Customer Experience at StellarWP which includes all things related to SolidWP as well.

Thanks for these reports of this issue. I flagged this today with our devteam and we’re working on replicating the issue, clearly something is off, but so far we’ve tried all of the below without being able to replicate the behavior you’re seeing:

• updating from 1.2.3 to 2.1.0 -> No issues
• updating from 1.2.7 to 2.1.0 -> No issues
• updating from 2.0.0 to 2.1.0 -> No issues

However, two different members of our team found this to be problematic:

1. Install 1.2.3 version
2. Setup the SMTP.
3. Confirm that it’s working as intended
4. Then update to 1.2.7 and see if the setting still persist

In each case upgrading to version 1.2.7 removed the previously existing settings.

So can each of you confirm from which versions you upgraded from and to?

And just as an olivebranch, we’ll work hard to resolve this as best we can, but keep in mind that we acquired the plugin when it was at version 1.2.7 and we had to do a lot of clean up before we had confidence in version 2.0. This wasn’t done hastily it without due diligence, just like we are taking your input and feedback seriously and working towards resolution today as well.

Thank you!

OK, I simplified this a ton and just used:

file_get_contents

And it worked great. Solve it by rubber-ducking it with you. Thank you!

I’ve also tried creating a helper function for this.

function wppt_transcript_export($value) {
    // Check if the file exists and is readable
    if (file_exists($value) && is_readable($value)) {
        // Output the contents of the file
        return file_get_contents($value);
    } else {
        // Handle the case where the file doesn't exist
        return "File not found or not readable.";
    }
}

But it always returns “File not found…” even though every episode has an associated file.

Adding some links for convenience:

RSS feed is in the original ticket above

Original .m4a file:

https://wpproducttalk.com/wp-content/uploads/2024/09/ep78-WP-Product-Talk_-How-Pre-Launch-Marketing-can-help-HYPE-your-Next-Product-Launch-with-Kevin-Geary.m4a

Blurbrry url:
https://media.blubrry.com/3788743/wpproducttalk.com/podcast-download/2499/pre-launch-marketing-hype.m4a?ref=new_window

Thanks!

• This reply was modified 5 months, 2 weeks ago by Matt Cromwell.

Hi there,

Looks like you’ll need to go all the way back to version 1.4 of WP Rollback to use it with WP 4.7.29.

Good luck!

@deeveearr Is your installation also in a sub-directory like @eugene212 is reporting? That would be helpful for us to be able to replicate the issue.

UPDATE: @deeveearr I see your original ticket that @eugene212 is also commenting on. I’ll chime in over there.

@afizesan – Thanks so much for identifying the source of the issue, so glad Devin was able to push a fix based on your insight. Thank you!

@mhartste – Glad it’s working for you now. Yes, Devin and I are co-founders of GiveWP, and we built WP Rollback together with a friend a long time ago for a “Pluginpalooza” contest at WordCamp Orange County. This plugin has a special place in our hearts, and Devin’s recently been giving it tons of new love and attention. I just get to come around and be helpful if possible, but the work Devin’s done is really impressive.

@deeveearr – If you have any kind of server logs or WPDebug logs enabled that could give us insight on where things are failing that would be really helpful. If you have a system info you could provide that would be great too. But in the interest of all the folks on this thread, would you mind creating a new ticket since your issue seems to be unique from the others. That way we can isolate based on your unique environment. Thank you!

I do have Cloudflare actually. But I have Cloudflare + Solid Security + Limit Login Attempts on my personal blog and it doesn’t have this same error. So I’m really stumped.

@deeveearr – give me some details, what DID happen? Did you see the wp-rollback endpoint? Was everything enabled for Administrators?

Then, as I said above, if it did NOT work then you need to contact your host. Did you do that? What did they say?

Always looking for the next step and we can only get there with more information. Help me help you.

Hey folks, I did a little bit of digging on this error myself. It pops up a lot with any plugin that has custom REST API endpoints. The root cause seems to always be related to those endpoints not being created correctly or successfully. So something in your environment is preventing WP Rollback from creating those endpoints. Here’s what I’d do to troubleshoot this a little further:

0. Ensure WP Rollback is on the latest version

I know you’ve updated several times, and rolled it back as well, but in order for these next steps to work, start by having Rollback on the latest version.

1. Install the “Disable REST API” plugin

Install this plugin: Disable REST API

It doesn’t just disable the REST API endpoints, it allows you to control all the REST API endpoints on your site per user role.

2. Go to the Disable REST API settings page

There you’ll see a dropdown to choose different user roles. It defaults to “Unauthenticated users”, which is fine for now. On this screen, just verify that you see a section for WP Rollback, it should say /wp-rollback/v1 like this:

3A. If you DO see that section

If you do see that section, ensure that when you toggle to the Administrator at the top of that screen, that all the WP Rollback endpoints are enabled.

Then go to Settings > Permalinks and just resave permalinks again.

Hopefully now you’re all set.

3B. If you do NOT see that section

If you don’t see that section, then we’ve verified that something in your environment is preventing WP Rollback from registering those endpoints correctly. I would reach out to GoDaddy about that, it’s most likely a security setting in your server settings.

4. Further Reading

Here’s several sources I found that pointed me at some of this info. I believe between the troubleshooting above, help from your web host, and these resources that you should be able to find and resolve the issue.

• How to Resolve the ‘No route was found matching the URL and request method’ Issue – WP Simple Pay – Several options, including security related items, Modsecurity specifically, and jQuery errors
• rest_no_route error | www.remarpro.com – the tip on saving permalinks is here
• No route was found matching the URL and request method · Issue #2626 · WP-API/WP-API (github.com) – some of these folks recommended restarting PHP, your host would have to do that for you.

Try that out, and let us know what you discover. I’m certain we can get to the bottom of this together. Thanks!

OMG, somehow I literally did not see that there even WERE general settings. First time I’ve seen that page. Thanks! All set!