After playing with several Drupal installations, I have my first real project to work on. I am finding a real-world example makes all the difference when it comes to really learning how Drupal works, although that should come as no surprise. I have been reluctant to track my progress on this site here, simply because it is an extra step and I have only so much time to work on things. I rethought this as I found myself returning to previous posts, like this one, when it was time to do another dotProject installation. I decided it might be valuable to do especially because modules in Drupal seem to multiply like cottontails after a wet spring.
This project is good because it is limited in scope and the site owner is fairly relaxed as to schedule, which is excellent. The site will look like a regular website until the user, either a Teacher (content creator) or Parent (content reader, commenter), logs in. Then, users will land on home page with the latest updated content, and from there a Parent will be able to click on a page with a list of all content that references their child; search for other content based on other children’s names; and have access to their child’s progress reports. That child’s Parent and the Teacher should be the only ones that have access to this information. There will also be an area for downloading forms or other documents, and a school calendar/syllabus combined.
That is the english version. In modified Drupal-speak, the site needs to:
- Present like a regular site to the unregistered user; with no access to updated material like blogs.
- Present different homepages for anonymous and logged in users.
- Present different blocks for different roles.
- Present different menu items for different roles.
- Allow for uploading, embedding, and possibly captioning images in posts.
- Allow for creating nodes based on taxonomies.
- Allow for access to nodes by a single user.
- Have a calendar.
After playing around a bit, I think I have figured out what I can and cannot do from the above list with the standard core installation. It is now time to think about modules. I’m sure that I might end up with some duplication as I wade out and try to figure out what is and is not going to work; in any case modules will be the subject of Part II.
Here is the location of my test site.
BTW, I’m happy to announce that the very first module I installed was the brand-spankin’ new Update Status for Drupal 5 by Merlinofchaos. Thanks, Earl!
For a calendar, you can choose event.module or CCK + Views + calendar.modulle.
For access to individual nodes by a user, access modules in Drupal 5 are still catching up. Start with tac_lite and see if it’s up to the task. It may not be.
There are a LOT of choices for uploading images into posts. CCK + imagefield + imagecache can be very good, but will require a little bit of extra work. I’ve done something along those lines and I’ve been meaning to post a recipe for doing so. webchick has posted a recipe for something along those lines as well over at the lullabot site.
Presenting different menu items for different roles is clearly the most difficult part in Drupal right now; the menu system is annoyingly inflexible for that application.
Presenting different blocks for different roles, however, isn’t quite so bad. You’ll use the block visibility settings a lot, and test $user->roles.
Different homepages can be accomplished using the front_page module; different look can be accomplished using a very very short custom module to switch themes based upon existence of a role.
Hope that helps!
Thank you, you are my hero! I had managed to download every module you recommended except for image cache, I think, plus a few extra, but I was unaware of the particular combinations you mentioned. You saved me a lot of time!
Update status is working perfectly so far, by the way.