The size (a.k.a. width or length) of other textfields can be controlled with a field setting, but telephone doesn't have this option... I request adding it.
I know you can do this with CSS, but often the node edit forms are displayed using the admin theme which makes it harder to add CSS to customize them.
This issue is to coordinate and track the steps needed to remove Bartik from core to contrib. The steps to remove a theme and move it to contrib are in development, the steps for modules is being used as a guide. See Remove a core module and move it to a contributed project of the deprecation policy.
The removal of Bartik was approved in TBA
The current settings tray dialog CSS is fairly messy, with resets scattered around the codebase. It's very hard to style elements within the dialog, and unintentional styles also tend to leak in (see overrides within Claro and Olivero)
See
We can do proper resets by using a combination of all: revert, :where(), and selector arguments of :not(). For example the following modern CSS can replace several hundred lines of code, and be more resilient at the same time.
#drupal-off-canvas *:where(:not(svg, svg *, .ck-reset *, [data-drupal-ck-style-fence] *)) { all: revert; box-sizing: border-box; -webkit-font-smoothing: antialiased; &:after, &:before { all: revert; box-sizing: border-box; } }
Right now, it’s a real pain if we want to change the look and feel of the setting tray. Modern CSS can let us fix that.
#drupal-off-canvas-wrapper { --off-canvas-background-color: #444; --off-canvas-text-color: #ddd; --off-canvas-button-background-color: blue; --off-canvas-button-text-color: white; --off-canvas-text-size: 14px; --off-canvas-spacing-unit: 8px; --off-canvas-font-family: "Lucida Grande", "Lucida Sans Unicode", sans-serif; }
There are tons of benefits of refactoring
dialog), we don’t have to add it)Testing for this isn’t as terrible as it seems. The patch is large (over 200k) and has over 50 commits. Looking at the diffs will be difficult because of the styles moving around.
Tugboat link: https://3291797-off-canvas-6-ggpezyyiyfqyuna635hb6gpahwycstwb.tugboatqa.....
Ping me in Drupal Slack (or here) for admin credentials to test.
To test:
I've been running sqlite3 on my local dev environment (Ubuntu 10.04 Lucid Lynx, sqlite3 3.6.22) and have seen more than one of these fatal "database is locked" #fails. In each case, a page reload fixes it fine. I'll see if I can do an upgrade of sqlite and see what happens.
Error message
PDOException: SQLSTATE[HY000]: General error: 5 database is locked: INSERT INTO {variable} (name, value) VALUES (?, ?); Array ( [0] => rules_empty_sets [1] => a:55:{s:29:"commerce_cart_product_prepare";i:0;s:33:"commerce_customer_profile_presave";i:1;s:32:"commerce_customer_profile_insert";i:2;s:32:"commerce_customer_profile_update";i:3;s:32:"commerce_customer_profile_delete";i:4;s:26:"commerce_line_item_presave";i:5;s:25:"commerce_line_item_insert";i:6;s:25:"commerce_line_item_update";i:7;s:25:"commerce_line_item_delete";i:8;s:22:"commerce_order_presave";i:9;s:21:"commerce_order_insert";i:10;s:21:"commerce_order_update";i:11;s:21:"commerce_order_delete";i:12;s:36:"commerce_payment_transaction_presave";i:13;s:35:"commerce_payment_transaction_insert";i:14;s:35:"commerce_payment_transaction_update";i:15;s:35:"commerce_payment_transaction_delete";i:16;s:24:"commerce_product_presave";i:17;s:23:"commerce_product_insert";i:18;s:23:"commerce_product_update";i:19;s:23:"commerce_product_delete";i:20;s:19:"rules_config_insert";i:21;s:19:"rules_config_update";i:22;s:20:"rules_config_presave";i:23;s:19:"rules_config_delete";i:24;s:11:"node_insert";i:25;s:11:"node_update";i:26;s:12:"node_presave";i:27;s:9:"node_view";i:28;s:11:"node_delete";i:29;s:4:"init";i:30;s:4:"cron";i:31;s:8:"watchdog";i:32;s:11:"user_insert";i:33;s:11:"user_update";i:34;s:12:"user_presave";i:35;s:9:"user_view";i:36;s:11:"user_delete";i:37;s:10:"user_login";i:38;s:11:"user_logout";i:39;s:14:"comment_insert";i:40;s:14:"comment_update";i:41;s:15:"comment_presave";i:42;s:12:"comment_view";i:43;s:14:"comment_delete";i:44;s:15:"comment_publish";i:45;s:17:"comment_unpublish";i:46;s:20:"taxonomy_term_insert";i:47;s:20:"taxonomy_term_update";i:48;s:21:"taxonomy_term_presave";i:49;s:20:"taxonomy_term_delete";i:50;s:26:"taxonomy_vocabulary_insert";i:51;s:26:"taxonomy_vocabulary_update";i:52;s:27:"taxonomy_vocabulary_presave";i:53;s:26:"taxonomy_vocabulary_delete";i:54;} ) in variable_set() (line 804 of /home/rfay/workspace/d7git/includes/bootstrap.inc).
The SQLite database does not support row level locks. As a result we have to acquire a reserved lock on the database immediately.
For more information, see: https://bugs.php.net/42766.
I do not know when this errors was taken
address: /admin/reports/fields
Notice: Undefined index: image in Drupal\field_ui\FieldStorageConfigListBuilder->buildRow() (line 119 of core/modules/field_ui/src/FieldStorageConfigListBuilder.php).
Full text in file admin.reports.fields.txt
address: /admin/structure/types/manage/news/fields/node.news.field_img/storage
Notice: Undefined index: alt in Drupal\image\Plugin\Field\FieldType\ImageItem->defaultImageForm() (line 437 of core\modules\image\src\Plugin\Field\FieldType\ImageItem.php).
The same with the title, width, height
Full text in file node.news_.field_img.txt
How do I remove these errors?
When reverting a parent entity revision, the parent/child relationship looks like:
+------------+ +------------+ +------------+
|Host Entity | |Host Entity | |Revert VID 1|
|VID: 1 | |VID: 2 | |VID: 3 |
|Timestamp: 1| |Timestamp: 2| |Timestamp: 3|
+------------+ +------------+ +------------+
| | |
v v |
+------------+ +------------+ |
|Block Entity| |Block Entity| |
|VID: 1 | |VID: 2 | |
|Timestamp: 1| |Timestamp: 2| |
+------------+ +------------+ |
^ |
+---------------------------------+
Custom block entity form
+-----------------------------+
|$saved_entity change time: 2 |
|$new_entity change time: 1 |
|Validator throws error |
+-----------------------------+
When block entity VID 1 is loaded into the custom block form, the validator compares it against VID 2 as the "saved entity". The validator sees that a new revision has been created since VID 1 and throws an error.
Node handles this by updating the changed timestamp in \Drupal\node\Form\NodeRevisionRevertForm::submitForm when a node is reverted, but there isn't currently a process to create new entity revisions of custom blocks when a host entity is reverted.
Create a modified version of EntityChangedConstraint for BlockContent entities that skips the constraint validation for non-reusable (also known as "inline") block entities. This validation constraint is not necessary for inline block entities because Layout Builder is already creating new revisions of blocks when the layout is saved (see \Drupal\layout_builder\InlineBlockEntityOperations::handlePreSave). There's no danger of losing content.
We're so close. One remaining task:
None
Block content entities will no longer use the Drupal\Core\Entity\Plugin\Validation\Constraint\EntityChangedConstraint, but will now use Drupal\block_content\Plugin\Validation\Constraint\BlockContentEntityChangedConstraint, which extends Drupal\Core\Entity\Plugin\Validation\Constraint\EntityChangedConstraint instead.
None
TBD
Viewing the front page of a Drupal 10.1 install as user 1 shows the following CSS aggregates in the header.
As you can see, there are four aggregates, with the second aggregate including media="screen".
<link rel="stylesheet" media="all" href="/sites/default/files/css/css_AI3tdfWguXKwGYQh77azpIWFB75vRNg_QczKMd7wJAo.css?delta=0&language=en&theme=olivero&include=contextual/drupal.contextual-links%2Csystem/base%2Colivero/global-styling%2Ccore/drupal.active-link%2Colivero/powered-by-block%2Colivero/feed%2Cviews/views.module%2Colivero/navigation-secondary%2Colivero/search-wide%2Colivero/navigation-primary%2Colivero/search-narrow%2Ccore/modernizr%2Ccore/drupal.debounce%2Ctoolbar/toolbar%2Cuser/drupal.user.icons%2Ccore/shepherd%2Ctour/tour-styling%2Ctour/tour%2Ccore/drupal.tabbingmanager%2Ccontextual/drupal.contextual-toolbar%2Cshortcut/drupal.shortcut%2Ctoolbar/toolbar.escapeAdmin%2Cbig_pipe/big_pipe" />
<link rel="stylesheet" media="screen" href="/sites/default/files/css/css_5FA3K14RQkYOhjLi22sUkXa3rr9UmOmp2HuTM9zq2n4.css?delta=1&language=en&theme=olivero&include=contextual/drupal.contextual-links%2Csystem/base%2Colivero/global-styling%2Ccore/drupal.active-link%2Colivero/powered-by-block%2Colivero/feed%2Cviews/views.module%2Colivero/navigation-secondary%2Colivero/search-wide%2Colivero/navigation-primary%2Colivero/search-narrow%2Ccore/modernizr%2Ccore/drupal.debounce%2Ctoolbar/toolbar%2Cuser/drupal.user.icons%2Ccore/shepherd%2Ctour/tour-styling%2Ctour/tour%2Ccore/drupal.tabbingmanager%2Ccontextual/drupal.contextual-toolbar%2Cshortcut/drupal.shortcut%2Ctoolbar/toolbar.escapeAdmin%2Cbig_pipe/big_pipe" />
<link rel="stylesheet" media="all" href="/sites/default/files/css/css_kuhPJIoUEPrw6lSo2T4L7_-4v37wAeKmhT8fPFwvE1E.css?delta=2&language=en&theme=olivero&include=contextual/drupal.contextual-links%2Csystem/base%2Colivero/global-styling%2Ccore/drupal.active-link%2Colivero/powered-by-block%2Colivero/feed%2Cviews/views.module%2Colivero/navigation-secondary%2Colivero/search-wide%2Colivero/navigation-primary%2Colivero/search-narrow%2Ccore/modernizr%2Ccore/drupal.debounce%2Ctoolbar/toolbar%2Cuser/drupal.user.icons%2Ccore/shepherd%2Ctour/tour-styling%2Ctour/tour%2Ccore/drupal.tabbingmanager%2Ccontextual/drupal.contextual-toolbar%2Cshortcut/drupal.shortcut%2Ctoolbar/toolbar.escapeAdmin%2Cbig_pipe/big_pipe" />
<link rel="stylesheet" media="all" href="/sites/default/files/css/css_qKcdHo1cKu_xYxsR9LUksx-DrCUAFfMtkTdFg2jt9CM.css?delta=3&language=en&theme=olivero&include=contextual/drupal.contextual-links%2Csystem/base%2Colivero/global-styling%2Ccore/drupal.active-link%2Colivero/powered-by-block%2Colivero/feed%2Cviews/views.module%2Colivero/navigation-secondary%2Colivero/search-wide%2Colivero/navigation-primary%2Colivero/search-narrow%2Ccore/modernizr%2Ccore/drupal.debounce%2Ctoolbar/toolbar%2Cuser/drupal.user.icons%2Ccore/shepherd%2Ctour/tour-styling%2Ctour/tour%2Ccore/drupal.tabbingmanager%2Ccontextual/drupal.contextual-toolbar%2Cshortcut/drupal.shortcut%2Ctoolbar/toolbar.escapeAdmin%2Cbig_pipe/big_pipe" />
The media="screen" contains only the CSS file for tour-styling, due to this:
tour-styling:
version: VERSION
css:
component:
css/tour.module.css: { media: screen }
I think when we added media support many years ago, we thought it'd add one extra file to support media="screen" (and that it would mostly be used for media="print"), however in fact it turns one aggregate into three which is a lot of extra http requests.
This is because we also deal with weights of assets, so if some assets in an aggregate need to go before tour, and some after, for it to be in the middle there have to be three files. And we also add weights based just on the order that files are added to the page, so that's pretty much all the time unless an asset with media screen happened to be the very last or very first one. Even if we remove weight support, unless we explicitly put screen assets first or last, they could still end up in the middle and require their own aggregate.
Inline media declarations during aggregation, for anything that is not media="print", this means that the common case of media="screen" will be included in the same aggregates. Since we're concerned about front end performance on screens, and not worried about a few extra CSS bytes when someone's printing a web page, there should not be a downside to doing it like this.
All browsers that Drupal supports, support nested media queries now that we've dropped support for IE11.
Here's how the CSS aggregates for exactly the same page look after applying the patch and clearing caches:
<link rel="stylesheet" media="all" href="/sites/default/files/css/css_fp0O1ULW3vedV1lZnnaJEzM2rc-NGp8-8c7NCRZR1ng.css?delta=0&language=en&theme=olivero&include=contextual/drupal.contextual-links%2Csystem/base%2Colivero/global-styling%2Ccore/drupal.active-link%2Colivero/powered-by-block%2Colivero/feed%2Cviews/views.module%2Colivero/navigation-secondary%2Colivero/search-wide%2Colivero/navigation-primary%2Colivero/search-narrow%2Ccore/modernizr%2Ccore/drupal.debounce%2Ctoolbar/toolbar%2Cuser/drupal.user.icons%2Ccore/shepherd%2Ctour/tour-styling%2Ctour/tour%2Ccore/drupal.tabbingmanager%2Ccontextual/drupal.contextual-toolbar%2Cshortcut/drupal.shortcut%2Ctoolbar/toolbar.escapeAdmin%2Cbig_pipe/big_pipe" />
<link rel="stylesheet" media="all" href="/sites/default/files/css/css_qKcdHo1cKu_xYxsR9LUksx-DrCUAFfMtkTdFg2jt9CM.css?delta=1&language=en&theme=olivero&include=contextual/drupal.contextual-links%2Csystem/base%2Colivero/global-styling%2Ccore/drupal.active-link%2Colivero/powered-by-block%2Colivero/feed%2Cviews/views.module%2Colivero/navigation-secondary%2Colivero/search-wide%2Colivero/navigation-primary%2Colivero/search-narrow%2Ccore/modernizr%2Ccore/drupal.debounce%2Ctoolbar/toolbar%2Cuser/drupal.user.icons%2Ccore/shepherd%2Ctour/tour-styling%2Ctour/tour%2Ccore/drupal.tabbingmanager%2Ccontextual/drupal.contextual-toolbar%2Cshortcut/drupal.shortcut%2Ctoolbar/toolbar.escapeAdmin%2Cbig_pipe/big_pipe" />
As you can see, this reduces four aggregates down to two. The reason we still have two aggregates instead of one, is because core intentionally puts theme CSS into its own aggregate, that's unrelated to this change and by design.
Right now all audits to plain Drupal websites get the warning "Serve images in next-gen formats".
Since this something increasingly important to all Drupal installs, we should consider supporting some of the "next-gen" formats.
- Imagem from auditing drupal.com
The formats that Google Lighthouse indicates are JPEG 2000, JPEG XR, and WebP that still have limited browser support.
In order to make it work on all Drupal supported browsers, we would need to have a fallback strategy.
We would need to be able to also generate images on that formats from the image style, and then make them available on the generated markup.
<picture>
<source srcset="img/yourImage.webp" type="image/webp">
<source srcset="img/yourImage.jpg" type="image/jpeg">
<img src="img/yourImage.jpg" alt="Your image">
</picture>Inside the CSS file "core/modules/system/css/components/align.module.css"
replace :
.align-center {
display: block;
margin-right: auto;
margin-left: auto;
}
with :
.align-center {
display: flex;
justify-content: center;
}
Follow-up to #3304991: [Symfony 6] HttpKernel should opt-in to catching `\Throwable`
This issue is to coordinate and track the steps needed to remove Seven from core to contrib. The steps to remove a theme and move it to contrib are in development, the steps for modules is being used as a guide. See Remove a core module and move it to a contributed project of the deprecation policy.
The removal of Seven was approved in TBA
There is logic in /core/themes/seven/js/nav-tabs.js that if the height of a set of tabs is taller the first set of tabs, (primary tabs), to switch to a vertical or mobile view. This is great on mobile and tablet, but doesn't work well on large desktop, as you end up with very long full-width vertical tabs that push everything way below the fold. For example if you have many display modes, it pushes everything below the fold:
In my case, when the secondary tabs are set to verity on a macbook retina on /admin/structure/types/manage/article/display, the ul.tabs.secondary these secondary tabs are 1375 pixels in height! (Labels changed to preserve anonymity).
I don't believe any special is required to recreate this. Just create a bunch of view modes.
Proposed Solution:
Update the logic to exclude the vertical tabs after a certain width.
MimeTypePass was added as a compatibility bridge between Symfony 4 and 5 MIME services, we can remove this and go back to the simpler TaggedHandlersPass in Drupal 10 once the BC layer is removed in #3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support).
The PasswordReveal element adds an attribute, data-drupal-password-strength. However, when removing that attribute, the strength indicator still appears.
I have created a patch which looks for that attribute and only adds the indicator if it's present.
Try, for example, with https://www.drupal.org/project/entityreference_dragdrop, whose info.yml file says:
name: Entity Reference Drag & Drop
As for tests, I can see a theme whose name contains special characters, presumably for testing this (modules/block/tests/modules/block_test/themes/block_test_specialchars_theme/block_test_specialchars_theme.info.yml), but we don't seem to have a module for this! So that means there's maybe no test coverage for the Extend page, even though that gets the escaping right.
When the Image tab gains focus, there is insufficient change in contrast to indicate that focus has been achieved. This is a violation of WCAG 2.1 1.4.1 A Use of color
1. Install Drupal 9.3.12
2. Login as admin
3. Go to /admin/config/content/formats/manage/full_html?destination=/admin/config/content/formats
4. Select CKEditor as the text editor
5. Use the tab key to move the focus to the Image tab.
Expected results:
On focus, the word Image either gains an underline (preferred) or else the difference between focus and unfocused is at least 3:1 in contrast.
Actual result:
On focus, the word Image changes from #004F80 to #2073BF, a contrast change of 1.75:1.
3277559 focused.png shows the tab label Image having focus
3277559 unfocused.png shows the tab label Image not having focus
While it is true that the user can't accomplish anything by activating the focused location, it still needs to be clear for orientation where the focus is.
Increase the contrast between focused and unfocused to 3:1. However, there also needs to be 3:1 contrast between unfocused and surrounding text that is not a (potential) link.
If it is not possible to achieve both contrasts - which is often a result in multi-color situations - then the correct solution might be to underline on focus, even though clicking the link would not achieve anything in this particular case.
Uninstall and then re-install Stark and you will get default block mapping in theme. This shouldn't happen.
Configuration files should be with the object being configured. Move Stark configuration files from core/profiles/standard/config/install to core/themes/stark/config/optional. 'config/optional' is chosen rather than 'config/install' because tests may fail due to unmet dependencies.
The user picture is provided by a field called user_picture.
If you perform a minimal installation of Drupal 8, this field is not created, so you have no user pictures what so ever. The "User pictures in posts" and "User pictures in comments" options in the theme settings are disabled as well.
If you create a new image field, there is no way to make this field the "user pricture" field. And due to the special naming of the "user_picture" field (instead of eg "field_user_picture") there seems to be no way to achieve this through the interface.
Hi all
I'm trying to use Drupal 8 + angular and I've got a trouble.
I have html like this
<section class="actions-menu-inner" ng-style="{ 'max-height': maxPanelHeight }" ed-pretty-scrollbar ed-scroll-axis="y" ed-scroll-theme="light"></section>
Here is special attribute for angular - ng-style.
When I've tried to render it, I found that attribute ng-style wasn't rendered correctly. It was cropped like this:ng-style=" maxPanelHeight }"
It happens in Xss::attributes in this line
$thisval = $skip_protocol_filtering ? $match[1] : UrlHelper::filterBadProtocol($match[1]);
The only way to avoid it is this piece of code (it's in method attributes too):
$skip_protocol_filtering = substr($attribute_name, 0, 5) === 'data-' || in_array($attribute_name, array(
'title',
'alt',
));What the best way to add my own exception for attributes beginning from "ng-". Seems it's not possible right now?
Any help will be appreciated.
The documentation of Drupal\Core\Entity\EntityTypeInterface::getLinkTemplates contains outdated information. The first version of this description was introduced in #1970360: Entities should define URI templates and standard links.
<?php
/**
* Returns link templates using the URI template syntax.
*
* Links are an array of standard link relations to the URI template that
* should be used for them. Where possible, link relationships should use
* established IANA relationships rather than custom relationships.
*
* Every entity type should, at minimum, define "canonical", which is the
* pattern for URIs to that entity. Even if the entity will have no HTML page
* exposed to users it should still have a canonical URI in order to be
* compatible with web services. Entities that will be user-editable via an
* HTML page must also define an "edit-form" relationship.
*
* By default, the following placeholders are supported:
* - [entityType]: The entity type itself will also be a valid token for the
* ID of the entity. For instance, a placeholder of {node} used on the Node
* class.
* - [bundleEntityType]: The bundle machine name itself. For instance, a
* placeholder of {node_type} used on the Node class.
*
* Specific entity types may also expand upon this list by overriding the
* Entity::urlRouteParameters() method.
*
* @link http://www.iana.org/assignments/link-relations/link-relations.xml @endlink
* @link http://tools.ietf.org/html/rfc6570 @endlink
*
* @return array
*/
public function getLinkTemplates();
?>Rewrite the documentation.
Update IS according to #14
Patch
Review
Commit