Quantcast
Channel: Issues for Drupal core
Viewing all 291155 articles
Browse latest View live

Drupal 8 updating issue - Drupal\Component\Plugin\Exception\PluginNotFoundException: The "<whatever>" plugin does not exist

$
0
0

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>

IncludeResolver not returning correct version data for moderated content references

$
0
0

When trying to access the working revision entity data with resourceVersion=rel:working-copy and using includes, the current revision of the referenced entities is being returned by the method "resolveIncludeTree" in IncludeResolver class. This method should return the data as per the revision being passed in the API query or the working revision.

Convert config, config_environment module hook_help() to topic(s)

$
0
0

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the config, config_environment module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

  1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
  2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
      switch ($route_name) {
        case 'help.page.contact':
    

    And ends either at the end of the function, or where you find another case 'something': line.

  3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
  4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
  5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
  6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
  7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

  1. Apply the patch.
  2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
  3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
  4. Review the topic text that you can see on the page, making sure of the following aspects:
    • The text is written in clear, simple, straightforward language
    • No grammar/punctuation errors
    • Valid HTML -- you can use http://validator.w3.org/ to check
    • Links within the text work
    • Instructions for tasks work
    • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
  5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Implement Server Timing performance metrics

$
0
0

Problem/Motivation

Providing server timing would help developers estimate site performance.
The corresponding W3C specification is currently in "Working Draft" status and its already supported by Google Chrome and partially by Firefox.
https://www.w3.org/TR/server-timing/

Proposed resolution

Add Server-Timing header with relevant timing information.

Query condition 'users_field_data.mail IN ()' cannot be empty

$
0
0

I get a exception when I make a curl request to /user/password with invalid parameters.
Ex:
curl -X POST --form name%5B0%5D="" --form form_id=user_pass -- http://test.local/user/password?name%5B0%5D

curl -X POST --form form_id=user_pass http://test.local/user/password?name%5B0%5D=""

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

I am not sure if this a user.module issue or not.

Node Revision page for non-existing revision returns fatal error, should be 404

$
0
0

Node Revision page for non-existing revision returns fatal error such as "TypeError: Argument 1 passed to Drupal\Core\Entity\EntityViewBuilder::view() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in /Applications/MAMP/htdocs/drupal-8.9/core/modules/node/node.module on line 688 in Drupal\Core\Entity\EntityViewBuilder->view() (line 133 of /Applications/MAMP/htdocs/drupal-8.9/core/lib/Drupal/Core/Entity/EntityViewBuilder.php)"

steps to reproduce
1. Delete all node revisions
2. Update some node's it will add new revisions
3. Visit old revisions.

Add published/unpublished option to taxonomy filter on views

$
0
0

Since taxonomies can be published/unpublished #2899923: UI for publishing/unpublishing taxonomy terms#2880149: Convert taxonomy terms to be revisionable, an option should be added to "configure filter criterion" on a taxonomy field on views to display published/unpublished taxonomy terms

Example:

  • Taxonomy contains Aus States: QLD NSW WA etc...
  • Unpublish NSW
  • Create a view, add taxonomy as filter and configure filter criterion to expose filter to users (see screenshot 1)
  • All taxonomy terms will be displayed in the filter to the users (see screenshot 2)

Expected behaviour would be only published taxonomy terms to be displayed in the filter by default (and option added to specify which taxonomy terms to display to filter configuration).

Screenshot 1:

Screenshot 2:

Incorrect process of language prefixed a langcode other than the current langcode

$
0
0

Given following code snippet with a Drupal installation have `en` and `de` language enabled with LanguageUrlNeogotiation, and currently on an en page.

$url = '/de/i-am-an-alias';
$url_object = $this->pathValidator()->getUrlIfValidWithoutAccessCheck($url);

The expected result is to have a `$url_object` that correctly points to the related canonical entity URL of de language.

The actual result is the `$url_object` is null.

After digging into the underline code, below is the call stack.

\Drupal\Core\Path\PathValidator::getUrlIfValidWithoutAccessCheck -> \Drupal\Core\Path\PathValidator::getPathAttributes -> \Drupal\Core\PathProcessor\PathProcessorManager::processInbound -> \Drupal\Core\PathProcessor\PathProcessorAlias::processInbound

Inside `PathProcessorAlias::processInbound` it calls `aliasManager::getPathByAlias`, but it discards the `$request` parameter completely. As the alias handling is heavily relying on the language negotiation result, ignore the language in `$request` context, will certainly give a problematic result.

After some analysis, I think what core `PathProcessorAlias::processInbound` does make sense, because the whole language negotiation sub-system is introduced in Language module, the core `PahtProcessAlias` should not be aware of any of it.

Proposed Solution:

- Respect `$reqest` parameter in `PathProcessorAlias::processInbound` and get the negotiated language from the `$request`.
- Introduce a new `PathProcessorLangugeAlias` processor, take into considration of lanuage negotialtion methods of the url.


Expected type hint "GetResponseEvent"; found "FilterResponseEvent" for $event

Always set X-Drupal-Cache and X-Drupal-Dynamic-Cache headers, even for responses that are not cacheable

$
0
0

Problem/Motivation

Currently if a response is not cacheable Drupal sets X-Drupal-Dynamic-Cache = UNCACHEABLE, but in some cases it does not. See DynamicPageCacheSubscriber::onResponse for details.

Proposed resolution

Always set X-Drupal-Dynamic-Cache header.

  1. This changes the existing X-Drupal-Dynamic-Cache: UNCACHEABLE to X-Drupal-Dynamic-Cache: UNCACHEABLE (poor cacheability).
  2. This adds X-Drupal-Dynamic-Cache: UNCACHEABLE (no cacheability) (for responses which aren't instances of CacheableResponseInterface).
  3. This adds X-Drupal-Dynamic-Cache: UNCACHEABLE (policy) (when the Dynamic Page Cache request/response policy tagged services deny caching).

This makes it much easier for developers to understand what the Dynamic Page Cache module is doing, and why.

Remaining tasks

None.

Blank index in array passed to convertExposedInput()

$
0
0

In my views, I override the text for the filter button for exposed filters. The text is rendered correctly, but while debugging another issue, I noticed there's an element in the $input array (first arg for that member function) with a blank index. For example, the last five items in that array for one of my views are:

'submit' => "Filter"'reset' => "Reset"'form_build_id' => "form-GeIWX9X-mNXDa_BxzyPZcHacqwiZjszmrvfn1VLCMbw"'form_id' => "views_exposed_form"'' => "Filter"

I have verified that it is related to overriding the button text because I changed it and the new value showed in the array (as well as on the page). I suspect that it is rendering correctly because of the 'submit" element of the array.

claimItem in the database and memory queues does not use expire correctly

$
0
0

Problem/Motivation

Items in the queue cannot be reclaimed or get incorrect lease times leading to unexpected behaviour with expiration and claims.

There are three errors:

- The system cron only resets the expired items of the Database Queue. Memory queue items can never be reclaimed, because their expire value is never set to 0.
- The cron time and the lease time are incorrectly using the same value defined in the annotation of the queue worker.
- The lease time for items in cron-based queues are incorrectly set to 1 second.

Proposed resolution

1. Let queues handle expiration of items themselves.
2. Fix the lease time for cron based queues.
3. Allow queueworkers to set specific lease times as well as cron times.

API changes

Added cron lease time in the QueueWorker annotation definition.

Cached forms can have duplicate HTML IDs, which disrupts accessible form labels

$
0
0

I don't really know if this is a core issue or block cache alter issue... even I don't know if it there is any solution...
I have a website with both "User login" block and "Search" block, cached with "Globally cached" option. But when using cache on that blocks, I get duplicated ID's (i.e., #edit-submit and #edit-actions). I think it's because admins don't see "User login" block, so "Search" block HTML gets cached with #edit-submit ID. Then, when first anonymous visitor comes to the site, "Search" block HTML gets loaded from cache, and "User login" block it's dinamically generated with #edit-submit ID (because it wasn't generated dinamically before). So, the HTML generated can't be validated by automatic tools.
This also can generate bugs in javascript, and stylesheet problems (luckily for me, it's not my case).
Is there any way to avoid this? Storing somewhere IDs cached used when caching or something...
As I said, I don't know if this is a core issue or not.

SelectInterface and QueryPluginBase type hint missing

$
0
0

Type hint "\Drupal\Core\Database\Query\SelectInterface" missing for $select_query
Type hint "\Drupal\views\Plugin\views\query\QueryPluginBase" missing for $view_query

Menu Active In Sub level page

$
0
0

Hi team,

How to add menu active to sub level page using the page current URL. I have customised the menu template added the following code. But the active class renders in all the anchor not just the active anchor tag.
{%
set link_classes = [
item.in_active_trail ? 'active',
]
%}
{{ link(item.title, item.url, {'class': link_classes}) }}

Thanks
Divya


Replace ZendFramework/* dependencies by their Laminas equivalents

$
0
0

Since the transition of Zend Framework to the Laminas project, composer has been warning about the deprecation of the zendframework/* components.

Our composer dependencies should be updated to reflect this.

  • zendframework/zend-diactoros → laminas/laminas-diactoros
  • zendframework/zend-escaper → laminas/laminas-escaper
  • zendframework/zend-feed → laminas/laminas-feed
  • zendframework/zend-servicemanager → laminas/laminas-servicemanager
  • zendframework/zend-stdlib → laminas/laminas-stdlib

Replace the DiactorosFactory message factory in symfony/psr-http-message-bridge with a PSR-17 compliant message factory

$
0
0

Problem/Motivation

In July 2018, PHP-FIG accepted PSR-17, providing a standard interface to http message factories. The interface for this standard requires PHP 7.0, and most implementations require PHP 7.1. The symfony/psr-http-message-bridge provides a wrapper interface around the message factory, and can be used with our current DiactorosFactory or with PSR-17 compliant factories. Beginning with psr-http-message-bridge v1.2, the non-PSR-17 Diactoros factory is deprecated, in favor of the PsrHttpFactory, which uses PSR-17 factories under the hood.

Proposed resolution

zend-framework/zend-diactoros provides a set of PSR-17 standard factories beginning with version 2.0, which can be plugged into the symfony PsrHttpFactory wrapper, however version 2.0 requires PHP 7.1. We should consider switching when we also support a PHP minimum version of 7.1. Because the symfony wrappers have the same interface, there are no BC concerns, and we could do this in Drupal 8.9 if we choose to support a minimum PHP version of 7.1 in Drupal 8.9. Alternatively this could be targeted for Drupal 9.0

A test of this swapout was done in #3039584: The "Symfony\Bridge\PsrHttpMessage\Factory\DiactorosFactory" class is deprecated since symfony/psr-http-message-bridge 1.2, use PsrHttpFactory instead. and it was found that a direct swap resulted in passed tests with minimal code adjustments

Remaining tasks

Update the vender versions,
Add services for the individual factories
Replace the current factory service with the new service, and pass in the individual factory service
Remove deprecation suppression messages regarding DiactorosFactory being deprecated in symfony/psr-http-message-bridge v1.2

User interface changes

none

API changes

Our message factory would use PSR-17 factories under the hood to build our PSR-7 messages

Data model changes

none

Release notes snippet

Drupal now uses PSR-17 compliant message factories to create PSR-7 Requests and Responses.

Select All media option is missing while adding media in Table format

$
0
0

Step to Reproduce

1. Add media as reference field in Basic Page content type.(Allow unlimited)
2. Add basic page content.
3. While adding basic page in media section click Add Media
4. Then select Table as format.
5. In 1st column select all checkbox is missing.

My idea is that it's good to provide select all option to end user when media entity is more than 1.

Value returned from FileSystem methods are not checked in streamUploadData() function

$
0
0

In TemporaryJsonapiFileFieldUploader class streamUploadData() function calls the methods implemented from the file_system services without checking they return a failure value. FileSystem::tempnam() return a Boolean value in case of error.

[META] Update / reconsider dependencies for Drupal 9

$
0
0

Problem/Motivation

Some dependencies need updating, some need to be reconsidered and removed or replaced.

Proposed resolution

The following are to be updated before Drupal 9.0.0 is released:

  1. #3088369: Update Drupal 9 to Symfony 4.4-dev
  2. #3041076: Update Drupal 9 to Twig 2
  3. #2950132: Support PHPUnit 7 optionally in Drupal 8, while keeping support for ^6.5
  4. #3091418: Update composer dependencies on 9.0.x (and followups)
  5. #3078671: Pin behat/mink and behat/mink-selenium2-driver to use resolvable release
  6. #3020296: [meta] Replace Symfony's classloader as it does not exist in Symfony 4
  7. #3104265: Update Composer dependencies on Doctrine components in 9.0.x
  8. #3104354: Update Diactoros to 2.1
  9. #3104353: Test Guzzle 7.0.0-beta1
  10. #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1
  11. #3104265: Update Composer dependencies on Doctrine components in 9.0.x

There is also an ongoing issue at #2864037: [META] Update core PHP dependencies which is not Drupal-9-specific.

The following will happen later after Drupal 9.0.0 sometime in Drupal 9's lifetime:

  1. #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10

The following are considered for removal or replacement: #3080837: [meta] PHP (and JS) dependencies to consider decoupling or removing

The following are already not used by Drupal 8 and will be removed in Drupal 9: #3032686: Remove references to unused packages in Drupal 9's vendor hardening

Remaining tasks

See above.

User interface changes

Likely none, depends on updates with UIs.

API changes

Depend on updated dependencies that Drupal is exposing as-is.

Data model changes

Depend on updates.

Viewing all 291155 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>