Guest User

Untitled

a guest
Jul 18th, 2018
83
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.24 KB | None | 0 0
  1. As you all know, one of the goals for Habari 0.7 is to implement taxonomy. One aspect of this is implementing tags as terms in a tags vocabulary. We've been working on this in a branch. It now seems to be at a usable state, so the changes were merged into trunk in r3829 and r3830. The code needs some love yet, but maybe with it in trunk, it will get more.
  2.  
  3. As with all major updates, I'd recommend backing up your db before doing svn up. The update should be seamless, moving your tags and tag2post tables into the terms and object_terms tables respectively. The tags and tag2posts tables are *not* deleted. They are still in your database, but they are no longer registered.
  4.  
  5. One unavoidable side effect of this change is that any plugins or themes that use direct access to the database to get tags will need to be updated to use the new table structure. In other words, until they are updated they will break. If the plugin or theme uses the api rather than direct database access, it should be okay. One possible common instance is
  6.  
  7. $tags = DB::get_results( 'SELECT * FROM ' . DB::table('tags') );
  8.  
  9. This will no longer work. Instead use
  10.  
  11. $tags = Tags::get();
  12.  
  13. More complex SQL will still require SQL. The new SQL will be more complex than what you are using now. General changes to look for are:
  14.  
  15. {tags} should be {terms}
  16. {tag2post} should be {object_terms}
  17.  
  18. Tags are now a vocabulary among many possible vocabularies, a vocabulary that is usually associated with the object type of 'post', so SQL will need to contain a WHERE clause that limits the output to terms associated with the vocabulary id for tags and associations limited to the object type id for post objects. If you look at the code in Posts::get() for retrieving posts based on tags, you'll see an example.
  19.  
  20. Another point to keep in mind is that the terms equivalent for 'tag_text' is 'term_display', and the equivalent for 'tag_slug' is 'term', so unless you want to change your api, you'll need to return those fields with the old names. For example:
  21.  
  22. SELECT term as tag_slug from {terms}
  23.  
  24. One other change, we tried to make tags something that isn't limited to posts, so in the future, if this was done right, plugin authors will be able to tag other object types that may be added.
  25.  
  26. Rick
Add Comment
Please, Sign In to add comment