Check an AI-proposed PHP snippet before activating it in WordPress

Define the result and retain the received file

An AI assistant has proposed PHP to add a notice to a WordPress page. Before choosing where to place it, state what the code should do in one verifiable sentence. In our exercise, a paragraph reading “Repère local PHP 731” must appear once at the end of the content on the “Atelier test PHP” page, on a local copy. The neighboring page must remain identical. The text entered in the editor must remain unchanged. After deactivation, the paragraph must disappear without restoring the database.

These criteria separate three checks. The first says whether PHP can parse the file. The second says whether WordPress executes the code at the correct time and within the right scope. The third says whether you can stop its effect and, when the code has changed data, restore the expected state. A positive answer to one does not determine either of the other two.

Keep the received file in a local working folder and make a second copy for corrections. Record the date, origin, expected effect and target WordPress version. Do not yet place any of these files under WordPress's served directory. If several snippets are proposed, separate them and start with just one. You can then connect a visible difference to the exact version that produced it.

A simple text addition can be made directly in a Paragraph block. If that meets the actual need, this solution avoids a PHP dependency. The case below deliberately uses a filter to teach you how to check when code intervenes. Replace the exercise with your own objective only after reproducing the checks with dummy data.

Read the effects before executing code

First find the first instruction executed when the file loads, then the functions hooked into WordPress. An action or filter is an entry point that WordPress calls at a specific time. For each entry point, identify the pages or operations involved, the conditions that must be true and what the function returns or changes. A comment may say “only on this post” while the code never checks the current post.

Distinguish a string returned for display from a persistent write. A call to update_option(), wp_update_post() or the database layer may change state even if the page looks identical. Also record scheduled tasks, account creation, file deletion and activation-time operations. For each, ask which exact item would be affected, with which permissions and what reverse operation. For a form or administrator action, authorization and protection against a forged request are two separate checks.

Identify possible outputs. An email, HTTP request or API call may be sent on the first display. Code that dynamically constructs function names, decodes an opaque block or loads a file you cannot read does not permit this review. A list of suspicious functions helps orient you but does not suffice to prove harmlessness. Also examine indirectly called functions and included files. If you cannot explain an effect or destination, stop at reading.

Keep the code and observations in your local files. Do not send snippets, logs or a database copy to an online PHP checker or assistant. Even an ordinary-looking file may contain a private domain, internal paths or a value granting service access. Consult a public reference by function name when information is missing.

Check syntax with the correct PHP version

If you have a terminal and local PHP interpreter, switch to the working folder containing atelier-test-php.php. In PowerShell, Get-Command php helps identify the program used. The CLI version is the command-line version. Compare at least its major and minor versions with those WordPress shows under Tools → Site Health → Info → Server in the target environment. A copy using a newer version than the target may accept syntax the target rejects. Use the same version where possible and also record the exact version and required extensions.

The two commands below are independent. The first gives the version; the second asks PHP to parse the file without executing it. In PowerShell, reading $LASTEXITCODE immediately after the check gives the command status. In a POSIX-compatible terminal, use echo $?. Expect a zero status and success message. If the terminal cannot find PHP, use your local environment's interpreter path or ask someone with that version to perform the check. Do not substitute an online checking service.

A plugin file begins with <?php. If the received code is intended for a field that wraps PHP itself, create a working file with a single opening tag for checking. Without an opening tag, PHP may treat the text as ordinary content and report no errors even though the instructions were not parsed. Check the final file and repeat for every other PHP file delivered with it. If an error occurs, correct one thing at a time, also reread the previous line and check again.

Successful linting does not verify that WordPress functions exist, that the correct number of arguments is supplied at the actual call, or that queries and permissions are appropriate. Nor does it check what an included file will do once loaded. Do not run php atelier-test-php.php to try an unknown snippet. The next step takes place in an isolated WordPress environment after review.

php -v
php -l atelier-test-php.php

Prepare a copy without sensitive data

The simplest option is a fresh WordPress installation on your machine, with two dummy pages and no real connector. Install the theme or plugin versions on which behavior depends, using authorized files, then disconnect test integrations. If the fault exists only with a particular configuration, reproduce that configuration with dummy entries. A copy of relevant settings is often enough. If a real copy is essential, work with a sanitized version before starting WordPress and keep it on your machine.

Check the local URL, separate database and file folder, and absence of real service credentials. A database shared with the live site defeats isolation. An address that looks like staging is also insufficient. Disable external sending and payment, CRM or synchronization integrations on the copy. Block outbound network access from the test environment if examining code that has not yet proven itself. A WordPress HTTP-blocking setting alone does not cover every way PHP might establish a connection. The exercise below uses no sending or service.

