Tagged: document revisions Toggle Comment Threads | Keyboard Shortcuts

  • Ben Balter 12:13 am on June 14, 2011 Permalink | Reply
    Tags: document revisions,   

    Revision 1: This week I got revision logging and RSS roughed into place. 

    Revision 2: This week’s task was revision logging and RSS.

    Revision 3: I tangoed with the siren song that is $wp_rewrite and I lived to tell the tale.

    After a rather hairy ordeal with rewrite rules and its fellow temptress $wp_query, revision logging should be up and running, absent a few known bugs. Revision logs (read: “commit messages”) are stored in the post_excerpt field, and displayed in a custom meta box with the relative date, editor, message, and ability to restore each revision. This revision log is also available via a custom RSS feed.

    Still in the works is figuring out how to authenticate that feed (HTTP? Append a key / hash?), H/t Nacin for some hash-code inspiration; still have to refine the query that powers the feed.

    Next week has in store permalinks and public/private toggling, which should result in permalinks for each revision (e.g., foo-revision-3.doc)

    • Andrew Nacin 12:16 am on June 14, 2011 Permalink | Reply

      Most feed readers aren’t a fan of HTTP. And some require you to just hardcode the user/pass in the form of user:pass@domain.com.

      The hash works real well. We run it on WP.org and elsewhere. Check out this gist: https://gist.github.com/963d6e67a8b9736039f9. It also locks down wp-content/uploads, so you may derive some additional inspiration.

      • Benjamin J. Balter 1:30 am on June 14, 2011 Permalink | Reply

        Mr. Nacin, thank you for the gist. Implemented both the hash code and the beefed up my serve_file function with some inspiration from ms-file.php

  • Ben Balter 12:06 pm on June 6, 2011 Permalink | Reply
    Tags: document revisions,   

    It’s been a productive week over here on team Document Revisions. The goal was to tackle the core of the plugin, upload handling and revisioning, and things are on track and looking good.
    • Moved admin functions to a separate include file
    • Created option to store documents in a folder other than wp-content/uploads, such as a folder above htdocs or public_html for greater security
    • Plugin now rewrites all document filenames on upload to a md5 hash so they cannot be accessed directly
    • Added lots of in-line comment goodness
    • Internationalized strings
    • Took an initial pass at JavaScript to automatically close the media upload box upon successful upload
    • Lots of bugfixes and general code improvement
     In addition to further refining the above, next on the chopping block is maturing the revision log and looking into creating an RSS feed or two. You’re more than welcome to grab the code and code and kick the tires. Things are still a bit rough, but the core functionality is should be there.
  • Ben Balter 2:05 am on May 31, 2011 Permalink | Reply
    Tags: document revisions,   

    Made some great strides this week. I created the document revisions class as well as a handful of helper functions used to manage revisions. The custom post type registration is done as is a rough pass of the edit document screen including a couple of custom metaboxes. I also took an initial pass at rewrites and permalinks. All in all, although rough, the plugin’s basic functionality is there. Next up is file uploading and revisioning, which may require some creative JavaScript to handle the post-upload dialog.

  • Ben Balter 11:41 am on May 23, 2011 Permalink | Reply
    Tags: document revisions,   

    Coding officially begins today. I have a shiny new dev environment set up and pulling directly from SVN. I added each week’s task to the project’s Trac. The scope/approach has been finalized, and the few concerns we had about security and IA have been, for the most part, quelled. It looks like I may actually be a bit ahead of schedule, per the project timeline, but look forward to using the opportunity to get a head start setting up the custom post types, and anticipating some challenges I may have down the road.

    The first challenge I know of is the ability to close the media upload dialog, once a document has been successfully uploaded (as the normally post-upload options, e.g., description, caption, etc., are not necessary). I’ve been able to stuff some javascript into an unrelated filter, but it’s not pretty. Going to continue to discuss the issue with my mentors, but anyone have any insight/experience with this?

  • Ben Balter 12:00 pm on May 16, 2011 Permalink | Reply
    Tags: document revisions,   

    Document Revisions Security and IA 

    Had some great discussions this past week with mentors and other assorted devs in the IRC chat. Two big components that have seen a lot of refinements this week were security and IA.


    Given the target audience, security is a top priority. As it stands now, out of the box, document revisions would store files as standard uploads in the /wp-content/uploads/year/month/ folder. Because this folder is accessible to the world, each file is renamed to an MD5 hash that only WordPress knows. WordPress would transparently convert that hash (e.g., /wp-content/uploads/2011/05/asdf1234.doc) to a custom post type permalink which would run through the standard rewrite system (e.g., /documents/2011/05/memo.doc). This way, all requests for the file (which would be a permalink to the latest revision), would be authenticated against WordPress’s normal privileges. Files can be made public/private using the visibility setting in the top right of the standard edit page. As an added layer of security, the upload destination can be optionally moved to a folder outside of the server’s web root, thus ensuring that files cannot be accessed without the proper privileges.

    Information Architecture

    The other big hurdle was ensuring that document revisions was both scalable, and had a minuscule footprint. Each document is going to be treated as a custom post type. The majority of the custom post type IA / functionality will be used as it is intended (author, post_parent for revisions, date for modified, etc.). Each revision of a document will be uploaded as an attachment (using the standard media uploader), and will generate a post revision. Document title will become post_title, the true path to the revision (see above) will be the post_content (with no editor box), and the revision log message will be the post_excerpt. This way, the plugin can in theory handle a near limitless number of documents, while at the same time introducing no additional metafields, tables, or substantial drain on the database if the server is also a public-facing web server.

    Things are coming together quickly, and can’t wait to sit down and begin coding soon.

  • Ben Balter 6:09 am on May 9, 2011 Permalink | Reply
    Tags: document revisions,   

    I shared my proof-of-concept mockup with my mentors this week and have been getting lots of great feedback on my approach. As a result, I have been further refining things both on a conceptual and a technical level.

    I’ve also been talking the project up a lot, and have heard nothing but positive feedback from folks. People in the community seem genuinely excited by the prospect of bringing WordPress’s rock-solid reputation to the world of document management and collaboration, and I never realized the project’s widespread applicability.

    I’ve included a brief wireframe above, which hopefully can better express where I hope the project would go, but more importantly, I would love your feedback. The idea would be to have a revision log, similar to what many of us are used to seeing in Trac, and a quick metabox with the link to download the latest version or upload a new one. Otherwise, should be nearly identical to the experience of authoring a post or page. Thoughts?

    • scribu 11:25 am on May 10, 2011 Permalink | Reply

      The thing I never understood is why this project is labeled as document management, when it could easily be generalized to all attachments.

      Media overhaul anyone? 🙂

      • Benjamin J. Balter 2:37 pm on May 10, 2011 Permalink | Reply

        Document revisions may be a bit under inclusive. In theory, the process should be format-neutral, the only limitation would be allowed upload types.

        A full-fledged media overhaul would be awesome, but may be beyond the scope of what can be tackled in a single GSoC project… The two big things I’d see, to make this more core than a plugin would be A) beefing up attachment.php to the above / merging it with edit.php and B) some sort of IA to store revisions (I believe the attachment parent now is the post to which is attached, no? That may make natively storing child attachments a bit trickier).

        • Jane Wells 2:41 pm on May 10, 2011 Permalink

          “beyond the scope of what can be tackled in a single GSoC project” << Yes, especially since it's not the project we accepted. Stick to your guns, and listen to your mentors above all others; they were hand-picked for each student with great care. 🙂

        • scribu 5:34 pm on May 10, 2011 Permalink

          Congrats, you just passed the derailment test. 🙂 (I just made that up)

        • Benjamin J. Balter 2:52 pm on May 13, 2011 Permalink

          Look at that. Not a single line of code and the projects already passing all its tests!
          If you have any suggestions for a better / more descriptive name, would love to hear ’em.

    • Daniel Bachhuber 12:28 pm on May 10, 2011 Permalink | Reply

      Will users be able to view the documents within WordPress, or will they be required to download them? I don’t know how insane the former would be, but I can see us needing to view documents more often than making changes to them

      • Benjamin J. Balter 2:40 pm on May 10, 2011 Permalink | Reply

        Really would love to keep it as format-neutral as possible to keep it widely applicable. Sure some basic support for viewing common image-types should be simple enough, but how would you view/format a .docx? PDF? PSD? Some sort of integration with Scribd / Google down the line would be pretty slick. Perhaps I can put in a handful of API hooks and let people adapt to their own use case?

  • Ben Balter 2:00 pm on May 2, 2011 Permalink | Reply
    Tags: document revisions,   

    And So It Begins… 

    This past week, my mentors and I had a very productive call in which we further refined the project scope and timeline, crystalized our overall vision for the plugin, and worked through some of the logistics for the summer (communication, etc.). Mitcho, Jon, and Aaron are all incredibly talented WordPress development connoisseurs and I look forward to learning a lot from them this summer.

    I spun up an AWS instance to serve as The Official WP Document Revisions Proving Grounds (a.k.a. a sandbox). The dev. environment syncs nightly off of WordPress trunk and the plugin’s repository on WordPress.org (a simple cron job / php frontend to run svn up on demand — let me know if you want the code). I also committed the plugin header and a readme placeholder. Feel free to follow along with the development log (or subscribe to these updates via rss).

    • Stas Sușcov 4:27 pm on May 2, 2011 Permalink | Reply

      All cool, but I think you rushed out a bit 🙂
      From last year, I remember we all had gsoc svn+trac repos for our projects, so I think it’s the best to wait for Jane’s/Barry’s email with those details, else you will have to migrate your repo ( I think @scribu had a nice svn migration script btw).

      Also I think the reports are mandatory starting only with the coding period (late May). Bonding period doesn’t require weekly reports (but I might be wrong, sorry if so).

      Anyway, nice job on integration part 😉

  • Ben Balter 2:01 pm on April 27, 2011 Permalink | Reply
    Tags: document revisions, ,   

    Hi, I’m Ben. 

    Hi everyone. I’m Ben Balter. This summer I’m hoping to inject document revision support into WordPress to facilitate the use of WordPress as an internal collaboration tool, not only for content publication, but for all sorts of content collaboration — text documents, spreadsheets, images, PDFs, sheet music — whatever you can throw at it. With some luck, this push can help make WordPress a bit more friendly for enterprise and government environments.

    About Me
    I’m a J.D./M.B.A. candidate at the George Washington University, a new media fanatic passionate about the power of digital communications, and an information junkie who loves learning new things. Concurrent with my studies, I have been a New Media Fellow, in the Federal Communications Commission’s Office of the Managing Director, where I help to oversee the relaunch of the agency’s multi-platform web presence, and am in the process of submitting a note to the Public Contract Law Journal, arguing that federal IT procurement practices should be made more amenable to more modern, agile software development methods.

    Why WordPress
    When not working or in class, I enjoy tackling otherwise-impossible challenges to sharing information using nothing more than WordPress, duct tape, and occasionally a pack of bubblegum. I’d argue that my biggest claim to fame, at least in terms of all things WordPress, is teaching core commiter Andrew Nacin everything he knows about WordPress (at least until he started teaching me). An aspiring attorney, a coder, and an all around geek, I look forward to bringing my life-long passion for technology’s ability to shape how we interact with one another to the WordPress–Google Summer of Code world.

    Why Document Revisioning
    Sexy topic, I know, right? Here’s the deal: as a member of DC’s government new media community, it is clear to me that WordPress and government just makes sense. At the same time, what is unclear to me is why WordPress has yet to take foothold in our nation’s capital.1 Government was once at the forefront of cutting-edge information technology. The first computers to see application beyond a university lab were employed by forward-thinking government agencies. Yet somewhere in the past half century government IT has fallen far behind not only the private sector from which it often seeks innovation, but the open source community as well.

    Providing WordPress with document management and version control functionality, combined with its already stellar usability can uniquely position the CMS as an integral part of any agency or firm’s workflow and thus the clear choice for any government and enterprise deployment.

    Want to learn more about my project? Check out my application, or read my post “When All You Have is a Pair of Bolt Cutters…

    I sincerely hope that this can serve as the start of a summer-long dialog. I’d love to hear your thoughts, so feel free to leave a comment below, heckle me on Twitter, or contact me directly.


    1. These are my personal views and not the views of any employer or any corporate-types that may or may not have left a briefcase of money next to me at a coffee shop last week. Honest.
Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc