Php deprecated array and string offset access syntax with curly braces is deprecated in

Ошибка deprecated array and string offset access syntax with curly braces is deprecated in

I’ve just updated my php version to 7.4, and i noticed this error pops up:

Array and string offset access syntax with curly braces is deprecated

here is part of my code which is triggering the above error:

public function getRecordID(string $zoneID, string $type = '', string $name = ''): string < $records = $this->listRecords($zoneID, $type, $name); if (isset($records->result->id)) < return $records->result->id; > return false; > 

there are few libraries in my project which is using curly braces to get individual characters inside a string, whats the best way to change the syntax issue?

9,443 7 gold badges 28 silver badges 39 bronze badges

It’s really simple to fix the issue, however keep in mind that you should fork and commit your changes for each library you are using in their repositories to help others as well.

Let’s say you have something like this in your code:

since PHP 7.4 curly braces method to get individual characters inside a string has been deprecated, so change the above syntax into this:

Fixing the code in the question will look something like this:

public function getRecordID(string $zoneID, string $type = '', string $name = ''): string < $records = $this->listRecords($zoneID, $type, $name); if (isset($records->result[0]->id)) < return $records->result[0]->id; > return false; > 

answered Dec 3, 2019 at 13:47

9,443 7 gold badges 28 silver badges 39 bronze badges

Насколько я понял, это может быть связано с версией php 7.4? У меня стоит 7.4.2

На всех страницах сайта на WordPress ошибка:

Deprecated: Array and string offset access syntax with curly braces is deprecated in /wp-content/plugins/clearfy/components/minify-and-combine/includes/classes/class-helper.php on line 205

/** * Returns true if given $url is protocol-relative. * * @param string $url URL to check. * * @return bool */ public static function isProtocolRelative( $url ) < return ( '/' === $url); // second char is `/`. >

PHP RFC: Deprecate curly brace syntax for accessing array elements and string offsets

Introduction

PHP allows both square brackets and curly braces to be used interchangeably
for accessing array elements and string offsets. For example:

$array = [1, 2]; echo $array[1]; // prints 2 echo $array1>; // also prints 2 $string = "foo"; echo $string[0]; // prints "f" echo $string0>; // also prints "f"

However, supporting both of these syntaxes can be confusing. Are there
circumstances where one syntax behaves differently than the other? Is
there a difference in performance between them? Is there some difference
in scoping, since curly braces are the standard way to separate scope?
What’s the purpose of the curly brace syntax?

Apart from two short notes in the PHP Manual, the curly brace syntax is
virtually undocumented. Furthermore, it has reduced functionality
compared to the normal bracket syntax. For example, it cannot be used for
pushing an element into an array:

$array[] = 3; echo $array[2]; // prints 3 $array> = 3; // Parse error: syntax error, unexpected '>'

Nor can it be used to create an array:

$array = [1, 2]; // works $array = 1, 2>; // Parse error: syntax error, unexpected '

It can’t be used for list assignment, either:

[$one, $two] = $array; // works $one, $two> = $array; // Parse error: syntax error, unexpected ','

Proposal

Deprecate curly brace syntax for accessing array elements and string offsets.

Deprecated: Array and string offset access syntax with curly braces is deprecated in test.php line 3 int(2)

Discussion

Wasn’t the curly brace syntax deprecated once before?

According to an internals discussion from June 2008 (see references
below), the curly brace syntax was deprecated in PHP 5.1 RC5, but the
deprecation warning was removed before the final release. In August
2006, the documentation for $str read “deprecated as of PHP 6”,
but again the deprecation never made it into a production release.

Is the curly brace syntax valuable for differentiating string and array offset access?

It has been suggested that the duplicate syntax is useful for differentiating
string and array offset access. The problem with this is that no distinction
is enforced by the language. Both syntaxes can be used for both arrays and
strings, so while one codebase might always use $str[0] for strings and
$arr for arrays, another codebase might use the opposite convention,
which leads to more confusion rather than less.

To make sure that code is indexing a string and not an array, a type check
should be used instead of relying on syntax that can be used for both strings
and arrays (and thus doesn’t tell you anything about the underlying type).

How frequently is the curly brace syntax used?

Nikita Popov checked the top 2k Composer packages, and found ~2.2k
individual uses of the curly brace array syntax. Compared to the 888.3k
total array accesses in the data set, usage of the alternative syntax is
about 0.25%. However, even this number is inflated somewhat due to
duplicate packages (for example, there are two packages that mirror the
WordPress Core repository, each with 182 usages). 92% of usages in the
top 2k packages are in just 25 unique projects.

Will it be too much work for people to migrate code away from the curly brace syntax?

Backward Incompatible Changes

A deprecation warning will be output when using the curly brace syntax
to access array or string offsets.

Vote

Started 3 July 2019. Ends 17th July 2019

Future Scope

Remove the feature entirely (replacing the deprecation warning
with a compiler error) in PHP 8 or another future release.

References

· Last modified: 2019/08/10 23:19 by

Where Excel file import in codeigniter, the problem exists for phpexcel 1.8.0 on PHP 7

A PHP Error was encountered
Severity: 8192

Message: Array and string offset access syntax with curly braces is deprecated

File: /opt/lampp/htdocs/example/application/third_party/PHPExcel/Autoloader.php
Line: 82
Function: _error_handler

File: /opt/lampp/htdocs/example/application/third_party/PHPExcel/Autoloader.php
Line: 82
Function: require

File: /opt/lampp/htdocs/example/application/third_party/PHPExcel/Autoloader.php
Line: 36
Function: spl_autoload_call

