Skip to content

fix: preserve archive filter directory context - #2985

Merged
Armanul46 merged 2 commits into
sovware:developmentfrom
RabbiIslamRony:fix/archive-filter-directory-reset
Sep 1, 2026
Merged

fix: preserve archive filter directory context#2985
Armanul46 merged 2 commits into
sovware:developmentfrom
RabbiIslamRony:fix/archive-filter-directory-reset

Conversation

@RabbiIslamRony

@RabbiIslamRony RabbiIslamRony commented Aug 30, 2026

Copy link
Copy Markdown
Member

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Security fix
  • Improvement
  • New Feature
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Text changes
  • Other... Please describe:

Description

Reported problem

A customer has three Divi Listings archive pages, each configured for a different directory type: Catalogo, Cerco Sponsor, and Sono Sponsor. The filter modal on all three pages rendered the Catalogo fields. As a result, the Location and Category controls appeared to be wrong or unavailable for the other two directories. The modal footer Reset Filters action also left selected checkbox, radio, and select values in place.

Root cause

The archive listing model read $_REQUEST[directory_type] before the configured directory for a listing archive instance. That allowed a stale request-level directory context to override the module-specific default_directory_type. The filter form then rendered the wrong directory schema.

The reset handler only reset forms it could find through the surrounding contents wrapper. It did not reliably reset controls inside the active modal itself.

Changes

  • Archive listing instances with an explicit default directory now keep that directory context before considering request-level values. Search-result pages continue to honor a requested directory filter.
  • Reset Filters now targets the active search modal first, clears checkbox/radio state, restores select fields to their placeholders, refreshes Select2, and removes selected UI states.
  • Generated build files are intentionally excluded from this PR.

How to reproduce the issue or test the changes

  1. Create or configure three archive/listing modules with different default_directory_type values.
  2. Seed a different directory_type request value and open each archive filter modal.
  3. Confirm every modal retains its own configured directory and displays only its corresponding Location, Category, and custom fields.
  4. In an advanced modal, select a Location/Category or custom checkbox/radio value.
  5. Click Reset Filters and confirm all fields return to their default state and selected UI styles clear.
  6. Verify desktop and mobile modal behavior.

Any linked issues

Support ticket: https://secure.helpscout.net/conversation/3427558246/6335
TeamSync: https://team.sovware.com/support/cmtfhskeq04p78ns6jm1eip92

Checklist

Validation

  • WP-CLI: an archive instance retained its configured classified directory despite a stale request value; a search-result instance still respected the request directory.
  • Browser QA: Reset Filters cleared an advanced-modal checkbox and its selected UI state.
  • php -l includes/model/Listings.php passed.
  • Local PHPCS could not complete because the installed WPCS version is incompatible with the current PHP runtime.

Dependent Divi Integration fix

This core change must be released together with the Divi archive event-propagation fix: https://github.com/sovware/directorist-divi-integration/pull/112

@RabbiIslamRony RabbiIslamRony added this to the v8.9.4 milestone Aug 30, 2026
@Armanul46 Armanul46 modified the milestone: v8.9.4 Sep 1, 2026
@Armanul46
Armanul46 merged commit dda2d63 into sovware:development Sep 1, 2026
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants