Problem

There is GD specific code in Rotate::validateArguments.
Generally, in GD toolkit operation classes (like, gd/Resize gd/Scale etc.) we only have calls to GD functions in their 'execute' methods.

This blocks #2578563: [PP-1] ImageToolkitOperations need traits as it is needed to have toolkit agnostic traits for the ::arguments and ::validateArguments methods for all image toolkit operations, so that contrib toolkits could benefit from those without having to re-add boilerplate code. See the Image Effects module for an example of using traits shared by GD and ImageMagick toolkits operations.

Proposed resolution

• Move GD specific code from ::validateArguments to ::execute
• Add test coverage.

The change in the test to add the mock logger is because, with the change to validateArguments() when the exception is thrown, it tries to log it.

Some out of scope changes can be done in follow-up #2796369: [PP-1] Cleanup gd/Rotate::execute() arguments array overloading

Remaining tasks

Review patch. Note changes might make more sense when looking at it in context.

User interface changes

None

API changes

None

Original report by @YesCT

original bug is no longer an issue

1. the new OS X builds have the toolkit
2. the test doesn't actually perform changes to images

In the test class it already stubbed out the 'execute' method of the image toolkit operations, so we can test the Image class without actually performing changes to images (this relates to the original issue report about testRotate() failing).

report was

On PHP 5.5.14 unit tests fail Drupal\Tests\Core\Image\ImageTest::testRotate imagecolorallocatealpha() expects parameter 1 to be resource, null given

Follow-up to #2463879: PHP unit tests fail if intl extension is missing

On running phpunit tests:
https://www.drupal.org/node/2116263

./vendor/bin/phpunit --filter=ImageTest
will run just the one class with the test that fails.

PHP 5.5.14

mac os x native /usr/bin/php

There was 1 error:

1) Drupal\Tests\Core\Image\ImageTest::testRotate
imagecolorallocatealpha() expects parameter 1 to be resource, null given

/Users/ctheys/foo/drupal/core/modules/system/src/Plugin/ImageToolkit/Operation/gd/Rotate.php:60
/Users/ctheys/foo/drupal/core/lib/Drupal/Core/ImageToolkit/ImageToolkitOperationBase.php:177
/Users/ctheys/foo/drupal/core/lib/Drupal/Core/ImageToolkit/ImageToolkitBase.php:127
/Users/ctheys/foo/drupal/core/lib/Drupal/Core/Image/Image.php:148
/Users/ctheys/foo/drupal/core/lib/Drupal/Core/Image/Image.php:190
/Users/ctheys/foo/drupal/core/tests/Drupal/Tests/Core/Image/ImageTest.php:455

FAILURES!
Tests: 7631, Assertions: 40525, Errors: 1, Incomplete: 2.

php -i | grep "GD Version"
GD Version => bundled (2.1.0 compatible)

MAMP php's

PHP 5.4.34

Tests: 7631, Assertions: 40527, Incomplete: 2.

PHP 5.5.18

Tests: 7631, Assertions: 40527, Incomplete: 2.

PHP 5.6.2

Tests: 7631, Assertions: 40527, Incomplete: 2.

Problem/Motivation

Follow-up from #3334489: ChainedFastBackend invalidates all items when cache tags are invalidated.

Several core plugin managers use cache tags for invalidation - for example the element info cache depends on the theme, so an 'element_info' cache tag is added, and that way the cache can be invalidated for all themes using the tag.

This is also done in at least some places by language.

This adds some overhead to cache gets, because the cache tag needs to be fetched. However, we know that the cache tag is not cleared arbitrarily, it's only used in ::clearCachedDefinitions()

element_info_build
* theme_registry
* library_info

Steps to reproduce

Proposed resolution

Instead of using a cache tag, loop over the list of themes in ::clearCachedDefinitions(), clearing each cid individually.

Remaining tasks

Anything straightforward I think we could do in one issue. There might be some other discovery mechanisms (breakpoints etc.) where we want to open spin-off issues.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In reviewing #2994702: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`, the UX team had this feedback about the "remove" button that appears for each embedded media item:

...it [is] entirely too easy to accidentally stray-click the "X" icon and remove an embed. They asked for a confirmation dialog to be displayed first. Since the existing image embed button does not display an "X" (you just have to click the embedded image and press Delete on your keyboard), we agreed to remove the "X" button from this patch and add it back, with a confirmation alert box, in a follow-up.

