-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chrome: Support custom taxonomies #2340
Conversation
56f4b62
to
e713c0e
Compare
Codecov Report
@@ Coverage Diff @@
## master #2340 +/- ##
==========================================
+ Coverage 24.69% 24.69% +<.01%
==========================================
Files 152 152
Lines 4738 4993 +255
Branches 799 853 +54
==========================================
+ Hits 1170 1233 +63
- Misses 3014 3158 +144
- Partials 554 602 +48
Continue to review full report at Codecov.
|
What's the best way to test this? |
@jasmussen good question, I added some instructions to the description |
Not sure about the rename, since without context, it's not clear what a "HierarchicalTaxonomy" component is. Might suggest instead: On the fence about even dropping "Flat" in favor of |
Do custom taxonomies belong under the "Categories & Tags" heading? In Calypso we have Categories & Tags containing.... categories and tags. But custom taxonomies under their own panels. |
* External dependencies | ||
*/ | ||
import { connect } from 'react-redux'; | ||
import { unescape, find, throttle } from 'lodash'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note entirely in scope but: The reason I'd renamed this in the other component is because there is a global function by the same name:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/unescape
This is problematic if the import is ever dropped for any reason, since linting will not surface any issues:
gutenberg (add/custom-taxonomies) $ git diff
diff --git a/editor/sidebar/post-taxonomies/flat-taxonomy.js b/editor/sidebar/post-taxonomies/flat-taxonomy.js
index 995aa17a..d21a7be6 100644
--- a/editor/sidebar/post-taxonomies/flat-taxonomy.js
+++ b/editor/sidebar/post-taxonomies/flat-taxonomy.js
@@ -2,7 +2,7 @@
* External dependencies
*/
import { connect } from 'react-redux';
-import { unescape, find, throttle } from 'lodash';
+import { find, throttle } from 'lodash';
/**
* WordPress dependencies
gutenberg (add/custom-taxonomies) $ npx eslint editor/sidebar/post-taxonomies/flat-taxonomy.js
gutenberg (add/custom-taxonomies) $
const TaxonomyComponent = taxonomy.hierarchical ? HierarchicalTaxonomy : FlatTaxonomy; | ||
return ( | ||
<TaxonomyComponent | ||
key={ taxonomy.name } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since name
is human-readable label and not necessarily unique, should we use taxonomy.slug
instead?
lib/client-assets.php
Outdated
@@ -375,6 +385,18 @@ function gutenberg_extend_wp_api_backbone_client() { | |||
return model.prototype.route && route === model.prototype.route.index; | |||
} ) ); | |||
}; | |||
wp.api.getTaxonomyModel = function( taxonomy ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eugh, why is rest_base
a thing 😞
lib/client-assets.php
Outdated
@@ -375,6 +385,18 @@ function gutenberg_extend_wp_api_backbone_client() { | |||
return model.prototype.route && route === model.prototype.route.index; | |||
} ) ); | |||
}; | |||
wp.api.getTaxonomyModel = function( taxonomy ) { | |||
var route = '/' + wpApiSettings.versionString + this.taxonomyRestBaseMapping[ taxonomy ] + '/(?P<id>[\\\\d]+)'; | |||
return _.first( _.filter( wp.api.models, function( model ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is copy-paste, but we should really use _.find
here so we're not filtering the entire list if match is one of the first entries.
I don't like special cases but if we want this, ok.
No personal preference for me. We can use a generic "Taxonomies" Panel, or maybe have a Panel per taxonomy to avoid special-casing |
I prefer leaving "Flat" because it indicates that the component is not usable for hierarchical taxonomies (avoids ambiguity) |
I have a feeling of déjà vu with this conversation around special treatment of Categories & Tags. I wasn't able to find much prior conversation aside from some of the related effort in Calypso (Automattic/wp-calypso#6744). I seem to recall some conversations with @mtias at the time about how we should treat Categories & Tags as special, independent from other taxonomies (together in their own accordion). Perhaps good for UX because in most real scenarios they're the common taxonomies? But also not consistent, in which case we could opt for:
Testing this makes me wish we support remembering toggle states of accordions 😆 |
Any thoughts on the which option to choose here? cc @jasmussen @mtias |
No strong opinion either way, though slightly leaning towards a single accordion. But I don't think this should hold off the PR from getting merged.
We should, long term, though. |
Ok I'm merging the PR as is now to include it in today's release |
closes #1342
This PR introduces support for custom taxonomies. It transforms the current
CategorySelector
andTagSelector
to more generic components:HierarchicalTaxonomy
andFlatTaxonomy
.This PR uses the same technique used for Custom Post Types to retrieve the
Model
and theCollection
of a Custom Hierarchy in the API client.Caveats
show_in_rest
=> true (issue being worked-on on Trac)Testing instructions
functions.php
of your theme for example):And check that you can set terms to the post for this custom taxonomy. (try switching the
hierarchical
flag)