feat: add Timber::get_terms([..], ['merge' => false]);#3213
feat: add Timber::get_terms([..], ['merge' => false]);#3213
Timber::get_terms([..], ['merge' => false]);#3213Conversation
…t_terms to support grouping by taxonomy
Timber::get_terms([..], ['merge' => false,]);
Timber::get_terms([..], ['merge' => false,]);Timber::get_terms([..], ['merge' => false]);
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 2.x #3213 +/- ##
============================================
+ Coverage 89.83% 90.03% +0.19%
- Complexity 1633 1643 +10
============================================
Files 57 57
Lines 5017 5027 +10
============================================
+ Hits 4507 4526 +19
+ Misses 510 501 -9 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This reverts commit 257fe74.
gchtr
left a comment
There was a problem hiding this comment.
@Levdbas I saw that you updated the implementation and removed the from_with_options() method again in favor of an $options parameter in the from() method. This looks clean to me now.
About the following consideration:
Future enhancements:
Themerge: falseoption name is functional but somewhat unintuitive (you set it to false to get grouping). Consider adding agroup_by_taxonomy: truealias in the future for better developer experience
Now we have different terms for the merge parameter in various places: merge, partition, group, split. I think it would be better if we only used one term, and I like the suggestion of using group instead of merge. What this would mean:
- Rename
partitionmethods and comments togroupin this PR - Leave the name of the
$mergeparameter, because that would be a breaking change - Starting using
groupin comments, variable names, methods, where we can.
I think this might help to understand this feature better.
…te documentation for term grouping by taxonomy
Related:
Issue
When working on the
PostQuery::terms()feature suggested by @cbirdsong , I ran into code code duplication betweenPostandPostQueryfor splitting term results by taxonomy. Then I remembered the very old Feature request in #2211 and decided to give that a shot.Solution
Moved the taxonomy splitting logic into
TermFactoryand exposed it through the existing but unused$optionsparameter inTimber::get_terms().Changes:
from_with_options()method to handle themergeoption andpartition_tax_queries()helper. I am not really a fan of this. Maybe @gchtr or @nlemoine can lend some eyes on this?get_terms()to pass options through to TermFactorypartition_tax_queries()and delegated toTimber::get_terms()Impact
Timber::get_terms()public API(Backwards) Compatibility:
All existing
Post::terms()and maybe futurePostQuery::terms()calls work identicallyUsage Changes
Users can now use the
mergeoption directly withTimber::get_terms():This was previously only available through
Post::terms()andPostQuery::terms()methods, which continue to work as before:Considerations
Future enhancements:
The
merge: falseoption name is functional but somewhat unintuitive (you set it tofalseto get grouping). Consider adding agroup_by_taxonomy: truealias in the future for better developer experienceTesting
Unit tests included
Added two new tests in
TermTest.php:testGetTermsGroupedByTaxonomy()- Verifiesmerge: falsecorrectly groups terms by taxonomytestGetTermsMergedByDefault()- Verifies defaultmerge: truebehavior returns flat array