That's this follow-up.

Proposed resolution

Restore and update the relevant code from #2994702-43: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption` into a new patch in this issue, and add a confirmation dialog when the "remove" button is clicked. (Also, figure out if the presence of the confirmation should be configurable.)

Remaining tasks

Restore the old code, then determine what the text of the confirmation box should be, whether it should be configurable, etc. Then add tests, get UX and accessibility sign-off, and commit.

User interface changes

Media items embedded in a CKEditor instance will receive a new button which allows them to be removed from the content.

API changes

None expected.

Data model changes

None.

Release notes snippet

TBD

Problem/Motivation

In Drupal 7, the entityreference module allowed to create multiple field instances of the same field. The migration here "works" but then any time an entity without any data attempts to set an entity reference value an InvalidArgumentException is thrown in ContentEntityBase.

InvalidArgumentException: Field <field name> is unknown.

A comparison between getting field definitions directly from entity_field.manager reveals that the field does in fact exist on the bundle, but getting the field definition on the entity itself fails. I found that if I reset the field definitions before the exception, then it tries to go further, but runs into a similar exception in typed_data_manager.

Furthermore this is only an issue for one of the bundles. The other bundle works fine.

Steps to reproduce (as detailed in a test-only patch):

1. Add field_reference_3 field_config
2. Add field_reference_3 field_config_instance to both article and forum node bundles.
3. Run the appropriate migrations.
4. Load node 2 (an article node) e.g. $node = Node::load(2);
5. Attempt to set an initial reference e.g. $node->set('field_reference_3', [5]); or $node->get('field_reference_3')->appendItem()->set('field_reference_3', [5]); or $node->field_reference_3 = ['target_id' => 5];
6. An exception is thrown and we can see that the field definition doesn't exist on the node, but does exist on field manager.

This might be why #2814963: Support Drupal 7 entity reference fields is still open/postponed even though plugins exist for it?

Proposed resolution

Reset the entity cache of the entity type that a field instance is attached to after the field instance is migrated.

Remaining tasks

1. Review proposed resolution
2. Reword test comments to accurately describe the issue and problem

User interface changes

Unknown

API changes

Unknown

Data model changes

Unknown

Problem/Motivation

When Drupal cannot connect to the migration database, migrate_drupal_migration_plugins_alter() adds an error to the messenger service:

Failed to connect to your database server. The server reports the following message: No database connection configured for source plugin variable.

• Is the database server running?
• Does the database exist, and have you entered the correct database name?
• Have you entered the correct username and password?
• Have you entered the correct database hostname?

There are two problems:

1. The problem usually has nothing to do with the variable source plugin.
2. Adding the error to the messenger service means that it is unpredictable where this error will be displayed.

The same error message is generated by the credential form in migrate_drupal_ui. The first problem applies there, but not the second.

Steps to reproduce

After #3063856: [PP-1] Expose full set of debugging data in migrate_message table (filterable/searchable), the easiest way to see the problem is to enable migrate_drupal_ui and then visit a page such as /admin/reports/upgrade-messages/d7_file.

Proposed resolution

For (1), move the error message reported by the server after the list of suggested remedies.

For (2), find a more reliable way to track errors.

Remaining tasks

User interface changes

Different error messages.

API changes

None

Data model changes

None

Release notes snippet

N/A

Problem/Motivation

We noticed this problem on #3063856-130: [PP-1] Expose full set of debugging data in migrate_message table (filterable/searchable).

A migration plugin that uses a source derived from SqlBase cannot be instantiated if the configured database connection is disabled. Although the plugin cannot be executed in this case, there are other reasons for instantiating it. For example, it gives access to the map and message tables.

Steps to reproduce

1. Install Drupal 7 with the devel_generate module (part of the devel project, at least for D7).
2. Generate some sample content: vocabularies, taxonomy terms, users, menu links, and nodes.
3. Install Drupal 10, with the patch from #3063856-120: [PP-1] Expose full set of debugging data in migrate_message table (filterable/searchable), and enable the migrate_drupal_ui module.
4. Migrate from the D7 site, starting at /upgrade on the D10 site.
5. Review the migration messages using the pages added in this issue.
6. Shut down the database server for the D7 site.
7. Repeat Step 5.

Alternatively,

