Make Drupal\Core\Database\Query\Condition driver overridable

February 13, 2020, 3:53 am

≫ Next: Plugin blocks cannot set their own attributes when put in the layout.

≪ Previous: Change hardcoded quote identifier in EntityQueryTest to square brackets

$

0

0

Problem/Motivation

At the moment all 3 by core supported driver can work with the same implementation of Drupal\Core\Database\Query\Condition.
The MSSQL database driver has to for #3113203: Kernel Test testDbLike mandates specific escape behavior. override the default implementation of the Condition class. Also there is for the SQLite driver an override necessary (see: #2031261: Fix SQLite variable limit). The way in which the override is implemented for the SQLite driver is very different to the other query operators. We should database driver override the default implementation of the Condition class in the same way as is done for: select, delete, insert, merge, schema, truncate, update and upsert.
If there are other examples of custom implementations of the class Drupal\Core\Database\Query\Condition, please add them here.

Proposed resolution

Change the calling of the Drupal\Core\Database\Query\Condition to the same way as is done for: select, delete, insert, merge, schema, truncate, update and upsert.

User interface changes

none

API changes

Add the method Drupal\Core\Database\Connection::condition().
All code like: new Condition('AND') must change to: Database::getConnection()->condition('AND').

Data model changes

none

---

Plugin blocks cannot set their own attributes when put in the layout.

August 28, 2019, 9:26 am

≫ Next: migrating entity translated nodes from 7 to 8 field values get deleted

≪ Previous: Make Drupal\Core\Database\Query\Condition driver overridable

$

0

0

Problem/Motivation

Normally, when creating block plugins, one can return an #attributes from the build() method. If that happens, the attributes are being added to the block's wrapper.

It looks like this logic is located here: https://git.drupalcode.org/project/drupal/blob/8.8.x/core/modules/block/...

It doesn't work if the block has been put inside the layout, through the layout_builder. I consider it a bug, as anyone would expect the same behavior here, and it will surely break some custom plugin blocks relying on this feature.

Proposed resolution

Apply the same logic inside the BlockComponentRenderArray as it is in the BlockViewBuilder, to make #attributes work with the layout_builder.

Remaining tasks

Review the patch.

API changes

If anyone used #attributes to put attributes in the content of their block, instead of the block's wrapper, this change will probably break something for him. The weight of this issue is reduced by the fact, that this person would have to create this block plugin only to work in the layout builder, as outside of it, he would quickly notice that it doesn't work as expected.

migrating entity translated nodes from 7 to 8 field values get deleted

November 4, 2019, 9:04 am

≫ Next: DeleteTruncateTest should not rely on default sorting order in DB

≪ Previous: Plugin blocks cannot set their own attributes when put in the layout.

$

0

0

I tried to migrate a site from D7 to D8 that uses entity translation for nodes and taxonomy. Whenever I migrate the site all fields that should contain translations are empty. Furthermore, fields that shouldn't be translated, like for example images are empty as well.

When I don't run the entity translation but just the migration of the node types everything is fine. The fields contain the correct values. As soon as I run the entity translation migration for that node type everything is empty.

It doesn't matter if I use the upgrade or migrations or drush. The result is the always the same: empty fields.

DeleteTruncateTest should not rely on default sorting order in DB

March 15, 2020, 10:16 am

≫ Next: SelectPagerDefaultTest should not rely on default sorting order

≪ Previous: migrating entity translated nodes from 7 to 8 field values get deleted

$

0

0

DeleteTruncateTest test is failed with MemSQL database driver https://www.drupal.org/project/memsql due to reason that MemSQL returns results unsorted. MySQL returns results sorted by primary key in this test.

$pid_to_delete = $this->connection->query("SELECT * FROM {test_task} WHERE task = 'sleep'")->fetchField();

SELECT * FROM {test_task} WHERE task = 'sleep' returns 5, 2 in MemSQL and 2, 5 in MySQL, so
$pid_to_delete == 5 in MemSQL.
$pid_to_delete == 2 in MySQL.

SQL standard doesn't define and databases (even MySQL or PostgresQL) can not guarantee default sorting order, so such order has to be defined in the query if we need specific order.

SelectPagerDefaultTest should not rely on default sorting order

March 15, 2020, 10:43 am

≫ Next: PP-1: Deprecate \Drupal\Core\Database\Database::getDatabaseDriverNamespace as it is no longer needed

≪ Previous: DeleteTruncateTest should not rely on default sorting order in DB

$

0

0

SelectPagerDefaultTest is failed with MemSQL database driver https://www.drupal.org/project/memsql.

SQL standard doesn't define and databases can not guarantee default sorting order, so such order has to be defined in the query if we need specific order.

