Can no longer save changes

@cloudduster I’ve made several tests and everything works fine on my end. Plus, no other complaints were made so I hope it’s either an isolated case or a plugin conflict that needs to be solved in case other users have the same problem.

I’d like to know, when did you notice this happening and what kind of changes have you made (e.g. Unload on this page)? Was it after the last update of the plugin? Have you recently installed a particular plugin and then noticed this problem?

Thanks for your reply.

I’ll test this further by disabling my plugins. I’ll give a feedback later.

Now I’m even more confused. It works perfectly on the ‘post’ type, but on ‘page’ type, it’s inconsistent.

i created an entirely new page and apply deapply and it works. and when i ‘unload’ something on existing pages, it won’t save.

@cloudduster When you’re saying existing pages, what kind of pages are they? Do they have something specific that might trigger this behavior? Not likely, but it’s worth checking out. It could also be from a caching system that doesn’t check properly the query strings (as the management is in the front-end) and loads the previously cached page which obviously prints the previous settings. Can you check if after you update an existing page (one that you’re saying has issues), you go to Edit Page in the backend and the values are changed? Maybe it updates the database, but it prints a cached page in the front-end with the old values.

PS: Don’t worry, these kind of issues are solvable. Everything has an explanation and it’s a matter of time until you find out what’s going on. May I know the reason why you prefer to use front-end management only?

My website basically relies on ‘page’ rather than ‘post’ type. Because I want to apply specific rules, for example advertisements, each page belongs to specific customized template pages. I do use the ‘default template page’ and I checked that, and it’s not the cause of the issue.

I use wp super cache, cloudflare and bunnycdn at the same time. I know cloudflare and bunnycdn has some sort of ignore query string settings, I will check this later. I have disabled caching for admin in wp super cache, so that shouldn’t affect the extension but for the sake of testing, I will take it down once my visitors will start to subside.

I did check the asset cleanup dashboard after adding or removing from the front end, and it’s pretty much the same thing. If it’s not reflected in the front-end, it’s not in the backend as well.

I don’t understand why I was able to set up, like unload Contact Form 7 in the ‘page’ type but as I want to ‘unload it’ on a specific page, the settings remain unchanged.

I have yet to take down my site for further testing maybe later as soon as my visitors would come down.

I prefer the front-end because I think it’s a lot easier. Also, does the lite version even offer to unload stuffs from its dashboard (not individual pages when editing)?

Here’s an update.

I’m now using Dashboard “Asset CleanUp Pro: CSS & JavaScript Manager” meta box. It’s a lot easier. Thanks for bringing this up on your previous reply.

So I compared two similar pages. Both have the same Parent Page. Both have the same Template page.

Page A loads fine. No error in Chrome console.
But Page B has this 403 error.

https://www.webbline.com/caregiver-vacancy-jobs-in-the-philippines/?wpassetcleanup_load=1&wpassetcleanup_time_r=1566284454431&_=1566284453431

And I think because of that error, my edit dashboard looks like this
https://nimb.ws/suzvKb

Is this useful?

I don’t know why it loads perfectly on Page A but not on Page B when both of them were applied with similar settings.

• This reply was modified 5 years, 7 months ago by cloudduster.

@cloudduster from my tests, I always get 404 messages whenever I’m using query strings on Page B. That’s what Asset CleanUp does to retrieve the assets list accurately. It appends a few relevant strings that are used by the plugin.

If I visit https://www.webbline.com/caregiver-vacancy-jobs-in-the-philippines/?query_string_here=1 it will return a 404 Not Found error. That’s very peculiar and shouldn’t happen.

Also, the same happens with well know query strings like “utm_source” from Google Analytics: https://www.webbline.com/caregiver-vacancy-jobs-in-the-philippines/?utm_source=value_here

That’s from your WP setup. If I visit https://www.webbline.com/caregiver-vacancy-jobs-in-the-philippines/ (no query strings) it redirects to https://www.webbline.com/list-of-available-caregiver-jobs-in-2019-rev8212019236/ – so this redirection and any script behind it are likely interfering with Asset CleanUp retrieval mode. Perhaps you can check other pages that use redirects, they could have the same behavior.

Thanks for your reply.

I don’t think it’s related to the redirection plugin that I’m using, because I’m not editing the old page. It’s the new page that’s displaying this error.

Anyway, I’ll continue to test but honestly I’m quite stressed now. I’ve looked into different pages, and I just couldn’t find the reason why this particular page works, the other page doesn’t. I can’t find a common culprit.

The workaround that I’m doing right is to duplicate a page that works fine. That is why you’re seeing the ../rev123456 thingy. It works.

Maybe the more time I spend using this plugin, maybe I can find out why it’s behaving this way but for now, I have got to stop digging into it because I’m already tired ??

Update. So I’ve finally found out the reason of the 403 errors.

For some reasons, there were 3 directories in the root my of website that correspond to the 3 Parent Pages that I was using. I didn’t create those directories and I don’t know how they got there. N

The support staff told me that it was the reason why all of the pages I created under these Parent Pages have 403 error in them.

We’ve removed those folders and Asset CleanUp is working back again.

@cloudduster thanks for letting me know about it! Those redirections were suspicious to me whenever you had a query string in the URL. It would be interesting to find out how/why those 3 directories were created in the first place. It’s good to know in case other users will have similar issues. Perhaps, a well-known plugin created those directories. Hopefully, it’s an isolated case!