File: /opt/lampp/htdocs/example/application/third_party/PHPExcel.php
Line: 6
Function: require

File: /opt/lampp/htdocs/example/application/controllers/Flats.php
Line: 4
Function: require_once

File: /opt/lampp/htdocs/example/index.php
Line: 318
Function: require_once

Common PHP 8.0 Compilation Error Messages

With PHP 8.0 closing on us, it is high time to check our code bases to see if they compile, at least. Here is a list of common PHP 8.0 compilation messages, and what do to with them.

The errors have been found on a corpus of 1756 PHP projects. Any emitted error was compared to the result of the PHP 7.4 compilation. This means that those errors are fatal in PHP 8, while they were absent, or a warning in PHP 7.4. In both cases, in PHP 7.4, it used to be possible to brush them under the carpet, but not in PHP 8.0 anymore.

Common PHP 8.0 compilation errors

• Array and string offset access syntax with curly braces is no longer supported
• Unparenthesized a ? b : c ? d : e is not supported. Use either (a ? b : c) ? d : e or a ? b : (c ? d : e)
• __autoload() is no longer supported, use spl_autoload_register() instead
• Cannot use ‘parent’ when current class scope has no parent
• syntax error, unexpected ‘match’
• The (real) cast has been removed, use (float) instead
• The (unset) cast is no longer supported
• Declaration of A2::B($c, $d = 0) must be compatible with A1::B(&$c, $d = 0)
• Unterminated comment starting line

Array and string offset access syntax with curly braces is no longer supported

Array and string offset access syntax with curly braces is no longer supported means that only the square bracket syntax is now valid.

Unparenthesized a ? b : c ? d : e is not supported. Use either (a ? b : c) ? d : e or a ? b : (c ? d : e)

Introduced in PHP 7.4, it is not possible to nest ternary operators. This is related to ternary being right associative, while most of the operators are left associative. PHP RFC: Deprecate left-associative ternary operators.

The error message is quite verbose : take advantage of it! Add some parenthesis, or even , split the nested operation into independent expressions. Exakat spots those with the rule Nested Ternary Without Parenthesis.

__autoload() is no longer supported, use splautoloadregister() instead

This error message might appear here thanks to very old applications. Or if they try to support very old PHP versions. In any case, the message is self-explanatory.

Cannot use ‘parent’ when current class scope has no parent

Using the parent keyword in a class without parent, a.k.a. without extends keyword, used to be a Deprecation Notice. In fact, the class would blow up during execution with a ‘Cannot access parent:: when current class scope has no parent’ Fatal error.

It is now a Fatal error at linting time. This will shorten significantly the time between the bug creation and its discovery.

As for the fix, there are lots of options, depending on how this parent keyword ended up there in the first place. Exakat spots those with the rule Class Without Parent.

syntax error, unexpected ‘match’

This is a consequence of the introduction of the match instruction in PHP. It is not possible to use that name in instantiation (new), use expressions, instanceof, typehints, functions, classes, interfaces, traits or constants. It is still OK inside a namespace, or for a variable name.

 // Match side effect : syntax error, unexpected ',' $result = match($content,"'KOD_VERSION','(.*)'"); ?>

When match is used as a function name, it may lead to an error about commas : the main argument of the new match keyword only accept one argument, so no comma.

The only solution is to rename the classes, interfaces, traits, functions or constants with another name and update the use expressions accordingly.

The (real) cast has been removed, use (float) instead

All is said here. (real) is gone, long live (float) .

Just replace (real) by (float) . While you’re at it, you can replace is_real() by is_float() : is_real() didn’t make it into PHP 8.0. Exakat spots those with the rule Avoid Real.

The (unset) cast is no longer supported

The big brother of the unset function is a type cast (unset) . It used to be actually the typecast (null) (not in name, but in usage). Very little new about this, and it is a good thing : it is gone for good.

Exakat spots those with the rule Cast unset usage.

Declaration of A2::B($c, $d = 0) must be compatible with A1::B(&$c, $d = 0)

Checking for method compatibility used to be a warning in PHP 7, and it is now a Fatal error at linting time. The method signature in a parent and its child class must be compatible. It means a lot of different things, depending on visibility, reference, typehint, default values. It is worth a whole article by itself.

The important part is three folds : first, PHP 8.0 emits a Fatal error at compile time for that. So, your PHP 7.0 may hurt on 8.0. If you can fix it now.

The second important part is that it only works when PHP lints both classes (parent and child), in the same file, and in the right order : parent first, child second. Otherwise, PHP will only check the compatibility at execution time, and deliver a Fatal error at the worst moment.

The third important part is that compatibility between method signature doesn’t cover argument names. The following code is valid, and a major sleeping bug. Just notice that the variables have been swapped.

Exakat spots those with the following rules Incompatible Signature Methods, and Swapped arguments.

Unterminated comment starting line

Unterminated comment starting line used to be a warning. It is now a parse error.

Just close the comment, and the code will be good again.

Compile with PHP 8.0 now!

PHP 8.0 moved a significant number of messages from Notice to Fatal errors, and, more importantly, from the execution phase to linting phase. This means that checking your current code with PHP 8.0 is sufficient to bring light on quirky pieces of code that will raise error when you want to upgrade to PHP 8.0. Simply fixing them will also improve your PHP 7.x code!

In the meantime, linting is as fast as it is superficial : it processes files individually, and postpone until execution some of the checks. Static analysis tools cover those situations, and report very early potential bugs and inconsistencies.

Install exakat and run the Migration audit on your code to get even better prepared for the Great Apparition of PHP 8.0. See you next month!

Источник