See #3109885-11: [meta] Ensure compatibility of Drupal with PHP 8.0 (as it evolves)
Fix PHP deprecation
PHP Deprecated: Method ReflectionParameter::getClass() is deprecated in /var/www/html/core/lib/Drupal/Core/DependencyInjection/Compiler/TaggedHandlersPass.php
Hi,
Steps for reproduce this issue :-
1. Create one node with url alias.
2. Create menu and put above node url alias in menu path.
3. Delete Path alias from url alias configuration.
4. Then go to fronted of website then it give white screen with error message.
Thanks
As title.
For example:
- $this->assertTrue(array_key_exists($route_name, $sample_routes));
+ $this->assertArrayHasKey($route_name,$sample_routes);
In core/tests/Drupal/KernelTests/Core/Config/ConfigSchemaTest.php file test method testSchemaMapping() found unused variable.
I removed the following variable.
$a = \Drupal::config('config_test.dynamic.third_party');
In core/tests/Drupal/KernelTests/Core/Database/UpdateLobTest.php file change static queries to dynamic queries in testUpdateOneBlob() and testUpdateMultipleBlob() methods.
$r = $this->connection->query('SELECT * FROM {test_one_blob} WHERE id = :id', [':id' => $id])->fetchAssoc();
$r = $this->connection->query('SELECT * FROM {test_two_blobs} WHERE id = :id', [':id' => $id])->fetchAssoc();
$r = \Drupal::database()->select('test_one_blob', 'tob')
->fields('tob')
->condition('id', $id)
->execute()
->fetchAssoc();$r = \Drupal::database()->select('test_two_blobs', 'ttb')
->fields('ttb')
->condition('id', $id)
->execute()
->fetchAssoc();TBD
None
None
None
TBD
In core/tests/Drupal/KernelTests/Core/Database/InsertDefaultsTest.php file change static queries to dynamic queries in testDefaultInsert(), testDefaultEmptyInsert() and testDefaultInsertWithFields() methods.
As per title
$num_records_before = (int) $this->connection->query('SELECT COUNT(*) FROM {test}')->fetchField();
-
+ $num_records_before = $this->connection->select('test')
+ ->countQuery()
+ ->execute()
+ ->fetchField();
- $job = $this->connection->query('SELECT job FROM {test} WHERE id = :id', [':id' => $id])->fetchField();
+ $job = $this->connection->select('test', 't')
+ ->fields('t', ['job'])
+ ->condition('id', $id)
+ ->execute()
+ ->fetchField();TBD
None
None
None
TBD
Given the following code:
$storage = $this->entityTypeManager->getStorage('group_type');
$group_type_ids = $storage->getQuery()
->notExists('third_party_settings.subgroup')
->execute();
and there being a group type that does not have any third party settings, I'd expect to get said group type's ID from the query.
Instead, I receive nothing. This is because of the following lines in Condition::matchArray()
if (is_array($data[$key])) {
$new_parents = $parents;
$new_parents[] = $key;
if ($this->matchArray($condition, $data[$key], $needs_matching, $new_parents)) {
return TRUE;
}
}
// Failing the above block leads to FALSE return value.
So unless the full parent path to the property (in this case third_party_settings) is set, matchArray() will never get to call match() where it checks the IS NULL condition.
Split from #3118143: [meta] Release Drupal 10 in 2022.
We released Drupal 8 without the migration path from Drupal 7 being finished, this was in November 2015.
The Drupal 7 migration path should be stable by the time Drupal 9.0.0 releases, this will be just under five years since Drupal 8 was released.
However, there are still more than 700,000 Drupal 7 sites, and Drupal 7 EOL is due end of 2021.
This means we're likely to see an acceleration of Drupal 7-9 migrations in the next 18 months, more bugs uncovered, and migrations added for contrib modules that previously didn't have them (in contrib rather than core except possibly some remaining cases where core replaced a contributed module and there's something to migrate).
Drupal 9 EOL will be 2023.
Drupal 10 will be released in 2022.
On the other hand, Drupal 7 vendor extended support will be provided until at least end of 2024 (well after Drupal 9 EOL and a year and half into Drupal 10).
Either:
1. Continue to support Drupal 7 migrations to Drupal 10 in core.
OR
2. Move the Drupal 7 migrations to contrib.
If we do move the Drupal 7 migrations to contrib, what happens to migrate itself? We'll still have all the destinations to support, but no sources in core except potentially 8-9/9-9 migrations which have a smaller use case.
In \Drupal\Component\Datetime\DateTimePlus::checkArray() we do
if (@checkdate($array['month'], $array['day'], $array['year'])) {
$valid_date = TRUE;
}
The $array['month'], $array['day'], $array['year'] values are not guaranteed to be integers and they should be. In PHP8 this causes test failures.
Casting each value to an integer works but is it the best fix?
This issue should also be backported to 8.9.x so that Drupal 8 can be PHP 8.0 compatible.
N/a
N/a
N/a
N/a
$result = $connection->query(
'SELECT name, value FROM {key_value_expire} WHERE collection = :collection',
[
':collection' => $collection,
])->fetchAll();$result = $connection->select('key_value_expire', 'kve')
->fields('kve', ['name'])
->condition('collection', $collection)
->execute()
->fetchAll();TBD
None
None
None
TBD
\Drupal\Component\Utility\Bytes::toInt() passes a string value to round(). In PHP 8 this will trigger an error.
Cast the $size value to an integer or a float as appropriate.
None
None
None
N/a
In \Drupal\Core\Access\CsrfTokenGenerator::validate() it's possible that $token returns something other than a string. In PHP 8 this causes a warning.
Ensure that $token is a string.
Under PHP 8 installing Drupal results in errors because \Drupal\Core\Database\StatementInterface::fetch() does not match \PDOStatement::fetch()
It seems that we can add the necessary scalar typehints and it works on both PHP 8 and PHP 7.3 and up. I wonder if it works oon Drupal 8 and PHP 7.0.
\Drupal\Core\Render\Element\StatusReport::preRenderGroupRequirements() and \Drupal\user\PermissionHandler::sortPermissions() sorts return bools. As these a PHP user sort functions it expects -1, 0 or 1. In PHP 8 returning a bool triggers a warning.
Use the spaceship operator to return the correct type.
None
None
None
N/a
On PHP 8 we need to ensure that the fragment is not set to an empty string. See the behaviour change https://3v4l.org/HsvX0
Get the value before setting it.
None
None
None
None
\Drupal\error_test\Controller\ErrorTestController::generateWarnings() does
public function generateWarnings($collect_errors = FALSE) {
// Tell Drupal error reporter to send errors to Simpletest or not.
define('SIMPLETEST_COLLECT_ERRORS', $collect_errors);
// This will generate a notice.
$monkey_love = $bananas;
// This will generate a warning.
$awesomely_big = 1 / 0;
// This will generate a user error. Use & to check for double escaping.
trigger_error("Drupal & awesome", E_USER_WARNING);
return [];
}
However the
// This will generate a notice.
$monkey_love = $bananas;
Does not work in PHP 8.
Relying on the underlying language not changing makes this test fragile. We should emit an E_USER_NOTICE here instead. They are largely treated exactly the same way as E_NOTICE and it won't be subject to change when the underlying language makes a change.
Alternatively we can rewrite the test to be more aware of PHP version.
None
None
None
None
The @todo refers to the issue #2999549: Allow button tag in LinkGenerator for better accessibility. Its resolution was fixed:
Remove the @todo
None.
None.
In PHP 8.0 imagecreatefrom* functions no longer return a resource. They return a \GdImage object.
Change \Drupal\system\Plugin\ImageToolkit\GDToolkit to support both a resource and a \GdImage object.
See https://github.com/php/php-src/blob/master/UPGRADING#L249
I think this issue will be okay for PHP 7.0 because it's really only loosening what we expect in \Drupal\system\Plugin\ImageToolkit\GDToolkit::$resource but testing this will be harder without all fixes from #3156595: Make Drupal 9 installable on PHP8
None
\Drupal\system\Plugin\ImageToolkit\GDToolkit::getResource() will return different things depending on PHP version.
\Drupal\system\Plugin\ImageToolkit\GDToolkit::setResource() will expect different things depending on PHP version.
None
@todo
There is no need to use t() in tests, unless we're testing translations, however in core we do not follow this consistently, which does not set a good example for new contributions.
In #3133726: [meta] Remove usage of t() in tests not testing translation we identified there are severals of calls to t() in calls to clickViewsOperationLink(), helperButtonHasLabel() and optionExists() and that removing all these in one go seems to be a suitable way of attacking this problem.
Identify and remove all calls to t() wrapped in calls to clickViewsOperationLink(), helperButtonHasLabel() and optionExists(), except those used by translation-related code (if any).
Trying to set up a view in Drupal 8 I get always empty results. The logs say:
Uncaught PHP Exception Symfony\\Component\\Routing\\Exception\\RouteNotFoundException: "Route "view.pages.feed_1" does not exist." at XXX/drupal8/core/lib/Drupal/Core/Routing/RouteProvider.php line 191, referer: http://example.com/admin/structure/views/view/page
A view page showing all content's teaser witch has a specific taxonomy term .
An empty view showing only it's title (the Title of the taxonomy term in this case).