#14466 closed defect (bug) (fixed)
Widget position uses footer position styling
Reported by: | newkind | Owned by: | koopersmith |
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Widgets | Keywords: | needs-patch dev-feedback |
Focuses: | administration | Cc: |
Description
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
Attachments (7)
Change History (49)
#2
@
14 years ago
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.
#5
@
14 years ago
- Milestone set to 3.1
- Resolution wontfix deleted
- Status changed from closed to reopened
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.
#7
@
14 years ago
- Keywords needs-patch added
- Type changed from defect (bug) to enhancement
Does someone want to tackle this in the next couple of days to get it in before freeze?
#8
@
14 years ago
- Cc batmoo@… added
- Keywords has-patch added; needs-patch removed
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!',
) );
#9
@
14 years ago
Alt patch strips the prefix without relying on a separate function. Might be a little cleaner.
#10
follow-up:
↓ 11
@
14 years ago
That regex should probably be anchored, otherwise sidebar-primary, with prefix to sidebar-sidebar-primary, gets reduced to primary, instead of sidebar-primary.
#11
in reply to:
↑ 10
@
14 years ago
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.
#12
@
14 years ago
- Keywords 3.2-early added
- Milestone changed from 3.1 to Future Release
Not in yet, and no discussion of what this might break. Are any plugins targeting CSS rules?
#13
follow-up:
↓ 14
@
14 years ago
- Keywords 3.2-early removed
- Milestone changed from Future Release to 3.2
Crazy idea: rename the admin #footer to #wpfooter, to match #wphead.
#15
@
14 years ago
- Cc andrewryno@… added
+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.
#16
@
14 years ago
Changing the IDs of all footers in the admin would certainly affect some plugins, things like jQuery('#footer')...
, etc. Perhaps 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.
#17
@
14 years ago
- Component changed from UI to Widgets
- Keywords commit added; ui footer widget position style removed
#19
@
14 years ago
- Owner set to koopersmith
- Status changed from reopened to assigned
Given we're overhauling UI HTML/CSS in 3.2, now is the proper time to do this.
#20
@
14 years ago
- Keywords 2nd-opinion added; commit early removed
- Milestone changed from 3.2 to Future Release
- Resolution set to maybelater
- Status changed from assigned to closed
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.
#21
follow-up:
↓ 22
@
13 years ago
- Milestone changed from Future Release to 3.2
- Resolution maybelater deleted
- Status changed from closed to reopened
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.
#22
in reply to:
↑ 21
;
follow-up:
↓ 23
@
13 years ago
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.
#23
in reply to:
↑ 22
;
follow-ups:
↓ 24
↓ 25
@
13 years ago
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.
#24
in reply to:
↑ 23
@
13 years ago
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).
#25
in reply to:
↑ 23
@
13 years ago
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.
#27
@
13 years ago
- Keywords needs-refresh added; 2nd-opinion removed
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.
#28
@
12 years ago
- Milestone changed from Future Release to 3.5
We should fix this one way or the other.
#31
@
12 years ago
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).
#32
@
12 years ago
- Keywords commit added
I'm game for 14466_alt_v2.diff. I imagine it needs a refresh and some final testing.
#33
@
12 years ago
- Keywords needs-refresh removed
Seems that the CSS changes are no longer needed.
Went with widget-area-
prefix rather than sidebar-
, since sidebar-sidebar-3
looked weird.
#37
@
12 years ago
- Keywords needs-patch added; has-patch commit removed
- Milestone changed from 3.5 to Future Release
This broke things. #22374.
#40
@
10 years ago
- Focuses administration added
- Keywords dev-feedback added
Is there any interest in attempting to refix this?
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")