MODX as a document management system

guys - thanks so much for your input and ideas. Thinking about all the other features and ideas this client portal needs it seems to me that automatically setting the appropriate settings for every file is going to be really hard.

I have come full circle with it a bit really and to be perfectly honest I can't see the problem with assigning a static resource to each document manually. If they upload all the documents via ftp it takes only a few seconds to assign them to a static resource and you then have massive control and they can attach further information to those resources and so we can build a simple version control system as well. Sottwells solution to storing them outside of the web root is ideal and seems like the perfect solution. (Thank you!)

I have gone back to the client with this - so hopefully they will agree its the best solution!

I will keep you posted with what happens!

Susan, this is a great tutorial.

I'm wondering how I could avoid getting the user to add [[$pathPrefix]] before each doc path.

Either

1. Modify the form to have [[$pathPrefix]] as the default
2. add [[$pathPrefix]] when the resource renders

I've been working on adding the path prefix from the Media Source on processing the resource, but there's a big problem. Binary static resources are pulled out of normal processing and their content re-loaded. Then the content is processed, appropriate headers for streaming content are set, and the file is streamed. The only event available is the OnParseDocument event, but it is run each time the page is sent through the parser, so trying to modify the content with that event is proving a bit awkward - it adds the path prefix each time through. I haven't yet figured out how to code the plugin to only add the path prefix if it's not already there.

You could automatically add the prefix path to the content using OnBeforeDocFormSave, thus saving the full path, if you are positive that it will never change. I would prefer to automatically add the chunk tag to the content instead; that way if the media source path is ever changed you only need to edit the chunk.

I spoke with some of the people responsible for the handling of media sources for static elements, and they were surprised that it wasn't also applied to static resources. They were of the opinion that this definitely needed to be taken care of, so all of this twisting around may not be necessary for much longer. I think I understand how it should be done, but this would involve adding another field to the site_content table to store the media source ID, as well as modifying the resource editing page to add the Media Source select drop-down. Then the modStaticResource class would have to be modified to check for a media source, and apply its path if one was indicated in the database. All of this would also require changes to the setup and upgrade scripts, so it's all a bit daunting for me to try to tackle on my own.

Ok, it's not mission critical. Your initial proposal enables me to create a much better document portal than I would otherwise have managed so I can wait to gild the Lilly.