Make WordPress Core

Opened 8 years ago

Closed 6 years ago

#41014 closed enhancement (maybelater)

Add `permalink_structure` to REST API settings endpoint

Reported by: aduth's profile aduth Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9
Component: REST API Keywords: has-patch
Focuses: rest-api Cc:

Description

Related: #38490

It is not currently possible to view or edit the permalink_structure option from the REST API. This makes it difficult to reimplement a post editor leveraging the REST API because the "slug" field is only applicable for sites configured to include %postname% in this option's value.

See: https://github.com/WordPress/WordPress/blob/9fb2e79/wp-admin/includes/post.php#L1323-L1324

This is relevant for the Gutenberg post editor reimplementation, where effort is blocked by unavailability of this setting from the REST API:

https://github.com/WordPress/gutenberg/pull/1042

A workaround may be to include the option in a server-rendered initialized (localized) JavaScript object, but (a) this is not available to clients which may intend to recreate this experience totally separated from the WordPress PHP environment and (b) is inconsistent with the expectation that settings should be manageable from the REST API (given the presence of the settings endpoint).

Caveats:

  • There is validation that is meant to occur in sanitize_option that tests whether the incoming permalink_structure includes a "structure tag". This feels like something that should be baked into the settings endpoint behavior (calling sanitize_option), and isn't entirely relevant to the changes proposed here.
  • Other permalink settings (category_base, tag_base) may be useful to include, but aren't part of the changes proposed here. I'm not sure the criteria with which settings are decided to be included on this endpoint. To me, it seems anything manageable through the Settings section of the admin dashboard should also be surfaced through these endpoints.

https://github.com/WordPress/WordPress/blob/9fb2e79/wp-includes/formatting.php#L4030-L4294

Attachments (2)

41014.diff (1.0 KB) - added by aduth 8 years ago.
41014.fixtures.diff (1.0 KB) - added by danielbachhuber 7 years ago.

Download all attachments as: .zip

Change History (23)

@aduth
8 years ago

#1 @aduth
8 years ago

  • Keywords has-patch added

#2 @jnylen0
8 years ago

Unfortunately the settings endpoint is currently restricted to administrators (current_user_can( 'manage_options' )) which makes it unsuitable for this use case. See also #38731, #39854.

#3 follow-up: @aduth
8 years ago

Why would it be unsuitable if that's the same capability checked on the equivalent admin screen?

https://github.com/WordPress/WordPress/blob/f28f4fc/wp-admin/options-permalink.php#L12-L13

Even if it were unsuitable, what is the proposed workaround?

#4 in reply to: ↑ 3 @jnylen0
8 years ago

Replying to aduth:

Why would it be unsuitable if that's the same capability checked on the equivalent admin screen?

Because users without manage_options would not be able to read the value of this setting, which they need to do in order to see a correct permalink.

what is the proposed workaround?

A couple of options discussed at #38731 (add better permissions capabilities to the settings endpoint, or add read-only "site info" to /wp-json instead, like we did for gmt_offset).

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


8 years ago

#6 @timmydcrawford
8 years ago

Another item to consider here, in the context of permalinks + editor - is my old favorite the auto slug. Not certain if the suggested slug is built in to the REST API or not yet. Sorry for the issue creep, but the issue brought back fond slug memories :)

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


7 years ago

#8 @joehoyle
7 years ago

In 42359:

REST API: Include permalink_structure in the settings route.

There are situations where the REST API client wants to be able to read and set the permalink_structure option. Though this doesn’t fix the use case of front-end rendered unauthenticated websites, it still has utility as a setting in it’s own right.

Props aduth.
See #41014.

#9 @joehoyle
7 years ago

As has been mentioned here, having this in the settings doesn't suit all use-cases due to being restricted to manage option, but I committed @aduth's patch as I do still think it's a useful addition to the settings controller.

I propose we also add the read-only value to /wp-json/

#11 @afercia
7 years ago

  • Milestone changed from Awaiting Review to 5.0

Does this still needs to stay open?

#12 @danielbachhuber
7 years ago

41014.fixtures.diff includes the regenerated tests/qunit/fixtures/wp-api-generated.js file.

#13 @netweb
7 years ago

  • Keywords commit added

#14 @peterwilsoncc
7 years ago

In 42540:

REST API: Update the fixture data for wp-api.js tests following [42359].

Props danielbachhuber.
See #41014.

#15 @SergeyBiryukov
7 years ago

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

Appears to be resolved in [42142] and [42359] above.

#16 @pento
7 years ago

#42465 was marked as a duplicate.

#17 @danielbachhuber
6 years ago

#45017 is a follow-up issue to put the computed permalink_template and generated_slug onto the Posts controller.

#18 @SergeyBiryukov
6 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

[42142], [42359], and [42540] should be backported to the 5.0 branch.

#19 @danielbachhuber
6 years ago

  • Keywords commit removed
  • Milestone changed from 5.0 to 5.1

Given this larger problem was solved with #45017, I think we should revert this ticket from trunk until there's some practical utility to it. In either case, it's not necessary to land in 5.0.

#20 @pento
6 years ago

In 44446:

REST API: Remove permalink_structure from the REST API settings endpoint.

This was ultimately fixed in #45017, so is redunant.

Reverts [42142,42359,42540].
See #41014.

#21 @pento
6 years ago

  • Milestone 5.1 deleted
  • Resolution set to maybelater
  • Status changed from reopened to closed

This can be re-added if we have a need for it in the future.

Note: See TracTickets for help on using tickets.