[wp-edu] Pre-poulating and Managing Custom Taxonomy Terms

[Andrew Nacin]

On Sat, Mar 17, 2012 at 8:45 PM, Kyle Jones <kylejones at thecorkboard.org>wrote:

> Hello WP-Edu folks-
>
> I'm working on a basic ePortfolio system using four custom taxonomies for
> the pages post type.  The pages act as the artifacts.  Each custom taxonomy
> needs to be pre-populated with terms.
>
> So far, the taxonomies are working just fine and they have been
> pre-populated successfully - all of this is packaged in a must use plugin
> on each site.
>
> However, when terms need to be edited or all-out deleted it's not straight
> forward.
>
> For example, if I want to edit the description of a course in the courses
> taxonomy the database doesn't recognize that it is an *edit* and
> misconstrues it as an *additional* term.  So, now two terms exist, of
> which one is now misleading.  The second issue presents itself when a term
> needs to be deleted.  Because wp_delete_term requires an ID and the IDs for
> each pre-populated term may be different across varying sites, I can't (at
> least I don't think I can) programatically delete the unnecessary term(s)
> across the entire site.
>

Sounds like you're using multisite with global terms. Editing a shared term
results in a duplication of the term. As it requires careful
synchronization when terms are modified, global terms get very messy very
quickly. We more or less deprecated the global terms feature when MU was
merged into 3.0 — it still exists, but it is turned off by default. To turn
it off (if you're not using it otherwise), you can change the
global_terms_enabled value in sitemeta to 0, or do add_filter(
'global_terms_enabled', '__return_false' );. Once you turn it off, terms
will stop being synced, and will become less "in sync" over time.
Obviously, turning it back on isn't really feasible, at least not without a
lot of non-shared properties.

Global terms aren't the issue here, though. That's just background for what
is occurring.

Instead what I would do is store all of your taxonomy data in a file. So,
you have an array of terms for each taxonomy, etc. Then you, in code, store
a global "version" of this taxonomy data, i.e. version 1. Then, when you
create a site, the terms get created based on the definitions in the file,
and an option is added to that site's options table saying that its
taxonomy data version is 1.

When you want to add or edit a term, you add the new one to the array.
Delete or edit, remove the old one. And then for edits, you have a second
array of mapping the old term to the new term. Then you bump the version to
2.

On admin_init (for every site), you check the version number in the DB. If
it's less than the one in the file, you initiate an upgrade, based on what
needs to be added, edited, or renamed. This can also apply for modifying
descriptions, etc. Once done, you bump the version number to 2.

You don't need to store everything in the file, but it would be nicer than
a switch_to_blog(1) to get that blog's taxonomy information. And, if
implementing this, it would make sense to disallow
editing/managing/deleting terms for everyone, from any site, except for a
super admin on the main site (where the canonical information, ideally,
would be kept).

If you're familiar with the internals of WP, this approach may sound
familiar. The routine is what WordPress does to update the DB — it keeps a
DB version in version.php and in the options table, and compares them in
admin.php. It does this for multisite too, but you can force an update
across the entire network from the Update Network screen in the network
admin.

Cheers,
Nacin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.automattic.com/pipermail/wp-edu/attachments/20120317/f6ddddfb/attachment.htm>