1. Install Drupal 10.1.x with the Standard profile.
2. Define $databases['migrate']['default'] in settings.php with a fake database host or one that is not running.
3. Enable the migrate_drupal module.
4. Execute this code: $migration = Drupal::service ('plugin.manager.migration')->createInstance('d7_node_type';. For example, use drush php or add that code to some module.
5. You should get a message something like this: "PDOException SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo for ddev-drupal7-db failed: Temporary failure in name resolution."

Proposed resolution

Catch the exception.

Drupal\migrate\Plugin\migrate\source\SqlBase::setUpDatabase() already catches ConnectionNotDefinedException and re-throws it as a RequirementsException.

1. Move that try/catch block to Drupal\migrate\Plugin\migrate\source\SqlBase::checkRequirements().
2. Update SqlBase::checkRequirements() it so that it catches \PDOException.
3. Update SqlTestBase as needed because of the changes in (2).
4. Add test coverage for the exceptions to SqlTestBase.
5. Add new kernel tests to the migrate and migrate_drupal modules.

Remaining tasks

1. Decide whether to move the existing catch block, as in #11, or just add a new one.
2. Decide how much of the new test coverage to keep.
3. Add a change record.

User interface changes

No more WSOD when using #3063856: [PP-1] Expose full set of debugging data in migrate_message table (filterable/searchable).

API changes

I do not think this counts as an API change.

Data model changes

None

Release notes snippet

N/A

Problem/Motivation

\Drupal\user\AccountForm programmatically checks entity field access for several User base field definitions. However, the 'mail' field has no such access check

Steps to reproduce

Implement a hook_entity_field_access() and forbid the mail field:

  if ($items && $items->getEntity()->getEntityTypeId() === 'user'&& $field_definition->getName() === 'mail'&& $operation == 'edit') {
    return AccessResult::forbidden();
  }

Proposed resolution

Add an access check for the Accountform 'mail' field.

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

A request that immediately follows a cache rebuild or a memcached flush results in a major performance issue, as Drupal tries to cache all available blocks at once. We ran into an issue on a couple of applications where memcached didn't have enough memory allocated to withstand the onslaught of memcache_set. This resulted in multiple calls for all of the blocks to be set en masse in memcached - because it attempts to fulfill its initial request ("write ~2300 blocks to cache_discovery, please"), then runs out of room (hits the memory ceiling), then tries to complete the job by taking a second swipe at it. You can see this at work in this xhprof run:

MemcachePool_set is being called over 4600 times here - which is approximately 2X the number of custom blocks in the database:

mysql> SELECT COUNT(*) FROM block_content;
+----------+
| COUNT(*) |
+----------+
|     2294 |
+----------+
1 row in set (0.00 sec)

Proposed resolution

Skip the entity api completely and go directly to the tables for the required data. The entirety of the required data for the current deriver is contained in block_content and block_content_field_revision. A single simple join is much faster and more performant for sites with heavy custom block usage.

Remaining tasks

Validate the approach in the patch and update as necessary.

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

In an issue in a different queue @dmundra figured out how to integrate Axe testing into our Nightwatch tests: #2857808: Automate Accessibility Checks for Core. In the time since that discovery, Nightwatch has added Axe support, so this can be done without any new dependencies.

Steps to reproduce

Proposed resolution

• Create a profile for a11y testing
• Create default and admin theme tests that visit a few common pages which are then scanned with Axe
• Ideally, some of these tests will include a few failing tests, so we can verify Axe is doing its job and establish the value of these tests.
• Update readme with info on running a11y tests

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Core Nightwatch tests now include Axe accessibility scans that check common pages and forms for accessibility bugs.

Problem/Motivation

Expected behavior:
If no description is given for an adminstrative block the description value should be "false", thus enabling themer to easily hide description if necessary
Current behavior:
The description value is an empty markup string. This does make it complicated to hide the description and even the default implementation of admin-block-content.html.twig in /core/modules/system/templates is not working correctly actually.

Proposed resolution

Check if description is empty (php empty) instead of checking if description is set (php isset)

Remaining tasks

• Provide patch
• Review

Example

The paragraphs module does not provide a description for Paragraph settings (admin/config/content/paragraphs) in paragraphs.links.menu.yml. So one would expect to have "false" on description, but instead there is an empty markup string.

Problem/Motivation

This is easily reproducible on simplytest.me:

1. Install Drupal w/ standard profile
2. Add an article node with garbage info
3. Create a view with base table of Content Revisions, displaying fields.
4. Add field "Tags" under category "Content (historical data)"
5. In settings for that field, rewrite the field using "Override the output of this field with custom text" (actually doesn't matter what you pick, you just need something that exposes the replacement tokens)
6. Observe that the replacement token for that field contains a hyphen: "{{ field_tags-revision_id__target_id }}"

Before

The problem is that you cannot have hyphens in twig variables like that. I believe it should be two underscores instead based on what I've seen in some other issues.

Proposed resolution

- Use the field alias instead, but don't break things that use field name in the view.
- Views post-update that is run as batch to be scalable for sites with many views.
- Write a test to assert the problem.
- Write a test to assert the post-update.

After

Remaining tasks

- Re-roll patch for 8.8.x branch. :|. Done in #52, tested in #58.
- Review current patch, tested in #58
- Manually test the patch for views post-update to confirm that the view was updated automatically (See #50 for ideal testing plan steps), done in #58.
- Don't override possible '-revision_id' string added by the administrators on the override strings. Use Regexp to actually replace only instances of '-revision_id' inside {{ }}. Done in #65

Completed

- Rewrote views post-update to use Batch API and added a test for views post-update.
- Patch #25 with views post-update, fix and test to assert the issue.
- Manual testing (DONE): Add Before/After screenshots.

Original report by bkosborne

This causes a couple issues:

1. There's an assertion in PluginBase::viewsTokenReplace() that checks if tokens are valid twig variables. So if the token replacement is performed for whatever reason, this assertion will fail and cause a 500 error.
2. I believe this would also prevent twig from performing the replacement correctly and/or using the proper field template for the field, but I can't be sure because I didn't test that behavior. The replacement token replaces the string 0 or 1, but not the actual value for the field.

I did a little big of digging and see that the token name for a given field is literally the "id" of the field, see FieldPluginBase::getFieldTokenPlaceholder(). Not sure on the solution here since I'm completely unfamiliar with this code.

Problem/Motivation

We have enabled CKEditor 5 on some of our websites and the CLS score of the websites dropped drastically.

Upon inspecting, CKEditor 4 set fixed width and height attributes of the images, reducing the content layout shift drastically.

Looking at CKE5, it seems most images don't get dimensions set at all, while some only get width set.

Proposed resolution

Make CKE5 also generate width and height HTML tags: https://github.com/ckeditor/ckeditor5/issues/5154.

Problem/Motivation

Follow-up to #3173031: Clean-up \Drupal\system\Plugin\ImageToolkit\GDToolkit when core require php 8.0

Since PHP version 8.0 the GD extension using classed object \GdImage instead of resource but toolkit methods has not a lot of usage and could improve DX for new-comers using nowadays state

Steps to reproduce

See #3156887: \Drupal\system\Plugin\ImageToolkit\GDToolkit needs to support \GdImage objects for PHP 8 compatibility
Usage in contrib http://grep.xnddx.ru/search?text=setResource%28&filename=

Proposed resolution

deprecate setResource() and getResource() in favour of

- public function setGdImage(\GdImage $gd_image): selfhttps://git.drupalcode.org/project/drupal/-/merge_requests/1486/diffs#no...
- public function getGdImage(): \GdImagehttps://git.drupalcode.org/project/drupal/-/merge_requests/1486/diffs#no...

Remaining tasks

agree/patch/commit

User interface changes

no

API changes

\Drupal\system\Plugin\ImageToolkit\GDToolkit::setResource() replaced with setGdImage()
\Drupal\system\Plugin\ImageToolkit\GDToolkit::getResource() replaced with getGdImage()

Data model changes

no

Release notes snippet

no

Problem/Motivation

As stated in the specification permitted parent elements for LI element are MENU, UL, OL but Drupal wraps action links with NAV element (except Claro theme).

Proposed resolution

Update the following templates by adding UL wrapper around content variable.

• core/modules/system/templates/block--local-actions-block.html.twig
• core/themes/starterkit_theme/templates/block/block--local-actions-block.html.twig
• core/themes/stable9/templates/block/block--local-actions-block.html.twig
• core/profiles/demo_umami/themes/umami/templates/classy/block/block--local-actions-block.html.twig

Remaining tasks

Create MR.

API changes

This can potentially break existing themes that do not override block--local.actions.block.html.twig template.

Steps to reproduce

1. create an entity type that includes AJAX calls on the node edit form, e.g. node with a link field and a media field, or a field with multiple elements and "add another" links
2. as a user without the 'link to any page' permission, try to create an instance of that entity
3. enter an invalid path in the link field, e.g. 'foo'
4. click on the button that initiates an AJAX request, e.g. file upload, add another

Expected result

An error message should appear about the invalid internal path, but you should be able to proceed with the action

Actual result

It isn't possible to proceed.
The AJAX call responds with a 500 error "The internal path component is invalid. Its path component must have a leading slash" with field widget type "Link".

↵An AJAX HTTP error occurred.↵HTTP Result Code: 500↵Debugging information follows.↵Path: /fr/node/6/edit?element_parents=field_test/widget/0&destination=/admin/content&ajax_form=1↵StatusText: 500 Service unavailable (with message)↵ResponseText: The website encountered an unexpected error. Please try again later.InvalidArgumentException: The internal path component 'test' is invalid. Its path component must have a leading slash, e.g. internal:/foo.

This error generates from \Drupal\Core\Url::fromInternalUri

It happens from \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
in code
$item->getUrl()->access() (core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php:175)

For avoidance of this error we have next element validator where check input values
\Drupal\link\Plugin\Field\FieldWidget\LinkWidget::validateUriElement

So we can't catch this error on common entity save operation.
But we can catch it with any additional ajax buttons, which skip validation with #limit_validation_errors

It appears on all browsers.

In my example "foo" value is incorrect for Link field. We can avoid this error by putting only correct values. But customer can be confused. He doesn't know what values are correct, and he doesn't know why all his AJAX buttons don't work. So we should avoid 500 error with ajax buttons.

I have investigated this issue and found, that we need to add additional check in \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
I have prepared patch and I will apply it in comment.

Problem/Motivation

Per the core idea issue: #2940739: Project messaging channel in core initiative

The vast majority of Drupal users do not have accounts on Drupal.org, and likely do not regularly follow Drupal project news, or engage with communications channels that promote important updates, news and events, or support for the community and association.

The goal of this initiative is to provide a channel for messaging about the Drupal project within the administrative interface of core. This channel could provide information about upcoming releases, new feature highlights, events like DrupalCon, and promote support of the project via Association membership or other programs.

Proposed resolution

Guidelines

We agreed to develop the feature using the following guidelines:

• Follow existing core patterns where possible
• Reuse existing visual display/layout from the settings tray
• Provide a notification icon in the primary toolbar
• Consume a feed from Drupal.org

For initial inclusion, the following potential features were not in scope:

• Configurable endpoints for multiple feeds.
• An API for extensibility by other contributed modules.

Prototype

Initial design concepts were provided here: https://www.figma.com/proto/Ws4Gk0ImaripDb4NAlTvCBtZ/Community-Alerts---...

This announcement feature has been developed as part of contrib: https://www.drupal.org/project/announce

Demo

This early demo shows an example of the announcement feed during the Contrib phase. It is not up to date with the latest changes from feedback in comments in this thread.

• Drupalpod instance with test feed enabled: https://gitpod.io/#snapshot/828d66df-5e7e-41bf-8a32-46e84e2a9f1f
• Screenshots (slides)

Original demo (outdated)

Remaining tasks

Steps to get this module into core

1. Merge into core and market it as an experimental module, according to typical process for new core features.
2. After a successful release as experimental, if no major changes are required, mark stable in following release.
3. Add it to the standard profile (and maybe others)
4. Figure out if and how to enable it on existing sites.

• Finalize the feed from Drupal.org (need to handle version constraints for messaging)
• #3249625: Document difference between featured and standard announcements
• #3249644: Clarify behavior of announcements, new, viewed, hiding, etc.
• #3249532: Display only the top 10 announcements by version (featured then recent) with a see more link
• #3071994: Document approval process for what appears in the official Drupal project messaging feed
• Complete tests: #3198730: Automated tests for Announce
• Standardize language to 'announcements' rather than 'alerts'
• Usability review
• Accessibility review
• Product manager review - Finalize policy for how the feed is to be used
• Framework manager review
• Release manager review - determine if we need to start as experimental, or can skip experimental since it is not a site-feature
• Make module experimental
• Re-roll patch for 9.5.x (currently doesn't apply)
• Roll patch for 10.0.x
• Reach out to release manager to figure out what needs to be done (and what core committer we can work with).

Follow-up

• Get core review and post the firstofficial post to the feed: https://docs.google.com/document/d/1d5Uq1ORQDy5bW_3WAyyorEVuHCtZBBB_aKMt...
• Follow-up: #3071997: Backport to D7
• Follow-up: Decide whether or not to backport to earlier D9 releases just to provide more exposure, get more adoption, since the point of this feature is communication with our ecosystem.

User interface changes

• Adds a notification icon to the admin toolbar
• Adds an announcement tray with a list of the announcements pulled from the feed

API changes

• This feature does not add any public APIs

Data model changes

• This feature uses cache tags in the user scope to handle read/unread status of announcements.

Security considerations

• The feed itself must be securely controlled from Drupal.org with a policy for who has access and editorial approval: #3071994: Document approval process for what appears in the official Drupal project messaging feed.

Release notes snippet

Drupal core now includes an announcements feed of project news from Drupal.org. This feed of announcements is displayed in the Drupal administrative toolbar to site owners/editors, tracking read/unread status with cache tags. Announcements may include: news about upcoming Drupal features, important information for site owners on older Drupal versions, and information about supporting the Drupal project through Drupal Association programs.

D7 Backport

This is an exceptional case where a backport to Drupal 7, even this late in Drupal 7's lifecycle, is likely worth our time. The large number of legacy sites on Drupal 7 are an audience we need to be able to reach, and this may be our only way to do so.

Contributors to D9 release

tedbow, Lal_, drumm, vimaljoseph, mohit_aghera, mitthukumawat, hestnet, Abhinand Gokhala K, AkshayAdhav

Testing

You will need to select which feed you want to test. You need to override the feed_url:

• Copy sites/example.settings.local.php to sites/default/settings.local.php
• Uncomment the last three lines of sites/default/settings.php to include the above file
• IMPORTANT: On drupalpod, go to the Ports tab (besides Terminal tab), then go to port 8080 and make it public. Copy the URL of your pod instance for the next step.
• Edit the sites/development.services.yml and add announcements_feed.feed_url: https://drupal.ddev.site/core/modules/announcements_feed/tests/announce_feed/community-feeds.json to the parameters section (replace drupal.ddev.site with the URL of your testing instance) - if you're on drupalpod it should be "repos/drupal/sites/development.services.yml". If you remove the above line, it will default to https://www.drupal.org/announcements.json
• ddev drush php:eval "\Drupal::service('user.data')->delete('announcements_feed');\Drupal::service('keyvalue.expirable')->get('announcements_feed')->deleteAll();drupal_flush_all_caches();"

Drupalpod instance with test feed enabled: https://gitpod.io/#snapshot/828d66df-5e7e-41bf-8a32-46e84e2a9f1f and then navigate to /admin/announcements_feed on the browser window.

To trigger the notifications as new run: ddev drush php:eval "\Drupal::service('user.data')->delete('announcements_feed');drupal_flush_all_caches();"

Within the new PostCSS for the off-canvas dialog, we neglected to include an ampersand (&) within a nested PostCSS block (see https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/misc/dialog...).

There are no differences in the visual styles because the values fall back from the correct CSS custom property to the the same value via inheritance. That being said, when someone extends the styles, the link colors may not match as expected.

Problem/Motivation

I was having a weird problem in a WebTestBase test that I am using to generate screenshots in Hungarian for the translation of the User Guide, and I traced it down to a weird bug that is either a problem in Drupal Core or localize.drupal.org, or some combination.

I was able to reproduce this bug on simplytest.me with the following steps:

a) Install Drupal Core 8.2.0-rc2 in English, with the Standard profile. Make sure that you check the "Check for updates" box, so that the Update Manager module is installed.

Note: In comment #17, this was retested in Drupal 8.6.x as of April 30, 2018, and it is still a bug.

b) Install the 4 multilingual modules from admin/modules.

c) Go to admin/config/regional/language and add Hungarian. Translations are imported from localize.drupal.org. Hungarian is 99% translated today in RC2 -- there are only 2 untranslated strings.

d) Set Hungarian as default language and delete English. (Note: this is interesting to try to do when you do not read Hungarian! Quite an adventure. Luckily, I am "slightly familiar" with the Drupal admin UI and URLs. :) ) At this point, you can verify that the Toolbar across the top of the screen is fully in Hungarian. In particular, the left-most link from the Manage menu (Content in English) says "Tartalom".

