Fix multi-directory save flow and Directory Builder access

[RabbiIslamRony]

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

Problem

The Enable multi-directory setting behaved differently from the other settings switches: it opened a confirmation modal, saved immediately, and forced a page reload.

After moving the switch to the standard footer Save changes flow, another existing routing problem became visible. The settings request is saved through AJAX, so the WordPress admin menu on the current page still contains the route from the previous multi-directory state:

• Disabled mode displays page=atbdp-layout-builder.
• Enabled mode displays page=atbdp-directory-types.

Previously, only the route for the newly saved state was registered on the next request. Clicking the stale menu link or opening a bookmark for the inactive route therefore produced WordPress's Sorry, you are not allowed to access this page. response, even for an administrator.

Solution

• Removed the confirmation, immediate-save, and forced-reload metadata from enable_multi_directory.
• Kept the visible Directory Builder route mode-specific, preserving the existing archive/editor screen IDs and asset-loading behavior.
• Registered the inactive slug as a hidden compatibility page with the existing manage_options capability.
• Redirected the inactive slug during the page load lifecycle to the currently active Directory Builder route using wp_safe_redirect().
• Kept only one visible Directory Builder submenu item.
• Documented the manual-save and compatibility-routing contracts in the settings-panel references.
• No setting keys, defaults, saved values, directory data, or generated assets are changed.

How to reproduce the original issue

1. Disable multi-directory and open Directorist > Settings > Directory > General.
2. Enable multi-directory and save through the footer Save changes button.
3. Without reloading the settings page, click the still-visible atbdp-layout-builder Directory Builder menu link.
4. Repeat in the opposite direction by disabling multi-directory while the current menu still links to atbdp-directory-types.
5. Before this fix, either stale route could show the WordPress access-denied page because that slug was not registered for the newly saved mode.

How to test the changes

1. Start with multi-directory disabled and confirm the switch changes without a modal, automatic save, or page reload.
2. Confirm the footer Save changes button becomes enabled, save the setting, and verify the button reports Saved while the page remains in place.
3. Click the stale atbdp-layout-builder menu link and verify it redirects to atbdp-directory-types, loads the directory archive, and shows only one Directory Builder submenu item.
4. Open page=atbdp-directory-types&listing_type_id=3&action=edit and verify the Business directory editor loads normally.
5. Return to settings, disable multi-directory, and save through the footer button.
6. Click the stale atbdp-directory-types menu link and verify it redirects to atbdp-layout-builder and loads the default Business directory editor.
7. Directly open either inactive route in both modes and verify it redirects instead of showing an access-denied response.
8. Confirm the original disabled setting state can be restored and that no duplicate Directory Builder menu item appears.

Verification performed

• Completed the enabled and disabled stale-menu flows in the signed-in local WordPress admin.
• Confirmed the enabled archive loads builder-archive.js and the editor loads multi-directory-builder.js.
• Confirmed PHP syntax for both changed PHP files with php -l.
• Confirmed the committed diff passes git diff --check.
• Full local PHPCS was unavailable in this checkout because vendor/bin/phpcs is not installed.
• The GitHub PHPCS Check workflow currently stops at its checkout step for fork PRs: its pull_request_target job attempts to check out the fork SHA, which GitHub rejects as unsafe before PHP setup or PHPCS execution. The reported failure is therefore an upstream workflow-policy failure, not a PHPCS result for this code. View the failed checkout job.

Any linked issues

None.

Checklist

• My code follows the WordPress coding standards