Widget position uses footer position styling

[newkind]

Hi,

If you add a widget position called Footer with id footer, it has exactly the same id as the footer of the whole admin and because of that the widget position uses the styling from admin footer ie. bigger padding, italic font, darker background. Please see the attached pic.

newkind

[TECannon]

It's not quite a reserved term, but the administration ui uses the html id "footer" for its footer. (You should also avoid ids like "header-logo", "wphead", "adminmenu", "sidemenu" which are also major admin areas.)

If you use more specific ids for the widget areas, you'll be less likely to run into conflicts like this.

(Example: Twenty-Ten uses "first-footer-widget-area")

[nacin]

I would rather prefix the IDs. Wondering how much that would break in terms of existing custom styling, but I think it would definitely be worth it. That's a silly conflict and potentially allows any future admin IDs to conflict. Suggesting reopen.

[TECannon]

How about change it to duplicate and refer to #11160?

[nacin]

I don't see #11160 gaining the kind of traction we need to repair this.

Going to re-open. Prefixing every ID on the widget page is not something I want to do, but I think it's the only good solution.

[hakre]

Should be possible to do for background only. Related #12615

[jane]

Does someone want to tackle this in the next couple of days to get it in before freeze?

[batmoo]

Patch attached. Prefixes the id with 'sidebar-' and strips it out before any related AJAX calls. (I was originally thinking to prefix it with 'sidebar-controls-' to be more specific but that seems far too verbose). Sample register_sidebar calls:

register_sidebar( array(
        'name' => __( 'Footer!' ),
        'id' => 'footer',
        'description' => 'This sidebar causes major problems!',
) );

register_sidebar( array(
        'name' => __( 'Sidebar!' ),
        'id' => 'sidebar-sidebar',
        'description' => 'This sidebar could cause major problems!',
) );

[batmoo]

Alt patch strips the prefix without relying on a separate function. Might be a little cleaner.

[nacin]

That regex should probably be anchored, otherwise sidebar-primary, with prefix to sidebar-sidebar-primary, gets reduced to primary, instead of sidebar-primary.

[batmoo]

Adds starts-with flag for regex

[batmoo]

Replying to nacin:

That regex should probably be anchored, otherwise sidebar-primary, with prefix to sidebar-sidebar-primary, gets reduced to primary, instead of sidebar-primary.

I tested with sidebar-sidebar (which gets prefixed to sidebar-sidebar-sidebar), and it seemed to work just fine (stripped to sidebar-sidebar). Same with sidebar-primary.

But, you're right, a starts-with anchor is a bit better. Updated.

[markjaquith]

Not in yet, and no discussion of what this might break. Are any plugins targeting CSS rules?

[scribu]

Crazy idea: rename the admin #footer to #wpfooter, to match #wphead.

[hakre]

Replying to scribu:

Crazy idea: rename the admin #footer to #wpfooter, to match #wphead.

+1

[andrewryno]

+1 on using #wpfooter (attached patch). Just some CSS changes and 1 JS reference. I can't imagine that breaking any plugins either, whereas prefixing all of the widgets might.

[azaozz]

Changing the IDs of all footers in the admin would certainly affect some plugins, things like jQuery('#footer')..., etc. However I think we can afford that early in the dev. cycle (i.e. now) as it follows our naming standards.

However I don't think we need to try and fix duplicate names/IDs for widgets. Creating a widget or a widget area is similar to creating settings page for a plugin. The author would have to prefix all unique names/IDs as recommended in the codex. For widgets this is even more critical as they live on a page where (many) different plugins share the same name-space.

[nacin]

Given we're overhauling UI HTML/CSS in 3.2, now is the proper time to do this.

[koopersmith]

I'm not convinced that changing the ID in this scenario is a silver bullet, but if we're going to do it, now is the time.

I also think that regardless of whether we change the footer, we should solve this properly and not use purely variable IDs.

[nacin]

