Ben Balter

@valicesupport — thanks for the detailed testing. There are actually two separate issues being discussed in this thread, so let me split them out.

The “new version doesn’t replace the file” problem you’re seeing on 5.0 (the document keeps serving the original file even though it shows a revision) is the attachment ID not reliably saving on upload, so the document keeps pointing at the old file. There’s a fix for that in https://github.com/wp-document-revisions/wp-document-revisions/pull/540, and @NeilWJames is taking it further — reworking the document upload to use WordPress’s modern media uploader and managing the file entirely server-side. That consolidated work is a few days out, so rather than ship the interim patch I’d like to fold these together into one release. I’ll follow up here when it’s ready; if you’re able to test before then, the branch on #540 addresses the save issue specifically.

@ennisprinting — you’re hitting a different issue, and I was able to reproduce it. After uploading, instead of returning to the post you land on WordPress’s media details screen (Title, Caption, Description, “Insert into post”, “Save all changes”). The plugin is supposed to close that upload window automatically; on recent WordPress (6.9/7.0) it was hooking in a moment too early — before WordPress finished initializing its uploader — and not retrying, so the window stayed open.

Good news on two fronts: I have a targeted fix for the current version (https://github.com/wp-document-revisions/wp-document-revisions/pull/541, confirmed against WordPress 7.0 with a test that runs a real file through the upload window), and the broader rework @NeilWJames is doing replaces that old upload window with WordPress’s modern media flow entirely, which resolves this at the root. These will go out together in the next release.

Two notes in the meantime:

• This is the classic editor path. If you’re using the block (Gutenberg) editor on the document screen, the upload path is different — can you confirm which one you’re on?
• A few of the fields you listed (Media Categories, Replace Media, PDF Secured, PDF Downloads) aren’t part of WordPress or this plugin — they’re added by other media/PDF plugins you have active. They aren’t the cause, but worth knowing your stack adds those.

If you’d like to test the immediate fix before the release, you can apply the one changed file (js/wp-document-revisions.js) from #541 on a staging site, and clear any caching/optimization plugin (e.g. WP Rocket) so an old minified copy of that script isn’t served. Let me know how it goes.

Thanks @nwjames (spot on as always) and thanks @valicesupport for the feedback. Give 4.0.6 (https://github.com/wp-document-revisions/wp-document-revisions/releases/tag/v4.0.6) a try?

Thanks for the feedback. Try 4.0.5? https://github.com/wp-document-revisions/wp-document-revisions/releases/tag/v4.0.5

For the folks on this thread that had trouble with 3.3.0, are you able to please confirm if 3.3.1 resolves the issue for you?

@nwjames fair point. I did some digging, and believe I have a theory, described in https://github.com/wp-document-revisions/wp-document-revisions/issues/254.

If either of those fixes can resolve the issue (and are as simple as they appear to implement), that could potentially quickly resolve the issue without other users running into the same frustration.

In the interim, please do give the filter fix a try and report back so we can confirm gzip is the culprit here.

• This reply was modified 5 years ago by Ben Balter.

Does the problem occur even when you deactivate all plugins and use the default theme?

I am wondering if https://github.com/benbalter/wp-document-revisions/pull/132 may not be the cause.