↧
Admin Toolbar incorrect target for User dropdown
↧
Shortcut: Errors validating the config synchronization
An error appears while importing configuration.
How to reproduce
- Install site using
standardprofile. - Export configuration using a single file.
- Import configuration.
Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization. in Drupal\Core\Config\ConfigImporter->validate() (line 730 of /var/www/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php).
The import failed due for the following reasons:
Entities exist of type Shortcut link and Default. These entities need to be deleted before importing.
↧
↧
Track Layout override revisions on entities which support revisioning
Problem/Motivation
Revisionable entities with custom layout override only track layout changes incidentally when an entity is saved via the entity's edit form. In order to provide full layout revisioning, we should check that the entity type's bundle is revisionable and whether or not a new revision should be created before calling entity save in the Section Storage object.
Proposed resolution
Section storage for the field should determine if the entity's bundle is RevisionableEntityBundleInterface and check shouldCreateNewRevision(). If this is "true" then a new revision should be set on the entity before saving.
Remaining tasks
Write a patch
Write tests
Convince people
User interface changes
No direct changes to the UI. Layout saves for entity override would prompt the creation of new revision which would display the entity's revision tab. That "ui change" is incidental and expected.
API changes
None
Data model changes
None
↧
layout_builder_entity_view_alter() should check whether layout builder configuration is used
layout_builder_entity_view_alter() blindly replaces extra fields for every entity view. It doesn't check whether the entity display is actually using layout builder configuration, thus potentially removing extra fields while it shouldn't do that.
Found while working on #2966959: Value Conflict with Layout Builder
Will see if I can come up with a test here.
↧
Field blocks in the layout builder do not have view mode suggestions
Currently all the field blocks in layout builder are being rendered in ---custom view modes. Having field templates for user defined view modes is not possible at the moment, and hence not able to get the required markup for the page when using layout builder.
↧
↧
View more link in recipe cards is not fully translated
Problem/Motivation
View more link in recipe cards is not fully translated. The bundle is always in English because we are using the bundle machine name.
Proposed resolution
Use the type label() for rendering the translated type name.
Remaining tasks
Patch
User interface changes
None (in English), but will make this translatable.
API changes
None
Data model changes
None
↧
To follow standards base.css should not be under component:
After exploring the demo_umami profile (and reading documentation about the things I was wondering about) I see that the umami.libaries.yml are well organized, but slightly off standard.
According to https://www.drupal.org/docs/develop/standards/css/css-file-organization-... there should be base: component: and layout: categories.
I've included a patch
↧
Allow sites to restrict the blocks available in Layout Builder with configuration
Problem/Motivation
Even with recent improvements to Layout Builder's block listing, the number of categories and blocks is daunting to users. It would be nice if sites could restrict the blocks available to make building layouts easier.
Proposed resolution
Provide a new configuration object that allows sites to restrict the blocks available in Layout Builder. A blacklist seems easier to maintain than a whitelist, especially when considering derived blocks. The config could allow for category and block plugin specific filtering.
As a part of this, it would be nice if Layout Builder shipped optional config for existing core profiles (Standard, Umami) to make the out of the box experience better.
Remaining tasks
Write a patch.
User interface changes
None.
API changes
TBD.
Data model changes
New, optional configuration.
↧
Remove unnecessary UrlGeneratorTrait from core/modules/search/tests/modules/search_extra_type/src/Plugin/Search/SearchExtraTypeSearch.php
In old #2364157 issue_url has been replace with Url objects.
Look at the difference below from issue #2364157:
diff --git a/core/modules/search/tests/modules/search_extra_type/src/Plugin/Search/SearchExtraTypeSearch.php b/core/modules/search/tests/modules/search_extra_type/src/Plugin/Search/SearchExtraTypeSearch.php
index d1855ad565..fc358d03fa 100644
--- a/core/modules/search/tests/modules/search_extra_type/src/Plugin/Search/SearchExtraTypeSearch.php
+++ b/core/modules/search/tests/modules/search_extra_type/src/Plugin/Search/SearchExtraTypeSearch.php
@@ -9,6 +9,8 @@
use Drupal\Component\Utility\SafeMarkup;
use Drupal\Core\Form\FormStateInterface;
+use Drupal\Core\Routing\UrlGeneratorTrait;
+use Drupal\Core\Url;
use Drupal\search\Plugin\ConfigurableSearchPluginBase;
/**
@@ -21,6 +23,8 @@
*/
class SearchExtraTypeSearch extends ConfigurableSearchPluginBase {
+ use UrlGeneratorTrait;
+
/**
* {@inheritdoc}
*/
@@ -57,7 +61,7 @@ public function execute() {
}
return array(
array(
- 'link' => _url('node'),
+ 'link' => Url::fromRoute('test_page_test.test_page')->toString(),
'type' => 'Dummy result type',
'title' => 'Dummy title',
'snippet' => SafeMarkup::set("Dummy search snippet to display. Keywords: {$this->keywords}\n\nConditions: " . print_r($this->searchParameters, TRUE)),
UrlGeneratorTrait class is deprecated and not required by the Url class so we should remove it.
↧
↧
Installation profile missing after upgrade to 8.6.1
I recently upgraded from Drupal 8.5.6 to 8.6.1 and everything appeared to go well. But I noticed today that when attempting to edit a view or review the user list on the site, I received this message:
Drupal\Core\Extension\Exception\UnknownExtensionException: The module minimal does not exist. in Drupal\Core\Extension\ExtensionList->get() (line 257 of /core/lib/Drupal/Core/Extension/ExtensionList.php).
I happened to be on the Status page for the install and noted the installation profile looked liked this:
This is what appears in the error log:
Uncaught PHP Exception Drupal\Core\Extension\Exception\UnknownExtensionException: "The module minimal does not exist." at /core/lib/Drupal/Core/Extension/ExtensionList.php line 257
So it looks like the install profile was removed when the upgrade was conducted.
↧
Two relations from content revisions to content look identical
Problem/Motivation
Create a new view of "Content revisions", open the "Advanced" section, and Add a relationship.
Two of the options have title "Content", category "Content revision", and no description:
The two options are different: one joins on the content ID (nid) and the other joins on the revision ID (vid).
Proposed resolution
Add descriptions that distinguish between the two options:
- Joining on the
nidalways gives some result, so add the description "Content associated to this revision". - Joining on the
vidgives NULL except for the current revision, so add the description "Associated content for the current revision, NULL otherwise".
Remaining tasks
- Review (wordsmith) the new text.
User interface changes
Change the "Add relationships" dialogue.
API changes
None
Data model changes
None
↧
Remove unnecessary UrlGeneratorTrait from core/modules/node/src/NodePermissions.php
In old #2495833 issuecontentPermissions() method has been removed. Together with this method $this->url('system.admin_content') has been removed so UrlGeneratorTrait class is no longer needed.
Look at the difference below from issue #2495833:
diff --git a/core/modules/node/src/NodePermissions.php b/core/modules/node/src/NodePermissions.php
index 74a6442..dca4671 100644
--- a/core/modules/node/src/NodePermissions.php
+++ b/core/modules/node/src/NodePermissions.php
@@ -20,21 +20,6 @@ class NodePermissions {
use UrlGeneratorTrait;
/**
- * Gets an array of content permissions.
- *
- * @return array
- * The content permissions.
- */
- public function contentPermissions() {
- return array(
- 'access content overview' => array(
- 'title' => $this->t('Access the Content overview page'),
- 'description' => $this->t('Get an overview of <a href="!url">all content</a>.', array('!url' => $this->url('system.admin_content'))),
- ),
- );
- }
-
- /**
* Gets an array of node type permissions.
*
* @return array
UrlGeneratorTrait class is deprecated and it is no longer needed so we should remove it.
↧
drupal_check_incompatibility() should be moved to a VersionChecker class
Problem/Motivation
This issue is a blocker for #1612910-384: [PP-1, policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc)
Core needs to be able to determine, internally, if dependencies are met when installing a module. Modules may need to rely on a particular bug being fixed in another module, or within core itself in order to function properly. If a module cannot say "This module requires drupal 8.5.3 or higher" due to something that got fixed in that version, then we'll end up with broken sites because incompatible code was allowed to satisfy a dependency. This issue enables core to be able to support semantic versioning internally, as a feature of the platform.
The module handler includes a parseDependency() method that converts a module version string into an array format expected by the closely related drupal_check_incompatibility(), which is a global function but depends on this expected format.
Proposed resolution
Introduce a new VersionChecker helper class which can parse dependencies and check them for incompatibilities.
Remaining tasks
Convert this code to an exportable Component?
Allow this code to understand semver?
User interface changes
N/A.
API changes
\Drupal\Core\Extension\VersionChecker added.
Data model changes
None.
↧
↧
"Restrict images to this site" restricts images that, by definition, *are* on this site.
On one of our sites, we've set up a block, and using the RAW HTML text format, gave it this code
<img src="/sites/default/files/2018-09/adi%20logo%20banner%202017_04_21.svg" />
This results in a broken image with the alt text "This image has been removed. For security reasons, only images from the local domain are allowed.". The image referred to does exist, and *can't* be on another site, yet is treated as though it is not on the site. Why isn't an image src specified from the root of the local site not treated as on the local site?
↧
Improve migrate UI database credential form
Problem/Motivation
I just attended a UX meeting and learned, among other things, that the form to collect database credentials needs some improvement. Specific items pointed out were better explanations, as in where to find the database password, and more helpful error messages.
Current
And this is the form after entering incorrect data, taken from #87 in #2562845: Validate file path on Credential form
After applying patch
Proposed resolution
Add help text as suggested in #3. This has been added by another issue.
Display database related errors in the same way as when installing Drupal.
Remaining tasks
UX Review. Apply patch goto /upgrade/credentials or /upgrade and click through to the credential form.
Commit
User interface changes
Yes, the database credential form used in Drupal upgrade, at /upgrade/credentials
API changes
N/A
Data model changes
N/A
↧
Allow admins to select a default starting moderation state
Problem/Motivation
Currently 'draft' is the default moderation state for all new content. There are two kinds of defaults when it comes to content moderation:
- The default state in the select list, the one that appears as the selected option on the entity form.
- The default state of the entity, the state that is chosen as the starting point to validate which transitions an entity may use to undergo a state change and the value of
$entity->moderation_statebefore any state is assigned.
The default entity state will be the same as the default widget state as long as the logged in user has access to a transition that allows the default state to be selected. In effect, it's possible to configure a starting state that may never be returned to and will thus never show up in the select list. Under those circumstances, the selected state will revert to the first one in the list.
Proposed resolution
Allow admins to configure the starting entity state. The widget state will also default to this value, provided the user has access to an appropriate transition that allows it.
Remaining tasks
- Tests for setting the default.
- We should not allow deleting the default state.
User interface changes
Additional settings form on moderation workflows.
API changes
A configurable starting state.
Data model changes
Additional config schema value for the content moderation workflow type.
↧
"illegal choice" on add another item in presence of another required field
Make a content type with 2 fields:
* Multivalue text field, make it required
* Select field, make it required but specify no default value
Add a new node of that content type.
Fill in the first value of the text field. Click on "Add another item" button.
You will get message: "An illegal choice has been detected. Please contact the site administrator."
This does not happen when we select a value in the select field underneath. So this problem has something to do with not yet filled in values in other required field(s).
↧
↧
Media entity needs its own entity reference selection handler
Problem/Motivation
Media entities currently use the default entity reference selection plugin (\Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection)
This doesn't take into account the 'published' flag.
Proposed resolution
Add a new selection plugin for media.
Remaining tasks
Reviews
User interface changes
API changes
Data model changes
↧
Add a way to execute a function in the context of a specific workspace
Problem/Motivation
This was proposed by @FabianX in #2784921-151: Add Workspaces experimental module.10:
+++ b/core/modules/workspace/src/Plugin/RepositoryHandler/LiveRepositoryHandler.php @@ -0,0 +1,196 @@ + // Get the latest revision IDs for all the entities that are tracked by + // the source workspace. + $query = $this->entityTypeManager + ->getStorage($entity_type_id) + ->getQuery() + ->condition($entity_type->getKey('id'), $tracked_revisions, 'IN') + ->latestRevision();While this current is not a problem, if we ever wanted to also act on latestRevision() (I get that comment now), we should explicitly specify to override the currently active workspace, so that we compare with whatever workspace we want to compare against (currently default / live):
e.g.
In cps we have:
cps_override_changeset('published');
// ...
cps_override_changeset(NULL);
---
For better code flow I would suggest to use a closure:
$this->workspaceManager->executeInWorkspace(::DEFAULT_WORKSPACE, function() { // Do queries and entity operations against the live site. });We tried to avoid that in CPS at first, but it ended up to be necessary and useful.
Proposed resolution
Add a executeInWorkspace() method to the workspace manager which receives two arguments, a workspace ID and a closure.
Remaining tasks
TBD.
User interface changes
Nope.
API changes
Nope.
Data model changes
Nope.
↧
UI for publishing/unpublishing taxonomy terms
Follow-up to #2880149: [PP-1] Convert taxonomy terms to be revisionable
Problem/Motivation
In #2880149: [PP-1] Convert taxonomy terms to be revisionable taxonomy terms got a publishing status field, but no UI is yet available for users to publish / unpublish taxonomy terms.
Things that should be taken into consideration:
- #2892304: Introduce footer region to ContentEntityForm
- Whats being done on #2834546: UI for publishing/unpublishing block_content blocks
Proposed resolution
Implement the same solution as for nodes, content blocks etc.
- Add a published checkbox on the taxonomy term edit page
- Add publish and unpublish system actions in preparation to using views, and so that users can build their own UIs
published column on vocabulary overview pageSee #35, #36bulk operation actions for publishing / unpublishing termsSee #35, #36
Remaining tasks
User interface changes
Adds a published checkbox to the taxonomy term edit page.
API changes
None.
Data model changes
None.
↧