WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 weeks ago

Last modified 2 weeks ago

#41683 closed feature request (fixed)

Add Widget REST API endpoint

Reported by: spacedmonkey Owned by: noisysocks
Milestone: 5.8 Priority: normal
Severity: normal Version: 4.7
Component: REST API Keywords: has-patch has-unit-tests needs-dev-note
Focuses: rest-api Cc:

Description

There needs to be a REST endpoint to interacts with widgets. Current users can use the options api to interact with the data, but this is extremely limited. I would recommend that we look to WP CLI for pointer on how the api is laid out. Docs can be found here - https://developer.wordpress.org/cli/commands/widget/ .

One of the likely issues with if the is a view, how the html for a widget is rendered.

Change History (32)

#2 @wonderboymusic
4 years ago

getting a widget by itself may be useful for admin screens, but to build a front end, you actually need access to Sidebars. See something I am using here: https://highforthis.com/wp-json/graphql/v1/sidebars

Without the sidebar context and a representation of the widget HTML, how useful is the data?

#3 @joehoyle
4 years ago

We have the repo https://github.com/WP-API/wp-api-menus-widgets-endpoints for adding this as a feature plugin, so I don't think we need to manage and do this in trac.

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


22 months ago

#5 @TimothyBlynJacobs
22 months ago

  • Type changed from defect (bug) to feature request

#6 @TimothyBlynJacobs
22 months ago

This looks to be something that the Gutenberg team is actively working on: https://github.com/WordPress/gutenberg/issues/13204

Work should probably be happening there for now.

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


8 months ago

#9 @TimothyBlynJacobs
3 weeks ago

#51460 was marked as a duplicate.

This ticket was mentioned in PR #1293 on WordPress/wordpress-develop by TimothyBJacobs.


3 weeks ago

  • Keywords has-patch has-unit-tests added; needs-patch needs-unit-tests removed

#11 @TimothyBlynJacobs
3 weeks ago

  • Milestone changed from Awaiting Review to 5.8

#12 @prbot
3 weeks ago

noisysocks commented on PR #1293:

Code LGTM. If tests pass I'm happy 👍

#13 @noisysocks
3 weeks ago

Committing this will break Gutenberg CI because the plugin will re-declare classes that already exist, so let's just hold off on committing this until I have a Gutenberg PR ready to go that fixes that.

Last edited 3 weeks ago by noisysocks (previous) (diff)

#14 @noisysocks
3 weeks ago

  • Owner set to noisysocks
  • Resolution set to fixed
  • Status changed from new to closed

In 50993:

REST API: Add widget endpoints

Adds the sidebars, widgets and widget-types REST API endpoints from the
Gutenberg plugin.

Fixes #41683.
Props TimothyBlynJacobs.

#15 @swissspidy
3 weeks ago

Committing this will break Gutenberg CI because the plugin will re-declare classes that already exist, so let's just hold off on committing this until I have a Gutenberg PR ready to go that fixes that.

Why doesn't Gutenberg have class_exists guards for that or use different class name prefix?

Also, I feel like all the contributors to the original class in Gutenberg should have received props.

#16 @noisysocks
3 weeks ago

There are a few class_exists guards but some of it isn't working properly. https://github.com/WordPress/wordpress-develop/pull/1284 will address those.

Folks who contributed in Gutenberg should get props when we generate props from the Gutenberg git commits, no? Nonetheless I definitely forgot to props @spacedmonkey and will work on editing the commit message to include that.

#17 @noisysocks
3 weeks ago

In 50994:

REST API: Revert widget endpoints

Reverts [50993] as it has missing props.

Reverts [50993].
See #41683.

#18 @noisysocks
3 weeks ago

In 50995:

REST API: Add widget endpoints

Adds the sidebars, widgets and widget-types REST API endpoints from the
Gutenberg plugin.

Fixes #41683.
Props TimothyBlynJacobs, spacedmonkey, zieladam, jorgefilipecosta, youknowriad, kevin940726.

#19 @SergeyBiryukov
3 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Per the WordPress Documentation Standards:

@author Tag

It is WordPress’ policy not to use the @author tag, except in the case of maintaining it in external libraries. We do not want to imply any sort of “ownership” over code that might discourage contribution.

@copyright and @license Tags

The @copyright and @license tags are used in external libraries and scripts, and should not be used in WordPress core files.

@copyright is used to specify external script copyrights.
@license is used to specify external script licenses.

Based on the above, would rest-api/endpoints/class-wp-rest-sidebars-controller.php still be maintained as an external library or a core file from now on? If the latter, then I guess this whole fragment should be removed from WP_REST_Sidebars_Controller for consistency with other REST API classes:

 * Copyright (C) 2015  Martin Pettersson
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see <http://www.gnu.org/licenses/>.
 *
 * @author    Martin Pettersson <martin_pettersson@outlook.com>
 * @copyright 2015 Martin Pettersson
 * @license   GPLv2
 * @link      https://github.com/martin-pettersson/wp-rest-api-sidebars

To keep the original author's credit, it could be replaced with a comment like the one we have in the wpdb class:

Original code from {@link http://php.justinvincent.com Justin Vincent (justin@visunet.ie)}

#20 @spacedmonkey
3 weeks ago

@SergeyBiryukov As far as I know, that copyright information is wrong and should be removed.

#21 @TimothyBlynJacobs
3 weeks ago

That copyright info is from the original plugin that was used as a basis for the endpoints. During the 5.6 cycle I asked @pento whether we should remove or modify the copyright information given that it had been modified extensively. I was advised that we should leave the original copyright in place, like we do for kses.php. Since 5.6, the code has been modified even more substantially.

I don't have any real opinions on what the right way to handle it is.

#22 @desrosj
3 weeks ago

In 51007:

Coding Standards: Apply some minor coding standards adjustments.

Follow up to [50977], [50987], and [50995].

See #41683, #53156, #53175.

#23 @peterwilsoncc
3 weeks ago

In 51020:

REST API: Remove WP_Test_REST_Widgets_Controller tests.

This test suite is causing a loop in PHP8, remove tests to investigate.

Props SergeyBiryukov, desrosj.
See #41683.

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


3 weeks ago

This ticket was mentioned in PR #1304 on WordPress/wordpress-develop by peterwilsoncc.


3 weeks ago

Trac ticket:

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


3 weeks ago

#27 @peterwilsoncc
3 weeks ago

In pull request #1304:

  • Restores tests removed in [51020]
  • Defines are URL in the RSS widget of the get_items() test to avoid PHP8 infinite loop

I've created #53278 as a follow up to deal with the underlying issue.

#28 @peterwilsoncc
3 weeks ago

In 51029:

REST API: Re-introduce WP_Test_REST_Widgets_Controller tests.

Returns the test suite with the addition of defining a URL in the RSS widget within WP_Test_REST_Widgets_Controller::test_get_items() to work around an infinite loop in WP_Widget_RSS on PHP 8 if the URL is unset or empty.

Reverts [51020].

Props peterwilsoncc, TimothyBlynJacobs.
See #41683.

#30 @noisysocks
3 weeks ago

Thanks for fixing. Can this ticket be closed now @peterwilsoncc?

#31 @peterwilsoncc
3 weeks ago

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

Yup, it sure can.

#32 @milana_cap
2 weeks ago

  • Keywords needs-dev-note added
Note: See TracTickets for help on using tickets.