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

Warning: Illegal offset type in ContentEntityStorageBase->getFromPersistentCache()

$
0
0

When I add add {{ drupal_view('bijbehorende_producten', 'block_1', field_producttype_1 )}} in my view I get the warning below, Only after saving the view or clearing the cache. Without an argument it does not give any errors

Not sure if the fault lives here or somewhere else as I found a related issue.

Warning: Illegal offset type in Drupal\Core\Entity\ContentEntityStorageBase->getFromPersistentCache() (line 591 of core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php).
Drupal\Core\Entity\ContentEntityStorageBase->getFromPersistentCache(Array) (Line: 396)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->doLoadMultiple(Array) (Line: 242)
Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array) (Line: 507)
Drupal\Core\Entity\Entity::loadMultiple(Array) (Line: 19)
Drupal\taxonomy\Plugin\views\argument\IndexTid->titleQuery() (Line: 153)
Drupal\views\Plugin\views\argument\ManyToOne->title() (Line: 976)
Drupal\views\Plugin\views\argument\ArgumentPluginBase->getTitle() (Line: 1099)
Drupal\views\ViewExecutable->_buildArguments() (Line: 1254)
Drupal\views\ViewExecutable->build(NULL) (Line: 1378)
Drupal\views\ViewExecutable->execute(NULL) (Line: 1441)
Drupal\views\ViewExecutable->render() (Line: 2391)
Drupal\views\Plugin\views\display\DisplayPluginBase->preview() (Line: 1649)
Drupal\views\ViewExecutable->preview('block_1', Array) (Line: 63)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func(Array, Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 474)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 94)
__TwigTemplate_24cdf5df7d7fb14a7ef085dd4347a3d935fd098fbc4a8818edf1079f09f7cb21->doDisplay(Array, Array) (Line: 432)
Twig_Template->displayWithErrorHandling(Array, Array) (Line: 403)
Twig_Template->display(Array) (Line: 411)
Twig_Template->render(Array) (Line: 116)
Drupal\Core\Template\TwigEnvironment->renderInline('{# inline_template_start #}

{{ field_productfoto }} 
{{ title }}
{{ body }}


Ingrediënten
{{ field_ingredienten }}






{# Match integer #}
{% if field_producttype_1 matches '/^\\d+$/' %}
{{ drupal_view('bijbehorende_producten', 'block_1', field_producttype_1 )}}
{% endif %}

', Array) (Line: 52)
Drupal\Core\Render\Element\InlineTemplate::preRenderInlineTemplate(Array)
call_user_func(Array, Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array, 1) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, 1) (Line: 151)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 152)
Drupal\Core\Render\Renderer->renderPlain(Array) (Line: 407)
Drupal\views\Plugin\views\PluginBase->viewsTokenReplace('

{{ field_productfoto }} 
{{ title }}
{{ body }}


Ingrediënten
{{ field_ingredienten }}






{# Match integer #}
{% if field_producttype_1 matches '/^\\d+$/' %}
{{ drupal_view('bijbehorende_producten', 'block_1', field_producttype_1 )}}
{% endif %}

', Array) (Line: 1345)
Drupal\views\Plugin\views\field\FieldPluginBase->renderAltered(Array, Array) (Line: 1238)
Drupal\views\Plugin\views\field\FieldPluginBase->renderText(Array) (Line: 1173)
Drupal\views\Plugin\views\field\FieldPluginBase->advancedRender(Object) (Line: 224)
template_preprocess_views_view_field(Array, 'views_view_field', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('views_view_field', Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 1736)
Drupal\views\Plugin\views\field\FieldPluginBase->theme(Object) (Line: 765)
Drupal\views\Plugin\views\style\StylePluginBase->elementPreRenderRow(Array)
call_user_func(Array, Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 713)
Drupal\views\Plugin\views\style\StylePluginBase->renderFields(Array) (Line: 580)
Drupal\views\Plugin\views\style\StylePluginBase->renderGrouping(Array, Array, 1) (Line: 466)
Drupal\views\Plugin\views\style\StylePluginBase->render(Array) (Line: 2117)
Drupal\views\Plugin\views\display\DisplayPluginBase->render() (Line: 1520)
Drupal\views\ViewExecutable->render() (Line: 171)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1617)
Drupal\views\ViewExecutable->executeDisplay('page_1', Array) (Line: 78)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func(Array, Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 149)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 652)
Drupal\Core\DrupalKernel->handle(Object) (Line: 22)

`link` fields in REST, JSON:API and GraphQL cannot be rendered by client

$
0
0

Problem/Motivation

Link fields and menu links are output in JSON:API in the following format:

"field_link": [
  {
    "uri": "internal:/",
    "title": "Home",
    "options": [
    ]
  },
  {
    "uri": "entity:node/5",
    "title": "News Center",
    "options": [
    ]
  }
]

This isn't very useful for anything consuming the API because it needs to process these links. In most cases the data can't be fetched because it's unknown what node type is being referenced, and so which endpoint to query is unknown. If this was known, then it would require a lot of unnecessary requests to get the links from various bundle endpoints.

Proposed resolution

Add a computed full_url property at \Drupal\link\Plugin\Field\FieldType\LinkItem::propertyDefinitions()

"field_link": [
  {
    "uri": "internal:/",
    "full_url": '/'"title": "Home",
    "options": [
    ]
  },
  {
    "uri": "entity:node/5",
    "full_url": '/node/5'"title": "News Center",
    "options": [
    ]
  }
]

Remaining tasks

Review.
RTBC

User interface changes

None

API changes

An additional property full_url is added to the link item.

Data model changes

Adds a new computed field so no change in the data model.

Release notes snippet

A new property full_url has been added to the link field to access the generated URL.

Edit.: The new field was going to be called just url but it caused some twig override issues (see #22,#26,#27 so full_url was used instead as suggested in #67)

Drupal 9 and 10's Drupal\Component composer.json files are totally out of date

$
0
0

Problem/Motivation

Drupal's components (in the namespace Drupal\Component) all have composer.json files for #1826054: [Meta] Expose Drupal Components outside of Drupal.

For example, here's the Annotation component's composer.json:

{
  "name": "drupal/core-annotation",
  "description": "Annotation discovery and implementation of plugins.",
  "keywords": ["drupal"],
  "homepage": "https://www.drupal.org/project/drupal",
  "license": "GPL-2.0-or-later",
  "require": {
    "php": ">=7.3.0",
    "doctrine/annotations": "^1.4",
    "drupal/core-file-cache": "^8.8",
    "drupal/core-plugin": "^8.8",
    "drupal/core-utility": "^8.8"
  },
  "autoload": {
    "psr-4": {
      "Drupal\\Component\\Annotation\\": ""
    }
  }
}

There are several problems with this:

  1. The PHP version requirement is wrong. Drupal core requires PHP 8.1, so PHP 8.1 syntax may appear in the core components at any time.
  2. The constraint for Doctrine is out of date for D10; 10.0.x requires ^1.12.
  3. The specified versions of other components are also wrong and/or broken. Very bad things would certainly happen if you tried to install the 8.8.x version of the Plugin component with parts of Drupal 10. I think the most we could guarantee is that they work with each other within the same major version. (Actually, this means they're all incorrect in Drupal 9 too, because they say ^8.8 rather than ^8.8 || 9.)

There is also no set of expectations anywhere that I could find about the support, BC, and ugprade path policies of the theoretical standalone packages that would come from these composer.json files. Nor has anyone reported the D9 components' packages being broken with unresolvable dependencies.

Proposed resolution

Either get rid of these files, or come up with a way to make them maintainable.

  • One possibility is to write a script or something that at least updates them automatically for when a new major version is branched.
     

  • That's still not a complete solution because they also would potentially need to be updated every time core increases a requirement for an external dependency they have a constraint on, which could happen in any minor or patch release.
     

  • Additionally, the external dependencies would need to be updated between releases. For example, doctrine/annotation is going bye-bye in Drupal 10. (TBD whether this component will go along with it, or just be rewritten for the PHP attributes implementation, but other for other components it'd be easy to miss that removing a use statement might also mean needing to update the composer.json file.)

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Release notes snippet

Drupal's Component packages are now semi-automated from drupal/drupal's update script.

The drupal/drupal dev repo now reconciles components' dependencies with those of drupal/core and drupal/drupal during a Composer update command.

This means that dependency constraints declared in the components will always follow the needs of Drupal core.

This step is taken to ease maintainership of these components.

Scaffold ReplaceOp::copyScaffold() throws an error for empty files

$
0
0

Problem/Motivation

If you scaffold an empty file, (one which exists in the source directory, but has length=0), the scaffold plugin throws an error.

Steps to reproduce

Proposed resolution

ReplaceOp::copyScaffold() says this:

    $success = file_put_contents($destination->fullPath(), $this->contents());
    if (!$success) {
      throw new \RuntimeException($interpolator->interpolate("Could not copy source file <info>[src-rel-path]</info> to <info>[dest-rel-path]</info>!"));
    }

file_put_contents() can return 0 for the length of the written file, or FALSE on failure. Since we're checking for !$success, we generate an error in either case.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Allow image style to be selected in Text Editor's image dialog (necessary for structured content)

$
0
0

Updated: Comment #212

Problem/Motivation

Inserting an image in the text editor dialog today allows the user to fiddle with image dimensions. It doesn't even have aspect ratio locking.

It's not great for the authoring experience nor for structured content reasons that users are defining the specific dimensions of every single image they insert. It'd be much better to allow them to choose from image styles — just like we do for image fields.

Proposed resolution

Allow an image style to be selected in the image dialog, which gets stored in a data-image-style attribute, and is handled by a yet-to-be-added imagestyle filter.

Remaining tasks

  1. Initial patch: select image style in dialog, inserting that sets a data- attribute, and a filter transforms the end result.
  2. Get #1589176-4: Follow-up: Use data-* to store #states api informations— a blocker to this patch — committed.

User interface changes

  • The new ability to select an image style.
  • A new filter.

API changes

None.

Update phpstan/phpstan and mglaman/phpstan-drupal to latest versions

$
0
0

Problem/Motivation

phpstan/phpstan 1.7.1 is out and gives some performance improvement. However, per https://github.com/phpstan/phpstan/releases/tag/1.7.0,

Analysed code is no longer executed, except for files referenced in bootstrapFiles and files sections in Composer autoload configuration

this means that constants defined via define() no longer are scanned, and that our PHPUnit-Bridge version dance confuses PHPStan so we need to replicate that dance in a bootstrap file for PHPStan.

Also mglaman/phpstan-drupal has a new version released.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[META] Make Drupal 9/10 compatible with PHP 8.2

$
0
0

Problem/Motivation

PHP 8.2 is due 24 November 2022 as per https://github.com/php/php-src/milestone/4. Alpha versions are expected soon. Drupal core must be compatible with it in 9.5 and 10.0 as much as possible.
The release schedule is https://wiki.php.net/todo/php82 - at July 21 is beta1 with frozen API version should be available.
Starting with September 1 final polishing went to Release Candidate phase

Steps to reproduce

Compile PHP 8.2 locally and run a site to reproduce any errors. Once alpha releases become available, this will become easier.

Proposed resolution

See child issues.

When PHP 8.2 is available as a reasonable pre-release to begin testing with, 'un-postpone' this DrupalCI issue to create the environment:
#3283449: Create a DrupalCI Environment for PHP 8.2

Remaining tasks

See if we need more child issues. Fix the child issues.

User interface changes

N/A

API changes

See child issues.

Data model changes

N/A

Release notes snippet

TBD

Add ability to use Quick Edit to the latest_revision route

$
0
0

Problem/Motivation

At the moment, Content Moderation and Quick Edit are incompatible. Quick edit is not integrated into revisions of entities that are the latest revision.

For example, enable moderation on an entity bundle, publish a draft, then create a new draft of that entity, visit the latest version tab witness the lack of quickedit options.

You can view a screencast showcasing the current problems here: https://www.youtube.com/watch?v=gvnXaT7HCeU

Proposed resolution

There are a number of steps that need to happen to make these modules work together:

  1. Load the latest revision of an entity for routes that deliver quickedit form components.
  2. Ensure that Contextual Links display on the latest revision of a Node. Otherwise Quick Edit will be inaccessible to users.

Latest patch in action:

Remaining tasks

Review the provided patch.

  1. Create a follow up to add configuration form to Quick Edit or Content Moderation that restricts user's ability to edit content in certain states. (I think the existing permissions already cover this?)

User interface changes

Additional edit and quick edit contextual links rendered on the latest version of an entity.

API changes

An additional contextual link "group" exclusively for the latest version of an entity.

Data model changes

None.


A serial/primary key field can not be added to an existing table for some databases

$
0
0

Problem/Motivation

- DBTNG does not support adding a serial field to an existing table, even if all the supported DB engines can do that just fine
- DBTNG does not handle primary keys properly when adding a new field to an existing table. \Drupal\Core\Database\Schema::changeField() documents that primary keys have to be handled manually by the calling code, but \Drupal\Core\Database\Schema::addField() documents that it handles primary keys by itself.

Proposed resolution

Fix DBTNG to support adding a serial field to an existing table.

Fix implementations of \Drupal\Core\Database\Schema::addField() to handle primary key changes automatically.

Remaining tasks

Review.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Can't specify the language in TermStorage::loadTree

$
0
0

I've a multi language website but when I try to get terms using loadTree, I got terms with its default language

Changing the Alt Text for Media Thumbnail Changes the Image Filename

$
0
0

Problem/Motivation

We're using Drupal 8.9.20. We are trying to change the alt text for our images from the Content > Media > Image page. However, after changing the alt text successfully on the image, the images is replaced with a different thumbnail entirely.

Steps to reproduce

1. Go to Content > Media > Image
2. Upload a file and set the alt text (see screenshot: initial-upload.png)
3. Click Save
4. Edit the file and change the alt text
5. Click Save
6. The alt text is updated but the media filename changes from the original filename (see screenshot: after-alt-edit.png)

migration crashes if a change to the migration has required a change to the map table

$
0
0

Problem/Motivation

I created a migration with the destination set like this:

destination:
  plugin: entity:node

I ran the migration, and realised I needed to configure it correctly for translations! So I changed it to:

destination:
  plugin: entity:node
  translations: true

I ran the migration again, and it crashed with:

[error]  SQLSTATE[42S22]: Column not found: 1054 Unknown column 'destid2' in 'field list': UPDATE {migrate_map_test_node} SET sourceid1=:db_update_placeholder_0, sourceid2=:db_update_placeholder_1, sourceid3=:db_update_placeholder_2, source_row_status=:db_update_placeholder_3, rollback_action=:db_update_placeholder_4, hash=:db_update_placeholder_5, destid1=:db_update_placeholder_6, destid2=:db_update_placeholder_7
WHERE source_ids_hash = :db_condition_placeholder_0; Array
(
    [:db_update_placeholder_0] => 9
    [:db_update_placeholder_1] => 18
    [:db_update_placeholder_2] => en
    [:db_update_placeholder_3] => 0
    [:db_update_placeholder_4] => 1
    [:db_update_placeholder_5] =>
    [:db_update_placeholder_6] => 9
    [:db_update_placeholder_7] => en
    [:db_condition_placeholder_0] => 4cb145ab98671627a0b10c88decd26a045f4f6c6a6c6a77daf9af6bece13e312

This is presumably because with translations enabled, the map table needs an extra key.

Steps to reproduce

Proposed resolution

- Simplest fix: catch this sort of DB error and re-throw an exception which explains the problem more clearly: Something in the migration has caused a change in the structure of the map table and you need to deal with it manually.
- Perfect fix: adjust the map table automatically when this happens

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

TypeError: Argument 1 passed to Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer

$
0
0

I already reported this for various versions in the past, but never got a solution. Now I installed a complete new 9.1.x Drupal site with a new database and migrated my whole content to the new installation.

Today I upgraded to 9.2.0 and the error is back! :(

I have 7 outstanding DB upgrades, but I only get this in the log:

TypeError: Argument 1 passed to Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer::renderBarePage() must be of the type array, bool given, called in /home/.sites/136/site1497/web/core/modules/system/src/Controller/DbUpdateController.php on line 195 in Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer->renderBarePage() (Zeile 73 in /home/.sites/136/site1497/web/core/lib/Drupal/Core/ProxyClass/Render/BareHtmlPageRenderer.php)
#0 /home/.sites/136/site1497/web/core/modules/system/src/Controller/DbUpdateController.php(195): Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer->renderBarePage(false, Object(Drupal\Core\StringTranslation\TranslatableMarkup), 'maintenance_pag...', Array)
#1 [internal function]: Drupal\system\Controller\DbUpdateController->handle('core', Object(Symfony\Component\HttpFoundation\Request))
#2 /home/.sites/136/site1497/web/core/lib/Drupal/Core/Update/UpdateKernel.php(114): call_user_func_array(Array, Array)
#3 /home/.sites/136/site1497/web/core/lib/Drupal/Core/Update/UpdateKernel.php(75): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request))
#4 /home/.sites/136/site1497/web/update.php(27): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#5 {main}

The DB upgrades are NOT done.

I am sure that I am not the only one with this problem. And it does not help closing this issue and pointing to a different one where also no solution is provided. My site is in maintenance mode after going to /update.php, but the updates are NOT done.

So PLEASE, help me/us to solve this isse as it is very annoying when to DB upgrades are possible.

If there is no fix for it - how can I do the DB upgrades by hand?

Thanks a lot for your help!

Media Library filtering by user not possible

$
0
0

Problem/Motivation

Users can see all media files from all other users when creating content that has a 'Media' field using the Media Library widget.
The issue is this, my current project is expecting a little over 100 users at launch, and if things go well, it could go into the thousands.
When user 101 goes to add content and the select the field to upload the Media Library will show all images/files from all of the other users, it could be over 500 items to scroll through. Now, all of the images/files will all be public, the issue is that the user should only see/work with their files. If the site does reach 1000+ users, it will be an absolute nightmare for a user to find their content. Plus, I would not want a user to reuse someone else's content/media as a rule.

Also, the overhead of having to load all of those images seems to me would be an issue as the site user count increases.

Fixes tried:
Create content by three different users
Added a contextual filter of 'Author by' to (Media Library) views on all pages, this will filter the view on /admin/content/media but in the content type it shows no results when browsing media. Removing the contextual filters will show all content from all users.

Steps to reproduce

  1. Create a content type
  2. Add 'Media' field
  3. Set 'Manage Form Display' widget for Media field to "Media Library"
  4. Create content for new content type, add media files to field.
  5. Do this for two other users, the content from all three users will be available to each one.

Proposed resolution

The default behavior should be for the Media Library browser to auto filter by user logged in.
Only the content the logged in user has uploaded should be visible to the user.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

ResourceResponse should document that the route it is used with must define the _format requirement

$
0
0

Problem/Motivation

If you return a \Drupal\rest\ResourceResponse from a custom route, you get a crash:

> TypeError: Symfony\Component\Serializer\Encoder\ChainEncoder::getEncoder(): Argument #1 ($format) must be of type string, null given, called in /var/www/vendor/symfony/serializer/Encoder/ChainEncoder.php on line 49 in Symfony\Component\Serializer\Encoder\ChainEncoder->getEncoder() (line 80 of /var/www/vendor/symfony/serializer/Encoder/ChainEncoder.php).

This is because ResourceResponseSubscriber::getResponseFormat() looks at the route definition for the _format requirement. If that is missing, then a NULL is incorrectly passed as a parameter.

Steps to reproduce

Proposed resolution

Add documentation to \Drupal\rest\ResourceResponse to say the route needs this requirement to be set.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput()

$
0
0

Problem/Motivation

Numeric views filter (\Drupal\views\Plugin\views\filter\NumericFilter) and all child filters (Date, SearchApiDate, etc) throw a php notice when using grouped exposed filters with a group identifier that doesn't match the filter identifier.

Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput()

Since PHP 8 this is upgraded to an error:

TypeError: Cannot access offset of type string on string in Drupal\views\Plugin\views\filter\Date->acceptExposedInput()

Steps to reproduce

(require updates)

  1. Install Drupal standard profile
  2. Edit the default Content view at /admin/structure/views/view/content
  3. Add a "Changed" filter
  4. Select "Expose this filter to visitors, to allow them to change it"
  5. Select "Grouped filters"
  6. Change the "Filter identifier" to "date"
  7. Set the Grouping 1 label to "Last week", operator to "Is greater than", value type to "An offset from ..." and value "-7 days"
  8. Press Apply and then Save
  9. Navigate to /admin/content
  10. Set the "Changed" filter to "Last week" and press "Filter".

Proposed resolution

Update \Drupal\views\Plugin\views\filter\NumericFilter::acceptExposedInput to target the exposed group identifier as per patch in #48.

Remaining tasks

  1. Add an automated test;

Provide Olivero theme settings to control the behaviour of the header regions

$
0
0

Problem/Motivation

Olivero provide theme customisation settings for the header regions, specifically "Enable mobile menu at all widths" and "Header site branding background color", however it does not currently provide settings to control the behaviour of the header with respect to whether it is fixed to the top of the screen or not, and whether it will collapse or always stay expanded.

Specifically, it would be useful if the theme settings to:

  1. Enable or disable whether the header is fixed to the top of the screen while the user scrolls.
  2. Enable or disable the behaviour of the header collapsing and expanding as the user scrolls. Additionally, some sites may want to completely remove the button/link next to the site branding which expands and collapses the header, or they may want to keep this but just stop the automatic expanding/collapsing behaviour.

Having control over these behaviours would be a nice addition.

Steps to reproduce

Proposed resolution

Remaining tasks

Decide if these options should be provided, if so whether it is one toggle or multiple toggles, then implement.

User interface changes

API changes

Data model changes

Release notes snippet

PostgreSQL: Impossible to change a field to serial, bigserial, or numeric

$
0
0

When upgrading a field / changing it's type using pgsql:changeField, it's impossible to make a field a serial, bigserial, or numeric. This appears to be because of confusion between the typecast that is required to do the data-conversion and the field-type we are creating. As is currently stands, pgsql:changeField() is forcing serial, bigserial, or numeric to be int.

We found this issue because of this contrib issue: #1657910: Field type update fails in PostgreSQL

Related to this, is that there should better logic around when we need to force explicit casting with a USING statement. It's not always required, and we shouldn't use it unless we need to.

PhpMail : broken mail headers in PHP 8.0+ because of LF characters

$
0
0

Problem/Motivation

Originally, the email sent by the Webform module was delivered as plain text instead of HTML. It turns out the mail headers were broken for no reasons, one space was added before every header line :

MIME-Version: 1.0
 Content-Type: text/html; charset=UTF-8; format=flowed
 Content-Transfer-Encoding: 8Bit
 X-Mailer: Drupal
 Return-Path: <****>
 Sender: ****
 From: =?utf-8?Q?Th=C3=A9=C3=A2tre?= du Jorat <info@theatredujorat.ch>
 Reply-to: ****

After some researches, Webform is not guilty, and everything is running fine until the call to Drupal\Core\Mail\Plugin\Mail\PhpMail :

    // For headers, PHP's API suggests that we use CRLF normally,
    // but some MTAs incorrectly replace LF with CRLF. See #234403.
    $mail_headers = str_replace("\r\n", "\n", $headers->toString());
    $mail_subject = str_replace("\r\n", "\n", $mail_subject);

If I understand correctly, the "mail" function is replacing CRLF characters by LF characters, because some MTA may misinterpret CRLF and convert CRLF into CRCRLF.

This trick is working fine with PHP 7.4, but from PHP 8.0 and beyond, it is causing this problem, as also reported here : https://stackoverflow.com/questions/70502065/php8-mail-function-adding-s...

This PHP issue may also be related, as it is mentioned to work with PHP 7.4 but not on PHP 8.0, because of LF char in headers : https://github.com/php/php-src/issues/7902 .

A comment on PHP bug tracker also seems to enforce the fact that PHP 8 would not be tricky-compliant : https://bugs.php.net/bug.php?id=81158

The fix for the bug, which has been reported more than ten years
ago, had deliberately been delayed to PHP 8 (a new major version).
It should probably get a changelog entry, but I am against
reverting this fix. If your mail software replaces CRLF with
CRLFCRLF, or whatever, in mail headers, consider to report that
bug upstream.

I can confirm this behavior is happening on PHP 8.0 and 8.1, but not on PHP 7.4. My MTA is Exim 4.92 but it may not be related.

Steps to reproduce

Use Mailsystem through PhpMail implementation with custom mail headers. Show the source of the received mail, there is a space before each header line.

Proposed resolution

Remove the trick :

    $mail_headers = $headers->toString();

or ensure the line ending are CRLF characters by using implode and CRLF characters.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

#states Does Not Work Directly on Table Elements

$
0
0

Problem/Motivation

When a form contains a table, that table does not properly handle the #states property. As a workaround, the table can be wrapped in a container element type, but that shouldn't be necessary.

In digging into the code, it appears that FormHelper::processStates() gets invoked for all render elements, including tables, and the <table> HTML element is rendered with a data-drupal-states HTML attribute. In addition, states.js does process the behavior and sets up all the triggers. It seems like the issue is that states.js uses jQuery to find the nearest '.js-form-item, .js-form-submit, .js-form-wrapper' wrapper around the table, which it does not find. This causes the behavior not to work.

Steps to reproduce

  1. Create a form like this in a custom module:
    
    namespace Drupal\my_module\Form;
    
    use Drupal\Core\Form\FormBase;
    use Drupal\Core\Form\FormStateInterface;
    
    class SomeForm extends FormBase {
    
      public function getFormId(): string {
        return 'repro_form';
      }
    
      public function buildForm(array $form,
                                FormStateInterface $form_state): array {
        $form['required'] = [
          '#type'          => 'checkbox',
          '#title'         => $this->t('Check me'),
          '#default_value' => FALSE,
        ];
    
        $form['some_textfield'] = [
          '#type'  => 'textfield',
          '#title' => $this->t('Some field'),
          '#states' => [
            'invisible' => [
              ':input[name="required"]' => [
                'checked' => TRUE,
              ],
            ],
          ],
        ];
    
        $contacts_table = $this->buildContactsTable();
    
        $contacts_table['#states'] = [
          'invisible' => [
            ':input[name="required"]' => [
              'checked' => TRUE,
            ],
          ],
        ];
    
        $form['contacts'] = $contacts_table;
    
        $form['contacts_wrapper'] = [
          '#type'   => 'container',
          '#states' => [
            'invisible' => [
              ':input[name="required"]' => [
                'checked' => TRUE,
              ],
            ],
          ],
          'contacts' => $contacts_table,
        ];
    
        return $form;
      }
    
      protected function buildContactsTable(): array {
        $table = [
          '#type'    => 'table',
          '#caption' => $this->t('Sample Table'),
          '#header'  => [
            $this->t('Name'),
            $this->t('Phone'),
          ],
        ];
    
        for ($i = 1; $i <= 4; $i++) {
          $table[$i]['name'] = [
            '#type'          => 'textfield',
            '#title'         => $this->t('Name'),
            '#title_display' => 'invisible',
          ];
    
          $table[$i]['phone'] = [
            '#type'          => 'tel',
            '#title'         => $this->t('Phone'),
            '#title_display' => 'invisible',
          ];
        }
    
        return $table;
      }
    
      public function submitForm(array &$form, FormStateInterface $form_state) {
        // Do nothing for this sample.
      }
    
    }
    
  2. Create a routing file in the custom module for the form:
    some.form:
      path: '/admin/some-form'
      defaults:
        _form: '\Drupal\my_module\Form\SomeForm'
        _title: 'Demonstrate bugs'
      requirements:
        _access: 'TRUE'
  3. Install the module or clear caches (if module is already installed).
  4. Visit /admin/some-form
  5. Place a checkmark in the "Check me" box.

All the form elements except the checkbox should hide, but the unwrapped table does not.
All the form elements except the checkbox and table are hidden.

Proposed resolution

Either tables should be wrapped automatically by some class that states.js recognizes, or states.js should not require a wrapper element to do its work.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Viewing all 296561 articles
Browse latest View live


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