Can you check which version you are running? (Can be seen from the configuration panel for blocks: yourserver/moodle/admin/blocks.php )
I believe it might have something to do with that. TIA
Same problem as with the PhotoFrame module: it might seem easier at first to start with an existing php application and rework it to make it compatible with Moodle, but in the long run this has proven not to be the correct way of doing things: you end up having to rewrite most of the code (using Moodle functions) just to make some small modifications.
It will not be possible to take out all the bugs and shortcomings (which it has, I am no longer using the block myself because it was to hard to maintain)
I could make a 1.5 version of this block using Jon's excellent documentation, but then it won't take advantage of all the other niceties the revamped block code allows (edit icon, more than one block allowed, etc....) so I hesitate to do so.
I believe your best bet is to wait for the datamodule to arrive.
I second this....
I am slowly replacing the bookmarks block with a new glossary format. Students add links to a link collection. They can categorize them, comment on other's links, etc.. A teacher can grade them, approve them so they really become part of the course, new links in the link collection show up in the recent activity, etc...
I have added an extra field 'url' to the glossary module. It is optional, but I have the feeling that it might be useful for other uses of the glossary module as well.
Unfortunately this involves some changes in the core of the glossary code that can't be made inside the glossary format, so it's not exactly a 'plugin'.
As for new links showing up in the recent activity, does it work for items that need to be approved by the teacher? There's a bug related to this (bug 2985) that doesn't seem to have been fixed yet.
Right now it's a glossary format + a collection of hacks necessary to add an extra field for the url. I want to have a look at an easier way to install it. I can send you the code if you want to try it out.
I'm with my eyes opened looking for any progress.
PLS let me know if you do it.
It's just not worth it. Adding an extra field url to the glossary_entries table requires people making changes to the backup/restore code / the edit.php and edit.html files... and all these changes will break next time you upgrade your moodle.
The only solution to make it an independent glossary format which doesn't need an extra field added to the database, is by storing the url inside the definition. But then users would have to fill in the concept and definition fields like this:
Concept: Google Definition: [url=http://www.google.com] Search engine
This is not intuitive. You have the same situation when using the glossary for maintaining FAQ's: you have to tell the user that the concept field holds the question and the definition field holds the answer. Needing an extra field just makes it worse.
There are a lot of examples of people using the glossary module in very creative ways: FAQ's, poetry collections, book reviews, ...
It would be nice if the form where you add the entry could reflect the glossary format instead of having the standard concept / definition pair.
A way to make the glossary formats more flexible, would be to add classes/methods to the glossary code.
That way you could have a method displayform which depending on the glossaryformat would print:
Concept: ____ Definition: ______
Picture title: _____ Description:____
Question:____ Answer: _____
Title: ____ URL: _____ Description: _____
with some code that glues the url and description fields together in one big field. That means backup / restore code don't need to be altered.
The new structure of the assignment module or the resource module is really great. I sure hope one of the moodle developers will find the time someday to add this kind of structure to the glossary module as well. Until then, sorry, you're out of luck.
I can send you the files I sent to Julian and Jon, if you are willing to have a try at improving it.
I'm grateful for receive these files.
Your idea is very interesting: Not just make a glossary for a single format. Make a flexible glossary format where you can define the fields in the glossary. I like it.
where you can define the fields in the glossary
I guess this would be overkill. The datamodule in 1.6 will allow user defined fields.
I would already be happy if glossary formats could override the names of the concept and definition field. That way you no longer have to tell users that what they have to enter in the concept field is actually the title of the poem, or the question they have, etc...
I've sent you the files.