DexWPA request such as “make the header easier to use on mobile” sounds simple. The result, however, depends on the theme, the navigation, existing customizations and the pages where that header appears. A description of the proposed code cannot tell you everything you need to know about the experience.
For supported code and visual changes, DexWP uses a sandbox so you can try the result before approving deployment to the live site. Dex prepares the change in a staging copy, you inspect it, and the approved work can then be applied to production. Understanding what that copy includes makes the review more useful.
Where the sandbox lives
A Bridge-created sandbox lives on the hosting that already runs your WordPress site. Dex Bridge prepares a separate site directory and copied database tables there. DexWP coordinates the workflow, but it does not move that staging copy into a separately hosted container.
That distinction matters. The sandbox separates the WordPress copy used for testing, but it still relies on your host’s disk space, filesystem permissions and server environment. It is WordPress staging, not container-level isolation. It is also not a substitute for a full-site backup.
If you already have a suitable staging environment, you can connect it through the authenticated setup flow and meet the Bridge requirements there. A staging address by itself is not enough: DexWP needs authorized access to the environment where it will prepare and validate the work.
What is copied, and what is not
The sandbox needs enough of the WordPress installation and database to render and exercise the affected features. The database copy lets the staging site use its own tables rather than treating the live database as a place to experiment.
Existing media files are not duplicated as part of the Bridge sandbox workflow. The preview can display those existing images without copying the entire uploads library. On a site with years of photography or downloadable assets, that avoids one potentially large source of duplicate storage.
Skipping media does not make the sandbox free of storage requirements. Database tables, themes, plugins and other copied files still take space. A large database or a restricted hosting account can prevent setup from completing. The useful response is to address that specific requirement or connect an appropriate staging environment, rather than attempt the untested change on the live site.
Follow setup progress in DexWP
When a task needs this workflow, DexWP can guide you through the sandbox requirement. You should not need to know a special phrase to request a private preview. The nature of the proposed work determines whether supported sandbox preparation is needed.
The workflow reports progress as it checks requirements and prepares the copy. Creating tables and copying files may take longer on a larger site or a slower host. A failure message should be treated as a point to investigate before continuing, not as proof that a usable preview exists.
Use the Sandbox page for the selected site to inspect the available copies and their state outside the conversation. Check the site name and address, particularly when you manage several similar client websites. A preview is useful only if it belongs to the site and task you intend to review.
Why theme work uses a separate child theme
Directly editing a parent theme creates an obvious maintenance problem: a later theme update may replace the edited files. DexWP’s theme workflow therefore uses a child theme for supported changes.
If your active theme is already a child theme, DexWP creates its own copy for the work instead of overwriting your original child theme. Existing customizations can be carried into that working copy, while the original remains available. After approval, the DexWP-managed theme can become the active version without removing the customer’s original theme files.
This makes the boundary between original and proposed code clearer. It does not mean every visual change can be reversed without considering what happened afterward. Later edits and additional deployments still matter, so inspect the proposed reversal rather than assuming an old snapshot should always replace newer work.
How fixes to other plugins are handled
When a plugin exposes a suitable hook or extension point, a supported fix can live in Dex Customizations rather than in the original plugin’s files. That keeps the custom behavior separate when the upstream plugin is updated.
Not every plugin problem can be solved through an external customization. Some changes depend on private implementation details or require cooperation from the plugin developer. Dex should identify that limitation instead of pretending that a separate plugin can override anything safely.
A request to build a genuinely new plugin is different: it should produce a separate plugin for that purpose. In either case, review dependencies. If the original plugin is disabled or removed, the customization should not assume its functions are still available. That is an important behavior to test in the staging environment.
Review behavior as well as appearance
Open the preview beside the chat when you want to discuss changes while looking at them. You can resize the embedded view or open the preview in a separate tab. If the host prevents embedding, use the separate view rather than treating an empty frame as a working preview.
Begin with the page named in your request, then look at nearby cases that share the same components. A change to a global navigation menu deserves a check on a post, a page and a narrower screen. A product-page adjustment deserves a check with realistic titles, prices and image dimensions.
- Try the interaction: open menus, follow links and exercise the affected controls.
- Check narrow and wide layouts, including long headings and real content.
- Look for missing assets, broken spacing and unexpected text changes.
- Verify the relevant business behavior without creating unintended real-world transactions or messages.
- Return to Dex with specific observations and repeat the check after a revision.
A staging copy can contain integrations copied from the original site. Treat email, payment and other external side effects carefully. Having a different URL does not, by itself, prove that every third-party integration is isolated from its live service.
Approve a focused deployment
Once the preview is ready, read the proposed deployment and confirm its scope. Approval applies the prepared, supported changes. It should not replace the live database wholesale with the staging database, which could overwrite content or activity added while the preview was being reviewed.
Check the live result after deployment as well. Production caching, traffic and integrations can differ from the preview. If you need to undo work, review the available reversal and any conflicts with changes made since deployment. Preserving later customer edits is part of a careful recovery, not an optional detail.
Return to the sandbox when you need it
Sandbox access turns off after an hour of inactivity. When you return to the task, resume it from DexWP. Suspension does not mean the copied files and tables have disappeared; it closes access so the preview is not left continuously available.
Private access controls and indexing restrictions are intended to keep previews out of ordinary public navigation and search results. Do not use the preview URL as a public launch link. When the copy is no longer needed, remove it through the supported workflow to recover its storage.
The value of a sandbox is the opportunity to inspect a concrete result, ask for a correction and make an informed deployment decision. Give that review enough attention to match the importance of the change, then use DexWP’s conversation to keep the next step clear.