Passing null to parameter of type string is deprecated

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 8.1 migration guide describes this deprecated handling of null for built-in functions with non-nullable parameters. A deprecation message does not prove every affected function immediately stopped.

Investigate the application's error handling. Use the reported parameter number to locate the relevant input. Null and empty text are different values; deciding whether they can mean the same thing here is part of the repair.

Choosing the correct repair

Ask the maintainer to follow the value from its source to the built-in function. Empty text may be a valid agreement for an absent optional description. An absent required name may instead need a request for input.

Blindly converting everything to text can hide the distinction. Decide for the particular input field and describe what a visitor should see when that information is missing.

Five steps to a repair

1. Record the function name and parameter number from the complete message. Save the calling location and the action that reaches this code on the test copy.
2. Check the relevant parameter in the PHP manual. Establish which value the application actually supplies and where null first appears along the route supplying that information.
3. Decide whether absent information is legitimate for this field. Choose intentional empty text for an optional field or a clear response where a required field is missing.
4. Test normal text, empty text and null as separate cases. Include a filled value such as the character zero, so valid text is not accidentally discarded.
5. Repeat the original journey and review fresh logs. Inspect the final stored text and visible output to ensure the change has preserved information that should remain available.

A practical check

An optional note attached to a request provides a possible acceptance scenario. A completed note should arrive unchanged. An intentionally empty note should receive the agreed empty presentation.

A missing required name should remain recognisable as incomplete input. Review these results separately with the administrator. This exercise does not prove every text operation has been checked, but it supplies a concrete acceptance point for the parameter named in your error message.

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.