Sidebar endpoints

[westonruter]

Initial work on a read-only sidebar endpoint has been done at https://github.com/martin-pettersson/wp-rest-api-sidebars

A sidebar resource can look like:

{
    "name": "Sidebar Name",
    "id": "sidebar-id",
    "description": "Sidebar description...",
    "class": "sidebar-class",
    "before_widget": "<aside id=\"%1$s\" class=\"widget %2$s\">",
    "after_widget": "<\/aside>",
    "before_title": "<h1 class=\"widget-title\">",
    "after_title": "<\/h1>",
}

All of these would be readonly. As with the widgets endpoint, I suggest that rendered is not applicable to the REST API because a sidebar will have different content depending on the URL it is rendered onto.

Now, as for the actual list of widgets in a sidebar, I believe the representation should be just a list of widget IDs which would then allow the widgets assigned to a sidebar and their relative positions to be updated easily. The list of widget IDs can be exposed as a widgets property on the sidebar resource itself.

The sidebars endpoint should support returning the widgets among the _embedded, for example sidebars/:id:

{
    "name": "Sidebar Name",
    "id": "sidebar-id",
    "description": "Sidebar description...",
    "class": "sidebar-class",
    "before_widget": "<aside id=\"%1$s\" class=\"widget %2$s\">",
    "after_widget": "<\/aside>",
    "before_title": "<h1 class=\"widget-title\">",
    "after_title": "<\/h1>",
    "widgets": [ "text-2", "search-4", "archives-3" ],
    "_embedded": {
        "widgets": [
                { "id": "text-2", "type":"text", "instance":{ "title": "Hello", "text": "World" } },
                ...
        ]
    }
}

Note that the widgets belonging to a sidebar could also be queried via a filter param, such as: wp/v2/widgets?filter[sidebar]=sidebar-1

[NateWr]

Sounds good.

Just to raise the issue we discussed about whether or not the REST API should be concerned with presentational information: do we want to return the class, before_widget, after_widget, before_title, and after_title params? Is this data that's stored in the database or registered dynamically with each page load?

I'm not sure whether these bits qualify as "data" or if they are merely convenient config params for template development that do not belong with the grouping resource we talked about.

[westonruter]

Yeah, great points. These aren't stored in the database. They're only registered at runtime via PHP.