Old PHP code after a WordPress deployment: check OPcache and the correct release

Distinguish an old result from an old program being executed

After replacing a PHP file, WordPress seems to retain its previous behavior. A function remains absent, a message cites an old line, or the correction disappears depending on the request. OPcache may be involved, but simply displaying an old page is insufficient to identify it.

OPcache retains a compiled version of the PHP program to avoid preparing it again for every request. This code cache differs from a cache retaining an HTML page or WordPress data. Clearing browser cookies or the object cache does not necessarily update these programs.

The desired result is for the web process to use the expected release with a consistent refresh mechanism. We will first confirm files and destination, then examine the validation and invalidation policy. A general purge or restarting every service might change the symptom without explaining why the release was not picked up.

Confirm the files and every responding server

In the deployment process, compare the intended file with the one actually installed at its active path. A correct copy in an old directory is unused if the domain points elsewhere. A release link may also target a version other than the one viewed through file access.

If several servers respond, check their consistency before blaming the cache. One request may reach an updated node and another a node still on the old release. A version number read on one machine does not describe the entire service.

1. Record the deployed version, affected file, and expected behavior.
2. Confirm the root and path actually used by the domain.
3. Privately compare content and file information with the known release.
4. Have every active node checked when the architecture contains several.
5. If files differ, first complete a consistent deployment. Do not force invalidation to mask an incomplete copy or incorrect path.

Rule out a page cache before the PHP layer

An old HTML response can be served without executing the file you just changed. Compare a request that actually passed through PHP in the intended flow, using private logs or the provider’s diagnostic mechanism. Do not assume that a parameter added to the URL bypasses every cache.

If only a retained page is old, address its generation and invalidation in the relevant page cache. If a process actually executing PHP behaves incompatibly with the confirmed files, the code cache becomes a more relevant lead. Both phenomena can coexist.

Keep the time and request used for the check. Avoid modifying commercial content or submitting a form for technical evidence: use a representative copy and a read without external effects. An error line may also correspond to an earlier version if you are viewing an old log; check its date. The aim is to establish a current difference between deployed and used code, not successively clear every layer until a page changes.

Identify the PHP context serving the domain

Record the site’s PHP version and execution mode from available information, then have the operator confirm the service handling its requests. Terminal access may use another executable and configuration file. A local command’s result therefore does not prove what the domain does.

In the private diagnostic mechanism already provided by hosting or the release pipeline, request the web context’s effective OPcache configuration, particularly timestamp validation and its frequency. The functions opcache_get_configuration() and opcache_get_status() report on the instance executing them; the latter describes the memory cache, not the disk cache. The operator may restrict access to them.

Do not create a public page displaying phpinfo() or the script inventory. This information may expose internal paths. If no private tool is available, send support the domain, time, path, and expected version so it can supply a targeted record. Keep web results separate from terminal results. An empty cache observed on the command line does not rule out an old web cache.

Prepare a change with verifiable rollback

Choose one hypothesis before changing the service. If deployment is incomplete, correct the files; if deployment policy requires invalidation, examine that step; if timestamps should be checked automatically, verify effective values. This decision avoids combining a configuration change and a purge whose effects would be hard to separate.

Keep a private backup of active configuration and the reference for the currently installed release. A staging copy helps reproduce behavior provided its PHP mode and cache policy are comparable. It does not guarantee that production shares the same settings.

1. Identify the PHP service owner and the scope of any other affected sites.
2. Record effective values, the file or panel enforcing them, and the documented application procedure.
3. Prepare the read-only check that will show the version actually used.
4. Define rollback to the previous configuration and who is responsible for applying it.
5. Make one correction, then compare results with the initial record before considering another lead.

Restore timestamp validation when intended

When automatic validation is enabled, OPcache checks changes according to its revalidation frequency. When disabled, lowering that frequency resolves nothing: deployment must refresh code through an explicit mechanism. First confirm whether disabling it was intentional.

On a site whose files are replaced in place and whose policy calls for automatic detection, the operator may restore the following values in the appropriate PHP configuration. Two seconds here corresponds to the documented default; it is not a promise that every release will be fully visible within that time. A zero frequency checks every request, with a cost to assess.

This example is INI configuration, not PHP to paste into wp-config.php. Do not add it simultaneously to several files hoping one will be read. In an intentionally immutable release process, retain the approved policy and instead repair the invalidation step or service renewal planned by the operator.

opcache.validate_timestamps=1
opcache.revalidate_freq=2

Apply configuration in the relevant service

A file saved on disk and an active value are two different states. How configuration loads depends on the PHP integration. Use your hosting or operations team’s documented mechanism to apply the change to the service serving this domain, then reread the effective value in that same context.

Do not choose a restart command found at random: service name, version, and scope differ between installations. A panel may manage several PHP versions on the same server. The operation must target the site’s version and respect other dependent applications.

A success response from the panel primarily means that the action was accepted. Then check site availability, new errors, and expected behavior. If application fails, restore the backed-up configuration using the same documented procedure. Do not leave an invalid file in place waiting for a future restart. If you do not manage the service, ask support to confirm the value after application instead of adding more local configuration files.

Invalidate a file within an existing private procedure

If deployment uses targeted invalidation, have its path and execution context checked. The call must reach the relevant web PHP instance through an existing protected and administered private procedure. A call from a terminal or wp eval may concern another context: success does not establish that visitors use the new program.

The following example illustrates invalidating a known file in that existing procedure. Replace the path with that of the file actually deployed. The second argument requests invalidation regardless of timestamp comparison. According to current PHP documentation, the corresponding file-cache entry is also invalidated when that cache is enabled.