e) Go to admin/modules and install the core Activity Tracker module. Translations are imported. Note: I have no idea why translations would be imported at this time, since weren't they already imported for Core? But they are definitely being imported... I can see this in my test as well.

f) Go to admin/config/regional/translate and search for the word "Content". You will see that its translation has become "Content" (English) instead of "Tartalom". Content type is also screwed up, but some other words are still translated... Screenshot:

In my tests, after this point the Toolbar in screenshots is sprinkled with English words amongst the Hungarian. The words "Help" and "People" and "Content" are in English, while the rest is still in Hungarian. But the root cause appears to be that some translations are being overwritten.

I have no idea what the root cause of this happening is... and I think I have a way to work around it for my screenshots (on admin/config/regional/translate/settings I should be able to set it so imports do not overwrite existing translations. Hopefully.) Also note that in my tests I have verified just before installing this module that the word Content is translated to Tartalom and just after it is Content, so I am quite sure it is the translation import from this module install that is causing the problem.

Proposed resolution

1. Figure out why:

a) Translations are being imported when installing a Core module even though Core translations have already been imported when I added the language.

b) When they are imported, they are overwriting some words with English instead of Hungarian.

2. Fix the problem(s).

Remaining tasks

Make a patch with a test.

User interface changes

UI translations will not be overwritten when installing a Core module.

