Opened 8 years ago
Closed 8 years ago
#43521 closed defect (bug) (fixed)
Excluded terms filter in get_adjacent_post is not executed if excluded_terms parameter is empty
| Reported by: | zottto | Owned by: | pento |
|---|---|---|---|
| Priority: | normal | Milestone: | 5.1 |
| Component: | Posts, Post Types | Version: | 4.9.4 |
| Severity: | normal | Keywords: | has-patch has-unit-tests |
| Cc: | Focuses: |
Description
The filter get_previous_post_excluded_terms / get_next_post_excluded_terms is only executed if the parameter $excluded_terms of get_adjacent_post (resp. get_previous_post / get_next_post) is set.
If $exclued_terms is not set (e.g. because the parameter is optional) it is not possible to change the list of excluded terms.
Expected behaviour: The filter should also be executed with an empty $exclided_terms list to be able to add terms to this list.
The apply_filter is called within a condition if ( $in_same_term || ! empty( $excluded_terms ) ) which is not met if the parameter is empty.
Attachments (4)
Change History (13)
#4
@
8 years ago
- Resolution fixed
- Status closed → reopened
Hi, thanks for fixing the bug so fast.
But in my opinion there is now another change in the behaviour of the filter.
Before the fix, the filter was applied only to an array of term IDs. Now the filter is applied before the backwards compatibility part that changes the old usage of term IDs concatenated with "and" to an array.
If the filter is executed now it could happen that the term IDs handled in the filter are in the old style which was not possible before.
From my point of view it would be better to apply the filter after that back-compat part (or to execute the back-compat part before the filter, whatever makes more sense).
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Patch + tests