threemcc

If IIS, then it sounds like a problem I was having… Your rewrite rules are not quite right or they are getting messed up by subsite rules… (note the “remove” clauses in my rules)

I also modified/added to the normal WP rewrite rules so they work better… I was having issues with certain plugins and subfolder installs until I edited my rewrite rules.

<rewrite>
			<rules>
				<remove name="Security Rule" />
				<remove name="SEO Rule" />
				<!--   -->
				<rule name="Force HTTPS" enabled="true">
					<match url="(.*)" ignoreCase="false" />
					<conditions>
						<add input="{HTTPS}" pattern="off" />
					</conditions>
					<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
				</rule>
				<rule name="WordPress Rule 1" stopProcessing="true">
            <match url="^index\.php$" ignoreCase="false" />
            <action type="None" />
        </rule>
        <rule name="WordPress Rule 2" stopProcessing="true">
            <match url="^wp/([_0-9a-zA-Z-]+/)?wp-admin$" ignoreCase="false" />
            <action type="Redirect" url="{R:1}wp-admin/" redirectType="Permanent" />
        </rule>
        <rule name="WordPress Rule 3" stopProcessing="true">
            <match url="^" ignoreCase="false" />
            <conditions logicalGrouping="MatchAny">
                <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" />
                <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" />
            </conditions>
            <action type="None" />
        </rule>
        <rule name="WordPress Rule 4" stopProcessing="true">
            <match url="^wp/([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*)" ignoreCase="false" />
            <action type="Rewrite" url="wp/{R:1}" />
        </rule>
        <rule name="WordPress Rule 5" stopProcessing="true">
            <match url="^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*)" ignoreCase="false" />
            <action type="Rewrite" url="{R:1}" />
        </rule>
        <rule name="WordPress Rule 6" stopProcessing="true">
            <match url="wp-login.php" ignoreCase="false" />
            <action type="Rewrite" url="wp-login.php" />
        </rule>
        <rule name="WordPress Rule 7" stopProcessing="true">
            <match url="." ignoreCase="false" />
            <action type="Rewrite" url="index.php" />
        </rule>
      </rules>
    </rewrite>

Don’t do that. If you do that it probably detects the revisions as “Redundant” and deletes them. They look very similar, so w/o that plugin knowing exactly how Document Revisions (DR) works, and how to tell the difference between revision A and revision B, then it will probably screw up and delete more than it should.

The main issue is that DR works using “a novel way of handling post attachments”. So without additional coding and understanding of how DR works, that plugin will have issues…

I would request that the vendor put in a filter that tells “Better Delete Revisions” plugin to leave post_type “document” or “revision” AND their respective attachments and meta alone.

I am also guessing that it determines that they are duplicates due to the fact that each post with an attached revision has the same “post_content”…

Not really much that can be done from this end, this is an issue with “Better Delete Revisions” not being able to tell that the two revisions have the same content, however different attachments.

Ok I believe what you are looking for is this:
Unfortunately there isn’t a filter or action I can just use, but here is the solution… hopefully Ben will add this in, because mime type and file extension mismatches are a problem for IE security settings and some proxy servers…

In the file:
\wp-content\plugins\wp-document-revisions\includes\admin.php
@line 405 just after the line that says: “continue;”

Add this code:

if(is_numeric($revision->post_content)){
	$fn = get_post_meta( $revision->post_content, '_wp_attached_file', true );
	$fno = pathinfo($fn);
	$info = pathinfo(get_permalink( $revision->ID ));
	$fn = $info['dirname'].'/'.$info['filename'].'.'.$fno['extension'];
	}else{ $fn = get_permalink( $revision->ID ); }

Then just below there you will find the code where the revisions list is generated…
Change
<td><a href="<?php echo get_permalink( $revision->ID ); ?>"
To
<td><a href="<?php echo $fn; ?>"

Then each revision link will have the proper extension.

Look in database for the filename that wp document revisions would have used.

In your theme function file add the following

if($r = $wpdb->get_results("SELECT meta_value FROM ".$wpdb->postmeta." WHERE meta_key='_wp_attached_file';"))
		echo '<pre>'.print_r($r,true),'</pre>';

Then reload your admin interface to get a dump of all the filenames and relative path upload path… once you see the dump you can comment out the code above… just don’t reload.

Mine returns:

Array
(
    [0] => stdClass Object
        (
            [meta_value] => 2015/02/0db560200ec202737130ac36ff6b3769.doc
        )

    [1] => stdClass Object
        (
            [meta_value] => 2015/02/9053bd318ff6cb81ff895c9d137f83c7.doc
        )
...
)

If this is a multisite install, then the actual directory will be:
/wp-content/uploads/sites/<site id>/<year>/<month>/<filename>.<ext>

Now look for the files again, just to be sure that you are looking in the right place. We are also assuming that you didn’t override this using the general/network setting.

If you find the files, then check for the “Document Upload Directory” setting in your general/network settings to be sure that it didn’t default to something… If that field has something odd in it, then follow what I wrote to do here:
https://ww.wp.xz.cn/support/topic/broken-and-unable-to-resolve-issue-myself-at-this-time?replies=7

Otherwise, I have no idea what happened… I’ve had WPDR do some weird things, but deleting files isn’t one of them… I am guessing they are misplaced or became unlinked by a revision cleaning or WordPress db optimization utility type thing maybe… just a guess.

Not sure #1 is capable of being setup easily, because it would have issues with handling new revisions of the file. You could probably set up the WebDav server option and just upload a small file initially, then use WebDav to update the file… just make sure the file size limits are set high enough in PHP, WP, IIS/Apache, etc to allow the files. You may have to work with the MIME Types and such a bit to get it working…
Good Luck tell me how it goes.

As for #2 you could create a custom field and populate it using the “save_post” action when the file is uploaded.

Similar to “filetype-taxonomy.php” from his “code cookbook”
https://github.com/benbalter/WP-Document-Revisions-Code-Cookbook/blob/master/filetype-taxonomy.php

So:

function wpdr_update_size( $postID ) {
	$wpdr = Document_Revisions::$instance;

	if ( !$wpdr->verify_post_type( $postID ) )
		return;

	$post = get_post( $postID );
	$attachment = get_post( $post->post_content );
	$filesize = filesize(get_attached_file($attachment->ID));
	update_post_meta( $postID, 'document_file_size', $filesize );
}
add_action( 'save_post', 'wpdr_update_type', 10, 1 );

If you want to be able to update the value that gets generated, then you will also need to add a custom field. You can do that with a number of free and paid tools outlined within the Document Revisions documentation and by a general Google or WP plugins search.

In your theme’s functions.php file:
if(is_admin()){
add_filter( ‘override_post_lock’, create_function(“”, ‘return false;’ ));
}

Done.

Yes, look under “network settings” if this is a multi-site install.
I think it would be under Settings->”general” in single site install…
Anyways, look for the section titled “Document Settings”
Then change the “Document Upload Directory” settings.

One caveat is that it will save ‘\’ characters improperly on IIS.
In this case set the value, then directly update the option in the database.

Hope that helps.

In your theme’s functions.php file:
if(is_admin()){
function documents_admin() {
global $wpdr;
$admin = $wpdr->admin;
remove_action( ‘show_user_profile’, array( $admin, ‘rss_key_display’ ) );
//remove_action( ‘wpmu_options’, array( &$admin, ‘network_settings_cb’ ) );
}
add_action(‘wp_loaded’, ‘documents_admin’);
}

The first remove_action will remove the field in their profile.

The second remove_action will remove the field in network admins for upload folder and slug. (It doesn’t work properly on IIS host.)