When a user performs a revert of a node, there is no record of that action in the revision table, or in the UI (although there is a watchdog message logged that contains the current user). For a production site though, its very possible that watchdog is turned off, making it very difficult to see who actually reverted a revision.

Consider the following:

• User A creates a node (initial revision)
• User B updates the node, saves and creates an additional revision
• User C reverts to initial revision

As far as I can see, there is no reference to User C performing the revert, resulting in a sort of 'data loss'.

I believe the user performing the revert should be marked as the revision author. We still have a reference to the original revision, which contains the original revision author (User A above in this example).

Problem/Motivation

The non-hyperlink pager items in the Seven theme do not meet WCAG AA section 1.4.3 requirements for text contrast.

To reproduce,
1. Login to drupal 8
2. Navigate to /admin/content
3. Make sure you have ~500 content items so you see the ellipsis
3. Run DAP Chrome plugin or other WCAG compliance checker on page
4. See a message similar to the following.

"Minimum contrast of 3.36 with its background is not sufficient to meet WCAG AA requirements for text of size 13.0486px and weight of 700."

See attached screenshots (pager ellipsis>, pager items) for details.

Proposed resolution

Review current colors and backgrounds for pager items that are not hyperlinks and determine a suitable change that is in line with the Seven theme styles that also passes WCAG AA.

Before

Before screenshot from #17:

After

After screenshot from #17:

Remaining tasks

User interface changes

Update Seven pager item styles to increase contrast for pager items.

API changes

None

Data model changes

None

So I've got a textfield with #autocomplete_route_name and #ajax set.

    $form['dept_filter'] = array(
      '#type' => 'textfield',
      '#title' => t('Department Name'),
      '#autocomplete_route_name' => 'mymod.dept_filter_autocomplete',
      '#description' => t('Department Filter'),
      '#default_value' => $_SESSION['dept_filter'],
      '#ajax' => array(
        'callback' => 'Drupal\mymod\Controller\DeptDashController::deptFilterSelect',
        'event' => 'blur',
      ),
    );

If I set #ajax['event'] to 'blur', I can get it to call my DeptDashController::deptFilterSelect callback on blur, but I actually want that to fire when something is selected in the autocomplete.

I think because '#autocomplete_route_name' is set, it's overriding the 'change' event.

So is there another event I can use to fire my callback when an option is selected from the autocomplete?

I've scanned through both documentation and code, and haven't yet come up with anything that works the way I want yet. I may have actually discovered some bugs!

Events I've tried, with result:
'change': Fires if I change the text and tab away, but NOT after I select an autocomplete option, even after tabbing away.
'blur': Default functionality - fires callback on blur, then returns cursor to textbox, so anything I click on will blur and fire the callback again.
'select': Fires callback in an infinite loop as soon as I type anything into the box.

Any help would be appreciated!

Problem/Motivation

Tested a large Drupal 8 project on 8.5.0-alpha1 today and started getting test fails for views that had rest exports powered by CSV serialization
The views have URLs like /some/path/to/download/content.csv
They work if I change the URLs to /some/path/to/download/content.csv?_format=csv

Proposed resolution

Is this an issue in CSV serialization or a regression in core?

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

The EntityViewBuilder::getBuildDefaults has an $entity parameter that should respect the EntityInterface.

Yet in the getBuildDefaults() method there's a call on the $entity object to a method that's not on the EntityInterface:

$entity->isDefaultRevision();

isDefaultRevision() lives on the ContentEntityBase but EntityViewBuilder might be used by a ConfigEntityBase.

This may result in an error Error: Call to undefined method Drupal\my_module\Entity\MyConfigEntity::isDefaultRevision() in EntityViewBuilder.php on line 181

Proposed resolution

We should check if the entity is an instance of RevisionableInterface first:

$entity instanceof RevisionableInterface

Hi,

Upgrading to 8.5 a website using content moderation, i got that error

Définitions des entités/champs
La définition des entités et/ou des champs ne correspondent pas
Les changements suivants ont été détectés dans le type d'entité et les définitions des champs.
État de modération du contenu
Le champ Identifiant (ID) du type d'entité de contenu nécessite d'être mis à jour.

a drush entities update gives:

/||0||Drupal\Core\Entity\Exception\FieldStorageDefinitionUpdateForbiddenException: The SQL storage cannot change the schema for an existing field (content_entity_type_id in content_moderation_state entity) with data. in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->updateSharedTableSchema() (line 1597 of /data-platforms/platforms/drupal8-dev/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php).

How could i solve that?

I currently serve as the Home Owners Association Web Site Manager. My knowledge of Drupal is slightly above the novice level so please bear with me. The site is currently operating Drupal 7

We currently are using the Creative Responsive Theme and have the Nivo Slider block loaded in the Slideshow region to display a slide show of our community.
I recently installed the Marquee Block with the intent of creating a scrolling text box across the top of the screen to notify residents of upcoming events/postings.

My problem is this, when I place the Marquee Block in the Slideshow region it will scroll as desired, but the Nivo Slider block disappears and will NOT display the slides. I have tried placing the Marquee Block in other regions with the same result. Removing the Marquee block automatically restores the Nivo Slides.

Any Help/ suggestions would be greatly appreciated.

When using a the "Content: ID" contextual views filter (for example to filter nodes that reference the current node), you can use the argument to override the title. Here the original language label is returned instead of the translation from the context.

Similar to https://www.drupal.org/project/drupal/issues/2765297

Steps to reproduce:

• Enable content_translation module
• Add any language
• Enable content translation for nodes
• Create a node and translate it
• Create a view that uses the "Contextual filter""Content: ID"
• Ensure that "Replace title" is checked, and {{ arguments.nid }} is used as the title replacement
• Look at the view on a non-English page with the id of a translated node as context
• The English title will be shown instead of the translation - this is the bug.

After upgrading to 8.5 suddenly the Performance tab is showed twice.
see screenshot.

Nielsvoo

Problem/Motivation

At the moment when $settings['skip_permissions_hardening'] = TRUE, the system module's system_requirements unconditionally issues a warning about the site's config files' permissions without actually checking them:

      if (file_exists($full_path) && (Settings::get('skip_permissions_hardening') || !drupal_verify_install_file($full_path, FILE_EXIST | FILE_READABLE | FILE_NOT_WRITABLE))) {
        $conf_errors[] = t("The file %file is not protected from modifications and poses a security risk. You must change the file's permissions to be non-writable.", ['%file' => $full_path]);
      }

This is quite confusing and misleading (see related issues).

Proposed resolution

Drupal should either skip the checks without issuing a warning, or perform the checks but only issue any valid warnings (as opposed to errors).

