Calendar widget can sprout a page with multiple, identical ID

[Denis-de-Bernardy]

There is a div id="calendar_wrap in the calendar widget. It can end up outputting multiple widgets with the same IDs on the page.

Is it needed for any reason?

[hakre]

using <div class="calendar_wrap" ... and a small mod of a themes (the default themes?) css should fix this.

is it only for the calendar widget? or are other widgets having the same problem?

[Denis-de-Bernardy]

only the calendar.

[azaozz]

This would probably break all themes that have styling for the calendar. There's no point of having two calendars on the same page anyways as they will look the same (only the title can be set in the widget).

[Denis-de-Bernardy]

Replying to azaozz:

TThere's no point of having two calendars on the same page anyways

Agreed 100%. But I didn't suggest the code that made calendars a multi-widget. And as a result users and bound to use it. Maybe we should roll that back instead? ;-)

[DD32]

See also: #9503 (new defect (bug)) Multi-calendar can result in multiple versions of the #wp-calendar ID

[DD32]

Er, Only now i notice that it refers to different ID's.. Still I think it might be best to keep it to the single ticket.

[hakre]

The new Multiwidget class should handle this properly and preventing mutliple identical IDs.

[Denis-de-Bernardy]

it doesn't... and this one will still be needed:

​http://core.trac.wordpress.org/attachment/ticket/9503/9503.diff

Else we'll have validation fascists who will be all over trac to report the issue.

[hakre]

eh calm down using that language. I can not take care for everything. This one is on my list. I would really love to see a more wise class usage that IDing everything.

[Denis-de-Bernardy]

oh, no worries, I wasn't meaning you or others in trac, I was meaning end-users in forums. :)

Andrew's note is quite valid though. It's rare that more than one calendar will get included anyway, and changing this may break quite a few things in practice -- especially in older themes.

[hakre]

Well an uplift of a major version is a chance to break something :D

[Denis-de-Bernardy]

9503.diff is broken. 9451.diff still works fine. commit the latter (in which case I'll redo the other one), or wontfix?

[Denis-de-Bernardy]

based on andrew's remark