Support for retrieving custom post types. #158
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Restores the ability to use `wp.post().type('my_post_type').get()`.
Credit to @jasonphillip's implementation, this version fixes the
associated tests as well as making it compatible with the most recent
master.
jasonphillips@c3b1854
Collaborator
|
Thanks for this, @elyobo (and @jasonphillips). One of the other WIP PR's here will expose custom resources as top-level chain initiators (so |
Contributor
Author
|
Works for me, I'm not wedded to this approach, I just wanted a way to access the CPT data and this implementation is consistent with the docs in README.md. The approach in #144 also looks good (and could possibly be used to reimplement posts/pages/media as well). |
Contributor
Author
|
@kadamwhite Do you have any clearer idea of where you're going to go custom post types in here or #144? |
kadamwhite
added a commit
that referenced
this pull request
Jun 16, 2016
This supersedes both #144 and #158 by providing a method that developers can use to arbitrarily support any endpoint. --------------------------------------- Support for Custom Post Types is provided via the `.registerRoute` method. This method returns a handler function which can be assigned to your site instance as a method, and takes the [same namespace and route string arguments as `rest_register_route`](http://v2.wp-api.org/extending/adding/#bare-basics): ```js var site = new WP({ endpoint: 'http://www.yoursite.com/wp-json' }); site.myCustomResource = site.registerRoute( 'myplugin/v1', '/author/(?P<id>)' ); site.myCustomResource().id( 17 ); // => myplugin/v1/author/17 ``` The string `(?P<id>)` indicates that a level of the route for this resource is a dynamic property named ID. By default, properties identified in this fashion will not have any inherent validation. This is designed to give developers the flexibility to pass in anything, with the caveat that only valid IDs will be accepted on the WordPress end. You might notice that in the example from the official WP-API documentation, a pattern is specified with a different format: this is a [regular expression](http://www.regular-expressions.info/tutorial.html) designed to validate the values that may be used for this capture group. ```js var site = new WP({ endpoint: 'http://www.yoursite.com/wp-json' }); site.myCustomResource = site.registerRoute( 'myplugin/v1', '/author/(?P<id>\\d+)' ); site.myCustomResource().id( 7 ); // => myplugin/v1/author/7 site.myCustomResource().id( 'foo' ); // => Error: Invalid path component: foo does not match (?P<a>\d+) ``` Adding the regular expression pattern (as a string) enabled validation for this component. In this case, the `\\d+` will cause only _numeric_ values to be accepted. **NOTE THE DOUBLE-SLASHES** in the route definition here, however: `'/author/(?P<id>\\d+)'` This is a JavaScript string, where `\` _must_ be written as `\\` to be parsed properly. A single backslash will break the route's validation. Each named group in the route will be converted into a named setter method on the route handler, as in `.id()` in the example above: that name is taken from the `<id>` in the route string. The route string `'pages/(?P<parentPage>[\d]+)/revisions/(?P<id>[\d]+)'` would create the setters `.parentPage()` and `id()`, permitting any permutation of the provided URL to be created. To permit custom parameter support methods on custom endpoints, a configuration object may be passed to the `registerRoute` method with a `mixins` property defining any functions to add: ```js site.handler = site.registerRoute( 'myplugin/v1', 'collection/(?P<id>)', { mixins: { myParam: function( val ) { return this.param( 'my_param', val ); } } }); ``` This permits a developer to extend an endpoint with arbitrary parameters in the same manner as is done for the automatically-generated built-in route handlers. Auto-discovery of all available routes will be supported in the near future, as will re-utilizing existing mixins (like `.search()`) on custom routes.
Collaborator
|
Provisionally superseded by #176, input requested on that PR! |
kadamwhite
changed the title
Collaborator
|
#176 has merged |
Contributor
Author
|
Cool, thanks @kadamwhite; been busy so haven't been able to play with the changes yet but they looked good! |
Collaborator
|
@elyobo thanks! If you find any issues with the interface we've implemented please let us know :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Restores the ability to use
wp.post().type('my_post_type').get().Credit to @jasonphillip's implementation, this version fixes the
associated tests as well as making it compatible with the most recent
master.
jasonphillips@c3b1854