In the copy's wp-config.php only, look for WP_ENVIRONMENT_TYPE. If the constant is absent and your configuration permits it, add define( 'WP_ENVIRONMENT_TYPE', 'local' ); before wp-settings.php loads. If it already exists, check the value and avoid a second definition. This value is a marker read by the code; it does not isolate the machine. Check the address and database separately. If the copy is managed and you can neither configure it nor stop loading, choose a fresh local WordPress installation.

Take a rollback point before activation, including files and the test database state if writes are planned. For this display example, primarily retain a way to access the plugin folder without opening the administration area. Open that location before the first test. Also record theme and plugin versions that might alter the same content.

Build the control on a single page

Under Pages, create “Atelier test PHP” and “Page témoin PHP”. Set the first page's URL slug to exactly atelier-test-php. Give each a distinct paragraph, then publish both pages only on the isolated local copy. Reopen the target page under Pages → All Pages. In its editing screen's address, record the number following post=. Replace 314 in 314 !== get_queried_object_id() with this local number, without quotes. The comparison uses the WordPress ID directly. Another title or URL slug, even a numeric one, cannot be mistaken for this page. Open both as a visitor before testing and search for “Repère local PHP 731”. It must be absent from both. Note what you see below the paragraph, such as the start of the footer, to detect an addition in the wrong place.

The following file forms a small ordinary plugin. Save it as UTF-8 without a byte order mark and without adding a closing PHP tag. Lint that exact file, then, on the copy only, place it at wp-content/plugins/atelier-test-php/atelier-test-php.php if your installation uses default paths. If the content directory has moved, first find the actual plugins folder. Keep a checked copy outside that folder. Once the file is in place, “Atelier test PHP” should appear under Plugins → Installed Plugins.

The code returns without registering outside the local environment. On the copy, it adds text to the the_content filter's result only in the requested page's main loop. Comparing the current content with the queried object also excludes another entry whose content is evaluated within the page. The REST API check excludes that context when WordPress has flagged it. Nothing here changes the saved post. If you want a sentence on a real page, use a solution validated for that need. This exercise plugin is designed to remain in the sandbox.

<?php
/**
 * Plugin Name: Atelier test PHP
 * Description: Témoin d’affichage sur une seule page d’une copie locale.
 */
if (
    ! defined( 'ABSPATH' ) ||
    ! function_exists( 'wp_get_environment_type' ) ||
    'local' !== wp_get_environment_type()
) {
    return;
}

add_filter( 'the_content', static function ( $content ) {
    if (
        is_admin() || is_feed() || is_embed() ||
        ( defined( 'REST_REQUEST' ) && REST_REQUEST ) ||
        ! is_page() || 314 !== get_queried_object_id() ||
        ! in_the_loop() || ! is_main_query() ||
        get_the_ID() !== get_queried_object_id()
    ) {
        return $content;
    }

    return $content . '<p>Repère local PHP 731</p>';
} );

Compare positive and negative cases

Activate “Atelier test PHP” in the copy's plugin list. Load the target page as a visitor, then the neighboring page in the same browser. Repeat in a logged-in session. A sentence visible on the target page confirms the positive case only if it appears once and in the correct location. The other page, page list and areas around the post serve as negative controls. Then open the target page in the editor. The marker must remain absent from the saved text.

If the administration area says “active” but the marker is missing, check the address, page number in the file and environment type before altering the filter. Also inspect theme rendering. A template not using the main content may never call this filter under the expected conditions. If needed, compare with a standard theme on the copy only, then restore the original theme. A difference between two themes indicates a rendering dependency to explain. It does not justify removing conditions until text appears somewhere.

If an error message appears, record the time and requested page, then find the first corresponding message in the local PHP log. With WordPress debugging, keep visitor-facing error display disabled and choose a private log. Disable this diagnostic setting when no longer needed. An unknown-function error after clean linting often relates to the wrong loading context or a missing dependency. HTTP 200 without the intended result is also a failure. You validate the result and its scope as well as loading.

If the real objective concerns a form, role or order, replace this comparison with equivalent cases. For example, use an authorized dummy user and another without permission, then check that no action occurs for the second. For a saved change, also record the before-and-after state of each affected object. A display test covers neither authorization, persistence nor processing that may occur later.

Choose the loading method

An ordinary plugin suits cases where you have access to the copy's files and code should work independently of the theme. It gives the change a name, a file to compare and a switch under Plugins. Place the code in its own folder. Avoid third-party plugin files and core files, which an update may replace. Mandatory loading through mu-plugins does not offer the same switch. For a first test, keep the file in the ordinary plugins folder.

