Unsupported operand types 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.

From error message to calculation

PHP documents that non-numeric text used in a numeric context can cause a TypeError from PHP 8.0. That is one possible trigger for this kind of message. The complete error line and affected code must establish which operation and values are involved in your case.

Not every operand error concerns the same text conversion.

Ask the developer to describe both sides of the operation in plain language. Is it an amount and a percentage, two quantities or something else? Record where those values originate.

The price displayed on a page is not necessarily the same value supplied to the calculation.

Five steps to a repair

1. Save the error line with the reported types and line number. Note the choice that activates the calculation, such as a coupon, shipping method or product variation. Explain whether it affects every choice or only a small combination you can repeat.
2. Inspect the original values before the operation. Ask about their source, meaning and expected format. Keep real customer information out of test notes. An example with matching types and structure is generally more useful than a screenshot showing only the final screen.
3. Agree how invalid input should be handled. Can a missing discount mean zero, or must a purchase stop because a price is absent? These are different decisions. Do not introduce a default zero without reviewing its consequences for the calculation.
4. Test the targeted correction with ordinary numbers, empty input and unexpected text. Include the decimal notation used by your data source. Request an expected result calculated in advance. This checks the substance of the outcome rather than just the disappearance of the error.
5. Check the complete journey using the calculation. Compare intermediate results, the final amount and saved information. For a store, use a test order without a real payment. Then inspect fresh logs and retain the test example with the change record.

Separate amounts from display formatting

For testing, choose an amount displayed with a currency symbol. Ask which value enters the calculation and when visitor-facing formatting is applied. A developer should be able to explain where numbers are validated and where display text is produced.

This is an investigation example, not a description of how your store is implemented.

For import files, review the agreed meaning of each column. A field containing an amount may differ from a field describing that amount. Document the accepted format and how an invalid row should be reported.

Ask whether other rows should continue or the entire import should stop, then check that chosen behavior on the test copy.

If a failure only occurs with a particular discount, retain that exact combination for maintenance. A test using a standard product without a discount says little about that problem. Add a comparison in which the discount is deliberately absent.

This creates a small, repeatable check that remains useful during the next 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. or PHP upgrade.

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.