Query in the testInnerPagerQuery in core/modules/system/tests/src/Functional/Database/SelectPagerDefaultTest.php returns 27, 26, 25, 28 if MemSQL driver is used (actually, the same result if I run this query in the MemSQL console).
Expected result: [25, 26, 27, 28]

PP-1: Deprecate \Drupal\Core\Database\Database::getDatabaseDriverNamespace as it is no longer needed

February 23, 2020, 3:14 am

≫ Next: Apply formatters and widgets to Comment base fields

≪ Previous: SelectPagerDefaultTest should not rely on default sorting order

$

0

0

Problem/Motivation

#3112476: Always set $info['namespace'] on database connection info results in \Drupal\Core\Database\Database::getDatabaseDriverNamespace not being needed. Let's deprecate it for removal in D10.

Also we should deprecate calling \Drupal\Core\Database\Connection::__construct() without a 'namespace' key in the $connection_options array. Which will allow us to simplify \Drupal\Core\Database\Connection::getDriverClass and remove the override in \Drupal\database_statement_monitoring_test\LoggedStatementsTrait

Proposed resolution

Do it.

Remaining tasks

User interface changes

None

API changes

\Drupal\Core\Database\Database::getDatabaseDriverNamespace is deprecated.

Data model changes

None

Release notes snippet

N/a

Apply formatters and widgets to Comment base fields

March 27, 2014, 10:03 am

≫ Next: Mechanism to disable preprocessing of base fields in comment entity type so they can be configured via the field UI

≪ Previous: PP-1: Deprecate \Drupal\Core\Database\Database::getDatabaseDriverNamespace as it is no longer needed

$

0

0

As discussed in #2010930: [META] Apply formatters and widgets to rendered entity base fields (all besides node.title) it is policy to make rendered base fields throughout core configurable through the "Manage form display" UI.

In the case of the comments module, this will take care of many frequently-asked feature requests. This issue is about the Comment entity type's uid, name, mail, homepage and created fields.

#2578741: Add setting for size to email widget was spun off half way through as a dependency of this issue and is already committed.

Making the same change for "Manage display" is being handled in a separate issue #3090187: Mechanism to disable preprocessing of base fields in comment entity type so they can be configured via the field UI.

Remaining tasks

1. Rework patch to use, and remove any overlap with, #2578741: Add setting for size to email widget
2. Fix test failures.
3. Respond to code reviews #105,#106#108
4. Create upgrade path & upgrade path tests
5. ?"Once test failures are fixed, look into converting more base fields." (may no longer be relevant?)

User interface changes

None.

API changes

None. The comment.subject, comment.mail and comment.homepage base fields are rendered using widgets and formatters, and is no longer exposed as an "extra field".

Mechanism to disable preprocessing of base fields in comment entity type so they can be configured via the field UI

October 25, 2019, 9:54 am

≫ Next: Notice: Undefined index: status in _update_project_status_sort()

≪ Previous: Apply formatters and widgets to Comment base fields

$

0

0

#2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI deals only with nodes. This issue does the same for the comment entity types. Fix preprocess and templates to bypass special processing of base fields if the new setting is enabled:

• 'created'
• 'uid'
• 'pid'
• 'subject'

Solution

Copy everything done in #2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI.

---

Notice: Undefined index: status in _update_project_status_sort()

March 5, 2020, 9:53 am

≫ Next: Allow exposed form to preserve URL query parameters - BEF

≪ Previous: Mechanism to disable preprocessing of base fields in comment entity type so they can be configured via the field UI

$

0

0

Problem/Motivation

Background:

Given that the PHP version is "PHP7.3"
Installed Drupal with the "standard" installation profile with number of contrib modules
Enabled"Update Manager" module
Having"All messages, with backtrace information" for "Error messages to display" in "Logging and errors"
And login as the site admin or user number 1

Scenario:

When we go to any "/admin/*" page
Then we should not have any Notices

Notice: Undefined index: status in _update_project_status_sort() (line 634 of core/modules/update/update.module).
_update_project_status_sort(Array, Array)
uasort(Array, '_update_project_status_sort') (Line: 55)
update_requirements('runtime') (Line: 186)
update_page_top(Array) (Line: 336)
Drupal\Core\Render\MainContent\HtmlRenderer->buildPageTopAndBottom(Array) (Line: 135)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 67)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 694)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Proposed resolution

If we can't parse a version string, instead of leaving the project status empty and letting the rest of Update Manager blow up in unexpected ways, we should always set a status. In the case of an un-recognized version string, use UNKNOWN (or UpdateFetcherInterface::UNKNOWN for >=8.9.x).

TBD: We could also add a message about why the status is unknown.

Remaining tasks

