Make WordPress Core

Opened 8 years ago

Last modified 3 years ago

#35656 new enhancement

Deprecate old single (non-multi) widgets

Reported by: westonruter's profile westonruter Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.8
Component: Widgets Keywords: has-patch dev-feedback
Focuses: Cc:

Description (last modified by westonruter)

Widgets were introduced to Core in 2.2. These initial widgets only allowed one instance of a given widget to be registered at a given time. In 2.8 the WP_Widget was introduced which allowed for multiple instances of a widget type to be added, but more importantly it introduced an object-oriented MVC-ish paradigm for representing widgets. The WP_Widget::update() callback allows for a given widget instance to be sanitized without having to actually save it to the database. This ability is key for previewing widgets in the Customizer. In addition to the update callback, the WP_Widget can have schema information attached which works in conjunction with update to sanitize and validate a given widget for the REST API, for automatically generating a widget form, and automatically providing default values for a widget instance (see #35574). All of this is not possible with the old single widgets.

I believe it is time to deprecate old single widgets so that widgets can evolve. If support for old single widgets is removed in 4.5, then in 4.6 (or later) support can be removed which could clean up quite a bit of the widgets codebase, including the brittle “option transactions” functionality that was added to widgets in the Customizer.

Once single widgets are removed, moving widgets from being stored in options to a custom post type will be facilitated: #35669.

Attachments (1)

35656.0.diff (1.7 KB) - added by westonruter 8 years ago.
Add _doing_it_wrong()

Download all attachments as: .zip

Change History (16)

8 years ago

Add _doing_it_wrong()

#1 @westonruter
8 years ago

  • Keywords has-patch added

#2 @westonruter
8 years ago

  • Description modified (diff)

#3 @westonruter
8 years ago

  • Keywords dev-feedback added

Any concerns with committing this? I'd like to commit it sooner rather than later so we can start monitoring the impact of deprecating this old style of widgets.

This ticket was mentioned in Slack in #core by westonruter. View the logs.

8 years ago

#5 @westonruter
8 years ago

@ipstenu is going to grep the plugins directory to see how many (active?) plugins still feature old single widgets. There could be a lot of deprecation notices for WP installs, on the same magnitude as deprecating the PHP4 constructors (#31982).

@jorbin wisely pointed out that a migration docs should be published before the deprecation notice is committed.

#6 @Ipstenu
8 years ago

A quick look gives me about 3000 plugins, which is not as horrible as it might be.

#7 follow-up: @westonruter
8 years ago

@Ipstenu thanks! Is this only active plugins or does it include inactive/closed ones as well?

#8 @dd32
8 years ago

I don't think a deprecated notice is realistically the best option, although we've added them for far less.

I think the most important thing to think about here, is the user experience which this ultimately gives. To an end-user the fact a widget uses an older style API or a newer one is completely irrelevant, all that they're going to see is that the widget is missing from their UI (eventually) and that's bad.
It feels like this is a step towards removing support for something "just because" (which "cleaning up" is usually) - it's not immediately clear what the implications of it are.

If there's actual technical constraints, that should be showcased instead IMHO to see if someone else can dream up a way to make it work before just ruling it impossible and that the old API should be completely unsupported.

#9 in reply to: ↑ 7 @Ipstenu
8 years ago

Replying to westonruter:

@Ipstenu thanks! Is this only active plugins or does it include inactive/closed ones as well?

It includes inactive/closed as well (since they're still in use somewhere) unless the devs blanked out SVN.

This ticket was mentioned in Slack in #core by chriscct7. View the logs.

8 years ago

#11 @chriscct7
8 years ago

  • Milestone changed from 4.5 to Future Release

There's quite a lot of affected plugins by a deprecation this late in the release cycle, as most of those devs would want to update ahead of the release so their users don't see deprecation warnings when wp_debug is on. Punting per discussion in core slack (link above)

This ticket was mentioned in Slack in #core-restapi by rmccue. View the logs.

8 years ago

#13 @westonruter
8 years ago

  • Summary changed from Deprecated old single non-WP_Widget widgets to Deprecate old single (non-multi) widgets

#14 @noisysocks
3 years ago

#53993 was marked as a duplicate.

#15 @noisysocks
3 years ago

There's some more recent discussion on this in #53993 which I've closed as a duplicate. Well worth reading.

My 2¢: I definitely think it's time to deprecate this style of widget. I'd like to explore if we can remove non-multi widgets altogether and provide backwards compatibility by changing wp_register_sidebar_widget to register an anonymous subclass of WP_Widget.

Calling _doing_it_wrong() or _deprecated_function() is a great first step though.

Last edited 3 years ago by noisysocks (previous) (diff)
Note: See TracTickets for help on using tickets.