This was both punted and closed. I'm thoroughly confused.

My suggestion: s/footer/wpfooter/ now. Relieve the practical burden. The theoretical issues of prefixing can be dealt with in the future.

Closed #17858 as a duplicate.

[azaozz]

Replying to nacin:

My suggestion: s/footer/wpfooter/ now...

-1. It's far too late to introduce changes that potentially break plugins now (3.2-RC1).
This is not a regression (i.e. doesn't break anything at the moment) and plugin and theme authors should learn to prefix all their functions, HTML IDs, names, etc.

[newkind]

Replying to azaozz:

Replying to nacin:

My suggestion: s/footer/wpfooter/ now...

-1. It's far too late to introduce changes that potentially break plugins now (3.2-RC1).
This is not a regression (i.e. doesn't break anything at the moment) and plugin and theme authors should learn to prefix all their functions, HTML IDs, names, etc.

Yes it brakes, the position named 'Footer' in WP < 3.2 was only changing the styling but in WP 3.2 the whole position is unusable because it acts like it cannot be opened and it's holder appears in the admin footer. Talking about prefixing widget position names doesn't have sense for me as it's not something that has to be unique. Having it the way it is right now with CSS styling for the admin opens a huge variety of names that cannot be used as widget position names without avoiding style conflicts. If something must be prefixed here I'd say that all div ID's for the admin backend.

[andrewryno]

Yes it brakes, the position named 'Footer' in WP < 3.2 was only changing the styling but in WP 3.2 the whole position is unusable because it acts like it cannot be opened and it's holder appears in the admin footer. Talking about prefixing widget position names doesn't have sense for me as it's not something that has to be unique. Having it the way it is right now with CSS styling for the admin opens a huge variety of names that cannot be used as widget position names without avoiding style conflicts. If something must be prefixed here I'd say that all div ID's for the admin backend.

It broke before and it's still broken now. Theme developers should have known before 3.2 that it broke, and changed it. Now, if we change it this late in the cycle, it can break plugins that were working before. So what azaozz is saying that it's better to leave things 'broken' than fix one thing and potentially break other things.

While I'd love to see this get into 3.2, I agree with azaozz and think it's too late. There's always 3.2.1 (that's a fun version number).

[azaozz]

Replying to newkind:

... Talking about prefixing widget position names doesn't have sense for me as it's not something that has to be unique...

Apparently it needs to be unique. Also this is the best practice.

[scribu]

I think 14466_alt_v2.diff​ (prefixing the sidebars in the widget screen) is a more general solution and also wouldn't cause problems for plugins.

[scribu]

We should fix this one way or the other.

[nacin]

Let's do both. Rename #footer to #wpfooter, and also start prefixing sidebars.

[nacin]

In [21878]:

Rename div#footer to div#wpfooter in the admin. Namespace one of our major elements and avoid clashing with widgets with the id of 'footer'. props andrewryno, koopersmith. see #14466.

[newkind]

Not sure if anyone noticed but the same situation happens also if the widget position is named "Login" - you can open it and use it, but the whole styling is broken (tested on 3.4.2).

[nacin]

I'm game for 14466_alt_v2.diff​. I imagine it needs a refresh and some final testing.

[SergeyBiryukov]

Seems that the CSS changes are no longer needed.

Went with widget-area- prefix rather than sidebar-, since sidebar-sidebar-3 looked weird.

[nacin]

In 22387:

Prefix sidebar IDs on the widgets screen with "sidebar-". props batmoo. fixes #14466.

[nacin]

In 22406:

Revert [22387]. see #14466. see #22374.

[nacin]

#22374 was marked as a duplicate.

[nacin]

This broke things. #22374.

[chriscct7]

Is there any interest in attempting to refix this?

[helen]

Doesn't seem to have come up again, and we renamed the admin footer, anyway. The naming piece seems to be more in the territory of #11160.

[newkind]

Ooops, sorry my mistake. Please ignore this.