API changes

Probably not.

Data model changes

Probably not.

Problem/Motivation

Drupal\Core\Ajax\AjaxResponseAttachmentsProcessor does not validate its POST parameters. Because of this, it's possible to easily generate a lot of warnings/errors. This code can be executed on all public routes by adding the right query/POST parameters, which allows anyone to flood the logs of a Drupal website.

Steps to reproduce

Do an HTTP call to any path,. In this example, libraries is an array instead of a string, which is the expected type:

POST /?_wrapper_format=drupal_ajax&ajax_form=1
Content-Type: application/x-www-form-urlencoded

ajax_page_state[libraries][0]=test

In this example, the library definition is invalid which triggers an error in Drupal\Core\Asset\LibraryDependencyResolver:

POST /?_wrapper_format=drupal_ajax&ajax_form=1
Content-Type: application/x-www-form-urlencoded

ajax_page_state[libraries]=test

Proposed resolution

Add some basic validation to ensure libraries are in the right format and parameters are of the right type.

Hi, I have a very simple custom form to send an email with some information. I want to show this form within a node, in a twig.

In theme_preprocess_node I create the variable with the form:
$form = \Drupal::formBuilder()->getForm('Drupal\my_module\Form\my_ajax_form');
$variables['my_ajax_form'] = $form;

