[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