Hi,
I'm a web developer new to MODx. A client of mine needs the FileLister Add-on modified to allow for files/directory descriptions along with a few other enhancements.
If I modify the Add-on directly, I assume that I will no longer be able to upgrade it when future updates are released. If my assumption is correct, is there a better way to make modifications that still allows future updates? Or is there even just a recommended way or best practices to follow when modifying Add-ons?
Thanks!
Lauren
Well, this depends on the Add-on.
If there is no other way, to extend the Add-ons-functinality to your needs, than hacking the code, it may be the best way to make your own extended copy of it.
If its on github or somewhere you can get a fork and do a pull-request with your additions.
Perhaps the developer wants to merge your additions.
Or you can ask the community, by desribing your requirements exactly, if there is allready another solution out there, which can handle your needs.
Thank you Bruno. That helps.
FileLister is hosted on github so it's likely that I'll end up doing what you suggested.
I've done quite a bit of digging already so I'm not sure there's a solution that will meet our needs *exactly*. FileLister seems to come the closest. Basically, I need to replicate Joomla's DOCman extension, which is what they're using now. So far I know that we'll need to extend FileLister's ability to include:
- file/folder descriptions to display to the user
- search (only file/folder names and descriptions)
If you (or anyone else) knows of an Add-on or Extension that provides exactly what FileLister does plus search capability and file/folder descriptions, let me know!
I've had such a positive experience with MODx so far---good documentation, friendly/responsive community---and I haven't even begun the project yet! Thanks again for your help. I appreciate it.
-
☆ A M B ☆
- 24,524 Posts
You might want to consider "static" resources. These have all the fields of a regular resource, but instead of having content they are served as the type of file you specify (such as .pdf or .doc). That way you get fields to search, as well as the option of using TVs for tagging. But a link to the page will load the file or offer it for download or whatever else is appropriate for that type of file.
-
☆ A M B ☆
- 24,524 Posts
Just as a matter of interest, to arrange for static PDF resources, you need to go to System->Content Types, and create a new content type for PDF files. The extension is .pdf, and the mime type is application/Pdf. I also check the Binary checkbox. Then I set the resource's content disposition to Attachment when setting the document type of the resource.
Doc files have a real mouthful of a mime type:
application/vnd.openxmlformats-officedocument.wordprocessingml.document
Thanks Susan. I had noticed static resources at one point but can't recall why I didn't consider them as an option. If using static resources meets my needs, I'd much rather use them versus modifying an Add-on. Thank you for pointing it out as a possible solution!
I did a quick count and there looks to be a little over 1,000 files. Am I correct in assuming that I could potentially script the static resource creation process, e.g. loop over files, creating a static resource in MODx for each file? With your experience, would you be able to say whether or not using static resources would still be a good fit with that many files?
1000 static Resources shouldn't be an issue.
The only thing would be the big Resource-Tree.
I think it should be possible to manage them all with a MIGXdb - TV or a MIGXdb - CMP
with some special processors and hide the static Resources from Resource-Tree
Also synchronising the static Resources with the file-folder should be possible to handle with MIGXdb.
Is there only one directory with all the files or do you have them in different directories?
-
☆ A M B ☆
- 24,524 Posts
I'll be doing something similar, using a specially modified variation of Articles, one Articles container for each product, with all of its related support documents and other files as children of the Articles container, and the children using the standard resource object rather than the customized Article child resource object. There will be a CMP to add a menu item to the main Manager menu, Add Product, that will collect some basic information then automatically create an Articles container as well as a Media Source and appropriate folders in the file system.
There are some 18,000 resources in the original Evo site, but many of these are weblinks to other resources with lists of links for downloading files. Using this method with Articles and static resources, along with a heavily keyword- and tag-based search instead of content-based search, I'll be able to drastically reduce the resource count (at least in the Tree) and completely eliminate the pages full of triple-chained select dropdowns that are right now all hard-coded with nasty Javascript and have to be manually edited every time there is a new product or a new resource for an existing product.
If I do want a page with these chained select drop-downs to provide a different entry point to the desired product's files and documentation, it'll be easy enough to build it automatically from the Articles containers using tag filters. And use a nice, neat JQuery AJAX plugin for it.
The really interesting part will be that these documents are supplied by another part of the organization in a different part of the world, so there is duplication and the need to update several locations with new or updated files. If the organization has a central repository for these files, a custom Media Source will make the redundancy unnecessary.
