Call to undefined function each() after 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.

What changed? The PHP manual says each() was deprecatedA deprecation is an early warning that a feature still works today but will be removed in a future PHP version, so code using it must be changed in time. in PHP 7.2 and removed in PHP 8.0. It returned a key and its corresponding value, then advanced the collection's internal position.

That second behaviour matters during replacement. A loop that visits every element does not automatically express the same intention as code that processes one element on each separate call.

Choosing the correct repair

A foreach loop may suit a simple traversal. First establish whether other code relies on the internal position or changes the collection during processing. Do not simply delete the failing line.

The page might open again while part of an export is missing. Compare the contents and the number of processed elements, rather than treating the absence of an error as the only result.

Five steps to a repair

1. Record which page or background task produces the message. An export failure needs a different first test from a menu failure. Start with a small collection whose exact contents are known.
2. Find the owner of the old loop. Check whether it comes from a 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., a library or custom work. Give the supplier the exact function name and the installed version when requesting maintenance.
3. Document how the loop starts and stops. Does it process every element or stop halfway through? Also establish the expected behaviour when the collection is completely empty before any processing begins.
4. Test the replacement with zero, one and several elements. Compare keys, order and values. Include a case where the same operation is started twice in succession using the same test data.
5. Inspect the final output. For an export, count the rows and compare the last row with the expectation. Only then check the fresh log for messages produced during this particular test.

A practical check

Imagine an export containing three invented products. Write down their names and expected order before testing. After the repair, precisely those three products should appear, with no missing or duplicate rows.

Next, create an empty export and repeat with a single product. This suggested scenario distinguishes a quiet error logAn error log is a file where your website's software writes down what went wrong, with the time and place. It is the first thing to check when a site breaks. from a correct loop. Give the small test collection to the developer so the comparison can be repeated during future maintenance.

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.

Choosing the next step

Use the links below this article to choose the next step. The PHP update page helps you discuss maintenance with the administrator. The Exposure Check is a separate public check; do not treat its result as evidence that this programming error is repaired.

Use the status page for current security information. Keep the repair of the visitor action and the assessment of the server as separate checks in your notes. When requesting help, include the error text, the failed action and the expected result, but no passwords.

Ask for one responsible person to oversee both the change and its acceptance.