The logic is already there to switch to warnings instead of errors based on skip_permissions_hardening:

    // Allow system administrators to disable permissions hardening for the site
    // directory. This allows additional files in the site directory to be
    // updated when they are managed in a version control system.
    if (Settings::get('skip_permissions_hardening')) {
      $conf_errors[] = t('Protection disabled');
      // If permissions hardening is disabled, then only show a warning for a
      // writable file, as a reminder, rather than an error.
      $file_protection_severity = REQUIREMENT_WARNING;
    }
    else {
      // In normal operation, writable files or directories are an error.
      $file_protection_severity = REQUIREMENT_ERROR;

Remaining tasks

* Decide whether to skip checks, or perform them and issue only valid warnings.
* Patch the existing code accordingly.
* Update tests as appropriate.

User interface changes

* Removal of invalid warnings when config file permissions are not actually incorrect.

API changes

* None.

Data model changes

* None.

I am trying to update drupal core from 8.2.8 to 8.3.1 alongwith lightning from 2.0.1 to 2.1.0. I've created the sub profile for lightning and executed all the manual steps mentioned here - https://github.com/acquia/lightning/blob/2.1.0/UPDATE.md. When running travis, I'm getting the below error

Error: Call to a member function getColumns() on boolean in /docroot/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php, line 228

After a bit of debugging I found that the error is coming from the below line and the reason for the error is that $field_storage is setting to FALSE here

$columns = $field_storage->getColumns();

System information before update:

• Drupal Version: 8.2.8
• Lightning Version: 2.0.1

System information after updating:

• Drupal Version: 8.3.1
• Lightning Version: 2.1.0

Problem/Motivation

This issue is similar to #2883813: Move File/Image media type into Standard once Media is stable.

Having configuration in the module folder is always problematic for distributions. Distributions normally ship their config in different sub-modules. Overwriting module configurations like the workflow is only possible from the profile config directory. But that doesn't work, if the overridden config is now depending on a sub-module.

Proposed resolution

So please move the config into the standard profile to make it easier for install profiles to ship their own configuration.

I recently upgraded our Drupal install from 8.3.7 => 8.4.5. A major issue I am having is that any Twig templates with an attach_library call throws the below error:

LogicException: Render context is empty, because render() was called outside of a renderRoot() or renderPlain() call. Use renderPlain()/renderRoot() or #lazy_builder/#pre_render instead. in /vagrant/drupal-8.4.5/core/lib/Drupal/Core/Render/Renderer.php:241 [error]
Stack trace:
#0 /vagrant/drupal-8.4.5/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false)
#1 /vagrant/drupal-8.4.5/core/lib/Drupal/Core/Template/TwigExtension.php(380): Drupal\Core\Render\Renderer->render(Array)
#2 /vagrant/drupal-8.4.5/sites/default/files/php/twig/5a9f160ada026_file-link.html.twig__xP4ZKUjMG1Br_4AamdWV9Fbb/MO6fCVev6wq08Go5uaIPMEZ5_r-uQk-YHGauA3DKccg.php(43): Drupal\Core\Template\TwigExtension->attachLibrary('classy/file')

This error is produced when running 'drush -d twigc'. The biggest issue with this is that this stops once it gets to this error. So when I make a change to a template and clear cache, that twig template renders empty on the page and I can never get it back again since the twig templates cannot be recompiled successfully. I have tested this with Drush 8 and Drush 9. Of course the 'twigc' command is only in Drush 9, I can still replicate this issue using Drush 8 when rebuilding cache. This errors is being thrown in core template files as well, not just installed modules or any custom stuff.

In Quick Edit module, we have this nice drag/drop file upload capability, but it currently only works for File fields. We need to expand it to also work with Media fields, particularly if we want to eventually push Media fields as the primary way of content authors getting images, etc. into Drupal.

Problem/Motivation

hooks--
events++

SourcePluginBase::prepareRow() exists to provide an application-level opportunity to manipulate a source row, and potentially decide based on its contents to ignore it entirely, before entering the processing pipeline. This has been incubating in Migrate Plus for 3+ years. With us moving things from migrate contrib into Drush core, it is more important to have an event to handle this processing.

Proposed resolution

SourcePluginBase::prepareRow() should dispatch a PREPARE_ROW event instead of invoking hooks.

const PREPARE_ROW = 'migrate.prepare_row';

Remaining tasks

SourcePluginBase::prepareRow() should call PREPARE_ROW in addition to the hook.
If possible, trigger an error/warning when the older hook is utilized.

User interface changes

N/A

API changes

hook_migrate_prepare_row and hook_migrate_MIGRATION_ID_prepare_row deprecated.
const PREPARE_ROW = 'migrate.prepare_row'; added

Problem/Motivation

Split from #2488836: Refactor prepareRow() to add events in addition to hook.

Migrate Plus module is dispatching this event and this is critical to migrate runner because it allows the Drush option --idlist. But as the migrate runner goes to Drush core, and the two should run independently but also together, it's better to have the event dispatching in Drupal core.

There are also the reasons from #2488836: Refactor prepareRow() to add events in addition to hook.

Proposed resolution

Add the event constant, the event class & dispatch the PREPARE_ROW event.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

Running php core/rebuild.php from the Drupal root directory currently fails with:

Fatal error: Uncaught Symfony\Component\DependencyInjection\Exception\InvalidArgumentException: The service file "core/core.services.yml" is not valid.

this is because the first line of the script changes directory:

// Change the directory to the Drupal root.
chdir('..');

assuming the script is being run from the core directory.

Proposed resolution

Add the __DIR__ magic constant to the chdir() call.

Remaining tasks

User interface changes

API changes

Data model changes

I have tested that code:

process:
    uri:
      plugin: file_copy
      reuse: true
      source:
        - source_file_path_remote
        - destination_file_path

In the transform method of file_copy process plugin the download process plugin is called when a source file is remote. So the file is downloaded ignoring the reuse option.

Problem/Motivation

It is pretty common to want to use a token for a URL when editing text. For instance, you might want something like:

<a href="[my:token:here]">link text here</a>

However, if you try to do this in a body field that is using CKEditor, if you enter a token like that in the field, and then later edit the content that contains that field and save, the token is corrupted.

Steps to reproduce:
a) In a content item with a field that uses CKEditor for editing, and allows the A tag, type the link text in the editor.
b) Highlight to select the link text.
c) Click the Link button (chains) in the editor toolbar, and enter [my:token:here] as the URL in the popup.
d) Click Save in the popup. Verify that the HTML source looks like the above.
e) Save the content item you are editing.
f) Test -- the link works fine (assuming you are running a token replace so it gets replaced by the right URL).
g) Edit the content item again.
h) When you get back to the editor, look at the HTML source. Instead of seeing what was there before, you will see something like this:

<a href="en:here]">link text here</a>

So that's the bug: if you re-edit some HTML text using CKEditor and there is an A tag with a token in the URL, CKEditor truncates and mangles the token, leading to data loss. According to Priority Levels of Issues, this means it is a Critical bug (or at least Major?) because it leads to data loss.

Note: We are specifically seeing this in the proposed Help Topics module (see related issue #2943974: Route tokens in Help text format get truncated after editing a help topic).

Proposed resolution

Fix CKEditor so that it doesn't mangle tokens in URLs in A tags.

It might be a good idea to see if tokens are mangled elsewhere in HTML as well, such as in attributes for other HTML tags?

Remaining tasks

Fix the bug.

User interface changes

CKEditor will not mangle HTML containing tokens for URLs in A tags.

API changes

None.

Data model changes

None.

Follow up to #2849827: Move workflow "settings" setters and getters to WorkflowTypeInterface.

Problem/Motivation

Currently we have typical entity access for workflows, with the addition of "delete-state:foo". This is useful because for content_moderation, we don't want users to be able to delete states which are required for integrity.

After #2849827: Move workflow "settings" setters and getters to WorkflowTypeInterface, we delegated the responsibility of all state/transition storage to the workflow type plugins, essentially freeing types to be able to introduces states and transitions which weren't necessarily based on configuration within the workflow entity. Now states and transitions can be based on any 3rd party configuration or even predefined (days of the week? drupal user roles? commerce checkout panes? etc.).

Based on this, is there more scope to expand the workflow entity access system to encompass "edit-state:foo", "edit-transition:foo" and "delete-transition:foo". If I'm providing a workflow type with states based on something external to the workflows entity, restricting "edit" to states will likely make a lot of sense. To see this in action:

1. "drush en workflow_type_test -y"
2. Create a workflow of type "Predefined States Workflow Test Type"
3. See "edit" buttons which doesn't make sense, based on the states being totally pre-determined.

Proposed resolution

Expand the access controls.

Remaining tasks

Patch.

User interface changes

API changes

Data model changes