If your team already manages snippets through a dedicated interface, you can use that same route on the copy. Create an inactive entry, identify execution scope and separately check any option forcing it to load everywhere. Read your tool's PHP-tag instructions. The complete file above includes a WordPress header and opening tag; do not paste it unchanged into a field whose editor already adds the tag. In this approach, rollback means deactivating the specific entry. Make sure you know the documented recovery procedure if that screen becomes inaccessible. A built-in editor check replaces neither linting the working file nor controls on the copy.

If the need belongs to a theme template, a child theme may suit when the team already maintains it. This route requires comparing the affected file with a known version and being able to restore it through file access. Do not add the exercise filter to functions.php as an experiment. A bad test in that file can prevent the entire theme from loading, and rollback then affects the whole file. For a purely editorial or style change, first seek the block or template setting that achieves the result without PHP.

On WordPress.com or managed hosting, installation and file-access capabilities depend on the plan and configuration. In multisite, a test on one subsite does not validate network activation. The exercise is intended for a simple local installation. If the real environment differs in a way that determines the effect, record that as a test limitation.

Rehearse rollback before deciding

While the copy's administration area responds, go to Plugins → Installed Plugins and click Deactivate for “Atelier test PHP”. Reload the same target page without reusing a cached response, then the neighboring page and editor. The marker must disappear from the target; other content must remain as it was. If the marker persists, first check whether the response is old or a second copy of the code loads through the theme or a snippet manager. Do not delete a page to remove a paragraph added during rendering.

If the administration area stops responding, use the copy's file manager. Rename only the atelier-test-php folder to atelier-test-php-arret under the plugins folder, then open Plugins → Installed Plugins and reload the target and control pages. WordPress can no longer find the file at its previous path. Check the plugin status before restoring the original name and keep it inactive until the error is understood. This maneuver applies to the exercise's ordinary plugin. For code also loaded by the theme, mandatory loading or another tool, move or restore the file actually responsible according to its own procedure.

If WP-CLI is already available on the copy, you can deactivate the specific plugin by asking the program to start without loading it. Run the command below from this local installation's folder after confirming it is the correct target. The skip option does not deactivate the plugin by itself. If another cause still blocks WP-CLI, return to file access. Use neither bulk deactivation nor a network option for this case.

Deactivating code stops future execution. An option, post or file it already changed may remain modified. A real snippet that writes therefore needs a second restoration step: restore the affected item's previous value or version, or restore the planned snapshot on the copy and verify its contents. An email already sent or an operation performed by a remote service is not undone by clicking Deactivate. This is precisely why outputs remain disabled during tests. Here, rollback is limited to loading the filter because the code performs no writes.

wp plugin deactivate atelier-test-php --skip-plugins=atelier-test-php

Know when to reject the snippet

Keep a short record containing the exact checked file, versions, target page's local address, control case, results before and after activation and result after stopping. Note whether you merely read a dependency or actually exercised it. A function with valid syntax can still fail when the site receives empty data, an unauthorized account or a case absent from the copy. Add these cases when plausible for your change.

If the code exceeds its scope, you do not know what data changed, or the stop procedure depends on access you lack, keep the snippet inactive. Do the same when the result depends on a PHP version, theme or plugin you could not reproduce. When passing a request to your team, first describe the expected effect, failing condition and error message reduced to what is necessary, according to internal rules. You do not need to give an assistant a site export to establish that the test fails.

Your decision applies to the checked version. If someone renames the function, adds an included file or moves the snippet to a manager loading it earlier, repeat syntax checking, controls and rollback. In the exercise, the expected result is easy to review: one paragraph added to the dummy page's rendering, no saved change and verified removal on the copy.

Start the exercise in a fresh local WordPress installation

WordPress Studio provides a local environment for preparing a small site without copying production accounts or content. Download the application from its official source for your operating system, then create a new local site with a distinct staging name. Open its administration area from the application, create the two dummy pages and record their IDs. Use the site folder provided by Studio to locate wp-content/plugins and place only the exercise plugin there after checking syntax.

Then check the environment type expected by the code. The name “local” in the application does not replace reading wp_get_environment_type() or the guide's constant. Do not enable synchronization to a real site, public previews or an agent that would transmit your snippet during this test. A fresh instance reduces dependencies; it does not demonstrate compatibility with the final server.

If the real code depends on MySQL, a PHP module or a server-specific feature, reproduce those dependencies in a suitable copy before concluding. Success in a different local environment remains a check limited to the scenario actually executed.