The return value does not prove that the whole application is current: a positive response may also mean there was nothing to invalidate. A release modifying several files must be handled consistently by its owner. Do not turn this example into a public reset.php file, an anonymously accessible link, or a call executed on every WordPress visit.

opcache_invalidate( '/chemin/absolu/du/fichier.php', true );

Reserve general resets for a controlled scope

A reset may suit a complete release, but must be part of a known procedure. opcache_reset() concerns its instance’s entire memory cache and does not delete the on-disk file cache. It is therefore not a universal eraser for every storage layer or every server.

Ask the operator which applications share this instance and which operation its infrastructure recommends. After a reset, programs must be prepared again; observe load and errors during recovery. Do not repeat the action on every refresh if the result takes time: you could disrupt the service without correcting the wrong path or node.

1. Confirm the instance and included sites before any reset.
2. Prefer the private mechanism integrated into deployment when available.
3. Check that the action was applied to the expected web context.
4. Check a request executing the new code after the action.
5. If the result remains old, preserve evidence and return to release, context, and architecture diagnosis instead of scheduling repeated purges.

Handle preloading and multiple-instance architectures

PHP preloading requires particular attention. Declarations loaded at startup persist in the process; the manual states that restarting the PHP process is necessary to clear them. Ordinary invalidation must not be presented as guaranteed replacement of these declarations. Have someone confirm whether the release actually uses opcache.preload before pursuing this lead.

An application may also combine links to successive releases, several nodes, and a file cache. The logical path viewed by the team does not by itself explain the path used by every process. The operator must examine this architecture and its switching mechanism. Do not recursively delete shared cache directories to test a hypothesis.

If the symptom alternates, correlate requests with nodes and versions in private logs. A forgotten server can recreate the problem after a correction perfectly applied elsewhere. The right alternative is then to complete deployment and renewal on every intended instance. Adding a WordPress plugin to purge more data does not replace that consistency. Keep a short architecture description in the deployment record so the next incident does not start again from a single-server assumption.

Check the code used after the correction

Repeat the initial check on a request whose PHP execution is confirmed. Behavior must match the deployed files and remain consistent across several reasonably spaced reads. If the architecture has several nodes, have each checked through the operations team’s intended route; an isolated success is insufficient.

Then examine new errors without mixing in events from before the correction. An old line number in an entry dated yesterday does not invalidate the current result. Conversely, a recent message associated with the wrong version indicates that part of the problem remains. A correct response from the page cache still does not demonstrate which PHP version would be executed.

1. Record the action time and expected release.
2. Confirm effective values when configuration changed.
3. Run the read check prepared before intervention.
4. Compare results and recent logs on the relevant instances.
5. Check a public journey and administration access without a commercial operation.
6. Record the conclusion: corrected files, restored validation, or repaired deployment step. If evidence remains contradictory, send it to the operator without declaring resolution.

Return to the previous release without overlooking dependencies

If the new program produces a functional error after actually loading, the cache may merely have exposed a release defect. Returning to the old OPcache configuration is not a reliable application rollback: processes could retain a mix of programs depending on their activity.

Use the rollback mechanism planned by your deployment to restore a complete, consistent version, then apply its code renewal procedure. If the update also changed the database, examine that database’s compatibility with the older version. Restoring only a few files can worsen an unfinished migration. The owner must choose coordinated restoration from verified backups when necessary.

For a configuration-only change, restore the saved values, apply them through the documented mechanism, and reread their effective state. Then check availability and recent errors using the same protocol. Keep differences and times in the private record; they help determine whether failure came from code, loading, or the service. A purge repairs neither data already modified nor messages already sent by a defective version.

Prevent old code from returning with the next release

Document one refresh policy per environment. The team must know whether PHP detects changed files or an explicit step accompanies every release. An intentionally disabled option may be entirely consistent with a given infrastructure; it becomes an incident when the compensating procedure disappears from deployment.

Add an observable result of the expected version to release checks without publishing sensitive paths or operational data. Also verify rollbacks to the previous version: their renewal step deserves the same care as initial rollout. Keep the inventory of nodes and PHP service with access reserved for responsible owners.

This diagnosis does not require installing a new cache plugin. The operator’s native tools, file comparison, and a consistent release procedure address the identified problem. If only visitors see an old page while PHP executes the correct program, return to page-cache diagnosis and its scope. If a recent error persists with the correct version, handle that code error separately: refreshing OPcache again does not change a program already loaded correctly.

Separate disk checks from web-process checks

Prepare two distinct pieces of evidence before invalidation. The first identifies the on-disk release: version reference, active path, and file fingerprint obtained through the private deployment procedure. The second describes a web request actually executed by PHP after deployment: time, relevant node, and expected behavior. Neither record should be added to a public diagnostic page.

If the on-disk fingerprint differs from the release, correct deployment first. If it matches but only one node retains old behavior, examine that node and its PHP process. If the response does not pass through PHP, return to the page cache. This classification avoids treating success from command-line wp eval as proof of web-service renewal.

After correction, repeat the same request without external effects and compare the nodes intended by operations. Do not add an automatic reset loop in a plugin: it would recompile scripts without guaranteeing that the correct service is reached. The native deployment mechanism or hosting panel is preferable to another purge plugin.

For rollback to the previous release, also require its on-disk evidence and web result after renewal. Merely copying back an old version is not a completed rollback if processes still retain the new one. Any data migrations remain a separate check from this code verification.