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

Created date in node author details summary not displayed in current locale

$
0
0

Problem/Motivation

When creating or editing a node, the author details summary displays the created date if the created date field is filled in. The problem is that the format is always YYYY-MM-DD, even when the user's browser or operating system has a different locale.

Proposed resolution

Because the summary is generated by javascript it cannot use Drupal's date formats. It uses the input value of the created date input field instead, without formatting it.

Proposed resolution is to use the widely supported Date.toLocaleDateString method to format the string to the user's locale.


Changes in site building process can run into Cannot access offset of type StringTranslation\TranslatableMarkup on field creation path

$
0
0

Problem/Motivation

Under hard to tackle down circumstances an error makes admin paths like  admin/structure/types/manage/node-type/fields/add-field inaccessible with WSOD making it impossible to create new fields on any content or custom entity type from the UI:

Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 45 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

To bring up more here or where to look at or to investigate further we need hints regarding what DiscoveryTrait.php is for. Looking at api.d.org did not helped yet much. Usually you would get a listing of field types at that point entering the field creation path, so our first assumption was it belongs to query existing field types via the admin UI of that path. That's why I choose field system at first but maybe we need to move it to language system.

Reusing an existing field works without issues from UI and this is probably why we discovered the issue too late to have an idea what change here lately has caused the error. But the irreversible behavior and WSOD made me consider a core issue report. Because we maybe do have an underlying problem here where contrib modules do something or probably rather left or removed something they should not be allowed to after removal of settings or uninstalls which causes breaking core here. Maybe we need another step/check for safety to prevent this.

Steps to reproduce

Sadly this will be hard to reproduce and is probably caused by left overs from module configurations, installs and uninstalls and many back and forth in a longer site building process. Discovered here on a Drupal 11.04 upgraded project which came from 10.3.3 with 2 languages set up and activated for content, interface and configuration and with far too much contrib modules. All uninstalled step by step in the hope to maybe find the one causing it. First we thought modules creating new field types are the most suspicious, but non of them uninstalling made a change. Which makes sense if this is caused by something rather "missing" than being still around.

Line mentioned in the error log is 45 in core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php (git.drupalcode.org link):

if (isset($definitions[$plugin_id])) {

The whole block:

protected function doGetDefinition(array $definitions, $plugin_id, $exception_on_invalid) {
    // Avoid using a ternary that would create a copy of the array.
    if (isset($definitions[$plugin_id])) {
      return $definitions[$plugin_id];
    }
    elseif (!$exception_on_invalid) {
      return NULL;
    }

Furthermore this error appears on UI only. The field creation process via console (drush field:create) works without flaws.

Proposed resolution

There are some issues open mentioning TranslatableMarkup and other Cannot access offset of type xxx issues all not related in that sense but interestingly enough most of the latter raised in the last 2 years. So it probably belongs to newer PHP versions being more strict in the requirements of type checking and error behavior. Mainly in cases where array are empty or similar. Some of the issues discuss is_array() and similar workarounds.

Maybe related but I did not wanted to reference them yet if not, to prevent unnecessary noise:

Remaining tasks

Needs more steps/tests to reproduce.

Full error log

The website encountered an unexpected error. Try again later.  

TypeError: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 45 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Drupal\Core\Plugin\DefaultPluginManager->getDefinition() (Line: 16)  
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 76)  
Drupal\Component\Plugin\PluginManagerBase->createInstance() (Line: 136)  
Drupal\field_ui\Form\FieldStorageAddForm->processFieldDefinitions() (Line: 80)  
Drupal\field_ui\Form\FieldStorageAddForm->buildForm()  
call_user_func_array() (Line: 528)  
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)  
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)  
Drupal\Core\Controller\FormController->getContentResult()  
call_user_func_array() (Line: 123)  
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)  
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)  
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)  
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)  
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)  
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)  
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)  
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)  
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)  
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 53)  
Asm89\Stack\Cors->handle() (Line: 50)  
Drupal\ban\BanMiddleware->handle() (Line: 48)  
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)  
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)  
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)  
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)  
Drupal\Core\DrupalKernel->handle() (Line: 19)

Allow storing telephone number in E164 format

$
0
0

Problem/Motivation

One of the biggest challenges with the current Telephone module is that it's just a glorified textfield. It has no option to normalize the telephone number - either for the purpose of validation or formatting.

