WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 17 months ago

#14466 reopened enhancement

Widget position uses footer position styling

Reported by: newkind Owned by: koopersmith
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Widgets Keywords: needs-patch
Focuses: 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)

bug.jpg (10.8 KB) - added by newkind 4 years ago.
14466.diff (3.9 KB) - added by batmoo 3 years ago.
14466_alt.diff (3.7 KB) - added by batmoo 3 years ago.
14466_alt_v2.diff (3.7 KB) - added by batmoo 3 years ago.
Adds starts-with flag for regex
14466.2.diff (4.1 KB) - added by andrewryno 3 years ago.
wpfoot.diff (4.4 KB) - added by koopersmith 3 years ago.
14466.3.diff (1.8 KB) - added by SergeyBiryukov 19 months ago.

Download all attachments as: .zip

Change History (46)

newkind4 years ago

comment:1 TECannon4 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

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")

comment:2 nacin4 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.

comment:3 TECannon4 years ago

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

comment:4 scribu4 years ago

  • Milestone Awaiting Review deleted

comment:5 nacin4 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.

comment:6 hakre4 years ago

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

comment:7 jane3 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?

batmoo3 years ago

comment:8 batmoo3 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!',
) );

batmoo3 years ago

comment:9 batmoo3 years ago

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

comment:10 follow-up: nacin3 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.

batmoo3 years ago

Adds starts-with flag for regex

comment:11 in reply to: ↑ 10 batmoo3 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.

comment:12 markjaquith3 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?

comment:13 follow-up: scribu3 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.

comment:14 in reply to: ↑ 13 hakre3 years ago

Replying to scribu:

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

+1

andrewryno3 years ago

comment:15 andrewryno3 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.

comment:16 azaozz3 years ago

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.

Version 0, edited 3 years ago by azaozz (next)

comment:17 scribu3 years ago

  • Component changed from UI to Widgets
  • Keywords commit added; ui footer widget position style removed

comment:18 scribu3 years ago

  • Keywords early added

comment:19 nacin3 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.

koopersmith3 years ago

comment:20 koopersmith3 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.

comment:21 follow-up: nacin3 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.

Last edited 3 years ago by nacin (previous) (diff)

comment:22 in reply to: ↑ 21 ; follow-up: azaozz3 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.

comment:23 in reply to: ↑ 22 ; follow-ups: newkind3 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.

comment:24 in reply to: ↑ 23 andrewryno3 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).

comment:25 in reply to: ↑ 23 azaozz3 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.

comment:26 ryan3 years ago

  • Milestone changed from 3.2 to Future Release

comment:27 scribu2 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.

comment:28 scribu22 months ago

  • Milestone changed from Future Release to 3.5

We should fix this one way or the other.

comment:29 nacin19 months ago

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

comment:30 nacin19 months ago

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.

comment:31 newkind19 months 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).

comment:32 nacin19 months ago

  • Keywords commit added

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

SergeyBiryukov19 months ago

comment:33 SergeyBiryukov19 months 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.

comment:34 nacin18 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 22387:

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

comment:35 nacin18 months ago

In 22406:

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

comment:36 nacin18 months ago

#22374 was marked as a duplicate.

comment:37 nacin18 months ago

  • Keywords needs-patch added; has-patch commit removed
  • Milestone changed from 3.5 to Future Release

This broke things. #22374.

comment:38 ocean9018 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:39 toscho17 months ago

  • Cc info@… added
Note: See TracTickets for help on using tickets.