Kill use of colons in class names

[markjaquith]

Some of the WordPress admin uses class names with colon-separated values that have special meanings in our JS code This is a bad idea. Colons are a special character in CSS selector engines.

See #21106 for a really odd bug that cropped up because a css class contained the text foo:event which got parsed as an :even pseudo-class in JS.

HTML5 data attributes are the better way forward, in terms of attaching data to dom elements. We should kill all instances of colons in favor of data attributes.

[markjaquith]

In [21205]:

Change a jQuery selector to work around a change in jQuery 1.7.2 related to some class names containing colons. props SergeyBiryukov. fixes #21106 for trunk. see #21152

[azaozz]

Yes, these classes are older than four years. Colons in class names weren't a problem at the time. +1 to use data attributes instead, and the sooner that's fixed, the better.

[markjaquith]

We should also do it completely within the 3.5 cycle. This might break some plugins that depend on those class names for JS or CSS. Better to do a clean break that we can announce early in the cycle.

[azaozz]

To fix this we would need to change the way wp-lists.js works. Currently it passes values in the class names separated with colons.

[scribu]

Since it needs refactoring, maybe we could transform wp-lists.js into a Backbone view. (I have 0 experience with Backbone.js)

[wonderboymusic]

There is one remaining piece: I can't figure out why nav menu admin lists need the class="list:{$post_type} ..." but they break without it. Other than that, everything seems to work. Attached a patch.

[wonderboymusic]

P.S. are the min files auto-generated now?

[scribu]

Replying to wonderboymusic:

P.S. are the min files auto-generated now?

Yes, we have bump-bot that does that, but it probably needs an update after #21633.

In any case, you don't need to worry about it.

[wonderboymusic]

Updated the patch - fixed the CSS collision happening on Nav Menus, fixed the action context when you spam / unspam / spam / unspam etc. This legacy code, while not wholly inelegant, is brutal to debug.

[SergeyBiryukov]

Refreshed after [21688]

[nacin]

Doesn't seem like there have been any bugs other than #21106 that were reported against 3.4. Moving back to the 3.5 milestone.

[nacin]

In [21737]:

Modify a few jQuery selectors to prevent overflows and lagging. Todo, rewrite wp-lists and improve all of these selectors.

props SergeyBiryukov. fixes #21106 for trunk. see #21152.

[SergeyBiryukov]

#21852 was marked as a duplicate.

[SergeyBiryukov]

21152.3.diff​ moves the whole class names to data-wp-lists="...", as suggested by azaozz in ticket:21852:4. This restores AJAX in custom fields (#21852). Also noticed a couple of places not covered by the previous patches.

Tested:

• Adding categories on Edit Post screen
• Adding and deleting categories on Categories screen
• Adding, deleting and updating custom fields
• Comment moderation

Could definitely use a second pair of eyes and more testing.

[SergeyBiryukov]

21152.4.diff​ fixes keyboard shortcuts for comment moderation.

[jackreichert]

With the latest SVN I'm still having trouble with updating Custom Fields.
Attached is a patch that fixes it. I DID notice that all IDs for the update buttons are the same, this patch does not correct that, only the ability to ajax update the fields.

[jackreichert]

fix for custom field ajax

[SergeyBiryukov]

Replying to jackreichert:

I DID notice that all IDs for the update buttons are the same

This was fixed in [21781] (for #21829), so wp-lists.js.diff​ doesn't look correct. Make sure you have the latest revision.

this patch does not correct that, only the ability to ajax update the fields.

AJAX is broken due to some changes in #21598. #21852 was an attempt to fix that, but the consensus was to focus on this ticket instead, and 21152.4.diff​ should fix that as well.

[ocean90]

#22003 was marked as a duplicate.

[SergeyBiryukov]

Refreshed after [21955]

[wonderboymusic]

<IMO>I understand why switching to data-wp-lists is the easiest fix, but RegEx'ing colon-separated values still makes me want to vom. </IMO>

[arena]

custom field ajax not working in 3.5-beta2-22265

[SergeyBiryukov]

Yes, the patch was not committed yet.

[SergeyBiryukov]

Refreshed with the fix for adding link categories from #22340.

[azaozz]

Fixed in [22396].

[arena]

there are stil some class names with colon-separated values inserted via js in 3.5

such as

wp-admin/js/cat.js:1:jQuery(document).ready(function(b){var a=function(){return""!==b("#newcat").val()};b("#jaxcat").prepend('<span id="ajaxcat"><input type="text" name="newcat" id="newcat" size="16" autocomplete="off"/><input type="button" name="Button" class="add:categorychecklist:jaxcat" id="catadd" value="'+catL10n.add+'"/><input type="hidden"/><input type="hidden"/><span id="howto">'+catL10n.how+'</span></span><span id="cat-ajax-response"></span>');b("#categorychecklist").wpList({alt:"",response:"cat-ajax-response",confirm:a})});

[nacin]

This ticket was closed as fixed in 3.5. Please open a new ticket.

[SergeyBiryukov]

Replying to arena:

<input type="button" name="Button" class="add:categorychecklist:jaxcat" id="catadd"

That input has data-wp-lists attribute in 3.5, not class:
​http://core.trac.wordpress.org/browser/tags/3.5/wp-admin/js/cat.js#L3