Umami comes with a new language switcher.
When adding more languages (beyond the existing English and Spanish) it will break the nice flow of the header.
Add the list of available languages into a dropdown menu.
Create dropdown menu.
Figure out best positioning and a visual representation that will be easy to identify as "Here's where I can switch to another language"
Take the final steps to mark Layout Builder as a stable module
Swap Core (Experimental) for Core in the info file
Remove the @internal tag when only used because the module is experimental (and clarify the tag for the cases it is kept)
Copy the CSS and templates to Stable theme
Add an entry to MAINTAINERS.txt
Any remaining "Needs ____" tags, as applicable
Critical accessibility blockers have been completed. Many major issues remain. See #3007978: Accessibility Plan for Layout Builder.
Layout Builder does not support translated layout overrides currently. Any new sites installing Layout Builder will not be able to enable translation on Layout field through Content Translation.
But some sites that had both content translations and Layout Builder enabled before #3041659: Remove the layout tab from translations because Layout Builder does not support translations yetand had both translations and layout overrides on the same bundles maybe have Translations still enabled on the Layout field.
It could be not safe for them to just turn off translations because they may need the current values they have in the translated fields.
On Content Translation admin form add a warning to all Layout fields with a link to the handbook page https://www.drupal.org/docs/8/core/modules/layout-builder/layout-builder...
Image may be NSFW.
Clik here to view.
Only sites that were installed when Layout Builder was still beta will see this warning.
None
@see Proposed resolution
None
None
Image may be NSFW.
Clik here to view.
Hi All,
I am working on Drupal 8.2.0-dev for website on linux server with MariaDB as database server. The site setup is based on 3 instances of website setup or file system using one database. Whenever updates are made to the site cache is cleared from all 3 instances / nodes for changes to work properly esp. twig template changes.
Here is more detail about site configuration on server :-
The website is actually a 3-node cluster behind a load balancer.
Each node (node1,node2 and node3) are part of a MariaDB Galera Cluster, and each node is hosting the Drupal website.
Each drupal website communicates with it’s own DB. So this means when node1 is serving a page, it is reading/writing to the DB on node1. Likewise, node2 read/writes to node2’s DB and so on.
The website files on main location are replicated between the nodes using lsyncd and csync2.
So, when a visitor hits the website, traffic flow is :
HTTP Traffic -> HAPROXY Load Balancer -> (one of the 3 Nodes)
a. Node1 website communication to MariaDB on node1 (localhost)
b. Node2 website communication to MariaDB on node2 (localhost)
c. Node3 website communication to MariaDB on node3 (localhost)
I face an error :-
1. While using drupal admin interface for making updates or inserts website admin often gets error below.
2. Wen cache is cleared using Drush on website on the frontend also.
Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {cache_entity} (cid, expire, created, tags, checksum, data, serialized) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array, referer:
After searching on similar issues I found that solution suggested are using modules which are not ported to Drupal 8 yet e.g. https://www.drupal.org/project/apdqc. This issue was reported for Drupal 7 several times but not Drupal 8. I am not sure if its bug so adding support request.
Have not been able to find any reliable solution for this.
Just to add in my case the deadlock always is related to cache tables. Also can "Entity/field definitions" , " Mismatched entity and/or field definitions " as on page /admin/reports/status has any relation to this?
Any suggestions would be appreciated.
Thanks
Atul
The form-element.html.twig template in Classy wraps inline error messages in a <strong> element.
<strong> cannot contain grouping elements such as <div> or ul, these can be used only where flow content is expected.W3C Current recommendation, W3C Working draft
Remove the <strong> element from the core/themes/classy/templates/form/form-element.html.twig template and add `font-weight: bold;` for `.form-item--error-message`.
Provide a patch.
Themes that extending Classy should (must?) be reviewed.
Nothing.
Nothing.
KeyValueContentEntityStorage is a plain extension of KeyValueEntityStorage and thus is missing most of the abstract logic provided by ContentEntityStorageBase.
Add an implementation for all the missing content-entity-specific use cases and add further test coverage.
None
None
None
Imagine an organisation WidgetCo with editors and users in a variety of different time zones. They commonly face 2 problems trying to use the Date module. Support for some of this was present in D7's date but lost as it went to D8 core.
A. When creating session entities as part of their annual conference in New York, the times of the sessions as input by the editor are interpreted by Drupal in terms of the time zone of the editor who is creating or updating it, not New York. In this case their sitebuilder needs to be able to control the time zone used by the widget to interpret the times the editors input.
B. When creating meeting entities to describe meetings held at various locations across the world, the same problem happens. But in this case the intended time zone needs to specified for each meeting by the editor, and that preference needs to be stored with the date/time.
A timezone handling configuration drop down on field storage configuration, and if configured for per-date storage, a timezone selector on the date widget.
datetime form element will have an optional #expose_timezone boolean, that if TRUE, will add a timezone selector to the element.
Datetime storage will store a timezone per date.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
hi,
step to repeat
-create a view for a content type with a (required) date field
- add a filter 'that field value is greater than -7days'
- filter-expose that field
- choose group filters to have a select-option between ALL or -7days
it works but generate:
Warning: Illegal string offset 'value' in Drupal\views\Plugin\views\filter\Date->validateValidTime() (line 83 of core/modules/views/src/Plugin/views/filter/Date.php).
Drupal\views\Plugin\views\filter\Date->validateValidTime('field_seminary_end_date_value', Object, '>', '1') (Line: 72)
Drupal\views\Plugin\views\filter\Date->validateExposed(Array, Object) (Line: 140)
\Drupal\Core\Plugin\Context\ContextHandlerInterface::applyContextMapping() applies a set of contexts to a given plugin.
If any of the contexts required by the plugin are not present in those passed to the method, an exception is thrown.
However, if the plugin already had that context set, there is no reason to throw the exception
If a context is "missing" from those being applied, only throw an exception if the plugin doesn't already have that context
When accessing admin/structure/display-modes/view at the end of each entity type there's a link for adding a new view mode. Here are some examples:
Add new Custom block view mode
Add new Comment view mode
Add new Taxonomy term view mode
The problem is that the string used to create this output and also used for translation is: Add new %label @entity-type which looking above @entity-type should be 'Custom block', 'Comment' and 'Taxonomy term' not 'view mode' and %label should be 'view mode' not the actual entity types.
This is confusing when translating the UI and should be an easy fix.
This is a followup issue of #2994915: Remove Page Title block from homepage .
There is a title given to the Recipes sections along with a subheading which gives information about the whole section. IMO the Promoted section needs to have a heading & a subheading to define the section which will keep the design consistent.
Image may be NSFW.
Clik here to view.
In the `Header` in the Promoted view to add the heading and the subheading with the appropriate heading tags.
Discuss to come up with a solution since it's a design issue.
Heading and subheading will be added to the promoted section.
None
None
All entries on that day
Empty
Increase the range automatically by one day, if twice the same day was created
On migration from D7, the taxonomy term fields get migrated fine, but they are set to allow all vocabularies, even though that wasn't the case in source.
In D7, the allowed vocabularies is a part of field settings which is not available in instance migration, which is where it needs to be in D8. We should add the settings first and then process it during migration.
For all the allowed vocabularies the vid needs to be added to the row so somewhere in the pipeline a migration_lookup can be done to determine the new, migrated vocabulary name.
PatchReviewTesting - patch confirmed to work in #49
Commit
None
None
None
ViewRenderTest makes no HTTP request but is a functional test.
Convert ViewRenderTest into a Kernel test.
None.
None.
None.
None.
N/A
ViewsTemplateTest makes no HTTP requests but is a functional test.
Convert ViewsTemplateTest into a Kernel test.
None.
None.
None.
None.
N/A
Test Drupal\Tests\user\Functional\UserDeleteTest neve makes a HTTP request but i sfunctional.
Convert it to a kernel test.
Alternative: Remove it. For me looks like a naive test, all the functionality must have been tested somewhere in Entity API tests.
Make decision: convert or remove?
None.
None.
None.
N/A
Our CSS standards have a recommendation about the order of property declarations so we should apply it to core.
Add https://www.npmjs.com/package/stylelint-order and use the existing CSScomb config to configure it and use the --fix option to generate a patch.
Blocked on #3024518: Upgrade stylelint to the latest version
Once that has landed you can:
$ cd core$ yarn add stylelint-order --devcore/.stylelintrc.json$ curl https://www.drupal.org/files/issues/2019-03-08/3024527-4-28.patch | git apply --index --include=core/.stylelintrc.json$ yarn run lint:css --fixNone
None
None
CSS standards for ordering is now enforced using the stylelint-order plugin.
For the Drupal 7 version of this issue, see #2010898: Use tokens for entity selection view arguments.
Entity Reference allows using a View of a specific display type to set the available options. This is good.
It's also possible to set arguments (contextual filters) on that view from the ER field config screen. This is also good.
Those arguments must be completely static. This is not good.
Rather, it should be possible to have dynamic, context-aware arguments. The most obvious is "the node that this is on", allowing the view to filter based on the node itself. Ideally, other "relational" contexts (Panels-style, or maybe just via token if that's easier) should be possible, such as "the author of the node this is on", "the OG of the node this is in" (my actual use case), etc.
That would greatly expand the potential flexibility of that view to do all sorts of context-aware select lists.
Of course, there's the obvious problem of what to do when creating a node (or user, or whatever other entity) the first time, since there is no "this" yet to refer to. I see two possible ways to address that:
1) Allow for a default value, or a different context to pull from if null. Eg, if there's no node owner, default to the current user. This would be configurable.
2) Punt that question to the View, where there is already fairly sane default argument capability. As long as we are able to do relational arguments, so that the contextual filter on the View doesn't have to be the entity type that it is on, that's probably sufficient and easier to implement anyway.
In my specific use case, I want to have an ER from a node to other nodes of type Foo that are in the same OG as the node being edited; if the node is being added, default to the user's OGs. The same concept would apply in many other situations, of course, such as related posts by the same author, etc.
(The current alternative involves writing a completely new custom views default argument plugin for every use case, which is highly sub-optimal.)
Thinking about it, I believe tokens would likely be the most straightforward way to specify such values.
So:
1) Is this feature something that would be accepted?
2) I MAY be able to get some time to work on this for the client project that requires it, if I knew it would be accepted so that we're not working with a project fork. :-) Is this doable? (If not, we'd have to fall back to the one-off above.)
FieldGroupRowsTest make no HTTP requests but is a functional test.
Convert FieldGroupRowsTest into a Kernel test
None.
None.
None.
None.
N/A