The idea is to have a system that provides a layer to handle all files in Moodle, whether they are in the database or on the actual file system, or even just links to external resources. Once such a thing existed all the rest of Moodle could be re-engineered to use it. I think this combination would be absolutely dynamite.
Here's my dream-list of features:
- Written in PHP using ADOdb for database access
- Every "file" in the system has:
- metadata, using a site-defined schema
- versions, and information about each revision
- a primary author, and multiple co-authors
- read/write access control to users, group, class, site
- concurrent versions (eg different languages, or different resolutions)
- HTML files edited inline using HTML editor with spell-check etc
- Files are all user-based, not course based, so that a user can publish one of their documents in any course
- Each user sees their own files as a hierarchical file system
- Support for learning objects (import/export)
- Support for quotas per-user
- Support for WebDAV for downloading/uploading data
Have you thought about using existing content management systems? I run two sites using PostNuke (http://www.real-losers.com and http://www.mendhamnj.org). PostNuke has had some rough times in the last year but it seems the developers and leaders have gotten their act together. Some other suggestions include Xaraya (http://xaraya.com/index.php/news/c28/) which is being developed by PostNuke's old leader John Cox and the recently launched MD-Pro (http://www.maxdev.com/). All three are open source, written in PHP and I believe use ADOdb for database connection. As for your other requirements I am not sure - I am not that technical!
What I'm looking for is a backend product - an example of the sort of thing I'm talking about is Typo3 (try the demo). This product is probably too complex but it does demonstrate some of the more hardcore file handling I'm talking about.
(As a side note, the MD-Pro team have been looking at integrating Moodle into their project. )
I was about to suggest Typo3!
Fantastic product. I'm planning to use it along side Moodle. (Moodle for teaching resources, Typo3 for all other non-teaching related things)
If the two could be integrated, woopee, but as you say, Typo3 is probably a bit overly complex for the job.
Would it be easier to incorporate Moodle into it, rather than the other way around? PHPwebsite is designed to allow easy installation of modules. I think creating a Moodle Mod would basically involve removing different layers from moodle and placing their equivalent into phpwebsite. Everything you would need to create one can be seen in any one of the modules that are located in the "mod" directory. If you download phpwebsite and open the mod directory you will see them. There are only about six files that set up the db tables, permissions, interaction with other core mods, etc.. FYI, the Boost file and module is the one that performs the mod installation and integrations.
Since there are varied preferences and needs among Moodle users of whether to use a content management system or a portal ( but as you said, the differences are subtle) offering a Moodle Mod (while still maintaining a standalone Moodle) broadens the potential user base as well as the list of potential features. A Moodle Mod might allow for deployment into more of them by only slight changes to the mod itself. If my onion analogy applies correctly to this, there might be integrations to varying depths into the various portals/content mgmt systems depending on the complexity and their compatablility of their code. One portals/content mgmt system may be very compatable and allow deeper integration while another system would only integrate to a lesser degree. C'est la vie!
Phpwebsite is actually just another portal system / site management system... it and whether or not it is modular not really relevant here at all (look in moodle's mod directory and you'll see a simialar structure) ...
There is a big difference between a portal system and a real content management system (read my wishlist again, perhaps).
I know what Martin means about the distinction between portal and real Content Management System. However for those of us that also want to have websites, a portal type, or blog type "content management system" would also be a boon. There are two ways to go
1) Make moodle into a portal. It is nearly there. When the templates are a bit more configurable then a front page news forum will be as good or better than a blog. But as things stand, I would not want to run my website using Moodle.
2) Integration with a portal-type CMS (I hate to use the name, but that is what they call themselves).
I had a look around, at
Php Nuke: The most popular, but heavy and by accounts poorly/autocratically coded
Postnuke: popular PhpNuke breakaway with rewritten core, object oriented, cooperative, "the future of the web," Martin posts there and has posted a tip on linking the two user databases but still heavy and factional.
MD-Pro Max Dev's CMS. I know nothing about this community but Martin says above that are considering some sort of Moodle compatibability/linking.
LDU (land down under): a light one man, and in that sense a bit php-nuke like, much ligher cms with recommendation on a phpnuke vs. postnuke thread. Seemed convincing.
Phpwebsite: another light php nuke, looks fine, loads quicker than nukes, it seems.
Xoops: Popular in Japan Fairly heavy, I don't know much about this one but
E-Xoops: Is like the reverse of postnuke (in its relation to php nuke) in that it is a breakaway from its parent which has opting to be non-object orientated and not to rewrite the core.
Typo3 : Israeli? rather heavy but recommended and more like a real CMS
Others major players that I know nothing about include, eNvolution (looks nuke-like), e107 (likewise), lostnuke (postnuke branch), phpwebthings, ttcms, myPHPNuke, Mambo. There is PHPBB portal in the works and someone has made a new cms using PHPBB. See aloso google's mammoth list
But to be honest I need only the basics. I use Movable Type at the moment which is a blog. All it means is that I don't have to bother about linking up any new content I add. I just type it in, add an image, give it a category and press a button. The result is a page with built in forum-ish comment areas on each new page added. There are lots of blogs including the wonderful Movable Type, radio userland, and blogger (and again Moodle is really close to being a blog soft) but in php of merit there is
Serendipity (minor but light and has really good Wiki type functionality)
Wordpress (better naming, and cooperative and likely to expand)
pLog (only a few guys, but clever ones)
Nucleus (a blog which can be expanded)
Eventually I went for Nucleus after trying out demo sites. Serendipity and Wordpress were real alternatives but not so Japanese compatible. Nucleus like its name suggests is light - just a blog in its basic form - with lots of modular addons, such as emailable entries.
So I hope that Moodle becomes a portal/blogtype CMS or that it links up with one. Aside from the practical advantages, a link up might encourage a fresh injection of PHP wizardry.
But please, let's stay on topic here ... since the CMS term seems to be overloaded we should perhaps use the more specific term: "document management system" or DMS.
Now that the DMS discussion is elsewhere, is there any word on integrating Moodle with MaxDev? I can't find where Martin mentioned the fact that Max Dev may be aiming for moodle integration but I know he did. I promptly joined their mailing list, some time ago, but I have not heard anything from them regardind Moodle.
Personally, in my ignorance, I find myself unable to agree with "one thing the world doesn't need is yet another generic portal," because Moodle is so close to being able to provide portal functionality, that it seems a shame to have to install and master other systems. I am using Movable Type but it is making me sad because I am getting too much comment spam. Nucleus is okay too but...hmm...it does not provide much that Moodle can't do.
One of the biggest problems in using Moodle as a portal, for me, as it stands is that one click access is limited to the front page. So even if I made fake-courses (which are really website sections, or blogs, or blog categories) then people have to enroll or at least press Guest before click-through. Rumour has it that Guests will be allowed greater a degree of access in Moodle 1.2. Does anyone if it can be set up to allow complete transparent, i.e. open, clicking into courses?
And, why stick with educations management systems when would could have the world?
By the way, Moodle seems to be on line to be a big hit here at Yamaguchi University. There are going to be 350-500 students using it in 26 classes from September, aparently. I tremble at the thought.
as for PortalSystems - http://www.xaraya.com/ is comming - and it will be a big hit (very flexible, though robust),
and it is going to have mechanism to "import" postNuke's modules (probably Moodle as well). So some patience and around Christmas portal world will have some fun .
The ability to store the entire content of a website in the database and then manage it all online would be great for me and my assistant, who have to run the whole shebang, especially if it allows things like timed release and expiring of material and full control of the appearance through a decent templating system...but think about the librarian, when all she wants to do is post an occasional news article, or the captain of the student rugby team, who wants to put up a match report with a photo.
For them, a simple forms-driven interface where they can simply type (or cut and paste) their text in, and optionally upload a photo, is all they need. So something like that (with the ability to define who can post what and where, and whether or not it needs editorial approval) would be a valuable extra. Especially if the whole thing could make use of the pluggable authentication systems that moodle has.
I've had a good look at typo 3 and it seems pretty full-featured...but Waaaay over the top as far as ordinary users is concerned. One of the things we want to do is off-load the burden of routine updating of news pages, sports reports and so on....with something like typo 3 we'd end up with *more* work, as approximately 99.9% of our users wouldn't be able to use it.
We use Typo3 for our schoolportal (Sorry, in Dutch) http://www.hetstedelijk.nl
The trick is to trim its functionality down to the roles of the users you have in mind:
They range now from power-users to fill-only-that-one-topic-form-users.
We hired a Dutch company to help us with that.
That company (and the Typo3 platform also) looks now also at integrating eLearning in Typo3.
The Typo3 community first tried Claroline, because - they said - "Moodle did not support cohorts."
After that heavy trial they are now looking again (also: portfolio's for student users).
The rights-structure and tuning-options of Typo3 could help, but it is very complex.
One of the problems I still have with all these examaples of good CMS, is that they tear apart the "by-context-given-meaning-of-pieces" in a Moodle.
You end up - despite the many metadata annotations - with meaningless/senseless objects
In Moodle we have:
- Very interesting sets of resources+tasks+(later also scales?) in the sections of a Moodle.
- A combination of sections could "line-up" as an IMS/SCORM/Content Packaging outline/manifest
- a good CMS for Moodle should respect these logical organisation of Moodle-objects:
- A CMS, tuned for Moodle, must be able to translate an IMS/SCORM/CP into a Moodle course-backup-set
- Must be possible to export choosen sets the way we backup now courses
- Also interesting: create - leaning on this Moodle context-structure - a printable spin-off as a student-manual
- (in PDF, HTML, XHTML, HELP-formats etc..)
- Could be done in the way you now choose the objects for the backup.
- (integrating the free sources of a tool like: Aurigadoc?)
I know that it has a relatively nice front-end package available as well (aegir), but you are really looking for a back-end, yes? A CMS framework like midgard would suit better than a complete product then I guess.
Tiki's only real flaw at this time as far as a Curriculum M. System is that it lacks access control layer which is in fact being wrestled down right now.
Tiki also supports using other apps and having a wrapper envelope the other web app so that you are not aware that you are using another app while in Tiki...
Finally, Tiki is actively recruiting devs all of the time. Recruit early recruit often is the mantra there which is why it has grown so feature rich in so little time...That is the key really for OS success... the code has to be easy to understand and the door open to most everyone who makes an effort to contribute.
Tiki is a great app and well worth considering as a platform for moodle's modules...
Tiki is nice, I look at it also now and then for CMS: I like the way they offer services for normal teachers:
- store a picture (or other file) in the Tiki-galleries
- get under the picture a simple hyperlink you can cut and paste on your webpages..
I would *really* like to see some sort of version control in the file handling. Either actually or in spirit a kind of CVS interface for the files.
We have had situations where multiple people working on the same material have screwed each other up. As this is a well understood problem in software development it seems a shame not to have it in moodle material development.
I had a quick Google but couldn't come up with any quick PHP interfaces to CVS (or better yet a PHP native solution). I would be surprised if nobody has done it - I'll keep looking, particularly if this is interesting to anybody else.
While browsing through Hotscripts.com I stumbled upon ByteBoard and it reminded me about the document manager project. It's a file manager script that has chmod features, and document and folder sharing. It may or may not be useful, but I thought I'd pass it on.
see it at http://bytehoard.sourceforge.net/?features
I agree there is confusion over the term ... I've since been using "document management system" instead.