Follow-up to #3178534: Start running PHPStan on Drupal core (level 0). We want all of the Drupal core to be checked against PHPStan level 0.
Try to fix as many level 0 problems as possible in this issue.
Run phpstan level 0 on core and create a merge request to address problems.
The tops of the mobile menu doesn't look right in high contrast mode. IE and Firefox both lose 1/2 of the toggle, but it's a different part depending on the browser.
Firefox
IE11
This is probably due to the top positioning of the mobile menu being implemented via a thick border, and high-contrast modes treat borders and backgrounds differently.
layout_builder_is_active cache context implemented in \Drupal\layout_builder\Cache\LayoutBuilderIsActiveCacheContext does not seem to be providing the correct cache context value - it is always 0. Issues seem to be:
getContext() calls getDisplay(). getDisplay()checks whether the entity parameter from the route is an instance of OverridesSectionStorageInterface. AFAICT, OverridesSectionStorageInterface is not implemented by any entity classes; it's just the interface for the overrides section storage plugin. In which case, getDisplay() always returns NULL.getDisplay() says the method should return \Drupal\layout_builder\Entity\LayoutEntityDisplayInterface, but even assuming there is an entity implementing OverridesSectionStorageInterface, getDefaultSectionStorage() returns \Drupal\layout_builder\DefaultsSectionStorageInterface, not \Drupal\layout_builder\Entity\LayoutEntityDisplayInterfaceThis issue follows up on the discussion in #1975064: Add more granular block permissions
Custom blocks can be created as structural page elements and content editors might need to edit their content on a production site. For example, a block with opening times placed on the front page: Editors should not be able to move it, but might need to change it to add special opening times.
Currently, users need "Administer blocks" permissions to do such a purely content change that doesn't even change the configuration. However, this also gives them the permission to change the whole block layout, remove or delete blocks etc.
#1975064: Add more granular block permissions discusses more granular block permissions in general, but just adding a separate permission to edit existing custom blocks would already be a big improvement for user experience for content editors and for sitebuilders setting up the sites for such roles.
larowlan and Tim Plunket in #98 proposed to also add a "create blocks" permission as part of this issue because that would be useful for Layout builder.
Add an edit block permission per block type.
Provide an easy way for users with the new permission to reach the block-edit form.
BlockContentAccessHandlerTest::providerTestAccess() (done by #3022183).create $type block content permission to create blocks via /block/add route as per #106TBD.
\Drupal\layout_builder\Plugin\SectionStorage\OverridesSectionStorage provides local tasks for relevant entity types.
When viewing an entity of one of those types (let's just say node for simplicity), if overrides aren't enabled for the display for that node, as the links for the local tasks are built, the access for the layout_builder.overrides.node.view link has max-age 0. This max-age is applied to the local task block render array.
The reason this is happening is that as the local tasks are build, access to each link is checked via \Drupal\Core\Access\AccessManager::checkNamedRoute(). In that method, the parameters for the the layout_builder.overrides.node.view are upcasted, but since there is no overrides section storage for the entity, \Drupal\layout_builder\Routing\LayoutTempstoreParamConverter returns NULL for the section storage parameter, causing\Drupal\Core\ParamConverter\ParamConverterManager::convert() to throw. ParamNotConvertedException
The exception is handled by the access manager by denying accessing and making the access object cache max-age 0.
Since the local tasks block will vary by permissions and by each page anyway, making the block uncacheable is probably not wrong. However, it would affect page/response cacheability in #2352009: [pp-3] Bubbling of elements' max-age to the page's headers and the page cache.
Since IE11 needs to be supported until Drupal 10 at the earliest... (I know 🙁)
IE11 adds a horizontal scroll for breadcrumbs where it's clearly not needed
During the Drupal Accessibility Office Hour (18 Jun 2020) we reviewed the focus styles as they currently stand in Olivero.
Video recording of the focus style walk-through. https://www.youtube.com/watch?v=tZQMBdbv-x8
Note that the demo used Firefox. If you play with these in a different browser, you will see different user-agent default styles.
We need to standardize focus states across most hyperlinks.
* Focus states do not need to be tied to hover states
* Focus states should be 4 sided
* Focus states should work in high contrast mode (no box shadow, backgrounds, etc).
I run a multisite on Drupal 8.9.11. On one of my sites, I recently started having the error described at https://www.drupal.org/forum/support/post-installation/2019-07-31/error-..., where a config import would error out with the following error:
[error] Error: Call to a member function delete() on null in Drupal\Core\Config\ConfigImporter->checkOp() (line 902 of /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php) #0 /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(609): Drupal\Core\Config\ConfigImporter->checkOp('', 'create', 'system.menu.dev...')
#1 /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(514): Drupal\Core\Config\ConfigImporter->processConfigurations(Array)
#2 /var/www/html/vendor/drush/drush/src/Drupal/Commands/config/ConfigImportCommands.php(333): Drupal\Core\Config\ConfigImporter->doSyncStep('processConfigur...', Array)
#3 /var/www/html/vendor/drush/drush/includes/drush.inc(206): Drush\Drupal\Commands\config\ConfigImportCommands->doImport(Object(Drupal\Core\Config\StorageComparer))
#4 /var/www/html/vendor/drush/drush/includes/drush.inc(197): drush_call_user_func_array(Array, Array)
#5 /var/www/html/vendor/drush/drush/src/Drupal/Commands/config/ConfigImportCommands.php(304): drush_op(Array, Object(Drupal\Core\Config\StorageComparer))
#6 [internal function]: Drush\Drupal\Commands\config\ConfigImportCommands->import(NULL, Array)
#7 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
#8 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#9 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(302): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#11 /var/www/html/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#12 /var/www/html/vendor/symfony/console/Application.php(1005): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#13 /var/www/html/vendor/symfony/console/Application.php(255): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#14 /var/www/html/vendor/symfony/console/Application.php(148): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(118): Symfony\Component\Console\Application->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(49): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /var/www/html/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
#18 /var/www/html/vendor/drush/drush/includes/preflight.inc(18): require('/var/www/html/v...')
#19 phar:///usr/local/bin/drush/bin/drush.php(143): drush_main()
#20 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#21 {main}.
This only happens in my local and dev environments, and only one this one site. Copying the database from production or stage into the dev or local environments doesn't resolve the issue. Clearing the cache doesn't resolve the issue. Because I use Configuration Split to install different modules and change settings of other modules in certain environments, I checked the configuration between the site having the issue and my "default" site. Both matched exactly.
At https://www.drupal.org/forum/support/post-installation/2019-07-31/error-..., the resolution is to replace the code under the create operation of the switch statement in the checkOp function in core/lib/Drupal/Core/Config/ConfigImporter.php with code included in the forum post. However, the forum post assumes that $entity already has a value. If it doesn't, and the target config entity exists, $entity should be assigned that value and the operation should execute as expected. Otherwise, if it doesn't exist, it shouldn't execute the delete operation to avoid erroring out unnecessarily.
Hopefully I've described the issue adequately. I'd be happy to check other areas of my configuration, database, etc. if needed to ensure this is actually an issue needing correction and not just something wrong with my site.
I have created a View in Table format of a custom content type, displayed as a Page, and I've exposed the Search filter to allow keyword searching. The first unexpected thing about it is the filter displays on the page without my having to go to Place Block on the Blocks admin page. The other, more serious issue, is that when I perform a keyword search I get a "The website has encountered an error. Please try again later" error page. This error gets logged:
Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "Exception in Database listing[database_listing]: SQLSTATE[42000]: Syntax error or access violation: 1055 Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'library.node__field_resource_title.field_resource_title_value' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by: SELECT node_field_data.langcode AS node_field_data_langcode, node_field_data.nid AS nid, SUM(node_search_index.score * search_total.count) AS score, MIN(node_field_data.nid) AS nid_1\nFROM \n{node_field_data} node_field_data\nLEFT JOIN {search_index} node_search_index ON node_field_data.nid = node_search_index.sid AND (node_search_index.type = 'node_search' AND node_search_index.langcode = node_field_data.langcode)\nLEFT JOIN {search_total} search_total ON node_search_index.word = search_total.word\nINNER JOIN {search_dataset} node_search_dataset ON node_search_index.sid = node_search_dataset.sid AND (node_search_index.type = node_search_dataset.type AND node_search_index.langcode = node_search_dataset.langcode)\nLEFT JOIN {node__field_resource_title} node__field_resource_title ON node_field_data.nid = node__field_resource_title.entity_id AND node__field_resource_title.deleted = :views_join_condition_0\nWHERE (node_field_data.status = :db_condition_placeholder_1) AND (node_field_data.type IN (:db_condition_placeholder_2)) AND ((node_search_index.type = :db_condition_placeholder_3) AND (node_search_dataset.data LIKE :db_condition_placeholder_4 ESCAPE '\\\\') AND (node_search_index.word = :db_condition_placeholder_5))\nGROUP BY node_search_index.sid, node_field_data_langcode, node_field_data.nid\nHAVING (COUNT(*) >= :node_search_index_keys)\nORDER BY node__field_resource_title.field_resource_title_value ASC; Array\n(\n [:db_condition_placeholder_1] => 1\n [:db_condition_placeholder_2] => databases\n [:db_condition_placeholder_3] => node_search\n [:db_condition_placeholder_4] => % archival %\n [:db_condition_placeholder_5] => archival\n [:node_search_index_keys] => 1\n [:views_join_condition_0] => 0\n)\n" at [webroot]/core/modules/views/src/Plugin/views/query/Sql.php line 1489, referer: my-page-URL
I'm not certain this has been reported elsewhere; apologies if I've duplicated another issue.
After upgrading from Drupal 8.9 to Drupal 9.0 I get the two following error/warning messages when trying to create new content using some (not all) of my content types, among them the native “page”-type:
Error message:
The website encountered an unexpected error. Please try again later. Error: Call to a member function getAccountName() on null in Drupal\node\NodeForm->form() (line 155 of core/modules/node/src/NodeForm.php).
Warning message:
call_user_func() expects parameter 1 to be a valid callback, class 'Drupal\node\Entity\Node' does not have a method 'getCurrentUserId' in Drupal\Core\Field\FieldConfigBase->getDefaultValue() (line 397 of core/lib/Drupal/Core/Field/FieldConfigBase.php).
Does anyone know what causes this?
Currently redesigning the menu of a website, initially, it loaded up to a depth of 1. The website loaded perfectly normal.
But the new redesign requires we load all depth (So far I have seen it go far as 8th level) - The menu tree table has over 4400+ menu items.
Now page load time is in the region of 40-50 seconds (per page!)
After refreshing the page, the load time goes down to 1-2 seconds obviously due to the cache, however the website has new pages being created daily, so we can't rely on the drupal to cache the page AFTER its spent almost a minute to load the page.
As a temporary solution, the server specs had to beefed up (6 times what it was previously) just to handle the load request.
Create 4000+ items
Place menu in existing region
- set depth to 8 or 9
load page as anonymous user
Any way the load time can be reduced whilst retaining the new design?
It seems the default drupal menu block is cached globally, but sadly breaks on each page load as it needs to add active classes to active menu items.
In a multilingual site I set content access to enable translation for Basic page and another content type called "Club".
Permissions for "Translate Basic page content" are set for administrator only.
I need an editor to be able to translate content type "club" so I set permission for editor to "Translate Club content".
Now I am facing two problems:
1. If I do not set the "Create translations" permission for editor, there is no local task for "Translate" when editor views a "Club" node.
2. If I do set the "Create translations" permission for editor, there is a local task for "Translate" and all works fine but this "Translate" local task is also showing on other content types (which are not configured for editor translations).
When editor clicks on "Translate" for other content types (like Basic page) he gets the translation table but not edit or add option i.e you cannot really translate.
Steps to reproduce:
Some configuration values are multiline (mails, system.maintenance & etc) but their export contains "\r\n" to split lines.
That makes configuration merging hard for such strings and mostly impossible to use configuration translations management for big config objects (for example webforms #2836206: Translation of big webforms broken)
Beautify export and make diff/merge tools less painful
http://symfony.com/doc/3.1/components/yaml.html#dumping-multi-line-liter...
agree on approach
patch, commit
No
TBD
All config files that have multiline strings will be updated on next export
I opened #3134245: Run drush imports as user=1 to solve part of the problem. But that solution is very much a sledgehammer solution when perhaps a more valid solution is to just switch the user if entity validation is enabled. This does the latter.
Switch to the entity owner if it implements EntityOwnerInterface
Test the latest patch by enabling validation on the destination entity i.e. validate: true.
source:
plugin: d7_node
node_type: page
process:
title: title
type: type
body: body
destination:
plugin: 'entity:node'
validate: true
I discovered this while working on #3166602: Ensure media_filter → media_embed mapping does not cause fatal errors and subsequently #3166930: Migrated filters may have invalid/incomplete settings applied.
If a fatal PHP error occurs in the middle of a migration, it leaves the migration in a weird state:
\Drupal\migrate\Plugin\MigrationInterface::STATUS_IMPORTING stateSee the STR in #3166930: Migrated filters may have invalid/incomplete settings applied.
Set a custom exception handler while in MigrateExecutable, because these are currently caught by _drupal_exception_handler(), so surely the migration system can do the same, but provide extra context?
/**
* Migration error.
*/
const MESSAGE_ERROR = 1;
/**
* Migration warning.
*/
const MESSAGE_WARNING = 2;
/**
* Migration notice.
*/
const MESSAGE_NOTICE = 3;
/**
* Migration info.
*/
const MESSAGE_INFORMATIONAL = 4;
Also add MESSAGE_FATAL_ERROR so that it's possible to communicate this is even worse than MESSAGE_ERROR. → see #3👀
Fatal errors also show up.
Addition: \Drupal\migrate\Plugin\MigrationInterface:MESSAGE_FATAL_ERROR.
None.
Fatal errors while running a migration no longer cause the migration system to crash.
Using PHPStan to improve the code quality of Drupal core. When we run PHPStan (level 0) against the full core code base it return over 1100 errors. This is something we fix in a single issue. Level 0 is for PHPStan the lowest level. The first issue adds the PHPStan library to core and fixes a number of errors (#3178534: Start running PHPStan on Drupal core (level 0 - part 1)). Followup issues are:
The Drupal 7 date module allowed the site builder to configure whether to collect an end date or not:
(This is called 'todate' in the code.)
For example, on my personal site, I have a projectNodeType which has a "time range"date. Example: https://wimleers.com/work/project/ledgrid.
Upon migration, the start value (value) is migrated, but the end value (value2) is dropped
That's because this is being migrated to a @FieldType=datetime field in D8 instead of a @FieldType=daterange field in D8!
Make \Drupal\datetime\Plugin\migrate\field\DateField detect the todate setting and:
process chain to also transform data for @FieldType=daterangeend_value property, instead of only the value propertydaterange instead of datetime when appropriatedestination_module key in the @MigrateField annotation to datetime_range instead of datetime. The migration system seems to not have been designed for dynamic conditional edge cases like this one, and the harm of requiring that module to be installed even if unused is minimal; and certainly does not outweigh the data loss that is currently happening.N/A
N/A
N/A
TBD
Error on running database update script:
warning: array_merge() [function.array-merge]: Argument #1 is not an array in image_styles() (line 582 of /home/mysite/public_html/folder/modules/image/image.module)
I managed to fix the warnings by changing line 582 to:
$effect = array_merge((array)$definition, (array)$effect);
ie: (added "(array)" before each variable).
I would like to check with the module maintainers that this is not going to cause other problems and if not suggest this fix for inclusion in the dev branch. If it is the wrong approach can a proper fix be suggested?
The system_maintenance migration lists:
source:
plugin: variable
variables:
- site_offline_message
source_module: system
But site_offline_message hasn't been in use since #201415: Add permission to access site in maintenance mode, which was committed over a decade ago in https://git.drupalcode.org/project/drupal/commit/a9762cd3bf93ac8bbcafec2...😬
Change it to:
source:
plugin: variable
variables:
- maintenance_mode_message
source_module: system
Remove the variable 'site_offline_message' from the d7 fixture and keep the existing 'maintenance_mode_message', which has the same text so there will be no changes to the existing migration test.
Now that #2880152: Convert custom menu links to be revisionable is in, changes to menu links in non-live workspaces are not showing up. Making changes, and publishing changes from non-live to live works well. But it's not possible to preview the changes on the site's frontend.
This is probably due to cache issues where rendered menus needs to be cached per workspace.
Cache menus per workspace.
None.
