A GravityView embedded inside another View can make an apparently unrelated parent disappear before a search. Check the two View IDs and their individual search-visibility settings before changing permissions or rebuilding the form. A hidden result set and an unauthorized result set are different problems.
Start with the relevant release fix
The GravityView changelog lists a fix in 3.10.0 for an embedded View making its outer View inherit the inner hide-until-search setting. Record your installed version and compare a supported update on staging. The release note identifies one defect, not the cause of every empty directory.
Write down the page ID, outer View ID, inner View ID, and the form attached to each. Include the place where the inner View is embedded, such as a field or template. Similar display names are not sufficient: two Views can use the same form while having different settings and purposes.
Reduce the layout without changing access
Use a staging copy containing synthetic entries. Keep the membership rules, entry approval requirements, and relevant user role unchanged. Create an outer-only test page and an inner-only test page using the same Views. Compare those with the nested page.
If the outer-only page works but the nested page does not, the embed is a useful isolation point. If all three fail, inspect the underlying query and access configuration first. Do not disable protection to make a test directory populate. A populated page is not a success if the wrong visitor can read it.
For the initial test, give the outer View an unmistakable heading and its own test record marker. Give the inner View a different heading and marker. That makes it possible to tell whether the entire parent disappeared or only the child area stayed empty.
Four parent and child search states to test independently. Hidden-until-search is not an access-control boundary. Explanatory diagram.
Exercise four search states
Use the same authorized test account throughout this sequence. Choose search terms that match the synthetic records and note which search control belongs to which View.
| State |
Outer observation |
Inner observation |
| Neither searched |
Follows outer configuration |
Follows inner configuration |
| Outer searched only |
Intended outer matches |
Does not pretend a child search occurred |
| Inner searched only |
Must not silently change outer policy |
Intended inner matches |
| Both searched |
Correct parent results |
Correct child results |
If your layout does not expose an independent child search control, record that limitation and test the child separately. Do not invent a query parameter to force a state. Use supported controls and the actual generated URLs.
Reset each search and revisit the page without its query string. Then use browser Back and reload the resulting address. A first visit that works followed by a reset that hides the wrong region suggests retained state or an interaction between controls. Record the precise sequence rather than reporting only that search is intermittent.
Separate visibility from matching
An empty result after searching may be correct when nothing matches. Use a known matching test entry and a known nonmatching entry so that a visibility fix cannot conceal a broken filter. If the View appears but the returned set is wrong, continue with the multi-select ANY, ALL and NONE diagnostic.
Compare response behavior with the site cache in its normal supported configuration. If a stale page persists after updating, purge the affected page through the cache owner's controls and repeat the exact sequence. Avoid globally disabling caching on a busy site just to see whether something changes.
Acceptance criteria for the repair
The outer View must follow its own configured visibility policy. The child must follow its own policy. Search, reset, reload, and return navigation must preserve those boundaries, and the intended visitor must still see only permitted entries. Repeat with the denied role to confirm the repair did not broaden access.
Keep before-and-after versions, the three page URLs, test View IDs, and observed markers in a short support record. HandL WP can trace a nested View failure when the standalone and embedded results differ. Send synthetic examples, not customer directory records. These steps are a diagnostic proposal, not a claim that the issue has been reproduced on your installation.
Sources reviewed November 1, 2026. Examples and diagrams are diagnostic aids, not customer test results.