Problem/Motivation

As discussed in #1349794: [META] Allow for vocabulary selection & term autocomplete, one motivation for allowing the import of external definitions is so that the definitions can stay up to date without any intervention from module maintainers or site admins. However, currently the site admin needs to use drush or remove the row from the cache to refresh..

Proposed resolution

Add a one week expiration on vocabularies by default.

It might make sense to automate this on cron as well, so that if the import url can be accessed when cron is running, it replaces what is there. If it can't be accessed, then the old version stays. We could potentially allow for vocabulary-by-vocabulary configuration of expiration at regular intervals, but I think this would hinder user experience, not help it.

Remaining tasks

Implementation.

User interface changes

A refresh button will be added to admin/config/services/microdata/vocabularies.

CommentFileSizeAuthor
#1 microdata-refresh-cached-vocabs-1349886-1.patch6.51 KBdas-peter

Comments

das-peter’s picture

das-peter commented
Status: Active » Needs review
StatusFileSize
new microdata-refresh-cached-vocabs-1349886-1.patch6.51 KB

Attached patch introduces the requested feature and fixes an issue at the same time.
microdata_get_vocabularies() queries the DB to fetch cache items. This is a very bad idea since caches are pluggable and thus any assumption about the storage of the caches is simply invalid.
Further it adds a fallback to deal with items that aren't in the cache anymore.

Anonymous’s picture

Anonymous (not verified) commented

Great! thank you.

Would you mind splitting out the fix for pluggability and posting it in #1349872: Decouple vocabulary handling from schema.rdfs.org JSON format.

das-peter’s picture

das-peter commented

@linclark Thanks for your fast feedback. The pluggability part is about the caching system of Drupal and isn't directly related the microdata schemas.
My original issue was that I got a huge amount of notices in watchdog, while investigating I figured out that there's a db query to a cache bin - what's scary because cache bin's aren't tied to the db (there are cache extensions for memcache, apc, redis ...)
When I fixed that part I recognized that there was no fallback for the case there's no cached schema. But as a cache is per definition a volatile storage a fallback should always be available.
So I added a fallback too.
Then on the search for an existing issue related issue to post the patch I came across this here an thought let's fix this together ;)

Btw. regading the pluggability of schema sources, how about an optional info key to define a schema parsing callback? If the key isn't set a default callback is used. Building a class, register it in the info file and so on sounds a bit like an overkill for this functionality.

  • das-peter committed 321f513 on 7.x-1.x 
    Issue #1349886 by das-peter | linclark: Refresh cached vocabulary...
das-peter’s picture

das-peter commented
Issue summary: View changes
Status: Needs review » Needs work

Committed current patch.

Btw. regading the pluggability of schema sources, how about an optional info key to define a schema parsing callback? If the key isn't set a default callback is used. Building a class, register it in the info file and so on sounds a bit like an overkill for this functionality.

Needs more work.