Modals disappear from DOM for users with no listings (Multisite)

Bug Reports
1

Describe the issue

Running HivePress on a WordPress Multisite network with several subsites, all sharing user accounts via WP’s native multisite user tables. HivePress core 1.7.31, HivePress Reviews frontend JS 1.4.0.

On subsites where a user has never submitted a listing, HivePress modals (listing_report_modal, review_submit_modal, delete-account, etc.) don’t open. The trigger link changes the URL hash to #modal_name, but nothing renders.

Traced this to a specific mechanism: the modal HTML is present in the initial page source (document.documentElement.innerHTML.includes('listing_report_modal') → true on both working and broken subsites), but on broken subsites the modal elements are removed from the live DOM after page load — document.querySelectorAll('.hp-modal').length returns 2 on a working subsite vs 0 on a broken one, for the same logged-in user.

The deciding factor seems to be whether the user has ever submitted a listing, not which subsite they registered on:

  • Subsite1 (user has listings submitted): modals work.
  • Subsite2 (user had 0 listings): modals broken. Submitting one Free-plan listing immediately fixed it.
  • Subsite3 (user has 0 listings): same broken pattern, currently unresolved.

Ruled out:

  • LiteSpeed Cache — tested relevant settings off, then fully deactivated the plugin. Bug persisted.
  • Missing/mismatched frontend JS — confirmed identical common.min.js/frontend.min.js (1.7.31) and hivepress-reviews frontend JS (1.4.0) load on both working and broken subsites.
  • Custom site JS — a custom mobile-nav/loading-overlay script is byte-identical across subsites and has no reference to hp-modal or related classes.

Haven’t yet identified the specific script removing the .hp-modal nodes. Chrome DevTools “Break on node removal” didn’t catch it, nor did instrumenting Node.prototype.removeChild/Element.prototype.remove with debugger.

Steps to reproduce

  1. Log in as a user who has never submitted a listing on the current subsite.
  2. Open a page with a HivePress modal trigger (e.g. Report Listing, review submission).
  3. Run document.querySelectorAll('.hp-modal').length in console. Compare against a user who has submitted a listing.
  4. Click the modal trigger link.

Actual result
.hp-modal elements exist in raw HTML but aren’t in the live DOM for users with no listing-submission history. Hash changes on click but nothing opens.

Expected result
Modals like review submission, report-listing, delete-account should work for any registered user regardless of listing-submission history. Owning a listing shouldn’t be a prerequisite for these generic modals.

Extra details
Looking for the actual PHP component/hook conditionally omitting these modals, not workarounds like dummy listings or forced free-listing submission.

Thanks!

3

Thanks for the detailed bug report. We’ll try to test this further and let you know, user modals (like Report Listing) should be available in any case – there are modals that require specific permissions (like Delete Listing) that may be hidden if the current user is not a vendor (has no vendor profile and a Contributor role). Please also make sure there are no third-party PHP or JS (if modals disappear after the page is loaded) scripts that may cause this issue.

1 Like
7

Hi,

Thanks for the detailed report.

The bug has been confirmed, and we’ll address it in one of our future updates.

1 Like