When I test the form in the page I created in my_module.routing everything works ok but when I submit the form from the node, ajax callback is not called and the submit sends me to a page not found.

  public function buildForm(array $form, FormStateInterface $form_state, Request $request = NULL) {

        $form['intro'] = array(
            '#type'     => 'markup',
            '#markup'   => t('Si nos dejas tu mail te enviaremos la información de la sede a tu correo'),
            '#title'    => NULL,
        );
        $form['email'] = array(
            '#type'         => 'email',
            '#placeholder'  => t('Escribe aquí tu e-mail'),
            '#title'        => NULL,
            '#required'     => TRUE,
            '#prefix'       => '<div id="user-email-result"></div>'
        );        
        $form['message'] = [
          '#type' => 'markup',
          '#markup' => '<div class="result_message"></div>'
        ];
        $form['actions'] = [
          '#type' => 'button',
          '#value' => $this->t('Submit'),
          '#ajax' => [
            'callback' => '::setMessage',
            'type' => 'throbber',
          ],
        ];
  }
  public function setMessage(array $form, FormStateInterface $form_state) {

    $response = new AjaxResponse();
    $response->addCommand(
      new HtmlCommand(
        '.result_message',
        '<div class="my_top_message">'.$mensaje.'</div>'),
    );
    return $response;

   }
   
    /**
      * {@inheritdoc}
    */
    public function validateForm(array &$form, FormStateInterface $form_state) {
      
    }
    /**
     * {@inheritdoc}
     */
    public function submitForm(array &$form, FormStateInterface $form_state) {
   
    }

It's driving me crazy. Any help?