Cannot redeclare after a PHP upgrade

Before you start

Save the complete error line and its timestamp in a private note. Record the action that failed, the current PHP versionA PHP version is a numbered edition of PHP, like 8.3. Each edition is looked after for a limited time, then gets security fixes only, then nothing. and any components updated at the same time. Share only information needed for the investigation.

Public support forums are not suitable places for customer details, access credentials or complete server paths.

Back up both files and the database before making changes. Check that the backupA backup is a separate copy of your website's files and database, so you can bring the site back after a mistake, a hack or a failed update. is usable. Work on a restricted test copy with the same PHP version and relevant settings.

Disable real payments and outgoing customer emails there. Agree who will make the change and who will check the result. These steps are an investigation guide, not a diagnosis of your particular website.

Compare the two definitions

PHP does not allow a previously declared function to be redefined. This rule is not new with every PHP upgrade. Investigate changes made at the same time to plugins, themes, snippets and file loading.

The timing helps narrow the investigation but does not establish the cause.

include_once can prevent the same file from being included again. It is not a general solution for two separate files defining the same function. Ask the developer to distinguish a file loaded twice from different components using the same name.

The appropriate repair depends on that distinction.

Five steps to a repair

1. Save the complete message, including the reference to the earlier declaration. Record the exact function name. Do not investigate only the last line: the combination of both locations helps explain where the duplicate definition could originate.
2. List the affected components on the test copy. Check recently added snippets, active themeA WordPress theme is a ready-made package that decides how your WordPress site looks and how its pages are laid out. Change the theme and the design changes. components and pluginA WordPress plugin is an add-on you install in WordPress to give your site extra features, such as contact forms, SEO tools or a webshop. files. Ask who made recent changes. A leftover copy is a hypothesis to investigate, not a reason to remove directories without inspection.
3. Compare the purpose of the two functions. Do they do the same thing, or do different components expect different behavior from the same name? Have the maintainer identify the required implementation. Disable a suspected addition only on the test copy and record which feature changes.
4. Repair the specific collision. This may require correcting the loading sequence or having the maintainer change the code. If a name changes, review its callers too. A search and replace operation without understanding the application is insufficient evidence of a repair.
5. Test the original failing page and the features supplied by both components. Check saving, reopening and a second visit. Inspect fresh logs. Document which definition remains and why, so the duplicate snippet is not added again later.

Why an existence check is not the whole answer

For some designs, a developer may check whether a function already exists. Ask which implementation will then run and whether it suits every affected component. The disappearance of the error does not prove that the chosen function produces the correct calculation or output.

Behavior needs particular attention where money or access controls are involved.

For the handoff, write a small explanation in plain language: the first component supplies this function, while the second expects this result. Include one successful example for each component. This makes a naming collision understandable without requiring you to write PHP.

Ask how the repair will survive the next plugin or theme update. An isolated edit that disappears at the next update is not a maintainable solution.

Getting help and checking the repair

Use the help form below if you cannot access the logs or do not know who maintains the affected code. Describe one failed action and the expected result. Ask for a proposal that separates the cause, the change and the acceptance check.

Do not include passwords with your request.

After the repair, repeat the original action on the test copy. Also check a normal visitor journey, an empty result and invalid input where relevant. Review fresh log entries at the new test time.

Keep versions and outcomes in your maintenance notes. Let the responsible administrator decide when the tested change can be applied to the live website.