Tag API 3 Specification
Tag API 3
See also MDL-50851
Summary
This is designed to make the Tag API in Moodle more flexible. The main changes:
- allow to use different tag collections for different tag areas (for example, user interests would be a completely different set of keywords than blog posts)
- allow to enable/disable tagging in individual areas, not just one-for-all global $CFG->usetags setting
- introduce callbacks in the components that will be responsible for displaying entries related to the tag
Other possible future changes:
- split block_tags into block_tags and block_coursetags - it serves two completely different purposes now
- block_tags should be able to display tag cloud from one tag collection only and also only tags used in specific context (course/module/etc)
- improve "Manage tags" interface - it definitely needs some upgrade to 21st century
- introduce templates for tag cloud and tag list
Implementation
There are two new DB tables: tag_collection and tag_area
The unque index on table {tag} that used to have only tag name now contains tag collection id and tag name
Each plugin can define plugindir/db/tag.php that would contain the list of the tag areas and, if needed, completely isolated tag collections. They are registered in tables tag_area and tag_collection. Manager can create more collections, allocate tag areas to them and also enable/disable each tag area independently.
When developer wants to check if the tag area is enabled, they should call
core_tag::is_enabled($itemtype, $component);
for example: core_tag::is_enabled('user', 'core') or core_tag::is_enabled('wiki_pages', 'mod_wiki')
In order to add a form element to the moodleform developer also needs to specify the itemtype and component:
$mform->addElement('tags', 'tags', get_string('tags'), array('itemtype' => 'post', 'component' => 'core'));
Functions tag_set_tags(), tag_get_tags_array(), tag_get_tags(), tag_get_tag_csv(), tag_get_related_tags(), tag_get_related_tags_csv(), etc. will continue working and don't need changes.
Functions tag_find_records(), will be deprecated because it needs another required argument and it is not good to add it after the optional arguments.
Lots of tag-related functions will be deprecated because they require more arguments but good news is that plugins don't really need to use them and they are already defined in tag/lib as "access private": tag_type_set(), tag_description_set(), tag_get(), tag_get_id(), tag_rename(), tag_assign(), tag_autocomplete(), tag_record_count(), tag_record_tagged_with(), tag_set_flag(), etc. The complete list will be published later