• Troubleshoot with contrib and custom modules
• Provide a patch#39 and #41
• Bikeshed about the new message when we can't parse a version string.
• Other reviews, improvements.
• RTBC.
• Commit (e.g. #41 to 9.0.x branch and cherry-pick to 8.9.x, and commit the 8.8.x-specific patch (e.g. #45) to 8.8.x

User interface changes

Possibly adds a new message on the Available updates report for projects where we can't parse the currently installed version string:

Pre #3074993 (e.g. 8.8.2)

Before / current (as of 8.8.3)

After (with patch #41)

API changes

N/A

Data model changes

N/A
R

Allow exposed form to preserve URL query parameters - BEF

March 15, 2020, 2:10 pm

≫ Next: Improve hook_module_preinstall & hook_module_preuninstall to include recommendations for config import and pass an $is_syncing argument

≪ Previous: Notice: Undefined index: status in _update_project_status_sort()

$

0

0

Applying the same url query param reserve field to BEF. All other logic is done in the parent issue.

Improve hook_module_preinstall & hook_module_preuninstall to include recommendations for config import and pass an $is_syncing argument

March 5, 2020, 4:32 pm

≫ Next: A dropbutton changes position after opening

≪ Previous: Allow exposed form to preserve URL query parameters - BEF

$

0

0

Problem/Motivation

In #2914174: Improve hook_install() to include recommendations for config import and pass an $is_syncing argument $is_syncing parameters were introduced to hook_install, hook_uninstall, hook_modules_installed and hook_modules_uninstalled to check if the config was being synced while the hook was running, as creating/altering configuration entities can cause issues in these hooks.

In #3087130: Profile configuration should be able to depend on optional configuration provided by modules the currently proposed patch has if (!\Drupal::service('config.installer')->isSyncing()) inside hook_module_preinstall(). This is exactly what we wanted to avoid in this hook and replace with if (!$is_syncing)

Proposed resolution

Add the $is_syncing parameter to hook_module_preinstall & hook_module_preuninstall.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

A dropbutton changes position after opening

March 15, 2020, 5:33 pm

≫ Next: \Drupal calls should be avoided in classes, use dependency injection instead in book module

≪ Previous: Improve hook_module_preinstall & hook_module_preuninstall to include recommendations for config import and pass an $is_syncing argument

$

0

0

A dropbutton changes position after opening . It happen at a page like /admin/structure/types/manage/article/fields , after opening dropbutton, it moves left.

\Drupal calls should be avoided in classes, use dependency injection instead in book module

February 23, 2020, 11:59 pm

≫ Next: Activity Tracker module does not allow to prevent anonymous users from seeing the users activity.

≪ Previous: A dropbutton changes position after opening

$

0

0

Activity Tracker module does not allow to prevent anonymous users from seeing the users activity.

June 8, 2018, 7:24 pm

≫ Next: Entity view/form mode formatter/widget settings have no translation UI

≪ Previous: \Drupal calls should be avoided in classes, use dependency injection instead in book module

$

0

0

Problem / motivation
The core tracker module is a really useful module that enables tracking of recent content for users.
The main problem is that the most of times we want to enable and allow just admins or content editors to access this interface, but the module is currently using the default _permission: 'access content' for "/activity" url (see tracker.routing.yml). The most of times you might not want to have content types or users names disclosed to the anonymous users.

Steps to reproduce
1) Enable Activity Tracker module
2) As anonymous user, try to access http://yoursitedomain.com/activity
You might see all the information about the users activity, including "Page type", "Page Title", "Author", "Comments" and "Last Updated Date". There is no way to control who can see this information.

Proposed solution
Create a new "access users activity" permission and use it instead of the default "access content". It is possible to have better control of who should see the page by having this new permission type.

Entity view/form mode formatter/widget settings have no translation UI

August 5, 2015, 9:32 am

≫ Next: Download translation link in new tab

≪ Previous: Activity Tracker module does not allow to prevent anonymous users from seeing the users activity.

$

0

0

Problem/Motivation

We need to have all configuration that a user can define, which has translatable information on it, to be translatable in the Configuration Translation module's user interface.

There are several pieces of information from the Entity/Field system, which may include translatable strings, but which are not translatable using the Config Translation UI:

a) Field settings. For instance, on a Number field, there are translatable settings for the Prefix and Suffix in the settings config. But if you go to the Translate page for the field, all you can translate is the Label and Help for the field, not the prefix/suffix.

===> This is because the schema is wrong. See #2546356: Numeric field prefix/suffix settings should be translatable. Fields are translatable along with their settings, supposedly anyway.

b) Entity view displays - field formatter settings. For instance, on #2449597: Number formatters: Make it possible to configure format_plural on the formatter level we are adding the ability to numbers to have formatPlural() type formatting, but there is no way to translate the "1 item/@count items" strings. These are stored on the entity view display config items.

