WP Document Revisions is a document management and version control plugin. Built for time-sensitive and mission-critical projects, teams can collaboratively edit files of any format — text documents, spreadsheets, images, sheet music… anything — all the while, seamlessly tracking the document’s progress as it moves through your organization’s existing workflow.
WP Document Revisions is three things
A document management system (DMS), to track, store, and organize files of any format
A collaboration tool to empower teams to collaboratively draft, edit, and refine documents
A file hosting solution to publish and securely deliver files to a team, to clients, or to the public
Powerful Collaboration Tools – With great power does not have to come great complexity. Based on a simple philosophy of putting powerful but intuitive tools in the hands of managers and content creators, WP Document Revisions leverages many of the essential WordPress features that, for more than eight years, have been tested and proven across countless industries — posts, attachments, revisions, taxonomies, authentication, and permalinks — to make collaborating on the creation and publication of documents a natural endeavor. Think of it as an open-source and more intuitive version of the popular Microsoft collaboration suite, Sharepoint.
Document History – At each step of the authoring process, WP Document Revisions gives you an instant snapshot of your team’s progress and the document’s history. It even gives you the option to revert back to a previous revision — so don’t fret if you make a mistake — or receive updates on changes to the document right in your favorite feed reader.
Access Control – Each document is given a persistent URL (e.g., yourcompany.com/documents/2011/08/TPS-Report.doc) which can be private (securely delivered only to members of your organization), password protected (available only to those you select such as clients or contractors), or public (published and hosted for the world to see). If you catch a typo and upload a new version, that URL will continue to point to the latest version, regardless of how many changes you make.
Enterprise Security – Worried about storing propriety or sensitive information? WP Document Revisions was built from the first line of code with government- and enterprise-grade security in mind. Each file is masked behind an anonymous 128-bit MD5 hash as soon as it touches the server, and requests for files are transparently routed through WordPress’s time-tested URL rewriting, authentication, and permission systems (which can even integrate with existing enterprise active directory or LDAP servers). Need more security? WP Document Revisions allows you to store documents in a folder above the htdocs or public_htmlweb root, further ensuring that only those you authorize have access to your work.
Customization – WP Document Revisions recognizes that no two teams are identical, and as a result, molds to your firm’s needs, not the other way around. Need to track additional information associated with a document? Departments, editors, issues, sections, even arbitrary key-value pairs — whatever you can throw at it, it can handle. Development and customization costs are further minimized by its extensive plugin API, and the WordPress Custom Taxonomy Generator makes it easy for even the uninitiated to add custom taxonomies to documents. Need an audit trail to track check-ins and check-outs? User-level permissions based on the document’s state or another custom taxonomy? Support for third-party encryption? Check out the WP Document Revisions Code Cookbook for sample code. Looking for even more advanced control of your workflow? WP Document Revisions will detect the popular workflow plugin Edit Flow, if installed, and will automatically pull Edit Flow’s advanced workflow management tools into WP Document Revisions. Simply put, virtually every aspect of the plugin’s functionality from workflow states to user-level permissions can be fully customized to your team’s unique needs.
Future Proof – Switching costs a concern? WP Document Revisions is built with tomorrow’s uncertainty in mind. Equally at home in an in-house server room as it is in the cloud, moving individual files or entire document repositories in and out of WP Document Revisions is a breeze (history and all). And since the software is open-source, you can easily add tools to automate the process of moving to or integrating with future third-party systems.
Features
Support for any file type (docs, spreadsheets, images, PDFs — anything!)
Securely stores unlimited revisions of your business’s essential files
Provides a full file history in the form of a revision log, accessible via RSS
Helps you track and organize documents as they move through your organization’s existing workflow
Each file gets a permanent, authenticated URL that always points to the latest version
Each revision gets its own unique url (e.g.,TPS-Report-revision-3.doc) accessible only to those you deem
Files are intuitively checked out and locked to prevent revisions from colliding
Toggle documents between public, private, and password protected with a single mouse click
Runs in-house or in the cloud
Secure: filenames are hashed on upload and files are only accessible through WordPress’s proven authentication system
Can move document upload folder to location outside of web root to further ensure government- and enterprise-grade security
Documents and Revisions shortcodes, Recently Revised Documents widget
Multisite and Windows (XAMPP) support
French and Spanish language support (easily translated to your language)
Recently Revised Documents Widget, shortcodes, and templating functions for front-end integration
Features Available via the [Code Cookbook](https://github.com/wp-document-revisions/wp-document-revisions-Code-Cookbook)
Audit Trail – creates check in / check out audit trail for all documents
Taxonomy-based Permissions – allows setting user-level permissions based on a custom taxonomy such as department
Third Party Encryption – example of how to integrate at rest encryption using third-party tools
Rename Documents – changes all references to “Documents” in the interface to any label of your choosing
State Change Notification – how to use document api to allow users to receive notification whenever documents change workflow state
Bulk Import – how to batch import a directory (or other list) of files as documents
Filetype Taxonomy – Adds support to filter by filetype
Track Changes – Auto-generates and appends revision summaries for changes to taxonomies, title, and visibility
Change Tracker – Auto-generates and appends revision summaries for changes to taxonomies, title, and visibility
Security Policy
To report a security vulnerability, please email ben@balter.com.
Where to get help or report an issue
For getting started and general documentation, please browse, and feel free to contribute to the project documentation.
For support questions (“How do I”, “I can’t seem to”, etc.) please search and if not already answered, open a thread in the Support Forums.
For technical issues (e.g., to submit a bug or feature request) please search and if not already filed, open an issue on GitHub.
For implementation, and all general questions (“Is it possible to..”, “Has anyone…”), please search, and if not already answered, post a topic to the general discussion list serve
Things to check before reporting an issue
Are you using the latest version of WordPress?
Are you using the latest version of the plugin?
Does the problem occur even when you deactivate all plugins and use the default theme?
Have you tried deactivating and reactivating the plugin?
What steps can another user take to recreate the issue?
What is the expected outcome of that action?
What is the actual outcome of that action?
Are there any screenshots or screencasts that may be helpful to include?
Only include one bug per issue. If you have discovered two bugs, please file two issues.
WP-Documents-Revisions Action Hooks
This plugin makes use of many action hooks to tailor the delivered processing according to a site’s needs.
Most of them are named with a leading ‘document-‘ but there are a few additional non-standard ones.
Action change_document_workflow_state
Called when the post is saved and Workflow_State taxonomy value is changed. (Only post_ID and new value are available)
In: class-wp-document-revisions-admin.php
Action document_change_workflow_state
Called when the post is saved and Workflow_State taxonomy value is changed. (post_ID, new and old value are available)
In: class-wp-document-revisions-admin.php
Action document_edit
Called as part of the Workflow_State taxonomy when putting the metabox on the admin page
In: class-wp-document-revisions-admin.php
Action document_lock_notice
Called when putting the lock notice on the admin edit screen.
In: class-wp-document-revisions-admin.php
Action document_lock_override
Called after trying to over-ride the lock and possibly a notice has been sent.
In: class-wp-document-revisions.php
Action document_saved
Called when a document has been saved and all plugin processing done.
In: class-wp-document-revisions-admin.php
Action document_serve_done
Called just after serving the file to the user.
In: class-wp-document-revisions.php
Action serve_document
Called just before serving the file to the user.
In: class-wp-document-revisions.php
WP-Documents-Revisions Data Design and Data Structure
Requirements
To maintain a reference to a document and to hold a list of published versions of the documents.
It is not particularly concerned about how the document is created and the process to arrive at the state ready to upload.
It will maintain a status of where it is in the publishing process.
It makes use of a custom post type “document” and revisions to maintain the history of Document file uploads.
The Document file will be uploaded using the standard Media loader.
This will result in an Attachment post being created with the Document post as its parent.
It will not be visible in the Media library as Queries to the Media library remove attachments with parents that are documents.
Document files can be stored in a different host library.
The Document file should not be accessible directly by the user, but ideally via the WP interface.
This will be supported by changing the uploaded file name to be an MD5-hash of the original file name and load time.
This can be supplemented by changing .htaccess rules to stop direct access to files with MD5 format names
Standard WP processing may create a JPEG image of PDF uploads.
Since it will store these using the MD5 file name that will be downloaded to the user this would expose the MD5 file name. Therefore there is a process to change these images to use another name.
The document post record can also support Featured Images.
If loaded via the Edit document page, it would be considered as a Document file. So the parent post identifier will be removed to eliminate confusion between it being a Featured Image and a Document file being stored.
Since version 3.4 of the plugin, it is possible to enter a user-oriented description that can be displayed to users with the shortcodes or blocks provided with the plugin.
An audit trail of changes to published versions of the Document file.
The user can enter a reason for changing the Document including uploading a Document file; changing the Document Description; or Title; or any Taxonomy element.
This reason will be stored in the Excerpt field.
The aggregate information may be displayed as a Revision Log.
Use will be made of the standard WP Revisions functionality to contain the Audit Trail itself.
Standard WP processing creates a Revision if any one of these fields are changed: title, content or excerpt.
Since all Attachments are linked to the parent Document record, by storing the Attachment Id in the content field, then a Revision record will be created automatically.
This plugin is delivered with just one Taxonomy – Workflow_State. This shows the status of the Document file in its processing.
This is not considered very useful for user data classification.
However, being a generic tool, sites can use of a dedicated Taxonomy plugin.
Data Structure
The records held in the database will be:
Document Record
post_content contains the id of the latest Document file attachment record.
When a Document file is loaded on editing this Document record, the post_content will be modified to contain the ID of the Attachment record created.
In plugin versions prior to 3.4, this would simply be the numeric ID.
Subsequent versions hold this in the form of an HTML comment “<!– WPDR nnn –>” where nnn is the ID of an attachment post. It can also contain a text Document description.
When editing the post, this field is decomposed into its two parts of ID and description with program management of the former and user management of the latter, recombined automatically when changes are made.
post_excerpt will contain any comment entered when the document record is updated.
As taxonomy records are held only against this Document record, there is no effective audit trail of changes to Taxonomy. Changes can be noted manually in the excerpt field
Attachment Record(s)
There can be multiple Attachment records, one for each Document file loaded.
The name and title of the Attachment record is set to a MD5 hash of the original file name and the load time.
The Document file name is also set as this MD5 hash.
post_parent is set to the Document Record ID.
When a PDF Document file is loaded, then standard WP processing will attempt to make a JPEG image of the first page as a thumbnail (using all sizes). These will be held in the same directory as the Document file.
However if the file name is MD5Hash.pdf, then these images will be called MD5Hash-pdf.jpg.
If used on a page, this would expose the name of the file to the user.
To avoid this, there is a process to transform this name to another (essentially random) MD5 and rename these image files.
Once done, a postmeta record is created with these new file names (and a field denoting this process has been done).
If a Featured Image is loaded whilst editing the Document record, this would also have the same post_parent set, so in this case, the post_parent is set to 0 leaving the functional postmeta link to denote the presence of the featured image.
Revision Record(s)
When saving a Document Record, standard WP processing will be invoked to detect a change in title, content or excerpt fields. If one is found then a Revision record is created.
There can be multiple Revision records held, one for each saving event where a change in these fields are detected.
Because the document content contains the latest Attachment ID, an upload of …
I’m a user/developer/administrator… can I contribute?
Of course. Please! WP Document Revisions is an open source project and is supported by the efforts of an entire community. We’d love for you to get involved. Whatever your level of skill or however much time you can give, your contribution is greatly appreciated. Check out the “How to Contribute” page for more information.
Does it work on Mac? PC? Mobile?
WP Document Revisions should work on just about any system with a browser. You can easily collaborate between, Mac, PC, and even Linux systems. Mobile browsers, such as iOS or Android should be able to download files, but may not be able to upload new versions in all cases.
What are the different levels of visibility?
Each document can have one of three “visibilities”:
Private – visible only to logged in users (this can be further refined either based on users or based on the document’s status)
Password Protected – Non-logged in users can view files, but they will require a document-specific password
Public – Anyone with the document’s URL can download and view the file
How many people can access a document at a time?
A virtually unlimited number of people can view a document at the same time, but only one user can edit a document at a time.
While a file is “checked out” can others view it? What about a previous versions?
Yes.
Is there a time limit for checking out a file?
No. So long as the user remains on the document page (it’s okay if the window is minimized, etc.), the user will retain the file lock. By default, administrators can override this lock at any time. The origin lock-holder will receive a notification.
Does it keep track of each individual’s changes?
Yes and no. It will track who uploaded each version of the file, and will provide an opportunity to describe those changes. For more granular history, the plugin is designed to work with a format’s unique history features, such as tracked changes in Microsoft Word.
How do permissions work?
There are default permissions (based off the default post permissions), but they can be overridden either with third-party plugins such as the Members plugin, or for developers, via the document_permissions filter.
What types of documents can my team collaborate on?
In short, any. By default, WordPress accepts most common file types, but this can easily by modified to accept just about any file type. In WordPress multisite, the allowed file types are set on the Network Admin page. In non-multisite installs, you can simply install a 3d party plugin to do the same. The only other limitation may be maximum file size, which can be modified in your php.ini file or directly in wp-config.php
Are the documents I upload secure?
WP Document Revisions was built from the ground up with security in mind. Each request for a file is run through WordPress’s time-tested and proven authentication system (the same system that prevents private or un-published posts from being viewed) and documents filenames are hashed upon upload, thus preventing them from being accessed directly. For additional security, you can move the document upload folder above the web root, (via settings->media->document upload folder). Because WP Document Revisions relies on a custom capability, user permissions can be further refined to prevent certain user roles from accessing certain documents.
Is there any additional documentation?
In the top right corner of the edit document screen (where you upload the document or make other changes) and on the document list (where you can search or sort documents), there is a small menu labeled “help”. Both should provide some contextual guidance. Additional information may be available on the WP Document Revisions page.
What happens if I lose internet connectivity while I have a file checked out?
WP Document Revisions will “ping” the server every minute to let it know that you have the file open. If for some reason you lose connectivity, the server will give you roughly a two minute grace period before it lifts the file lock. If it’s brief (e.g., WiFi disconnected), you should be fine, but if it’s for an extended period of time (e.g., a flight), you may find that someone else has checked the file out. You do not need to re-download the file (if no one else has modified it), simply remain on the document page to maintain the file lock.
Do you have any plans to implement a front end?
In short, “no”, because each site’s use would be radically different. Although, you can always link directly to the permalink of any public document, which will always point the latest revision and is available on the document edit screen (right click on the “download” link), or through the add-link wizard when editing a post or page (simply search for the document you want). The long answer, is “it’s really easy to adapt a front end to your needs.” There are more than 35 document-specific API hooks, and the plugin exposes two global functions, get_documents() and get_document_revisions(), all of which are designed to allow plugin and theme developers to extend the plugins native functionality (details below). Looking for a slightly more out-of-the-box solution? One site I know of uses a combination of two plugins count shortcode, which can make a front end to browse documents, especially in coordination with a faceted search widget.
No really, how do I present documents on the front end?
A chronological list of all documents a user has access to can be seen at yourdomain.com/documents/. Moreover, because documents are really posts, many built in WordPress features should work and public documents should act similar to posts on the front end (searching, archives, etc.). The plugin comes with a customizable recently revised documents widget, as well as two shortcodes to display documents and document revisions (details below).
Can WP Document Revisions work in my language?
Yes! So far WP Document Revisions has been translated to French and Spanish, and is designed to by fully internationalized. If you enjoy the plugin and are interested in contributing a translation (it’s super easy), please take a look at the Translating WordPress page and the plugin’s translations repository. If you do translate the plugin, please be sure to contact the plugin author so that it can be included in future releases for other to use.
Will in work with WordPress MultiSite
Yes! Each site can have its own document repository (with the ability to give users different permissions on each repository), or you can create one shared document repository across all sites.
Can I tag my documents? What about categories or some other grouping?
Yes. You can use the Simple Taxonomy plugin to add taxonomies, or can share your existing taxonomies (e.g., the ones you use for posts) with documents.
Can I put my documents in folders?
WP Document Revisions doesn’t use the traditional folder metaphor to organize files. Instead, the same document can be described multiple ways, or in folder terms, be in multiple folders at once. This gives you more control over your documents and how they are organized. You can add a folder taxonomy with the Simple Taxonomy Refreshed. Just add the taxonomy with a post type of “Documents”, and as the “Hierarchical” set to True.
What if I want even more control over my workflow?
Take a look at the Edit Flow Plugin which allows you to set up notifications based on roles, in-line comments, assign all sorts of metadata to posts, create a team calendar, budget, etc. WP Document Revisions will detect if Edit Flow is installed and activated, and will adapt accordingly (removing the workflow-state dialogs, registering documents with Edit Flow, etc.). If you’re looking for even more control over your team’s work flow, using the two plugins in conjunction is the way to go.
Equally the PublishPress Plugin, a fork of Edit Flow, is detected and can be used with WP Document Revisions in exactly the same manner as Edit Flow.
I want some small changes to the processing, but there are few configuration options. How do I do this?
Yes, there are few Settings. However there are many filters that allows processing to be configured to your requirement. These are described here. This will need some coding to be done.
Can I make it so that users can only access documents assigned to them (or documents that they create)?
Yes. Each document has an “owner” which can be changed from a dialog on the edit-document screen at the time you create it, or later in the process (by default, the document owner is the person that creates it). If the document is marked as private, only users with the read_private_documents capability can access it. Out of the box, this is set to Authors and below, but you can customize things via the Members plugin (head over to roles after installing).
How do I use the documents shortcode?
In a post or page, simply type [documents] to display a list of documents.
More information is on this page.
How do I use the document revisions shortcode?
In a post or page, simply type [document_revisions id="100"] where ID is the ID of the document for which you would like to list revisions.
More information is on this page.
How do I use the recently revised documents widget?
Go to your theme’s widgets page (if your theme supports widgets), and drag the widget to a sidebar of you choice. Once in a sidebar, you will be presented with options to customize the widget’s functionality.
How do I use the `get_documents` function in my theme or plugin?
Simply call get_documents(). Get documents accepts an array of Standard WP_Query parameters as an argument. Use it as you would get_posts. It returns an array of document objects. The post_content of each document object is the attachment ID of the revision. get_permalink() with that document’s ID will also get the proper document permalink (e.g., to link to the document).
How do I use the `get_document_revisions` function in my theme or plugin?
Simply call get_document_revisions( 100 ) where 100 represents the ID of the document you’d like to query. The function returns an array of revisions objects. Each revisions’s post_content represents the ID of that revisions attachment object. get_permalink() should work with that revision’s ID to get the revision permalink (e.g., to link to the revision directly).
Can I set the upload directory on multisite installs if I don’t want to network activate the plugin?
Can I limit access to documents based on workflow state, department, or some other custom taxonomy?
Yes. Download (and optionally customize) the taxonomy permissions plugin from the Code Cookbook. Out of the box, it will register a “departments” taxonomy (which can be easily changed at the top of the file, if you want to limit access by a different taxonomy), and will create additional permissions based on that taxonomy’s terms using WordPress’s built-in capabilities system. So for example, instead simply looking at edit_document to determine permissions, it will also look at edit_document_in_marketing, for example. You can create additional roles and assign capabilities using a plugin like Members.
Is it possible to do a bulk import of existing documents / files already on the server?
Yes. It will need to be slightly customized to meet your needs, but take a look at the Bulk Import Script in the code cookbook.
SECURITY: WordPress can create images for PDF documents which if used would leak the hidden document name so image name changed.
NEW: An action ‘document_saved’ is provided for processing after a document has been saved or updated and all plugin processing complete. (#278)
NEW: A filter ‘document_serve_attachment’ is provided to review the attachment id being served. Return false to stop display. (#278)
NEW: A filter ‘document_show_in_rest’ is provided to display document data via the REST interface using document permissions. {#258, #259)
NEW: A tool is provided to validate the internal structure of all documents that the user can edit. If fixable then a button is displayed to fix it. (#260)
NEW: A user-oriented description may be entered for each document. This can be displayed with the Documents List shortcode and Latest Documents widget or their block equivalents. (#263)
NEW: These blocks can also display the featured image or generated image for PDF documents. (#264)
NEW: Blocks extended to support standard Colour and Fontsize attributes. (#264}
NEW: Revisions can be merged if made within a user-defined interval using filter ‘document_revisions_merge_revisions’ (Default 0 = No merging). (#263)
FIX: jQuery ready verb usage removed. (#262}
FIX: Caching strategy reviewed to ensure updates delivered to users. (#261}
FIX: Blocks used incorrect, but previously tolerated, parameter for RadioControls rendering them difficult to use.
FIX: Blocks are categorised within the Editor differently with WP 5.8
3.3.1
FIX: Content-Length header suppressed for HTTP/2 File Serve. (#254)
FIX: MOD_DEFLATE modifies etag, so no caching occurred in this case.
FIX: Gzip process invoked for encodings gzip, x-gzip and deflate.
3.3.0
SECURITY: Password-protected document can leak existence (by showing next/previous)
SECURITY: Queries on post_status do not do proper permissions check
SECURITY: Suppress excerpt output in feeds to stop information leakage
SECURITY: WP creates images when saving PDF documents (using the encoded name). These were being left when deleting the document.
NEW: Rewrite rules extended to access documents without year/month and/or file extension. (#253) @NeilWJames
NEW: Use standard WP process for Taxonomy workflow_state on Document Admin List. Note that it will change the column order seen as taxonomiees are on the end.
NEW: Implement Gutenberg Blocks for Shortcodes and Widget.
NEW: Integrate with either Edit-flow or PublishPress plugins
NEW: Taxonomy workflow_state is set as show_in_rest.
NEW: Add action ‘document_serve_done’ which can be use to delete decrypted files (needed for encrypted at rest files)
NEW: Add filter ‘document_buffer_size’ to define file writing buffer size (Default 0 = No buffering).
NEW: Add filter ‘document_output_sent_is_ok’ to serve file even if output already written.
NEW: Add filter ‘document_read_uses_read’ to use read_document capability (and not read) to read documents
NEW: Add filter ‘document_serve_use_gzip’ to determine if gzip should be used to serve file (subject to browser negotiation).
NEW: Add filter ‘document_serve’ to filter the file to be served (needed for encrypted at rest files)
NEW: New Crowdin updates (#244, #245)
FIX: Access to revisions when permalink structure not defined.
FIX: Design conflict with Elementor (#230) @NeilWJames
FIX: Document directory incorrect test for Absolute/Relative entry on Windows implementations
FIX: Document Taxonomies using default term counts will use same method as WORKFLOW_STATE, i.e. count all not-trashed documents
FIX: Ensure the action point to detect change in workflow_state worked (for CookBook functionality).
FIX: Fix error in time difference display when client and server are in different time zones
FIX: Fix WP 5.7 Breaking change (#38843) for Term Counts. (#250) @NeilWJames
FIX: Remove existing workaround for WP bug 16215 and long time fixed – and made information incorrect
FIX: Remove restore option on the current document and latest revision as it makes no sense.
FIX: Review document serving process to try to identify where other plugins could output text and corrupt file download
FIX: Review documentation. (#208) @NeilWJames
FIX: Review of Rewrite rules with/without trailing slash; also extend file extension length
FIX: Testing of blocks showed that if document taxonomies are changed, then existing blocks may not work. Some changes are now handled. (#217) @NeilWJames
FIX: Fixing compatibility issue with double slash in Documents URL when using WPML (#218) @BobbyKarabinakis
DEV: Update code to WP Coding Standards 2.2.1 (and fix new sniff errors)
DEV: Update coveralls to 2.2, dealerdirect/codesniffer to 0.6, phpunit/phpunit to 8.5 and wp/cli to 2.4.1
DEV: Rewrite Test library to increase code coverage.
Address technical debt for WP Document Standards (#192) @NeilWJames
On plugin activation, check that the user has edit_documents capability. If not, a warning message will be output that the menu may be incorrect. (#180) @NeilWJames
PHPCS review (#179) @NeilWJames
Bump phpunit/phpunit from 8.2.5 to 8.3.4 (#177) @dependabot-preview
Addresses phpunit and toolset versions and prepare for future release (#174) @NeilWJames
Version 3.2.2 gives an “property of non-object” at line 1403 on load (#161) @NeilWJames
3.2.3
Full phpcs 2.2 standardisation, complete filter documentation (#192) @NeilWJames
On plugin activation, admin warning if user doesn’t have edit_documents capability (#180) @NeilWJames
PHPCS Review (no functional changes) (#179) @NeilWJames
Review for WP Coding standard 2.1.1 and newer phpunit (#174) @NeilWJames
Bump version to V3.2.3 and Tested WP 5.2.2 (#174) @NeilWJames
3.2.2
Version 3.2.2 gives an “property of non-object” at line 1403 on load (#161) @NeilWJames
Add default capabilities only when they are absent. (#146) @NeilWJames
Unit tests now utilizes newer wordpress-tests framework, as recently adopted by core
serve_filenow hooks into template_include filter (rather than template_single) to prevent potential conflict with themes/plugins hooking into subsequent filters and producing extranous output after the document is served which would result in corrupting some files
Administrative CSS and Javascript files now versioned based on plugin version to allow for better caching
1.3.1
Better permalink support for draft and pending documents
Whenever possible browser will attempt to display documents in browser, rather than prompting with save as dialog (e.g., PDFs)
Fix for function get_file_type() breaking the global $post variable when no document argument is supplied
Improved Spanish translation with additional strings (special thanks, elarequi)
1.3
Plugin now includes unit tests to ensure security and stability, and undergoes extensive testing (WordPress 3.2/3.3/Trunk, Multisite/single, PHP 5.3/5.4) via continuous integration service Travis CI prior to release.
If you would like to help out by testing early releases, please try the continuously updated development version. Any feedback, technical or prose is helpful.
Added Spanish Translation Support (es_ES — special thanks to TradiArt)
Document URL slug (used for archive and prefixing all documents) now customizable via settings page and translatable. (e.g., http://domain.com/documentos/2012/04/test.txt rather than /documents/)
Subscribers and unauthenticated users no longer have the ability to read revisions by default (you can override this setting using the Members plugin.
Attempts to access unauthorized files now properly respond with HTTP code 403 (rather than 500 previously). Note: attempting to access private documents will continue to result in 404s.
Enhanced authentication prior to serving files now provides developers more granular control of permissions via serve_document_auth filter.
Better Edit Flow support (can now toggle document support on and off using native Edit Flow user interface). Note: You may need to manually toggle on custom status support for documents after upgrading.
Default document upload directory now honors WordPress-wide defaults and features enhanced multisite support
Ability to separate documents on server by site subfolder on multisite installs
1.2.4
Better support for custom document upload directories on multisite installs
Gallery, URL, and Media Library links now hidden from media upload popup when uploading revisions
Fix for plugin breaking media gallery when filtered by mimetype (MySQL ambiguity error)
Fix for upload new version button appearing for locked out users in WordPress 3.3
Fix for upload new version button not appearing after document lock override on WordPress 3.3
1.2.3
Owner metabox no longer displays if user does not have the ability to edit_others_documents
Fix for serving documents via SSL to Internet Explorer version 8 and earlier
GPL License now distributed with plugin
Code cleanup, minor bug fixes, and additional inline documentation
1.2.2
Plugin posted to Github if developers would like to fork and contribute
Documents shortcode now accepts additional parameters. See the FAQ for a full list.
Performance and scalability improvements to backend; files attached to documents are now excluded from media lists by join statements rather than subqueries
If plugin is unable to locate requested file on server, standard theme’s 404 template is served (rather than serving “404 — file not found” via wp_die() previously) and E_USER_NOTICE level error is thrown. Diagnostic information will be available via debug bar (if WP_DEBUG is enabled) or in the standard PHP error log
/documents/ now supports pagination
Support for linking to revisions with ugly permalinks
Custom post type’s has_archive property changed to true to help with theme compatibility
Fix for fatal error when user without read_document_revisions capability called wp_get_attachment_url() on file attached to a revision
Fix for broken permalink returned when get_permalink is called multiple times on the same document revision
Fix for wp_get_attachment_image_src returning broken URLs or the direct path to the document
Fix for “Call-time pass-by-reference has been deprecated” error when running certain versions of PHP
General code cleanup
1.2.1
French translation (Special thanks to Hubert CAMPAN)
Enhanced support for running on WAMP systems (XAMPP, etc.)
Improved integration with WordPress 3.3’s new upload handler
Significant performance improvements to verify_post_type() method
Document requests no longer canonically 301 redirect with a trailing slash
Fix for wp_get_attachment_url returning the attachment URL, rather than the document permalink when called directly
Menu item now reads “All Documents” (rather than simply “Documents”) for clarity
Fix for E_WARNING level error on edit-tags.php with custom taxonomies
Taxonomy counts (e.g., workflow states) now reflects non-published documents
Better translation support (see the FAQ if you are interested in translating the plugin into your language)
Compatibility fix for WordPress SEO’s “Clean Permalinks” mode
1.2
Added shortcode to display list of documents meeting specified criteria
Added shortcode to display a document’s revisions (formerly in code cookbook)
Added widget to display recently revised documents (formerly in code cookbook)
Created new global get_documents() and get_document_revisions() functions to help build and customize themes and plugins
Added filter to wp_get_attachment_url to force document/revision urls when attachments are queried directly
Better organization of plugin files within plugin folder
Fixed bug where revision summary would not display under certain circumstances