In Commerce applications, we see more and more requirements from payment gateways to collect and pass the telephone number to the payment gateway during Checkout. Given we have payment gateways from all over the world, supporting customers in virtually every possible market, we also must be able to process and send the phone number in a normalized way.

Fortunately, 2 standards are leading here:
- E.164 - the international public telecommunication numbering plan
- national format - popular if only supporting customers in one market

Google came up with the library that is now an unofficial standard, that allows transitions between formats as well as data validation. In PHP it was adapted as-is and released as a standalone composer library.

Drupal Contribs such as telephone_validation and telephone_formatter modules utilize said library to perform certain operations on the user input. But the problem is - we don't have a common storage where telephone could be stored in a normalized format, similar to how numbers or dates are already handled by core. With the steady growth in the usage of said modules and surpass of 10k installation I feel it's time to have better support directly in Core.

Proposed resolution

- Create a new field type plugin in the telephone module - TelephoneE164Item (telephone_e164). Allow users to choose that field type over current, simplified TelephoneItem
- Store the phone number user input AND E164 version in the database
- Create a validation constraint that will only accept the value IF user input can be represented in E164 format
- Create a formatter(s?) to show the value directly from user input, in E164 format, international or national format.

Remaining tasks

- Find out what should be the schema for the new field
- Document when the old field type should be used over the new field type (alarm numbers, vanity phone numbers, etc.

User interface changes

n/a

Introduced terminology

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

Provide a ConditionsFormTrait or form element for conditions

$
0
0

Problem/Motivation

Just had the need to implement form with conditions (from Condition Plugins) for two different module settings pages.

I think conditions for settings forms or entity forms aren't a rare case and most of us have seen them already (or someone implementing the conditions by hand, as they weren't aware it exists or how to use them - indeed it's not easy to find documentation, but that's another topic).

Typical forms where such conditions are used:

  • Core Blocks
  • Tracking / analytics integration modules to control visibility of the hook_page_attachments() added libraries (there are many and most of them implement the conditions not using Condition Plugins!)
  • Context module
  • Asset injector module
  • ...

Looking for existing implementations of form using conditions, I found
https://git.drupalcode.org/project/core_extend/-/blob/8.x-1.x/src/Form/C...
in the old https://www.drupal.org/project/core_extend module.

And I think that's an excellent basic idea for core to unify and simplify use of conditions in forms!

So the question is, if a trait is the best way to provide an easier integration (I think so) or if a form element would even make sense. Thinking about that, I think a form element would be hard to configure, harder to individualize and as conditions are typically displayed as vertical tabs, I think a form element would be untypical.

Another thing I found in my investigations was, that most contrib modules implementing Conditions in forms, were copying the implementation from BlockForm, for example see lazyloader module:
https://git.drupalcode.org/project/lazyloader/-/blob/8.x-1.x/src/Form/Ad...

Maybe the trait could help to reduce boilerplate code copies?

Steps to reproduce

Implement a Condition Plugin form in core or contrib

Proposed resolution

Add a ConditionsFormTrait or a "conditions" form element to core

Remaining tasks

  1. Discuss
  2. Implement
  3. Test
  4. Release

User interface changes

None

Introduced terminology

API changes

Data model changes

Release notes snippet

Library CSS definition should not fail is no CSS files defined

$
0
0

Problem/Motivation

If a library definition includes an empty "css" -%:gt; "component" structure, the following error is thrown:

CSS files should be specified as key/value pairs, where the values are configuration options. See https://www.drupal.org/node/2274843.

Steps to reproduce

Create a modulename.libraries.yml file with a library definition that includes an incomplete "css""component" section:

mylibrary:
  css:
    component:

What should happen:
* Nothing, the site should continue working.

What actually happens:
* The site fails.

Proposed resolution

The codebase only fails if the library's css -> component structure contains an invalid structure, it doesn't fail if the structure is simply empty.

Remaining tasks

TBD

User interface changes

TBD

Introduced terminology

n/a

API changes

TBD

Data model changes

n/a

Release notes snippet

TBD

Add Views EntityReference filter to support better UX for exposed filters

$
0
0

Continuation of #2429699: Add Views EntityReference filter to be available for all entity reference fields since there were so many comments the page was struggling to load.

Slack thread