c) Entity form displays - widget settings. For instance, many text fields have widget options to enter Placeholder text, and obviously this would need to be translated. These are stored on the entity form display config items.

d) Base field overrides, which seem to include labels.
==> will do this on a separate issue

The technical reason is, at least for the entity view/form display formatter/widget settings, that there is not an edit form for these things -- the config schema indicates they should be translatable, but there's no way to edit them so config translation module doesn't put up a UI for translating them either. They are settings that appear as part of the Manage Form or Manage Display pages in Field UI, but the individual fields do not have their own settings forms.

Comment #5 also looked at other config items to see if they were translatable and #8 discussed them; more issues will be open.

Proposed resolution

Make sure that these items have a translation UI.

Remaining tasks

Figure out how to make them translatable. Maybe add tests too?

User interface changes

You'll be able to translate your site. Can't now.

API changes

Probably not, but we'll have to see what the patch entails.

Data model changes

I wouldn't think so.

---

Download translation link in new tab

May 20, 2019, 6:16 am

≫ Next: Fix update.php missing version info from Git Deploy

≪ Previous: Entity view/form mode formatter/widget settings have no translation UI

$

0

0

Problem/Motivation

In Drupal core installation under the Choose language, It suggesting the external link https://localize.drupal.org/download. For better usability, open the external links in a new tab. So the end-user will not affect on-screen navigations.

Proposed resolution

Open the https://localize.drupal.org/download in new tab.

Remaining tasks

Nil

User interface changes

Nil

API changes

Nil

Data model changes

Nil

Release notes snippet

Nil

Fix update.php missing version info from Git Deploy

August 11, 2013, 1:01 pm

≫ Next: Problematic langcode syncing with preferred_langcode

≪ Previous: Download translation link in new tab

$

0

0

First, 8.x is a very different beast and will need an entirely different patch -- it's not solved there, it's a regression in D8 that I will file. In D7, however, this is an easy documentation fix that I deem major cos if someone accidentally pretties the code here by adding $module_list = array() here then git deploy is screwed.

Problematic langcode syncing with preferred_langcode

March 11, 2020, 10:11 am

≫ Next: Contextual Links Style Update

≪ Previous: Fix update.php missing version info from Git Deploy

$

0

0

Problem/Motivation

We've come upon an issue with the syncing of langcode with preferred_langcode on the User entity.

When editing the preferred language of the User entity to an existing entity translation langcode, an exception is thrown:
InvalidArgumentException: A translation already exists for the specified language (pt-pt). in Drupal\Core\Entity\ContentEntityBase->onChange() (line 810 of drupal/core/lib/Drupal/Core/Entity/ContentEntityBase.php).

After investigating the cause for this issue, our findings point to the entity builder Account:syncUserLangcode(), which is syncing the langcode with the preferred_langcode. This results in a problem when changing the langcode if the new value points to an existing translation. If this operation is removed, the problem no longer occurs.

Reproduction steps

1. Enable content translation
2. Add new languages to the site (e.g. pt-pt).
3. Translate the user entity to pt-pt.
4. Edit the User entity in its default translation, through the UI, setting its preferred langcode to pt-pt.
5. Save
6. Observe the thrown exception

Proposed resolution

Remove Account:syncUserLangcode(), which is BC break. We need to find out why it was introduced in the first place.
See #2230637: Create a Language field widget and the related formatter where this has not been discussed in the comments.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Contextual Links Style Update

January 1, 2019, 11:48 am

≫ Next: Claro layout on really wide screens/viewports causes uncomfortable text line length

≪ Previous: Problematic langcode syncing with preferred_langcode

$

0

0

Originally submitted on Github

Problem/Motivation

The admin UI theme is being redesigned and Contextual links need to be integrated with the new design system.

Proposed resolution

Implement new contextual links styles. No functional differences.

Complete specs: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

Remaining tasks

• Add design specs
• Update patch styling to include time inputs
• Accessibility review

Testing instructions

Enable Claro and set as the default theme
• If the profile used is Umami, access any existing content like /recipes/watercress-soup.
• If the profile is Standard, go to the homepage and hover the "No front page content has been created yet." message.

Claro layout on really wide screens/viewports causes uncomfortable text line length

November 23, 2019, 6:46 am

≫ Next: Workspace UI usability review

≪ Previous: Contextual Links Style Update

$

0

0

I've noticed that the Claro layout has no max-width set, so it can become quite awkward and unpleasant to use on really wide viewports, e.g. ultra wide monitors. You can simulate this on smaller screens by zooming out considerably with your browser's zoom. While the functionality seems to work fine, lines of text can become very long and difficult to read.