Problem/Motivation

When creating a workflow view for a user to find content that they are able to moderate, it would be nice to be able to filter for a given state (eg, Published) that a user can moderate content to.

For instance, if the user has access to 10 nodes, but 3 of them are in a state from which they don't have permission to move to Published, those could be filtered out
via this new filter.

Proposed resolution

Add a Views filter that takes into account the current user's access to transitions to one or more states.

The UI would present a list of to states (Published, Draft, etc).

The filter would then loop through transitions to those states and filter only content in the available transition's from state.

Remaining tasks

User interface changes

API changes

Data model changes

Currently when embedding media in CKEditor with the Align images filter enabled, the default value for data-align is center. This is too opinionated from a design standpoint, especially when center would be one of the least common choices when embedding media in a text area.

It would make more sense to leave the value empty and let the content creator opt in to media alignment, rather than having to take the extra step to undo the center align value.

After adding support for external stylesheets the next step is to add support for Drupal root paths, in the same way that Library definitions can have a Drupal root url for CSS/JS assets.

Stylesheets that aren't external and use a '/' as the first character can be safely assumed to be Drupal root relative (this what LibraryDiscoveryParser does).

So the supported set of stylesheets paths would look like this:

ckeditor_stylesheets
  - //www.external.com/stylesheet.css
  - /libraries/your-library/stylesheet.css
  - css/stylesheet.css

The use case for this is to include CSS assets from outside the theme directory (i.e. the libraries directory).

For the Drupal 7 version of this issue, see #2010898: Use tokens for entity selection view arguments.

Entity Reference allows using a View of a specific display type to set the available options. This is good.

It's also possible to set arguments (contextual filters) on that view from the ER field config screen. This is also good.

Those arguments must be completely static. This is not good.

Rather, it should be possible to have dynamic, context-aware arguments. The most obvious is "the node that this is on", allowing the view to filter based on the node itself. Ideally, other "relational" contexts (Panels-style, or maybe just via token if that's easier) should be possible, such as "the author of the node this is on", "the OG of the node this is in" (my actual use case), etc.

That would greatly expand the potential flexibility of that view to do all sorts of context-aware select lists.

Of course, there's the obvious problem of what to do when creating a node (or user, or whatever other entity) the first time, since there is no "this" yet to refer to. I see two possible ways to address that:

1) Allow for a default value, or a different context to pull from if null. Eg, if there's no node owner, default to the current user. This would be configurable.

2) Punt that question to the View, where there is already fairly sane default argument capability. As long as we are able to do relational arguments, so that the contextual filter on the View doesn't have to be the entity type that it is on, that's probably sufficient and easier to implement anyway.

In my specific use case, I want to have an ER from a node to other nodes of type Foo that are in the same OG as the node being edited; if the node is being added, default to the user's OGs. The same concept would apply in many other situations, of course, such as related posts by the same author, etc.

(The current alternative involves writing a completely new custom views default argument plugin for every use case, which is highly sub-optimal.)

Thinking about it, I believe tokens would likely be the most straightforward way to specify such values.

So:
1) Is this feature something that would be accepted?

2) I MAY be able to get some time to work on this for the client project that requires it, if I knew it would be accepted so that we're not working with a project fork. :-) Is this doable? (If not, we'd have to fall back to the one-off above.)

Problem/Motivation

