These variables are set in user_template_preprocess_default_variables_alter() and don't need to be duplicated in the node.html.twig documentation, which is approximately a metre long.
Remove the same documentation lines from duplicates of node.html.twig which is included in various core themes.
View modes have 3 property paths that are not yet validatable:
./vendor/bin/drush config:inspect --filter-keys=core.entity_view_mode.taxonomy_term.full --detail --list-constraints --fields=key,validatability,constraints
➜ 🤖 Analyzing…
--------------------------------------------------------------------- ------------- ---------------------------------------------------------------------------------------------
Key Validatable Validation constraints
--------------------------------------------------------------------- ------------- ---------------------------------------------------------------------------------------------
core.entity_view_mode.taxonomy_term.full 79% ValidKeys: '<infer>'
core.entity_view_mode.taxonomy_term.full: Validatable ValidKeys: '<infer>'
core.entity_view_mode.taxonomy_term.full:_core Validatable ValidKeys:
- default_config_hash
core.entity_view_mode.taxonomy_term.full:_core.default_config_hash Validatable NotNull: { }
Regex: '/^[a-zA-Z0-9\-_]+$/'
Length: 43
↣ PrimitiveType: { }
core.entity_view_mode.taxonomy_term.full:cache Validatable ↣ PrimitiveType: { }
core.entity_view_mode.taxonomy_term.full:dependencies Validatable ValidKeys: '<infer>'
core.entity_view_mode.taxonomy_term.full:dependencies.module NOT ❌ @todo Add validation constraints to ancestor type: config_dependencies
core.entity_view_mode.taxonomy_term.full:dependencies.module.0 Validatable NotBlank: { }
ExtensionName: { }
ExtensionExists: module
↣ PrimitiveType: { }
core.entity_view_mode.taxonomy_term.full:description Validatable Regex:
pattern: '/([^\PC\x09\x0a\x0d])/u'
match: false
message: 'Text is not allowed to contain control characters, only visible characters.'↣ PrimitiveType: { }
core.entity_view_mode.taxonomy_term.full:id NOT ⚠️ @todo Add validation constraints to config entity type: core.entity_view_mode.*.*
core.entity_view_mode.taxonomy_term.full:label Validatable Regex:
pattern: '/([^\PC])/u'
match: false
message: 'Labels are not allowed to span multiple lines or contain control characters.'
NotBlank: { }
↣ PrimitiveType: { }
core.entity_view_mode.taxonomy_term.full:langcode Validatable NotNull: { }
Choice:
callback: 'Drupal\Core\TypedData\Plugin\DataType\LanguageReference::getAllValidLangcodes'↣ PrimitiveType: { }
core.entity_view_mode.taxonomy_term.full:status Validatable ↣ PrimitiveType: { }
core.entity_view_mode.taxonomy_term.full:targetEntityType NOT ⚠️ @todo Add validation constraints to config entity type: core.entity_view_mode.*.*
core.entity_view_mode.taxonomy_term.full:uuid Validatable Uuid: { }
↣ PrimitiveType: { }
--------------------------------------------------------------------- ------------- ---------------------------------------------------------------------------------------------
11.x.composer require drupal/config_inspector— or manually install https://www.drupal.org/project/config_inspector/releases/2.1.5 or newer (which supports Drupal 11!)composer require drush/drushvendor/bin/drush config:inspect --filter-keys=core.entity_view_mode.taxonomy_term.full --detail --list-constraintsAdd validation constraints to:
core.entity_view_mode.*.*:dependencies.modulecore.entity_view_mode.*.*:idcore.entity_view_mode.*.*:targetEntityTypeThis requires looking at the existing code and admin UI (if any) to understand which values could be considered valid. Eventually this needs to be reviewed by the relevant subsystem maintainer.
For examples, search *.schema.yml files for the string constraints:😊
Reach out to @borisson_ or @wimleers in the #distributions-and-recipes.
None.
None.
More validation 🚀
None.
Node bundles in the standard profile:
article
page
User bundle:
user
Block bundle:
basic
Taxonomy bundle:
tags
Why is only one plural and the other default bundles singular? We should aways be consistent when providing defaults.
I get that changing the machine name would possibly mess up a lot of sites because folks unfortunately just install Standard profile and run with it instead of considering their own install profile with their own bundles.
However, I stand that with the next major version change, we should strongly consider refactoring the "out of the box" entity bundles and re-think what kind of DX confusion is caused by having both plural and singular used across the "default" bundle names.
I have many times run into issues with 'tags' (or any bundle name that is plural) due to this inconsistency.
I am not saying we should enforce people to not use plurals in bundle names, we should encourage consistency.
Currently the moderation form that appears on top of draft entities for the purposes of moderation is a custom form. This form doesn't attempt to validate entities before saving them, reducing the overall utility of entity validations.
Before:
After:
Review + commit.
Minor label changes.
Render array changes, with a change record.
None.
Hello, sorry for my English langage.
Context :
Site : https://aacm-france.fr
Host: PlanetHoster
CSV /Drupal version installed D10.3.0 managed with composer
Modules :
- drupal/ctools:^4.0
- drupal/imce:^3.0
- drupal/colorbox:^2.0
- drupal/media_gallery:^2.1
- drupal/admin_toolbar:^3.4
- drupal/vapn:^3.0@alpha
- drupal/ckeditor_font:^2.0@beta
PHP : 8.2.5
Database: 10.5.21-MariaDB
Bug: since update D10.2.7 to D10.3.0
Bug description: Modified display for creating or modifying an article, page or gallery with disappearance of areas of the writing body or summary (screenshots 1 -2 -3 ). In some cases semi-possible with simple HTML (screenshots 4 -5)
I tried to recreate the base of the site (core + modules + theme) several times directly with D10.3.0 same problem for each try.
In the reports: recent log messages: very many messages system. (screenshots 6 as 7 -8 -9).
Searches in the Drupal bug report: Issues for Drupal core: I couldn't find anything that resembled my problem.
Question: I don't understand why no one has the same problem. Is there a solution that I missed?
Layout builder region on Navigation block page is breaking when collapsed.
1. Install navigation module.
2. Go on admin/config/user-interface/navigation-block/ page
3. Collapse the left side bar
4. You'll see the design is breaking.
5. See image for reference
Fix the styling of collapsed aside region.
Solution - I have fixed the font size and reduced the padding on nav.
After Fix -
When hitting a site with at least one block configured with a request_path condition on any URL prefixed with index.php (i.e example.com/index.phpfoo, the following error is thrown (truncated stacktrace for brevity)
InvalidArgumentException: Source path foo has to start with a slash. in Drupal\path_alias\AliasManager->getAliasByPath() (line 185 of core/modules/path_alias/src/AliasManager.php).
Drupal\system\Plugin\Condition\RequestPath->evaluate() (Line: 77)
Drupal\Core\Condition\ConditionManager->execute() (Line: 84)
Drupal\Core\Condition\ConditionPluginBase->execute() (Line: 26)
/user/* and click "Show for the listed pages"InvalidArgumentException: Source path .php has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 229 of core/lib/Drupal/Core/Path/AliasManager.php).Potentially always prefix $path with a forward slash.
In #540008: Add a container parameter that can remove the special behavior of UID#1 an approach was taken where we can simply flag tests that are failing if we turn off user 1's super user powers, so that they can be taken care of in a followup. This issue is to collect all of these followups.
The goal is to have no tests in Drupal core that rely on UID1's special privileges so that we:
Go into any of the tests flagged with:
/**
* {@inheritdoc}
*
* @todo Remove and fix test to not rely on super user.
* @see https://www.drupal.org/project/drupal/issues/3437620
*/
And:
Assign the right permissions to make the test go green without the super user access policy. Those few tests that specifically test said policy can obviously stay, but will be removed along with the policy in D12.
Follow up from #2798531: Add example and sections to core Block API documentation that issue mentions removing reference to annotation\Block but should scope be expanded to include more modules?
N/A
TBD. Need to determine scope
Determine scope
N/A
N/A
N/A
N/A
Unlike many other pages of core documentation, the Block API documentation doesn't contain a worked example.
Compare:
* https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21me...
* https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Routing%2...
* https://api.drupal.org/api/drupal/core%21core.api.php/group/form_api/8.2.x
* https://api.drupal.org/api/drupal/core%21modules%21block%21block.api.php...
While the Block API documentation links off to examples elsewhere in a contrib module, this is probably not great practice (and definitely not consistent with the other API docs.)
Add an example to block.api.php
Add sections.
Do not remove references to \Drupal\Core\Block\Annotation\Block. let's do that in a separate issue
Review
Commit
None.
None.
None.
When you disable a text format it is not possible to re-enable it. This seems counter to the behavior in other situations, such as Views, which allows disabling than re-enabling a display. Furthermore, it can lead to major problems on a site if a text format was mistakenly disabled.
Disable a text format and experience the disappointment upon realizing it can't be re-enabled. You'd need to create a new text format (yet can't create one with the same machine name), then change all items previously using the old one to use the new one.
\
From #60
Add an "Enable" operation for disabled text formats, which can be used to re-enable the disabled text format.
Add a 'Status' column to disable the status of the format. This is similar to the search pages, /admin/config/search/pages.
Code review
If needed add a followup to explore and implement an effective solution for ensuring cache reflects changes when a text format is re-enabled. This may involve adjusting or entirely rethinking the approach to cache tag management within preRenderText method of core /modules/filter/src/Element/ProcessedText.php#142 and #144
Both screenshots taken after disabling the Basic filter
| Issue category | Bug because of unexpected behaviour. Upon disabling the text format it disappears from the form which makes it seem deleted, but it isn't actually deleted because you can't add a new text format with the same machine name. |
|---|---|
| Issue priority | Major because as cilefen states in #19:
|
| Prioritized changes | The main goal of this issue is two-fold, fixing a DrupalWTF bug and improving usability. |
| Disruption | Non-disruptive because only the filter format admin interface is changed. No API changes |
When troubleshooting and reviewing issues on different core branches I've following workflow
git checkout 11.x
composer install
php -d memory_limit=512M core/scripts/drupal quick-start standard
# Above command will install Drupal and generate random password. Due to #3271178 this will hang up randomly, so I must do following:
# 1. go to http://127.0.0.1:8888/user/1/edit and change "Email address" domain to valid one and change password to something that is easy to remember/static so the browser password manager can use it.
# 2. ctrl+c on terminal
php -d memory_limit=256M -S localhost:8888 .ht.router.php
I understand this workflow is just a work-a-round for #3271178: Quick start command installation stops responding, but since that issue is going to take time to fix, I'd like to get password option so the workflow could be minified to:
git checkout 11.x
composer install
php -d memory_limit=512M core/scripts/drupal quick-start standard --password=123
# ctrl+c on terminal
php -d memory_limit=256M -S localhost:8888 .ht.router.php
Add password option to Drupal\Core\Command\InstallCommand
- MR
- Acceptance for idea
- Tests
- RTBC
- Profit
Part of #2571965: [meta] Fix PHP coding standards in core.
Sniff for coding standard is not implemented.
<rule ref="Drupal.Semantics.FunctionT.NotLiteralString"/>
Add <rule ref="Drupal.Semantics.FunctionT.NotLiteralString"/> to phpcs.xml.dist
Add ignore lines where it can't be changed to using only literals. That is currently 70 lines.
Review
Commit
Child of #3396165: [meta] Convert all core plugin types to attribute discovery
For automated installations via CI or similar the progress output of core/scripts/drupal install is unnecessary and looks a bit strange, for example:
0/17 [░░░░░░░░░░░░░░░░░░░░░░░░░░░░]
Installing Drupal
6/17 [▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░]
Set up database
7/17 [▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░]
Set up database
9/17 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░]
Install site
11/17 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░]
Configure site
12/17 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░]
Configure site
13/17 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░]
Congratulations, you installed Drupal!
17/17 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓]
Congratulations, you installed Drupal!
There should be a --no-progress option, similar to other command-line tools such as Composer, PHPUnit, etc.
When searching for content in a multilingual website, Drupal core display results in all languages.
This maybe considered a blocking issue to resolve #3041039: Search for content in current language or a duplicate of that one.
When no language is chosen in advance-search, display results only in current language.
Create a patch.
When adding a Menu Item, it is possible to add special items like <nolink> or <button>
According to Menu Link form:Enter <nolink> to display link text only. Enter <button> to display keyboard-accessible link text only.
Current navigation twig template structure does not respect these items and render them as links whose href is empty, having a different behavior than the expected one.
Attaching screenshots of the same menu as part of navigation or as a block to show the differences:
Update navigation twig templates to respect the special menu items behavior.
Checked how menu.html.twig works and it seems this piece of code generates the expected markup:
{{
link(
item.title,
item.url,
item.attributes.removeClass(item_classes).addClass(link_classes)
)
}}Could be worth to explore how it works and try to reuse or replicate its behavior.
php Error LogicException: The mapping definition at
`ckeditor5.plugin.ckeditor5_list:properties` is invalid: its `label`
key contains a string. It must be an array. in
Drupal\Core\Config\Schema\MappSince 10.3 upgrade
Based on this comment by @drumm at #3200622-3: Have Drupal core Tugboat previews default to using Umami profile (instead of standard), we can add a .tugboat/config.yml file to Drupal core in order to manage Tugboat configuration more effectively.
At the moment Tugboat configurations are hosted at https://github.com/TugboatQA/drupalorg/tree/master/drupal. The way this works, it should pick up the configuration file right away if it exists. Details at https://git.drupalcode.org/project/drupalorg/-/blob/7.x-3.x/drupalorg/in....
Drupal core's current Tugboat QA integration requires a bit of custom code both in Drupal.org Customizations and with a separate repository hosted on GitHub that contains the configuration for Drupal core versions, as necessary. When a new core development branch is created, the Tugboat QA support team often needs to create a new branch here before Tugboat previews will build correctly for the new branch. For the most part, these separate configs are identical, with PHP versions being the primary difference.
It would be ideal for these Tugboat config files to live inside of the Drupal core repository itself. The benefits of this are:
, so that each branch can customize as necessary, and so that additional logic isn't needed inside of the drupalorg module to create
Add this config.yml file to the 11.x branch, and then backport to other active branches from there.
Some discussion around this change can be found in Drupal slack.
In drupal there are numerous notices.
e.g. MigrationInterface has the following status's
MESSAGE_INFORMATIONAL
MESSAGE_NOTICE
MESSAGE_WARNING
MESSAGE_ERROR
however claro only supports the following traffic light system namely
status - green
warning -amber
error - red
it would useful to add some additional notices
e.g.
info - blue
notice - greyblue
https://www.drupal.org/files/issues/2024-04-03/Screenshot%202024-04-03%2...
https://www.drupal.org/files/issues/2024-04-03/Screenshot%202024-04-03%2...