A WordPress page stops working after a change. You open Codex and want it to fix the problem. The fastest useful first instruction is usually not “disable the plugins.” It is “use Novamira to inspect this site and tell me what actually failed.”
The workflow is Codex → Novamira MCP → WordPress → browser check. Codex is the AI assistant. Novamira is the WordPress plugin that lets it inspect and work on the connected site. MCP, short for Model Context Protocol, is the connection method used here.
This guide walks through a teaching example: one page shows a critical-error message after a small code change. It does not claim that a real customer incident was repaired. Your error, file, and result must come from your own inspection.
Before you ask for a repair
Use a staging site for changes. This is a separate test copy where a failed experiment will not interrupt visitors. Have a recent backup and know who can restore it. A copy of the affected file can undo a file edit; it cannot undo every possible database change.
Novamira provides broad website access when enabled. Its configuration guide describes actions including PHP execution, database work, and file editing. Asking for read-only work is a useful instruction, but it is not a replacement for actual permissions and a test environment.
For this main route, Codex must already have a working Novamira connection to the staging site. If you have not connected it yet, follow the setup in the Codex WordPress walkthrough. You do not need WP-CLI for the steps below.
1. Record the failing page and action
Where: your browser and Codex. Open the affected page. Copy its address, note the time and timezone, and record the exact message. If you clicked something before the failure, describe that action too.
A critical-error message does not identify its cause. You may also see HTTP 500, which means the server could not complete the request. That number alone does not identify a plugin or a line of code.
What to check: another person could repeat the same action from your description. Give Codex this information and ask it to inspect through Novamira without changing anything yet.
2. Confirm the connected site before investigation
Where: Codex. Ask it to discover the available Novamira abilities, read the relevant instructions, and return the connected site’s Home and Site URL values. Compare them with your staging address.
Novamira abilities are the site actions Codex can use. The assistant should discover and inspect them rather than invent a special troubleshooting tool. A PHP ability can work with WordPress functions, but the actual inputs must come from the current connection.
What to check: Codex has read the intended site now. If it cannot connect, say that the connection failed; do not describe the website problem as diagnosed. Use the official Novamira connection instructions to resolve that separate problem.
3. Check how much of the site is affected
Where: your browser. Open the homepage, the failing page, and one other ordinary page. Compare a logged-in view with a private browser window if the page is public. Record which addresses load and which show the error.
Give that short list to Codex. If only one page fails, keep investigating that narrower problem. Do not treat a single broken page as proof that the whole installation needs rebuilding.
What to check: you know whether the failure is limited to one page, one action, or the whole site. If WordPress cannot load enough for Novamira to respond, use your host’s recovery route instead of pretending the connected-tool route is available.
4. Ask Novamira for the relevant site facts
Where: Codex. Ask it to inspect the active theme, installed plugin names and versions, the affected page, and the code or template that appears to control it. Keep this request read-only.
Use Novamira on [staging address]. Read only.
Investigate [page address] after [known recent change].
Separate facts you read from possible explanations.
Find the relevant page, theme or custom code.
Do not disable plugins or edit files yet.What to check: the response contains actual values and identifies what is still unknown. The latest updated plugin may be worth inspecting, but timing alone does not prove it caused the failure. Ask Codex to distinguish that guess from a finding.
5. Match the error to the time you recorded
Where: Codex through Novamira, if the relevant private log is available. Ask it to locate the log through the site’s known configuration and inspect entries around your request time. Do not give it a guessed public log address.
An error log is the server’s record of a problem. It may name a file, function, or missing dependency. If the connection cannot read the log, ask hosting support for the relevant entry and give them the page address, time, and timezone.
WordPress’s debugging guide explains its logging settings. For a test site needing logging, have Codex propose that specific configuration change separately. Keep error details out of the visitor page.
What to check: the entry belongs to the failed request you are investigating. An old warning from yesterday is not enough. Keep full logs private and share only the relevant details needed to continue.
6. Reproduce the failure on the test copy
Where: the staging page in your browser. Repeat the same action. Tell Codex whether it produces the same message, then have it compare the relevant site facts if production and test behave differently.
A stale test copy may have different plugin versions or content. Fix that understanding before choosing a repair. Otherwise, an apparently successful staging change may have nothing to do with the original problem.
What to check: you have a repeatable failure on the environment where the change will be tried. If you cannot reproduce it, keep investigating rather than asking for an unrelated cleanup.
7. Review one proposed change
Where: Codex. Ask it to explain the most likely cause, the observation supporting it, and one small test of that explanation. The proposal should name the file or setting it would change and how to restore the old state.
For example, if the log points to a recent custom-code edit, Codex should read that exact code and compare it with the known previous version. It should not immediately deactivate unrelated forms, translations, or payment plugins.
What to check: you can explain why the proposed change relates to the error. If the cause is still uncertain, ask for the next read that would distinguish the likely explanations. A longer patch does not compensate for a missing diagnosis.
8. Make the agreed repair through Novamira
Where: Codex. Once the proposal and recovery copy are ready, authorize that change on staging. Ask it to use the discovered Novamira ability, preserve unrelated work, and read the saved result afterward.
If the write fails or times out, check what was actually saved before repeating it. If the change makes the problem worse, use the agreed recovery method and return to the last understood state.
What to check: Codex reports a completed action and its saved result, not merely a plan. Keep the repair on staging while you perform the browser checks.
9. Repeat the original action in the browser
Where: the same staging page and browser state used to reproduce the failure. Repeat the exact action. Then check an ordinary page that was working before the repair.
Have Codex inspect the relevant log entries from this new test window if it has access. A clean-looking page and a new error entry deserve another look. If the repair involved a button or layout, check a narrow window as well.
What to check: the original problem no longer appears in the tested conditions, and the adjacent page still works. Record limitations. Testing one page does not establish that every feature on the site works.
10. Write a result you can use tomorrow
Where: Codex and your project notes. Record the failed action, the cause supported by inspection, the changed file or setting, the recovery reference, and the checks actually completed. State clearly that the result is on staging.
Production deployment is a separate decision followed by its own checks. Do not report a live repair from a local or staging result. A short accurate note is more useful than “everything fixed” without a location.
You can save a recurring investigation procedure as a Novamira Skill. It is an instruction for future work, not a technical limit on the assistant’s access. Compare the optional terminal route in WordPress MCP vs WP-CLI, or explore the WordPress playbook overview and free sample for guided practice.