The file core/lib/Drupal/Core/Entity/Plugin/Derivative/DefaultSelectionDeriver.php defines the class Drupal\Core\Entity\Plugin\Derivative\DefaultSelectionDeriver, but the documentation block for the constructor mentions a different class name:

  /**
   * Creates an SelectionBase object.
   *
   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
   *   The entity type manager.
   */
  public function __construct(EntityTypeManagerInterface $entity_type_manager) {

This mismatch is probably left over from the changes described in this change record.

This documentation block generates the API documentation for DefaultSelectionDeriver::__construct(), so I am adding the "API Documentation" issue tag.

Proposed resolution

I am not sure whether "SelectionBase" should be replaced by "DefaultSelectionDeriver" (the name of the deriver class) or "DefaultSelection" (the name of the base class). The conventional code comment for A::__construct() is "Creates a(n) A object", but maybe the convention is different for deriver classes. Look for other examples in Drupal core.

There is another code comment, later in the same file, that refers to "SelectionBase", and that one should be replaced with "DefaultSelection".

Remaining tasks

User interface changes

None, except for fixing the API documentation.

API changes

None

Data model changes

None

Problem/Motivation

In core/modules/block_content/block_content.module, the documentation block for block_content_query_entity_reference_alter() includes the line,

Block_content entities that are reusable should by default not be selectable

It should be "not reusable" rather than "reusable". Compare with the change record Added the ability to set Custom Block entities as non-reusable: it says, in part,

Since a Custom Block with the reusable field set to FALSE should not be reused in other parts of the site the queries of EntityReferenceSelection plugins will now automatically be altered to add:

$query->condition("$data_table.reusable", TRUE);

Unless the query satisfies one of these two conditions:
...

The API documentation for block_content_query_entity_reference_alter() is generated from this documentation block, so I am adding the "API Documentation" tag.

Proposed resolution

Insert the word "not" and rewrap the affected line and the next to 80 characters.

Remaining tasks

User interface changes

None, except in the API documentation.

API changes

None

Data model changes

None

Problem/Motivation

I have observed an InvalidQueryException being caused by what I believe is a bot probing for vulnerability to SA-CORE-2018-002. This occurs when UserPasswordForm::validateForm()is invoked but the 'name' value is not set.

Steps to Reproduce

[TODO]

Drupal\Core\Database\InvalidQueryException: Query condition 'users_field_data.mail IN ()' cannot be empty. in Drupal\Core\Database\Query\Condition->condition() (line 103 of core/lib/Drupal/Core/Database/Query/Condition.php).

Proposed resolution

Would it be appropriate to be more defensive and not assume that $form_state->getValue('name') returns a result in UserPasswordForm::validateForm()?

If a query parameter name is urlencoded (as it should), drupal_get_query_array() does not urldecode it.

This bug was long time partly compensated by drupal_http_build_query() not urlencoding query parameter square brackets, which was fixed in #2289867: [D7] W3C HTML5 Validation error with PHP array-based query-strings built with url() containing [ ] characters.

Said fix now leads to a regressions when modules rely on drupal_get_query_array(drupal_http_build_query($x)) === $x. Most notably views, see #2909709: Links to entity URIs with special characters in query parameter names are broken, especially since Drupal core 7.55 and the code snippet there. Prio major as this breaks existing sites, especially when they work with faceted search urls which contain query parameter names like "f[0]".

Problem/Motivation

Before a user uploads an image, if there is a maximum dimension set, the help text reads, for example:
"Images must be smaller than 100x100 pixels." This confuses the user since the image can be automatically resized to accommodate these limits. We therefore replace it with, "Images larger than 100x100 pixels will be resized."

Before the patch

Proposed resolution

Alter the text to be more accurate.

Also, see issues #16 through #33 suggesting that checking for the presence of an image toolkit should not be necessary, as a D8 installation without a toolkit is an edge case, and therefore a condition that is practically impossible to trigger.

After the patch in #31

Remaining tasks

Backport it to D7. Note that D7 version should have consideration for !ImageToolkit::isAvailable() (or functional D7 equivalent)

User interface changes

Changes user interface text to read: "Images larger than !max pixels will be resized".

Similar changes to the case where both a minimum and maximum resolution are specified.

The message about *minimum* dimensions (only) is not changed.

API changes

String is used in file file.field.inc line 931.
if/else block says:

- if there's a toolkit, resize the image
- else, just reject it for being too large.

Related Issues

See #847098: Revise image field settings form for clearer ui and usability.

Original report by fietserwin

Should read something like "Images larger than !max pixels will be resized". For the exact choice of text perhaps have a look at #311159: Inaccurate/misleading user text. String is used in file file.field.inc line 931.

This issue is a duplicate of https://www.drupal.org/project/drupal/issues/628094 since that one was closed, marked fixed, but the problem persists.

In file_save() we call the function filesize() on $file->uri assuming that $file->uri is a local file and not a remote one, but that's not a safe assumption to make.

In recent versions of PHP calling filesize() on remote files throws a PHP warning.

I'm providing a patch here from @micnap in the other issue, but @aaron should get credit for this too.

After updading a Drupal site from 8.6.16 to 8.7.1 (PostgreSQL 9.6.13 , Nginx) I get this error in almost every operation (creating a view , installing a module, importing feeds, ....) with diferent plugins

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "{whatever}" plugin does not exist.
Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan,[...]
in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 de /"
"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I use the drupal-project composer template so my update process was:

composer update --with-dependencies webflo/drupal-core-require-dev drupal/* "symfony/*" -d /<path/to/site> --no-interaction ;
cd /<path/to/site>
drush updb
drush cron
drush cr

It was not successfull, so I do this:

rm -rf vendor/*
composer update

and run again previous commands which It worked.

I though that I could be a problem with PHP version so I update from PHP 7.0 to PHP 7.3, but the error still remains.
I also thought that it could be related with a feeds module installation so delete all feeds content, feeds types, etc .. and unistall and reinstall the module several times (also run drush devel-entity-updates because drupal status report warned of a feeds field that needed to be deleted)

After see that the problem was related with multiples plugins I start looking for a more generic issue (config?, permissions?, ...) but I don't find cause/solution.

EDIT 1

Looking for a stack trace I try using drupal console:

drupal site:mode dev -v

and get this:

In DiscoveryTrait.php line 53:

  [Drupal\Component\Plugin\Exception\PluginNotFoundException]                                                                                                                                               
  The "system.performance" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, language_reference, language, map  
  , binary, timestamp, list, datetime_iso8601, uri, integer, duration_iso8601, email, field_item:comment, field_item:datetime, field_item:daterange, field_item:file_uri, field_item:file, field_item:font  
  awesome_icon, field_item:image, field_item:link, field_item:list_integer, field_item:list_float, field_item:list_string, field_item:path, field_item:telephone, field_item:text, field_item:text_long, f  
  ield_item:text_with_summary, field_item:time_range, field_item:time, field_item:webform, field_item:email, field_item:uri, field_item:entity_reference, field_item:uuid, field_item:timestamp, field_ite  
  m:string_long, field_item:language, field_item:password, field_item:changed, field_item:float, field_item:decimal, field_item:map, field_item:boolean, field_item:integer, field_item:created, field_ite  
  m:string, entity, entity:block, entity:block_content_type, entity:block_content, entity:block_content:basic, entity:captcha_point, entity:comment, entity:comment:comment_forum, entity:comment_type, en  
  tity:contact_form, entity:contact_message, entity:contact_message:feedback, entity:contact_message:personal, entity:editor, entity:field_config, entity:field_storage_config, entity:file, entity:filter  
  _format, entity:image_style, entity:imce_profile, entity:language_content_settings, entity:configurable_language, entity:media_type, entity:media, entity:media:audio, entity:media:file, entity:media:i  
  mage, entity:media:remote_video, entity:media:video, entity:node_type, entity:node,[...], entity:node:page, entity:node:position, entity:rdf_mapping, entity:responsive_image_style, entity:rest_resource_config, entity:rules_reaction_rule, entity:rules_component, entity:s  
  earch_page, entity:shortcut_set, entity:shortcut, entity:shortcut:default, entity:action, entity:menu, entity:taxonomy_vocabulary, entity:taxonomy_term, entity:taxonomy_term:badge_type, entity:taxonom  
  y_term:categories, entity:taxonomy_term:forums, entity:taxonomy_term:materials, entity:taxonomy_term:nivel, entity:taxonomy_term:tags, entity:toolbar_menu_element, entity:tour, entity:user, entity:use  
  r_role, entity:webform_options, entity:webform, entity:webform_submission, [..], entity:menu_link_content, entity:pathauto_pattern, entity  
  :view, entity:base_field_override, entity:entity_view_mode, entity:entity_view_display, entity:entity_form_mode, entity:entity_form_display, entity:date_format, entity_reference

Exception trace:
 () at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53
 Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php:25
 Drupal\Core\Plugin\DefaultPluginManager->getDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/DataDefinition.php:195
 Drupal\Core\TypedData\DataDefinition->getClass() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:86
 Drupal\Core\TypedData\TypedDataManager->createInstance() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:103
 Drupal\Core\TypedData\TypedDataManager->create() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/TypedConfigManager.php:394
 Drupal\Core\Config\TypedConfigManager->createFromNameAndData() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:134
 Drupal\Core\Config\StorableConfigBase->getSchemaWrapper() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:179
 Drupal\Core\Config\StorableConfigBase->castValue() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/Config.php:212
 Drupal\Core\Config\Config->save() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:150
 Drupal\Console\Command\Site\ModeCommand->overrideConfigurations() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:87
 Drupal\Console\Command\Site\ModeCommand->execute() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:987
 Symfony\Component\Console\Application->doRunCommand() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:255
 Symfony\Component\Console\Application->doRun() at /home/"<user>"/www/"<site>"/vendor/drupal/console-core/src/Application.php:184

EDIT 2

looking at the database I found two tables from feeds module (supposed to be uninstalled)

feeds_feed feeds_subscription

running drupal console commnand drupal debug:module feeds appears as the only module uninstalled with a schema version defined

ID     Name   Package  version      schema version  status      origin
...
feeds  Feeds  Feeds  8.x-3.0-alpha5    8001         Uninstalled no core
...

EDIT 3

After enable debugging (https://drupal.stackexchange.com/questions/127182/how-do-i-enable-develo...)

I got new clues about the error ( trying to create a view) but my lack of drupal core knowledge stops me from understanding where final cause is:

</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;views.view.*&quot; plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, [...], entity:entity_form_display, entity:date_format, entity_reference in <em class="placeholder">Drupal\Core\Plugin\DefaultPluginManager-&gt;doGetDefinition()</em> (line <em class="placeholder">53</em> of <em class="placeholder">core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php</em>). <pre class="backtrace">Drupal\Core\Plugin\DefaultPluginManager-&gt;getDefinition(&#039;views.view.*&#039;) (Line: 195)
Drupal\Core\TypedData\DataDefinition-&gt;getClass() (Line: 86)
Drupal\Core\TypedData\TypedDataManager-&gt;createInstance(&#039;views.view.*&#039;, Array) (Line: 103)
Drupal\Core\TypedData\TypedDataManager-&gt;create(Object, Array) (Line: 394)
Drupal\Core\Config\TypedConfigManager-&gt;createFromNameAndData(&#039;views.view.test2&#039;, Array) (Line: 134)
Drupal\Core\Config\StorableConfigBase-&gt;getSchemaWrapper() (Line: 179)
Drupal\Core\Config\StorableConfigBase-&gt;castValue(&#039;uuid&#039;, &#039;c2f6326b-a77f-4f1e-9698-cb96154252cb&#039;) (Line: 212)
Drupal\Core\Config\Config-&gt;save() (Line: 284)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;doSave(&#039;test2&#039;, Object) (Line: 449)
Drupal\Core\Entity\EntityStorageBase-&gt;save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase-&gt;save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;save() (Line: 993)
Drupal\views_ui\ViewUI-&gt;save() (Line: 191)
Drupal\views_ui\ViewAddForm-&gt;submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter-&gt;executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter-&gt;doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;view_add_form&#039;, Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder-&gt;buildForm(Object, Object) (Line: 93)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

Currently it is still set to "Drupal8".

Getting following issue after PHP upgradation to 7.2 in phpcs

"FILE: docroot/includes/form.inc
------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
------------------------------------------------------------------------------------------------------------------------------------------------------
725 | WARNING | Since PHP 7.0, functions inspecting arguments, like func_get_args(), no longer report the original value as passed to a parameter,
| | but will instead provide the current value. The parameter ""$form_state"" was used, and possibly changed (by reference), on line 724.
------------------------------------------------------------------------------------------------------------------------------------------------------"

Problem/Motivation

Sometimes it's difficult to trigger a section via CSS, particularly if there are layouts per page/node.

Proposed Solution

Provide a text field in block and section configuration form, to delare css classes (e.g. a comma separated enumeration).

Maybe here views configuaration can be a role model or block class module

When create filter then Views add field name to the Label, such as:
- HP Mobile (field_hp_mobile)

Please don't add the Field Name.

views blocks that were set to hide via "Hide block if the view output is empty: Yes" still renders the general structure of the view output. The view in question has a contextual filter "content: id" that is set to "Provide default value" -> content id from url. Fields are set to be hidden if empty. The rendered block doesn't show any output but creates the structure down to the views-row class.

How can blocks be completely hidden if there is no output? Seems like the "Hide block if the view output is empty: Yes" is without function at the moment, or?

Problem/Motivation

Update drupal/coder to the latest version.

• Includes PHP 7.4 support
• Bugfixes
• #2958175: Add rule to prevent direct usage of $_GET, $_POST, $_REQUEST and $_FILES in Drupal 8

Proposed resolution

Fix failing coding standards. Note DateTimePlus contains some non-standard documentation that doesn't work. See $settings documentation on https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Date...

    * @param array $settings
    *   @see __construct()

The @see does not work at all - and doesn't work in PHPStorm either. Fortunately there are other methods that already have

   * @param array $settings
   *   (optional) A keyed array for settings, suitable for passing on to
   *   __construct().

so we can copy that.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3083850: Darker blue color for :hover & :active broke the hover and the active styles of the default link buttons.

To reproduce:

1. Visit /admin/structure/block with Claro theme set as admin theme.
2. Hover (or long-click) any of the Place block buttons next to the region name.

Proposed resolution

Don't change the text color of link buttons.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

EntityViewsData generates incorrect data for entities that have fields which have numeric schema columns.

Instead of the numeric argument and filter, the standard ones are used.

This breaks at least exposed filters, I haven't tested anything more specific.

Proposed resolution

EntityViewsData contains the following (starting at line 395):

        switch ($column_type) {

          case 'int':
          case 'integer':
          case 'smallint':
          case 'tinyint':
          case 'mediumint':
          case 'float':
          case 'double':
          case 'decimal':
            $views_field['field']['id'] = 'field';
            $views_field['argument']['id'] = 'numeric';
            $views_field['filter']['id'] = 'numeric';
            $views_field['sort']['id'] = 'standard';
            break;

          ...

        }

The $column_type for decimal columns is numeric, though, not decimal. I think decimal doesn't actually exist.

Fix the condition to catch numeric columns.

Remaining tasks

User interface changes

API changes

Data model changes

Beta phase evaluation

Problem/Motivation

Follow-up to #1088112: Introduce a token to get site's base URL

Steps to reproduce:

1. Go to your installed drupal directory and append index.php (e.g http://drupal.test/index.php)
2. Build a URL with base prefix: Url::fromUri('base:sites/default/files/og_image.jpg')
3. Assert the URL to the image asset is broken as the path is /index.php/sites/default/files/og_image.jpg

Proposed resolution

When building a URL with base prefix use $request->getBasePath() instead of $request->getBaseUrl() which results in omitting index.php in case it is present.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet