[wp-trac] Re: [WordPress Trac] #5683: New tag section needs display filtering

WordPress Trac wp-trac at lists.automattic.com
Fri Jan 18 17:16:38 GMT 2008


#5683: New tag section needs display filtering
------------------------------+---------------------------------------------
 Reporter:  jhodgdon          |        Owner:  anonymous
     Type:  defect            |       Status:  new      
 Priority:  normal            |    Milestone:  2.5      
Component:  General           |      Version:  2.5      
 Severity:  normal            |   Resolution:           
 Keywords:  tags 2nd-opinion  |  
------------------------------+---------------------------------------------
Changes (by jhodgdon):

  * keywords:  tags => tags 2nd-opinion

Comment:

 I took a look at how this was coded up. A simple patch isn't possible, in
 my opinion. The code would need to be quite a bit more complex to handle
 the following:

 a) Raw tag names may not be appropriate to display to the user. They
 should be filtered with "display" filtering.

 b) Tag names filtered with "display" filtering, if put into the hidden tag
 input field, will not match up in the database when the post is saved, so
 the code will end up creating new tags instead of matching previously-
 entered tags. Slugs will match, or un-filtered raw tag names.

 c) If someone puts a "display" filtered tag name into the dynamic text
 entry field and clicks "add", you would want to match with existing tags
 in the database -- same problem as (b) if you don't.

 Right now, the code is assuming that the same text can be displayed to the
 user, matched when someone types a tag and clicks "add", and put into the
 hidden tag input field to match the DB when the post is saved. Which works
 fine for the majority of users, who are operating in a single language,
 don't use display filtering on their tags, and don't need to edit their
 tag slugs so they are readable in URLs.

 To fix it for those users in more complex situations, so that it will
 display filtered text, match on "add", and put slugs or unfiltered raw
 names into the hidden tag entry field makes things quite a bit more
 complex, because the filtering is done in PHP, matching is done in MySQL,
 and the display is done in JS.

 My approach in the Advanced Tag Entry plugin (which does handle display
 vs. slug vs. raw) was to do away with free text entry and just use drop-
 down lists for everything -- that works, because you can do the filtering
 at load time and save it in a JS array.  But it doesn't work well for
 users that have thousands of tags -- it takes forever to load the tag info
 into JS.

 Probably an approach that includes a free text field or avoids loading all
 the tags initially into JS can't easily be made to work with filtering...
 so I should just continue to maintain something like the Advanced Tag
 Entry plugin for my multilingual plugin users.

 And probably this bug should be closed as "won't fix". Thoughts?

-- 
Ticket URL: <http://trac.wordpress.org/ticket/5683#comment:1>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list