https://drupal.slack.com/archives/C6SQM2J94/p1706633005193429

Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Create a new Views Entity Reference filter plugin to be available for all entity reference fields but do not activate it at this stage. Make it available as an opt-in via views data alter.

How to use

  1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
  2. Use views data alter to allow your field to make use of the reference (see code snippet below)
  3. Create a view displaying this entity type.
  4. Add a filter on the view for field_test_reference.
  5. Configure the entity selection mode and the widget display mode.
  6. Configure the filter behavior (ex: required, multiple, etc.)
  7. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Code snippet to use this filter:

/**
 * Implements hook_views_data_alter().
 */
function MODULE_NAME_views_data_alter(&$data) {
  // Use entity reference for the field 'field_test_target'.
  $field_name = 'field_test_field';
  $data['node__' . $field_name][$field_name . '_target_id]['filter']['id'] = 'entity_reference';
}

Or use the contrib module: https://www.drupal.org/project/views_core_entity_reference

Remaining tasks

  • ☑ support for content entity reference
  • ☑ support for configuration entity reference
  • ☑ support for content with and without bundles
  • ☑ taxonomy filter rebased on generic entity reference
  • ☑ settings forms to configure the filter
  • ☑ display widget in select or autocomplete
  • ☑ filter values based on reference view
  • ☑ filter values based on bundles
  • ☑ maximum filter values in select list for performance concerns
  • ☑ sort for filter values when in bundle selection handler mode
  • ☑ argument support for when view selection handler is used
  • ☑ views configuration schema update
  • ☐ existing configuration migration (no longer needed if we create a new filter only)
  • ☐ fix select option (#208, #215)
  • ☑ tests for general functionality
  • ☑ write change record
  • ☑ get framework manager approval
  • ☑ update change record screenshots once green light has been given for this updated direction and considered ready to merge

Issues suggested to leave

As noted in #163, #164, and #169, suggesting we leave the outstanding non-checked items from below. Checked items are handled.

  • ☐ Address points in comment #49 (comment 534 from original ticket)
    • ☑ add test coverage for calculate dependencies
    • ☐ sort by empty on initial load (needs more info), see comment #49 Unable to reproduce, perhaps tied to older version of patch
    • ☐ prevent circular reference: validate no selection of an entity reference that uses itself as the filter, see comment #49 Suggested to be a follow-up
    • ☑ node titles in the select options when configuring the filter are double escaped (e.g. " shows as "), see comment #49 - Resolved in #200
    • ☑ exposed filters on the chosen entity reference view are also shown on the view, see comment #49 - Resolved in #199

Post tasks

User interface

UI
UI

UIUI

Known issues

  • CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
  • FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
  • FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

API changes

None.

For 10.2

See hidden branches and comment #143

Avoid warning from imagecreatefrompng when loading png with obscure iCCP profiles

$
0
0

Problem/Motivation

When a PNG (and some other rarely used formats) image contains iCCP chunk with sRGB IEC61966-2.1 color profile, libpng triggers warning:

Warning: imagecreatefrompng(): gd-png: libpng warning: iCCP: known incorrect sRGB profile in Drupal\system\Plugin\ImageToolkit\GDToolkit->load() (line 201 of core/modules/system/src/Plugin/ImageToolkit/GDToolkit.php).

This warning is printed for any such image, but they're still valid and displayed correctly.

Steps to reproduce

You need an image with iCCP chunk in it and sRGB IEC61966-2.1 color profile. You can achieve this in several ways.

You can find this color profile in attachments for that issue — sRGB IEC61966-2.1.zip. Extract it first to get .icc profile.

For examples, I will use core/tests/fixtures/files/image-test.png. It will be called image-test.png in commands below without full path.

ImageMagick CLI (convert)

Assuming that color profile (.icc) and image (image-test.png) in the same folder.

  1. convert image-test.png -profile sRGB\ IEC61966-2.1.icc -strip -profile sRGB\ IEC61966-2.1.icc -define png:include-chunk=zTXt,iCCP image-1-icpp.png
  2. Upload this image into Drupal and try to process it by any image style.

GIMP (OpenSource image editor)

  1. Open image-test.png in GIMP.
  2. Go to Image | Color Management | Assign Color Profile…
  3. In Assign section in select element chose Select color profile from disk…
  4. Select downloaded .icc profile.
  5. Click Assign.
  6. Save the image by File | Save as chose name and path and click Export. In open modal window, make sure you have checked Save color profile, and then again Export.
  7. Upload this image into Drupal and try to process it by any image style.

Proposed resolution

Add @ symbol before calling imagecreatefrompng() to suppress this warning.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Support priority for needs_destruction service tag

$
0
0

Problem/Motivation

RegisterServicesForDestructionPass::process() does not support a priority attribute. Being unable to set certain services to be destroyed after others has caused the following issue: #3008776: Search API list tag does not get purged.

The Purge Queue service's destruct method is called before Search API's, resulting in certain tags not getting added to Purge's queue for invalidation.

Also, the PerformanceDataCollector service fails to collect al information because it runs before some of the destructable services.

Proposed resolution

Make use of PriorityTaggedServiceTrait::findAndSortTaggedServices() to get the tagged services already sorted by priority.

Remaining tasks

None.

User interface changes

N/A

API changes

Destructable services are running in an order governed by the priority tag.

Data model changes

The kernel.destructable_services container parameter contains a list if service IDs sorted by priority.

Release notes snippet

The destructable service order can be set by using a priority attribute. See Drupal\performance_test\PerformanceDataCollector service.


Entity displays cloning requires special config action

$
0
0

Problem/Motivation

In the parent issue the general entity clone action was created, but unfortunately for entity display the clone process requires changing the mode property, see here https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co... . Method createCopy is called in https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/field... when the new entity display is added.

I believe this config action that mimics the behavior from admin UI will be useful.

Proposed resolution

The cloneAs config action should behave consistently, and not need to special-case entity displays. They should be able to properly handle changes to their ID, so override their set() method to update the target entity type, bundle, and view mode when the ID changes. This unlocks stuff like:

# Clone a particular display into another content type, with the same view mode. This can't be used with wildcards because the clone's ID is static.
core.entity_view_display.node.page.3column:
  cloneAs: node.blog.3column

Meanwhile, expose the createCopy() method as a normal config action, which allows wildcard compatibility:

# Create the search_result display as a copy of the full display, for all available content types.
core.entity_view_display.node.*.full:
  createCopy: search_result

Stop caching app.root and site.path in DI containter

$
0
0

Problem/Motivation

The Drupal kernel resolves the application root (app.root) and site path when initializing the container and sets them as parameters app.root and site.path in the container, with the following comment:

Drupal provides two dynamic parameters to access specific paths that are determined from the request.

But when those parameters are used as arguments for services, they are statically cached, like in the module_handler service:

  module_handler:
    class: Drupal\Core\Extension\ModuleHandler
    arguments: ['%app.root%', '%container.modules%', '@cache.bootstrap']
    tags:
      - { name: needs_destruction }

Those paths (especially app.root) actually can change per request, which is why they are explicitly set dynamically
on the container. Therefore they must not be statically cached, as that can break a Drupal site. It might not be obvious why the app.root path might change between two requests, but the most common case is a shared web hosting with chrooted SSH access. Usually the app root on such environments is in /var/www/vhosts/your-domain.tld/htdocs/web. The SSH access (and with it Drush) is chrooted and Drush\DrupalFinder\DrushDrupalFinder detects the app root as /htdocs/web.

Here, a HTTP request and a Drush command (which technically is handled as a request by Drupal as well) will have different app.root paths.

This is based on the PHP-FPM bug (#62279) explaining that the relevant server variables still unchrooted:

$_SERVER["SCRIPT_FILENAME"]
$_SERVER["PATH_TRANSLATED"]
$_SERVER["DOCUMENT_ROOT"]

Steps to reproduce

  • Setup a standard Drupal installation on a shared webhosting (like) environment with chrooted shell access.
  • Eventually set PHP error reporting to E_ALL and enable "display errors" to get the relevant PHP error messages.
  • Compare the outputs for "Drupal root" from drush status and browser based PHP Info or by displaying Drupal\Core\DrupalKernel::getAppRoot() via hook_requirements().

Execute drush cache:rebuild and then reload the site in the browser. This can crash the site.

I got the following error messages (in Drupal 10.3):

Warning: file_exists(): open_basedir restriction in effect. File(/httpdocs/web/modules/contrib/address/address.info.yml) is not within the allowed path(s): (/var/www/vhosts/your-domain.tld/:/tmp/:/var/lib/php/sessions) in Drupal\Core\Extension\Extension->__construct() (Line 73 in /var/www/vhosts/your-domain.tld/httpdocs/web/core/lib/Drupal/Core/Extension/Extension.php)

AssertionError: The file specified by the given app root, relative path and file name (/httpdocs/web/modules/contrib/address/address.info.yml) do not exist. in assert() (Line 73 in /var/www/vhosts/your-domain.tld/httpdocs/web/core/lib/Drupal/Core/Extension/Extension.php)

Further information: [Plesk Forum] How to set up chroot for php-fpm?

Proposed resolution

Resolve parameters %app.root% and %site.path% dynamically when instantiating services instead of caching the resolved values.

If that is not possible,

  • provide factory functions returning uncached values for %app.root% and %site.path% parameters and replace all usages in service definitions etc. in Core by calls to the corresponding factory functions.
  • Recommend all contrib modules to use the factory functions as well.

Remaining tasks

TODO

API changes

TODO

Release notes snippet

TODO

Give users option to override Claro --font-size-xs and --font-size-xxs with --font-size-s

$
0
0

Problem/Motivation

Claro's --font-size-xs is too small for me to use comfortably on my high-resolution screen. However, if I use the browser feature to zoom text, some other text becomes too large for me to use comfortably and, if I zoom enough times, it changes the layout. It would be good to allow users the option to always override --font-size-xs with --font-size-s. I recognize this can be used in user style sheets, however, Chrome and Edge do not support user style sheets, and I would prefer not to use browser plug-ins to accomplish this for security reasons.

Similarly, while I could zoom in, that affects all pages on the website, so would affect my view of our website pages, not just the administrative user interface, and also makes all content larger - including headings, which become excessively large.

Actually, some users may even find --font-size-s too small, so it would be good to be able to choose whatever the regular font size as the minimum size for all content. I don't understand the rationale for making instructions smaller, since if someone needs them it's important that they be able to understand them without barriers to comprehension such as having to make out tiny type.

Steps to reproduce

1. Go to simplytest.me
2. In the field, type core
3. Choose Drupal core
4. Press the button to create the website
5. Login as admin
6. Go to /admin/structure/types/manage/page/fields/node.page.body

Desired result:
"Instructions to present to the user below this field on the editing form.
Allowed HTML tags: <a> <b> <big> <code> <del> <em> <i> <ins> <pre> <q> <small> <span> <strong> <sub> <sup> <tt> <ol> <ul> <li> <p> <br> <img>
This field supports tokens."
is the same size as "Required field", without making other content larger.

Current result:
"Instructions to present to the user below this field on the editing form.
Allowed HTML tags: <a> <b> <big> <code> <del> <em> <i> <ins> <pre> <q> <small> <span> <strong> <sub> <sup> <tt> <ol> <ul> <li> <p> <br> <img>
This field supports tokens."
is noticeably smaller than other content such as "Required field".

I don't have any examples of where --font-size-xxs is used, but if --font-size-xs causes me a problem then I expect --font-size-xxs certainly will. Shrinking text below the base size is generally problematic for me.

Proposed resolution

Add a preference for minimum size to the user page /user/[userNumber]/edit

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Create an admin route condition plugin or add generic "Current theme" options for admin and default theme

$
0
0

Problem/Motivation

Now that admin paths are part of route definitions:

Option A) ... it would be super useful to have an "Is administrative path" condition plugin in core!

The use-case is not to use path conditions like

admin/
admin/*

for cases where conditions are used.
This check isn't really feature-complete for admin paths and kind of ugly. So frequently you end up with something like

/admin
/admin/*
/batch
/node/add*
/node/*/*
/user/*/*
/user/login
/user

...

A bonus would be to also be able to match paths that are shown in the admin theme, based on the theme settings checkbox, for example node edit forms.

Option B) The current workaround is to use "Current theme" = "Gin" (Name of the admin theme)
An alternative to the suggested approach would be to add generic options to the "Current theme" condition:

  • <Default Theme>
  • <Administration Theme>

Conditions like this are frequently used for Blocks, Analytics modules, Contexts, etc. that should only act in the frontend, but never on admin pages.

Would be nice to discuss, which solution is the core maintainers favourite, before we start with the implementation.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Contexts without data not visible in block context selector

$
0
0

Problem/Motivation

Contexts without data not visible in block context selector
screenshot

Steps to reproduce

Create new node with title "Super".
Create taxonomy term with name "Super".
Create custom context provider. Let it return term with name = title of current node.
Part of the code:

  public function getAvailableContexts() {
    $context = EntityContext::fromEntityTypeId('taxonomy_term', $this->t('Same name term'));
    return ['taxonomy_term' => $context];
  }

Create taxonomy term view with a block display.
Add contextual parameter "Term ID" and save the view.
Go to node type display settings.
Add this block to layout builder.
Click to block settings. There is no new created context provider.
But if change code to:

    $context = EntityContext::fromEntity(Term::create([...]), $this->t('Same name term'));
    return ['taxonomy_term' => $context];

context became visible.

Look at \Drupal\layout_builder\Context\LayoutBuilderContextTrait::getAvailableContexts.

Proposed resolution

All context providers should be visible (with and without data).
As in getAvailableContexts() written:

* When a context aware plugin is being configured, the configuration UI must
* know which named contexts are potentially available, but does not care
* about the value, since the value can be different for each request, and
* might not be available at all during the configuration UI's request.

But I don't know how we can get sample entity in context provider during preview.

File upload permission error showing in Media file field and CKEditor Image upload option

$
0
0

Problem/Motivation

Even if the folder has permission to upload, it shows below error messages as of now and this was working before properly till October 4 2024. Issues in different site versions,

  • Drupal Version: 10.3.6 - PHP Version: 8.3.9 - MySQL Version: 8.0.37-azure
  • Drupal Version: 10.1.6 - PHP Version: 8.2.21 - MySQL Version: 8.0.37-azure
  • Server: nginx/1.26.1
  • Platform: Azure Linux

If we enabled IMCE module and enabled for the file field in media, then user is able to upload via IMCE file browser.

  1. The upload directory public://FOLDER for the file field field_NAME could not be created or is not accessible. A newly uploaded file could not be saved in this directory as a consequence, and the upload was canceled.
  2. Symfony\Component\HttpKernel\Exception\HttpException: Destination file path is not writable in Drupal\ckeditor5\Controller\CKEditor5ImageController->upload() (line 157 of /.../core/modules/ckeditor5/src/Controller/CKEditor5ImageController.php).

Steps to reproduce

  1. Any supporting file format in /media/add/document or /media/add/image shows error from file.module
  2. Image upload option from CKeditor5 in all nodes shows error number 2 listed above in CKEditor5ImageController

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Route "_title_arguments" computation may be incorrect

$
0
0

Problem/Motivation

The current implementation of the title resolution mechanism does not behave as expected when both _raw_variables and _title_arguments are set in a route. Specifically, when _raw_variables is defined in the route, the getTitle() method continues to return the static value specified in the route rather than utilizing the provided _title_arguments. This creates confusion and prevents dynamic title generation based on URL parameters.

Steps to reproduce

  1. Create a route with URL parameters and set _title and _title_arguments
  2. Observe the displayed title
  3. The route display static titles as defined in the routing configuration, without reflecting any changes from the URL parameters or title arguments
  4. ex :

    custom_module.test_route:
      path: '/test-route/{test}/{test2}'
      defaults:
        _controller: '\Drupal\custom_module\Controller\CustomPageController::content'
        _title: 'Static title @test @test2'
        _title_arguments:
          '@test': 'value''@test2': 'value2'
      requirements:
        _permission: 'access content'

Proposed resolution

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Controlle...

The code for getting the arguments for the route in TitleResolver.php file in getTitle() is as follows:

      $args = [];
      if (($raw_parameters = $request->attributes->get('_raw_variables'))) {
        foreach ($raw_parameters->all() as $key => $value) {
          $args['@' . $key] = $value;
          $args['%' . $key] = $value;
        }
      }
      if ($title_arguments = $route->getDefault('_title_arguments')) {
        $args = array_merge($args, (array) $title_arguments);
      }

Here '_title_arguments' are the arguments specified in the routing file, which IMO, should be the default value in case "_raw_variables" are not there.

So IMO, the array_merge() should be:
array_merge((array) $title_arguments, $args);

Remaining tasks

- Needs Review

User interface changes

- None

API changes

- None

Data model changes

- None

Release notes snippet

- None


Do not require a 'title' field

$
0
0

Problem/Motivation

When creating custom content types, the "Title" field is manditory. This leads to akward work-arounds for content types that do not need a 'title' / 'short text' field. One example would be modeling people:

person { first_name, last_name } // no title necessary

Please provide a means by which we can create new content types through the UI without a mandatory title field (i.e. plain text field).

Some workarounds for the node title requirement, which indicate a longstanding, underlying usability issue, include:

Proposed resolution

Workaround - hide the title field on the form: admin/structure/types/manage/custom_content_type/form-display
Setting the title field to hidden will let you create nodes without the title.

Drupal Current theme condition plugin should provide an option to match all themes (- Any -)

$
0
0

Problem/Motivation

Currently it is not possible to exclude theme condition from evaluation. Though the select list with themes is not marked as required the user is always bound to select some theme because there is no "empty" option. For other condition plugins there is a workaround. For instance for Node bundle plugin you can uncheck all content types so the condition will always evaluate to TRUE. Same for User role condition plugin. And for Request path you can leave empty pages textarea.

Proposed resolution

Add "- Any -" option to theme select list of the plugin configuration form.

Enable current theme condition on block, because was removed on issue https://www.drupal.org/project/drupal/issues/2339151

API changes

The current theme condition is available on blocks and now there is a new option "- Any -" on the options.

Configure theme condition on blocks

Steps to reproduce:

  • Edit/create a new block on Structure/Block Layout
  • The current theme is not visible
  • Apply the patch
  • The current theme is available
    Configure theme condition on blocks
  • There is a list of enabled themes to choose where to show the block with the "- Any -" condition. and is possible to negate the condition
    List conditional theme

Fatal error: Uncaught TypeError: Drupal\Core\Extension\ThemeHandler::addTheme()

$
0
0

Problem/Motivation

Error was introduced in the 10.3.6 release of Drupal.

Fatal error: Uncaught TypeError: Drupal\Core\Extension\ThemeHandler::addTheme(): Argument #1 ($theme) must be of type Drupal\Core\Extension\Extension, null given, called in /var/www/html/core/lib/Drupal/Core/Extension/ThemeHandler.php on line 74 and defined in /var/www/html/core/lib/Drupal/Core/Extension/ThemeHandler.php:84

Steps to reproduce

Update drupal to version 10.3.6 using compser
Run drush updb

Config entities that have IDs which are built from other properties should update those properties when the ID changes

$
0
0

Problem/Motivation

#3481695: Entity displays cloning requires special config action extended the cloneAs config action to allow stuff like this:

core.entity_view_display.node.page.default:
  cloneAs: node.blog.full

In that issue, we modified EntityDisplayBase::set() so that, if the entity's ID is changed, the other properties which are derived from that ID (or, rather, used to build the ID) are updated too.

The problem is, we only did that for entity displays. There are other config entities that follow a similar pattern, where the ID relates to other properties in a meaningful way -- fields and their storages leap to mind. We should maybe generalize the logic of entity view displays so that it works for all config entities that are structured like that.

Add a default Content-Security-Policy-header for svg files

$
0
0

Problem/Motivation

People want to use SVGs on their websites. Unfortunately SVGs are a security disaster as they allow embedded CSS and JS. Which means that allowing users to upload SVGs should be viewed in the same was as allowing them to upload JS or create inline JS. That is to say that permission to do that should be require a permission that has a security warning.

Here is a really good article about SVGs - https://www.owasp.org/images/0/03/Mario_Heiderich_OWASP_Sweden_The_image... - the tldr; is

Allowing SVG for upload == allowing HTML for upload

Proposed resolution

Requiring additional permissions to upload SVGs is probably not going to happen since we don't have that type of granular permissions on fields. Also people want to make image styles play nice with SVGs - see #2652138: Image styles do not play nicely with SVGs.

Maybe we can leverage the content security policy header to prevent this. This is how github does it - see https://github.com/github/markup/issues/289.

Remaining tasks

Add Content Security Policy headers for SVGs using .htaccess and web.config
Consider adding warning to image fields when people allow SVGs to be uploaded.

User interface changes

None

API changes

None

Data model changes

None

Viewing all 294542 articles
Browse latest View live