pdf download listings
I need a way to distribute pdf downloads for a school:
· teachers are using IMCE for file management
· I have a 'downloads' folder-structure which has ten parent categories
· in each of these there are three or four subcategories
· each subcategory has an english and spanish folder
If teachers need to upload pdf files, it is easy for them to do so in an organised way.
This is VERY important. Eventually we'll have thousands of pdf files which will be continuously updated.
So they HAVE to be stored in an organised hierarchy of folders.
However, I'm totally stuck with the next bits:
1)
Each download would have: filename, description, filesize, filetype, date.
How would the teachers get all that information into the node(s) in a consistent way?
2)
How would users browse for the files?
They'd need to start off looking at the ten top categories, and somehow drill down to the file they wanted.
Cheers.
I would not use IMCE for
I would not use IMCE for this. You should use Taxonomy to organize your files. Use CCK and make a file node type. Add a file field to it and whatever else you need. Then make an associated vocabulary with terms to organize your new "file" node type. Then it's a simple matter to use views to pull lists of files in any way you want.
Yep-- this is what I did and
Yep-- this is what I did and it works quite well. Also, if you don't want the files accessible directly via the URL, you can use the http://drupal.org/project/dwnld or http://drupal.org/project/private_upload modules. Another handy module for this is the http://drupal.org/project/download_count module, but that works best with the core upload module (which also works well for this application in combination with the http://drupal.org/project/uploadpath module).
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
Thanks for your
Thanks for your replies.
I'll try using the core upload and upload path with a 'download' content-type and a 'download' vocabulary. I don't know how it will all come together, but there is no use trying to struggle against 'the drupal way'. Conceptually, this is extremely far away from having a traditional 'download section' script handle files.
For the moment, I envisage one node for each of the main 'categories'. This node's body explains generally what 'section' this is: office admin, monthly bulletins, excursion forms, parent handbooks, school policies, staff induction, inspection reports, prospectus, etc. (I know I could have one node per file attachment, but it seems ridiculous to do it that way - it would be an enormous amount of extra work and confusion).
Then I'll have multiple attachments at the bottom of the node, with filename and size. Apparently the 'upload path' module can append the filename with the date of the file when it is uploaded. So all that is missing, that I'd expect from a proper download script, is a description of each individual file, and information about who uploaded it.
Replacing updated files is easy enough, so that's ok.
The two things which I can't imagine working are:
1)
What happens when a node has 50-100 attachments. With a proper download script, I could have as many sub-categories as I liked, and the user would drill down to the one they wanted. So those 100 files could be placed in ten separate subcats, with only ten files in each. I don't see how to do that if I use a node to 'contain' a section of files. Again, I'm not prepared to create a node for every single download - that would be insane.
2)
How I'm actually going to display these nodes. I'm still a woolly about taxonomy and content-types.
If I had a 'downloads' button on my menu, what would it actually point to? How could a user drill through the taxonomy levels to find the file they wanted?
Eg. Downloads > office admin > finance > fees > bank-draft.pdf
I'm talking about a thousand documents. How will users find what they need?
Thanks for any further advice.
EDITS:
3)
One other small problem. Uploaded file names have spaces changed into underscores. What is doing that, and can I change it to hyphens instead, or turn off that behaviour and leave the spaces (like my old CMS used to do)?
Most (if not all) of your
Most (if not all) of your questions/problems here can be solved by using the suggestions given. Do not use 1 node for a category and attach 100 files to it. This is not manageable.
Use 1 node per file. This is not insane. This is exactly what drupal does and does very well. Use the upload/attachment method of your choice to associate a file with a node (several have been suggested). Allow these "file" nodes to be categorized however you need. Unless you are planning on letting general users have access to your server's file system (very bad idea), this is the way.
Uses the Views module or the core taxonomy module to "display" these "file nodes" however you need. If you use views you can use exposed filters and users can find what they want quickly.
Edit
In reference to your last problem. Maybe somebody else can give you an answer, but I do not see why it matters. Spaces in file names on web servers are bad juju. There even was a time before Uncle Bill and MS when they were not allowed on virtually any computer system. Converting spaces keeps the file names "safe" and it should not matter what the file is named on the server so long as the server "serves" the the file that the user wants. They can rename it to anything they like once the get it anyway. By making nodes for each file you can store all sorts of additional information, like a description, and this makes the physical file name rather inconsequential.
Thanks for your reply. > Use
Thanks for your reply.
> Use 1 node per file. This is not insane
Debatable ;)
Uploading/attaching ten or twenty files to one 'category' node will be much, much faster than creating each node individually. And it makes updating them much easier too; I only have to open one node, and can delete all the outdated files in one click, ready to upload the updated ones.
I don't quite understand the distinction between having ten separate downloads each 'associated' with one node, and having one node with ten downloads attached. I mean, how is having 'one node = one file' going to help the user start off with ten parent categories and drill down until they find the file they need? I just can't conceptually imagine how drupal can do this?
Currently my e107 downloads structure looks like this:
bulletins (0)
- parent bulletins (0)
-- english (12)
-- spanish (12)
- parents committee (51)
- staff bulletins (40)
handbooks (0)
- parent handbooks
-- primary
--- english (6)
--- spanish (6)
-- secondary
--- english (6)
--- spanish (6)
- staff handbooks
-- english (20)
-- spanish (20)
etc.
There are ten top-categories. Users see a tabled list of these when they go to the download area, and then they 'drill' down from the top level until they reach what they need; exactly like you do in windows explorer. I just can't see how drupal can do this, even if I do use one node per file?
> I do not see why it matters. Spaces in file names on web servers are bad juju
Sure, but I'd rather have hyphens than underscores though, but don't see where to change it,
or even which part of Drupal is doing it.
Thanks for your help and patience.
You have already described
You have already described several problems with having 50-100 files attached to 1 node. Problems such as sub-categorization and so on. Here is another one for you: What if you wanted to list all the files alphabetically in a category? How would you achieve this? Would you delete all 100 files from the node and the re-upload them in alphabetical order? What if tomorrow you wanted to order them by size? Would you re-upload them again in that order? Do whatever you want. I have no opinion on how you should design your site. I will try one last time to explain the suggestions given and why I think they are valid.
Nobody suggested associating 10 downloads with one node. The suggestion was to create a content type for the files and then associate them with Taxonomy Terms to categorize them.
This has a nice little added benefit. What do you do if you accidentally upload the file to the wrong "category node" in your design? Well you get to delete it and re-upload it to the right one. In the suggested design all you do is go to the file node, use the drop down selector and re-term the "file node" and it is recategorized. Which one is simpler?
What if down the road (I know this never happens but bear with me) you decide you want 10 more categories and/or 25 new sub-categories and some of your existing files need to get moved to those categories/sub-categories? Well in the design you describe we get to do some more deleting and some more uploading. Boy that sounds manageable. In the design suggested you once again only have to re-term the existing files.
What if 23 of the 100 files in a category are only to be shown to a certain user group? How does your design achieve this if they are all attached to the same node? The suggested design would allow you to put a file in multiple categories (say it isn't so) and then by using a module like Taxonomy Access you could set view permissions on those additional terms by user groups, thereby allowing only certain users to access certain files.
What if a file name is horrible (I know this never happens either but......) like myfile923y4983274.pdf? Very user friendly that is. Nodes have titles. We could give that "file node" a title of "Directions on how to use content types and Taxonomy to create an organized and manageable document storage system". Now that actually is user friendly. We could even have a description field that further tells us what the document contains. Pretty nifty huh? Here is the frosting on the cake. When we need to replace the file, we only need to replace the file. The title, the description, the picture, the (insert other info here) is always preserved for us. Not only that but this other data is able to be indexed, not only by drupal's search but by public search engines (you know google, yahoo, msn, etc...). Search engines do not bother with the contents of files so good luck if we want them to show them to people who are looking for them.
Still think it's debatable ;)?
I forgot to answer this: I
I forgot to answer this:
Because that is exactly what Taxonomy is all about. You show a list of taxonomy terms (categories). User clicks on a term. List of sub-terms (sub-categories) is shown. User clicks on sub-term. List of files is shown. User clicks on file and server serves file to user. You can make this structure as simple or complex as you like. It can be hierarchal, flat, have multiple hierarchies, files can be in as many categories as you like etc... This concept goes on and on.
Thank you very much for your
Thank you very much for your verbose reply. It really helped me to understand the long term benefits of creating each download as a node, even though creating them will take much longer.
> because that is exactly what Taxonomy is all about.
> You show a list of taxonomy terms (categories).
> User clicks on a term. List of sub-terms (sub-categories) is shown.
> User clicks on sub-term. List of files is shown
That's exactly what I need, but how do you do that? I wouldn't even know how to begin. If I had a content-type and a vocabulary called 'download', how would I list the ten parent terms (mentioned above) within that vocab? What would the list look? Would there be a description of each parent? Could the user see what children were inside before clicking on a parent?
And if a user then clicked a parent, how would I make drupal list the child terms within?
My only experience with taxonomy has been to tag a node with a term. Then when the node is displayed, the tag is listed in the node. When clicked, it takes you to a teaser-list of nodes which are tagged with that term. I don't see how to achieve the 'drilling down' through the terms as you describe. It would be great if you could briefly explain that.
Cheers.
this is actually quite
this is actually quite simple-- it's done with a view that uses arguments and a default summary view. Take a look at this quick little video to see it in action (it's not with files, but the principles are the same): http://drupal.org/node/247205. You might need to use the http://drupal.org/project/lineage module as well.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
yup
For full taxonomy drill-down (Yahoo Category-like) try taxonomy_context.module.
Agreed with everything said here - for document management, you need per-file metadata, and that is by node.
Later you get cool wins by using the filters to, eg show only things tagged as Spanish, Only PDFs, All Maths from 2009, etc.
Uploads will feel a little slower, yes, although there are tools to help that.
Importantly however, it means the data you input will actually be checked and relevant, rather than a bunch of files dropped one-time in an unlabelled bag.
If you are looking at hundreds, and are uncomfortable with the file naming and flat file repository (I would be!) look for
http://drupal.org/project/uploadpath or
http://drupal.org/project/filefield_paths
and tune that up a bit before you go uploading heaps. That lets you sort out a naming/folder convention using the metadata you should be tagging the files with win-win!
.dan.
if you are asking a question you think should be documented, please provide a link to the handbook where you think the answer should be found.
| http://www.coders.co.nz/ |
I just can't conceptually
What you describe above could be easily done in drupal with summary views if you use 1 node per file and taxonomy for the categories. Also, you could have the added benefit of using taxonomy_image if you want to associate pictures/icons with your different terms-- it makes drill down views very functional and attractive.
Obviously, you can do it whatever way you want-- but i've often found in the past, through real experience, fighting the 'drupal way' of doing something ends up being a mistake that takes a lot of time and effort to fix at some point down the road.
Also, the '1 node to 1 file' structure isn't really a drupal thing (though the 'node' term is)-- it's how document management has always been handled. One set of metadata to one file.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
OK, I've downloaded views2,
OK, I've downloaded views2, and have been messing around with it.
I'll start another thread with views specific questions toward obtaining my goal.
Thanks for everyone's help and patience.