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

Introduce a Connection::executeDdlStatement method

$
0
0

Problem/Motivation

If a database does not support transactional DDL, executing statements that alter the database structure in the midst of a transaction lead to the transaction to self-commit.

In our data processing layer, this is less of an edge case than we may think, especially since when we have started creating tables dynamically and not via the hook_schema() called at installation time.

While PostgreSql and SQLite allow transactional DDL, MySQL does not. In the current PDO MySQL driver we can adjust (=reset) the transaction stack when this happens, because it allows to detect if a transaction is active on the client directly. However, in the to-be mysqli driver this is not possible because there is not such a method - we will have to try and interpret exceptions (if they are thrown).
In both cases, though, this would be reactive rather than proactive.

Proposed resolution

1) Introduce a Connection::executeDdlStatement method that, in case of unsupported transactional DDL, will reflect in Drupal's transaction stack that a commit in an active client transaction occurred and make the necessary adjustments in TransactionManager so that the Transaction objects going out of scope do not try to perform database operations. In other words, after execution of the DDL statement, there is NO Drupal transaction active.

2) Change in the Schema classes the Connection::query calls that execute DDL to use Connection::executeDdlStatement instead.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Uncaught ajax.js error / exception

$
0
0

Problem/Motivation

When adding fields of type "Reference" and some other types to a content type, the message "Oops, something went wrong. Check your browser's developer console for more details." is generated, with an accompanying "Uncaught" exception in the console.

  • Windows 11
  • WAMP server running Apache 2.4.57.3, PHP 8.2.13, MySQL 8.0.32
  • Drupal 10.2.0
  • Firefox and Edge as the browser, both showing same behaviour.

Steps to reproduce

Create a new content type A. Create a taxonomy / vocabulary B. Create another content type C. Add a reference field to content type C of type Content. Attempt to pick content type A as the referring type. Error generated.

Add another reference field to content type C of type Taxonomy. Attempt to pick vocabulary B. Error generated.

The error also seems to be generated when attempting to change the display of the label from "Above" to "Inline" after having added a number of fields to content type C:

Uncaught 
Object { message: '\nAn AJAX HTTP error occurred.\nHTTP Result Code: 200\nDebugging information follows.\nPath: /admin/structure/types/manage/project/display?ajax_form=1\nStatusText: OK\nResponseText: [{"command":"settings","settings":{"ajaxPageState":{"theme":"claro","theme_token":"gNBkdUwZ3Dm97PoEDNJJoWphmNujk2zamwW_Vi1zy6U","libraries":"eJx9UkFywyAM_BDGb-hLPDIojlIsUQGepK8vTow7TtJeYLW7Gi2MwM_EQxYJI2i_3TYrooE_JXuWBZU4I-ej7X6n3UxO2ACzFHY4V3caToi-91oiBPuq2K3TjDQNkSL2DRgXQKV1MixdhjFt7BRkhNClfAvEk6lTM15zgdD8v0xXHZ_pf0sL4URxz-oyLXjvPvBOQoCY8EDWaAG9wvSetXCB66ukmKJwqmMe2vrBylW9fBXUmz2Jzg-FK4JA32g8LlifsJ57bOSFVHj91YHYk4Ms2ia9Fc2JMPhhUimxf-BCpoHWugvpLJpdyU1otXlalufaYnIQ8WPdGFMS7qFWfF-W9ANoHABw"},"fieldUIRowsData":{"field-client":{"rowHandler":"field","defaultPlugin":"entity_reference_label","name":"field_client","region":"content"},"field-client-rfx-number":{"rowHandler":"field","defaultPlugin":"string","name":"field_client_rfx_number","region":"content"},"field-description":{"rowHandler":"field","defaultPlugin":"text…', name: "AjaxError", stack: "@http://rp10.local/core/misc/ajax.js?v=10.2.0:196:32\n@http://rp10.local/core/misc/ajax.js?v=10.2.0:1915:3\n" }

Going back to add a new field. Attempted to add a Reference field. As soon as I clicked the radio button, error:

Uncaught 
Object { message: '\nAn AJAX HTTP error occurred.\nHTTP Result Code: 200\nDebugging information follows.\nPath: /admin/structure/types/manage/project/fields/add-field?ajax_form=1\nStatusText: OK\nResponseText: [{"command":"update_build_id","old":"form-AH1mp4QXqU3cjjrjzp4nYqgnBnxM3T8IpHXWBR7t99c","new":"form-NCqER1WPUgYCoXCqXqSDvo5kCCLxd_PCo-3VPafQolc"},{"command":"insert","method":null,"selector":null,"data":"\\u003Cdiv id=\\u0022group-field-options-wrapper\\u0022 class=\\u0022group-field-options-wrapper\\u0022\\u003E\\u003Clabel data-drupal-selector=\\u0022edit-label\\u0022 for=\\u0022edit-label--zUHmO2HZw88\\u0022 class=\\u0022form-item__label js-form-required form-required\\u0022\\u003EChoose an option below\\u003C\\/label\\u003E\\u003Cdiv class=\\u0022group-field-options js-form-wrapper form-wrapper\\u0022 data-drupal-selector=\\u0022edit-fields\\u0022 id=\\u0022edit-fields--8DH0tjsuWA0\\u0022\\u003E\\u003Cdiv class=\\u0022js-click-to-select subfield-option field-suboption__item\\u0022\\u003E\\n    \\u003Cinput class=\\u0022field-option-radio form-radio form-boolean form-boolean--type-radio\\u0022 data-once=\\u0022field-click-to-select\\u0022 data-drupal-selector=\\u0022field-uientity-referencenode\\u0022 aria-describedby=\\u0022field_ui:entity_reference:node--description\\u0022 type=\\u0022radio\\u0022 id=\\u0022field_ui:entity_reference:node\\u0022 name=\\u0022group_field_options_wrapper\\u0022 value=\\u0022field_ui:entity_reference:node\\u0022\\/\\u003E\\n      \\u003Clabel for=\\u0022field_ui:entity_reference:node\\u0022 class=\\u0022form-item__label option\\u0022\\u003EContent\\u003C\\/label\\u003E\\n    \\u003Cdiv id=\\u0022field_ui:entity_reference:node--description\\u0022\\u003E\\n      \\u003Cdiv class=\\u0022item-list\\u0022\\u003E\\u003Cul\\u003E\\u003C\\/ul\\u003E\\u003C\\/div\\u003E\\n    \\u003C\\/div\\u003E\\n    \\u003C\\/div\\u003E\\n\\u003Cdiv class=\\u0022js-click-to-select subfield-option field-suboption__item\\u0022\\u003E\\n    \\u003Cinput class=\\u0022field-option-radio form-radio form-boolean form-boolean--type-radio\\u0022 data-once=\\u0022field-click-to-select\\u0022 data-drupal-selector=\\u0022field-uientity-referencetaxonomy-term\\u0022 aria-describedby=\\u0022field_ui:entity_reference:taxonomy_term--description\\u0022 type=\\u0022radio\\u0022 id=\\u0022field_ui:entity_reference:taxonomy_term\\u0022 name=\\u0022group_field_options_wrapper\\u0022 value=\\u0022field_ui:entity_reference:taxonomy_term\\u0022\\/\\u003E\\n      \\u003Clabel for=\\u0022field_ui:entity_reference:taxonomy_term\\u0022 class=\\u0022form-item__label option\\u0022\\u003ETaxonomy term\\u003C\\/label\\u003E\\n    \\u003Cdiv id=\\u0022field_ui:entity_reference:taxonomy_term--description\\u0022\\u003E\\n      \\u003Cdiv class=\\u0022item-list\\u0022\\u003E\\u003Cul\\u003E\\u003C\\/ul\\u003E\\u003C\\/div\\u003E\\n    \\u003C\\/div\\u003E\\n    \\u003C\\/div\\u003E\\n\\u003Cdiv class=\\u0022js-click-to-select subfield-option field-suboption__item\\u0022\\u003E\\n    \\u003Cinput class=\\u0022field-option-radio form-radio form-boolean form-boolean--type-radio\\u0022 data-once=\\u0022field-click-to-select\\u0022 data-drupal-selector=\\u0022field-uientity-referenceuser\\u0022 aria-describedby=\\u0022field_ui:entity_reference:user--description\\u0022 type=\\u0022radio\\u0022 id=\\u0022field_ui:entity_reference:user\\u0022 name=\\u0022group_field_options_wrapper\\u0022 value=\\u0022field_ui:entity_reference:user\\u0022\\/\\u003E\\n      \\u003Clabel for=\\u0022field_ui:entity_reference:user\\u0022 class=\\u0022form-item__label option\\u0022\\u003EUser\\u003C\\/label\\u003E\\n    \\u003Cdiv id=\\u0022field_ui:entity_reference:user--description\\u0022\\u003E\\n      \\u003Cdiv class=\\u0022item-list\\u0022\\u003E\\u003Cul\\u003E\\u003C\\/ul\\u003E\\u003C\\/div\\u003E\\n    \\u003C\\/div\\u003E\\n    \\u003C\\/div\\u003E\\n\\u003Cdiv class=\\u0022js-click-to-select subfield-option field-suboption__item\\u0022\\u003E\\n    \\u003Cinput class=\\u0022field-option-radio form-radio form-boolean form-boolean--type-radio\\u0022 data-once=\\u0022field-click-to-select\\u0022 data-drupal-selector=\\u0022entity-reference\\u0022 aria-describedby=\\u0022entity_reference--description\\u0022 type=\\u0022radio\\u0022 id=\\u0022entity_reference\\u0022 name=\\u0022group_field_options_wrapper\\u0022 value=\\u0022entity_reference\\u0022\\/\\u003E\\n      \\u003Clabel for=\\u0022entity_reference\\u0022 class=\\u0022form-item__label option\\u0022\\u003EOther\\u003C\\/label\\u003E\\n    \\u003Cdiv id=\\u0022entity_reference--description\\u0022\\u003E\\n      \\u003Cdiv class=\\u0022item-list\\u0022\\u003E\\u003Cul\\u003E\\u003C\\/ul\\u003E\\u003C\\/div\\u003E\\n    \\u003C\\/div\\u003E\\n    \\u003C\\/div\\u003E\\n\\u003C\\/div\\u003E\\n\\u003C\\/div\\u003E","settings":null}', name: "AjaxError", stack: "@http://rp10.local/core/misc/ajax.js?v=10.2.0:196:32\n@http://rp10.local/core/misc/ajax.js?v=10.2.0:1915:3\n" }
ajax.js:196:32

Click submit, get error that type wasn't chosen, and now selection is enabled below. Pick "User", submit, get to the next screen, attempt to choose "Name" by which to sort, get error:

Uncaught 
Object { message: "\nAn AJAX HTTP error occurred.\nHTTP Result Code: 500\nDebugging information follows.\nPath: /admin/structure/types/manage/project/add-field/node/field_project_manager?destinations%5B0%5D%5Broute_name%5D=entity.node.field_ui_fields&destinations%5B0%5D%5Broute_parameters%5D%5Bentity_type%5D=node&destinations%5B0%5D%5Broute_parameters%5D%5Bfield_name%5D=field_project_manager&destinations%5B0%5D%5Broute_parameters%5D%5Bnode_type%5D=project&destinations%5B1%5D=/admin/structure/types/manage/project/fields/add-field\nStatusText: 500 Service unavailable (with message)\nResponseText: The website encountered an unexpected error. Try again later", name: "AjaxError", stack: "@http://rp10.local/core/misc/ajax.js?v=10.2.0:196:32\n@http://rp10.local/core/misc/ajax.js?v=10.2.0:1915:3\n" }
ajax.js:196:32

Flushing all caches does not help.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Add configurable description to content type title field.

$
0
0

Problem/Motivation

All fields have configurable description but not the title field. Also the title field will have configurable display once https://www.drupal.org/project/drupal/issues/2923701 gets merged. I think we should also provide a configurable description for the title field.

Proposed resolution

Create a new Content-Type Title Description field, which allows us to add a configurable help text/description for the title field.

Remaining tasks

  • Merge Code

Steps to reproduce/Testing steps

1. Goto admin/structure/types/manage/basic page

2. Observe that the title description field is absent.

3. Apply the patch.

4. Reload.

5. Observe that the title description field has been added.


User interface changes

New configuration Title Description field has been added for Content-Type

API changes

Data model changes

Release notes snippet

Cannot update database because 'module is too old'

$
0
0

Problem/Motivation

Upgraded core to 9.0.5, which went well but,

When executing database update, I receive the message

The installed version of the <em class="placeholder">Responsive Image</em> module is too old to update. Update to a version prior to 9.0.0 first (missing updates: responsive_image_post_update_recreate_dependencies).

I have no idea how to do that, and am a bit worried to break my site if I try things out. Any suggestions?

Steps to reproduce

Proposed resolution

For an understanding of the problem read #19

Remaining tasks

Provide complete steps to reproduce the issue (starting from "Install Drupal core").

User interface changes

API changes

Data model changes

Release notes snippet

Inject the display plugin manager into the view and view factory

$
0
0

Problem/Motivation

Replace calls of Views::pluginManager('display') and replace with injected service plugin.manager.views.display in \Drupal\views\ViewExecutable and \Drupal\views\ViewExecutableFactory

Steps to reproduce

NA

Proposed resolution

Properly dependency inject parameter

Remaining tasks

Review code changes and draft CR

User interface changes

NA

API changes

Calling ViewExecutable and ViewExecutableFactory will require an instance of \Drupal::service('plugin.manager.views.display') as their last argument

Data model changes

NA

Release notes snippet

NA

node_access filters out accessible nodes when node is left joined

$
0
0

If you are looking for a D7 version of this, see #3176634: [D7] node_access filters out accessible nodes when node is left joined.

Currently, when a node table is left joined into a query, adding a node_access tag to the query filters out accessible rows from the base table (effectively acting more like an inner join). In particular, rows containing null values are incorrectly filtered out by node_access (i.e., if the base table has null entries for the node ID, node_access denies access to all users based on those null values, even though they should have no relevance to node_access checks). The most common example is a view where rows disappear from the table after adding an optional relationship to the view.

See the tests in patch #326 to reproduce, or manually:
1. enable Views,
2. Create a field referencing nodes
3. Create a node having the entity reference field empty,
4. Create a View with a relationship using the entity reference field. Do NOT select "Require this relationship".
5. Expected result is that regular users can see the node in the View. Current result is that regular users cannot see the node.

Proposed resolution

The problems can be fixed by altering how the node_access conditions are added into the query whenever the node table is a joined table. Currently the conditions are added to the overall query conditions; the proposal is to instead add the node_access conditions into the join conditions.

This approach maintains the integrity of the node_access checks: all nodes to which the current user is denied access are removed from the query results. However, it makes as few additional changes as possible to the query results.

The primary effect is that rows containing optional, empty (null node ID) entries are no longer removed. Furthermore, if rows contain optional (left-joined) content from an access-denied node, only the content of the denied node is removed from the results. In the context of a view, this means that any individual cells of a table containing restricted content will be blanked, but non-restricted content in the rest of the row is still visible to the user.

Remaining tasks

Review the CR for the changes made in #542

Things discussed

  1. Recent questions include:
    1. Is the current patch, which avoids an API change, preferable (see #321)? => Yes
    2. Is it appropriate for a bug-fix patch to incorporate code for a requested feature (see #319)? => No
  2. Write tests. (Patch #326 contains comprehensive tests, including nested joins and all combinations of accessible and restricted content.) This needs tests for #480-3 which Spokje replied to in #489.
  3. In Postgres with 3 node tables and a count query, placeholders are getting inserted in the wrong sequence.(This was an issue for patch #149 but was reported as fixed by a subsequent patch. The current D8 patch doesn't edit the placeholders, and has been tested successfully using PostgreSQL.)
  4. Address issue of node access with a type of "entity" -- no known cases where this bug is triggered, recommend creating new issue.(The entity-specific query alterations have been removed in D8, making the issue no longer relevant.

User interface changes

None

API changes

None

Data model changes

None

Detailed example

As an example, a site has 'page' nodes containing a field that is a reference to a related 'article' node. A view is created to list the page nodes: the page title is shown in the first column; the related article's title is shown in the second column (using an optional relationship). The following is the view as seen by an admin. Any node with 'public' in the title is visible to everyone; any node with 'private' in the title should not be visible to regular users.

Case A: admin view
Page titleArticle title
Public-page-1Public-article-a
Public-page-2[none]
Public-page-3Private-article-b
Private-page-4Private-article-c


With current code, the table shown to non-admins incorrectly removes some rows containing public pages:

Case B: public view, unpatched
Page titleArticle title
Public-page-1Public-article-a


With patch #326, regular users will see:

Case C: public view, patched
Page titleArticle title
Public-page-1Public-article-a
Public-page-2[none]
Public-page-3[none]

All private pages and private articles have been filtered out. Public-page-3 is still displayed because it is public content; the reference to private-article-b is in an optional column, implying that unavailable content should result in a blank cell instead of removing the entire row.

Some users may prefer to construct a view where the entire row is removed if it contains a reference to an inaccessible article. In many cases, such views will simply want to change the article column into a required column. If, however, it is necessary to keep rows with missing articles, and only filter rows with inaccessible articles, users can add the appropriate filter into the view, for example, "where article_title is null AND article_reference is not null". This would produce:

Case D: public view, alternate
Page titleArticle title
Public-page-1Public-article-a
Public-page-2[none]

Different approaches were tried to address all the identified scenario's and the current approach ticks all the boxes.

Original report by [username]

I'm loving the Entity Reference module, but I've come across some weird behavior. It's probably just something I've missed setting.

I have a content type called Album. I've got another content type called Review which has an entity reference to Album.

I've created a View which lists Albums. I wanted to include some fields from my Review content type, but I still want to list each Album, even if a review referencing the album has not been created yet.

In my view, under Relationships, I add an "Entity Reference: Referencing entity" relationship. I make sure "Require this relationship" is NOT checked.

When I'm logged in as an administrator, all Albums are returned, as expected. But when I'm not logged in, or I'm logged in as a regular user, only albums that are referenced by a review are displayed. I'm really puzzled as to why I get different results depending on my user role.

I get the same results regardless of if I add fields from the Review content type or not. I've tried clearing the cache multiple times, and I've tried checking and unchecking the "Require this relationship" box. I've deleted the relationship and tried adding it again, but I always get the same results.

Release notes snippet

Queries with the node_access tag now get the access information joined to the correct table. This means that when joining the node table this data will be added to the correct join. Previously it would get joined on the base table which could cause results that should be visible to disappear. It also means that for queries with multiple joins to the node table there will be additional joins which might lead to longer query run times.

Regression from #3341682: #states + #required do not automatically work together, resulting in an unsubmittable AccountSettingsForm

$
0
0

Problem/Motivation

After changing/modifying any setting within /admin/config/people/accounts, changes to the configuration do not save after selecting "Save configuration" box at the bottom of the page.

Steps to reproduce

Verified the /admin/config/people/accounts section on Drupal version 10.1.7 works properly (can save), but after upgrading to Drupal version 10.2, the /admin/config/people/accounts section does not allow changes to the configuration to be saved.

Re-checked admin privileges for the Configuration Manager/Configuration Translations on Drupal version 10.2, and as an Admin, all permissions were granted (checked).

All other sections within the admin/config menu appear to be working properly (can save).

After upgrading to 10.2, I updated scripts, cleared caches, and rebuilt permissions, along with rebooting server.

Proposed resolution

Remaining tasks

Unknown

User interface changes

API changes

Data model changes

Release notes snippet

File formatter render absolute url to file

$
0
0

Problem/Motivation

Currently, file and image field's field formatter doesn't have support to render/display absolute URL.
ImageUrlFormatter and UrlPlainFormatter classes doesn't have flexibility to display absolute url.

Steps to reproduce

Configure the field formatter and check that we don't have flexibility to render absolute url.

Proposed resolution

- Add an option to both the field formatters.
- Validate option value in viewElements() method and display URL accordingly.
- Add test cases to validate newly added options.

Remaining tasks

Contact Usability for wording of new text in the UI.
- Review MR https://git.drupalcode.org/project/drupal/-/merge_requests/5882 which represents further changes since patch #122

User interface changes

- New option is added on both the field formatters.

File field:

Image field

API changes

- N/A

Data model changes

- N/A

Release notes snippet


Drupal Usability Meeting 2024-01-05

$
0
0

This meeting takes place every Friday at 14:00 UTC (currently 7:00am PT, 10:00am ET). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel 10 minutes before the meeting. Agenda is first come, first serve and set by attendees. Use the Needs usability review issue tag for issues that need review and/or suggest issues in comments here.

List of Slack users to ping 10 minutes before the meeting:
@Gábor Hojtsy (he/him), @worldlinemine, @lauriii, @AaronMcHale, @anmolgoyal74, @Antoniya, @Ravi, @shaal, @ckrina, @simohell, @gauravvv, @Mike Gifford (CivicActions), @Quynh, @yoroy, @EricRubino

This list gets copied to the issue for the next meeting. If that has already happened, then go to that issue to add/remove yourself to/from the list.

Recording of this week's meeting: TODO

Rough transcript of this week's meeting: Drupal Usability Meeting - 2024-01-05.txt

We discussed the following issue:

NR and RTBC issues marked Needs usability review.

The group is actively tracking progress on these issues:

Remaining tasks

  1. Add issue credits for the participants.
  2. Add the issue(s) we discussed to the issue summary and as related issues.
  3. Add a rough transcript.
  4. Add a link to the recording on YouTube.
  5. Comment on the issue(s) we discussed.

Add warning message to import translations after enabling Interface Translation

$
0
0

Problem/Motivation

When interface translation is installed after language the interface translations are not downloaded.

Steps to reproduce

  1. from a fresh Drupal 8.0.0-rc3 standard install, enable "Language"
  2. go to admin/config/regional/language and add a new language
  3. enable "Interface translation"

Expected behaviour
Translations of the user interface should have been imported.

What happens instead
User interface appears not translated when switching to the given language

Currently available workaround
From there, the following works fine:

  1. delete the given language
  2. add the given language again (while "Interface Translation is still enabled): then import process happens as expected, and the user interface appears translated (apart from the part currently missing, but this is another point)

Proposed resolution

  1. when enabling "Interface Translation", warn that there are translations ready for import, with a link

New warning message

Remaining tasks

review
commit

User interface changes

API changes

none

Data model changes

none

Release notes snippet

Use of UUIDs in image style config file for effect ids

$
0
0

Problem/Motivation

In #2110615: Do not ship with default UUIDs we removed default configuration entity UUIDs remove all default configuration provided by core (modules, themes and profiles). However, UUIDs are still present in image style configuration as effect IDs. For example, image.style.large.yml contents are:

name: large
label: 'Large (480x480)'
effects:
  ddd73aa7-4bd6-4c85-b600-bdf2b1628d1d:
    id: image_scale
    data:
      width: 480
      height: 480
      upscale: true
    weight: 0
    uuid: ddd73aa7-4bd6-4c85-b600-bdf2b1628d1d
langcode: en

In some ways this is not a problem because the use of the UUID is totally internal to the image style. It just exists so that there can be multiple effects of the same type - ie. you can added another image_scale transformation to this style. However this shows us that we really have a naming problem here where id: image_scale is not really an identifier but it is an effect type. And we're are just using UUID as a convenient way of generating a unique ID.

Proposed resolution

Depends on what we decide.

Remaining tasks

Decide if we need to change this.

User interface changes

Urls like admin/config/media/image-styles/manage/large/effects/ddd73aa7-4bd6-4c85-b600-bdf2b1628d1d will change

API changes

Probably

[D7] node_access filters out accessible nodes when node is left joined

Incorrect order and duplicate theme hook suggestions

$
0
0

Just by turning on twig debug and looking at theme suggestions, you can see for the main menu (and any corresponding menu like footer) that there is a duplicate theme suggestion and at the most specific level which overrides any and all customizations in hook_theme_suggestions_alter().

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'menu__main' -->
<!-- FILE NAME SUGGESTIONS:
   x menu--main.html.twig
   * menu--main--customization.html.twig
   x menu--main.html.twig
   * menu.html.twig
-->

Should be:

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'menu__main' -->
<!-- FILE NAME SUGGESTIONS:
   x menu--main--customization.html.twig
   * menu--main.html.twig
   * menu.html.twig
-->

Fix broken path resolution when Drupal bootstrapped outside app root

$
0
0

Problem/Motivation

When a DrupalKernel is created with an $app_root it cannot find the service yml files and gives this error:

 [Symfony\Component\DependencyInjection\Exception\InvalidArgumentException]
  The service file "core/core.services.yml" is not valid.

While most of the kernel uses the appRoot to find its files, the service provider discovery part does not.

Proposed resolution

Use the appRoot when loading service ymls.

Fix 12 'un' words

$
0
0

Problem/Motivation

These words are all words prefixed with 'un'. Most occurrences are in tests but some are variable names.

Steps to reproduce

  1. unassigning
  2. unassigns
  3. unbans
  4. unbundleable
  5. unclickable
  6. uncollapsible
  7. ungenerated
  8. unparseable
  9. unpromoted
  10. unregisters
  11. unvalidated
  12. unwrapper

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


[meta] Fix missing hyphens for prefixes - Words starting with "un"

$
0
0

Problem/Motivation

Quoted from parent issue:

Discovered at #2972224: Add .cspell.json to automate spellchecking in Drupal core, and pointed by @xjm in https://www.drupal.org/project/drupal/issues/3122088#comment-13628724

@xjm:

Should be hyphenated (un-assign, de-prioritize, re-render, etc.)

There's an interesting question of where to draw the line for these. Generally in English these prefixes are morphologically productive with a hyphen, and get de-hyphenated when the word is adopted into common usage. "Denormalize", "Unsanitized", "Uninstantiated" etc. are all obviously in common usage in programming. "Unsticky", "Unrevisionable", and the like are Drupal terminology, and I'm surprised that "unpublish" and friends aren't already in the main dictionary.

The parent issue tried to fix all words that should be hyphenated, but the patch for this was getting too big thus making it tricky to review. Also there were some debate about which words should be hyphenated, and which shouldn't. So they argued it would be better to separate the issue into 3 smaller ones (one each for words starting with 're', 'de' and 'un'). (see comment links bellow)

#3138768 #26.2 @xjm talks about the presave word and suggests to divide the issue.
#3138768 #31 @longwave agrees to divide the issue and says it's getting tricky to review.
#3138768 #36 @davidhernandez questions about if some words should be hyphenated.
#3138768 #38 @quietone agrees with @longwave about creating separated issues.

Proposed resolution

Check and decide as a group, with first-language speakers contributing, which of the following words are correct in Drupal and which should be hyphenated, then fix them as needed on the code.

  1. unban -> TODO: Look up context
  2. uncacheable -> un-cacheable
  3. uncategorized -> un-categorized (? – check if this is in the dictionary)
  4. undoable -> TODO: Look up context
  5. unfieldable -> un-fieldable
  6. ungroup -> un-group
  7. ungroupable -> un-groupable
  8. unindexed -> un-indexed
  9. uninstallation -> un-installation
  10. uninstallations -> TODO: Look up context
  11. unmanaged -> TODO: Look up context
  12. unminified -> un-minified (? – maybe de-minified)
  13. unmoderated -> un-moderated
  14. unpromote -> un-promote
  15. unpublish -> un-publish (? – check dictionary on this)
  16. unpublishes -> un-publishes (? – check dictionary on this)
  17. unpublishing -> un-publishing (? - check dictionary on this)
  18. unrevisionable -> un-revisionable
  19. unrouted -> TODO: Look up context
  20. unsanitized -> un-sanitized
  21. unserialization -> un-serialization
  22. unserialized -> un-serialized
  23. unserializes -> un-serializes
  24. unserializing -> un-serializing
  25. unsets -> un-sets (? – check dictionary on this)
  26. unsetting -> un-setting (? – check dictionary on this)
  27. unsticky -> un-sticky
  28. untabbable -> TODO: Look up context
  • #3409362: Fix spelling of some words with 'un' prefix
    1. unaliased
    2. unallowed
    3. unconfigured
    4. undelayed
    5. undraggable
    6. unextracted
    7. unflagged
    8. unhashed
    9. unhides
    10. unindented
    11. uninstantiatable
    12. uninstantiated
    13. unixepoch This is an SQLite function
    14. unixtimestamp
    15. unkeyed
    16. unmatch
    17. unpermissioned
    18. unpreloaded
    19. unrendered
    20. unshortened
    21. unsimplified
    22. untarring
    23. untrustable
  • #3412959: Fix 12 'un' words
    1. unassigning -> un-assigning
    2. unassigns -> un-assigns
    3. unbans -> TODO: Look up context
    4. unbundleable -> un-bundleable
    5. unclickable -> TODO: Look up context
    6. uncollapsible -> TODO: Look up context
    7. ungenerated -> TODO: Look up context
    8. unparseable -> un-parseable
    9. unpromoted -> un-promoted
    10. unregisters -> un-registers
    11. unvalidated -> TODO: Look up context
    12. unwrapper -> TODO: Look up context

Remaining tasks

  1. First, probably reduce the list above (as a non-native English speaker I couldn't remove all the 'obviously unhyphenated' words before posting here).
  2. Decide as a group what to do with each word.
  3. Remove and fix the words as defined by the group.
  4. Review.
  5. Commit.

User interface changes

API changes

Data model changes

Release notes snippet

Ajax error ajax.$form.ajaxSubmit() is not a function

$
0
0

Different Drupal forms throw an ajax.$form.ajaxSubmit error on submit.

This has affected users at image upload, Block editing within Layout Builder sections, and ajax submissions for webforms.

Screenshot of the working image upload field.

Screenshot of the add image gallery ajaxSubmit not a function error.

Screenshot of a ajaxSubmit not a function error alert.

Steps to Reproduce

To reproduce this issue, Install Stripe Module and enable its submodule stripe_examples and navigate to https://d10.local/stripe_examples/form/simple_checkout after adding stripe test API keys at https://d10.local/admin/config/stripe and try to submit the form. You will be getting this error.

use-ajax-submit does not includes core/jquery.form library to the form

$
0
0

Problem/Motivation

I want a form to be ajax submitted. As per the docs, I added class use-ajax-submit to the submit button of the form. The ajax submit is working if the page has the admin toolbar, but for users who cannot see the admin toolbar, for them it throws error:

drupal_ajax: ajax.$form.ajaxSubmit is not a function

I had to add core/jquery.form and core/drupal.ajax libraries to the form, to make it work.

Proposed resolution

Libraries core/jquery.form and core/drupal.ajax should be added by itself if use-ajax-submit class is added to the submit button.

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Deprecated function: strnatcasecmp(): Passing null to parameter #1 ($string1) of type string is deprecated in LayoutPluginManager

$
0
0

Problem/Motivation

Deprecated function: strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated in Drupal\Core\Layout\LayoutPluginManager->Drupal\Core\Layout\{closure}() (line 204 of core/lib/Drupal/Core/Layout/LayoutPluginManager.php).

appears on pages, where layouts are being listed in a select which uses $this->layoutPluginManager->getLayoutOptions() to get its options.

Example:

$form['field_layouts']['field_layout'] = [
      '#type' => 'select',
      '#title' => $this->t('Select a layout'),
      '#options' => $this->layoutPluginManager->getLayoutOptions(),
      '#default_value' => $layout_plugin->getPluginId(),
      '#ajax' => [
        'callback' => '::settingsAjax',
        'wrapper' => 'field-layout-settings-wrapper',
        'trigger_as' => ['name' => 'field_layout_change'],
      ],
    ];

(FieldLayoutEntityDisplayFormTrait.php)

layout_builder's layout_builder_blank aka BlankLayout neither has a label nor a category defined in its annotation:

/**
 * Provides a layout plugin that produces no output.
 *
 * @see \Drupal\layout_builder\Field\LayoutSectionItemList::removeSection()
 * @see \Drupal\layout_builder\SectionListTrait::addBlankSection()
 * @see \Drupal\layout_builder\SectionListTrait::hasBlankSection()
 *
 * @internal
 *   This layout plugin is intended for internal use by Layout Builder only.
 *
 * @Layout(
 *   id = "layout_builder_blank",
 * )
 */
class BlankLayout extends LayoutDefault {

it should be sorted out by

/**
 * Implements hook_plugin_filter_TYPE_alter().
 */
function layout_builder_plugin_filter_layout_alter(array &$definitions, array $extra, $consumer) {
  // Hide the blank layout plugin from listings.
  unset($definitions['layout_builder_blank']);
}

(layout_builder.module)

but that hook never gets called!

So the layout_builder_blank layout is being passed through without label or category, but these methods rely on these values to be present. They are being called indirectly by $this->layoutPluginManager->getLayoutOptions()

  /**
   * {@inheritdoc}
   *
   * @return \Drupal\Core\Layout\LayoutDefinition[]
   */
  public function getSortedDefinitions(array $definitions = NULL, $label_key = 'label') {
    // Sort the plugins first by category, then by label.
    $definitions = $definitions ?? $this->getDefinitions();
    uasort($definitions, function (LayoutDefinition $a, LayoutDefinition $b) {
      if ($a->getCategory() != $b->getCategory()) {
        return strnatcasecmp($a->getCategory(), $b->getCategory());
      }
      return strnatcasecmp($a->getLabel(), $b->getLabel());
    });
    return $definitions;
  }

  /**
   * {@inheritdoc}
   *
   * @return \Drupal\Core\Layout\LayoutDefinition[][]
   */
  public function getGroupedDefinitions(array $definitions = NULL, $label_key = 'label') {
    $definitions = $this->getSortedDefinitions($definitions ?? $this->getDefinitions(), $label_key);
    $grouped_definitions = [];
    foreach ($definitions as $id => $definition) {
      $grouped_definitions[(string) $definition->getCategory()][$id] = $definition;
    }
    return $grouped_definitions;
  }

  /**
   * {@inheritdoc}
   */
  public function getLayoutOptions() {
    $layout_options = [];
    foreach ($this->getGroupedDefinitions() as $category => $layout_definitions) {
      foreach ($layout_definitions as $name => $layout_definition) {
        $layout_options[$category][$name] = $layout_definition->getLabel();
      }
    }
    return $layout_options;
  }

This is why the error appears.

This deprecation warning didn't appear in older versions of PHP, so the bug wasn't visible.

TL;DR:

/**
 * Implements hook_plugin_filter_TYPE_alter().
 */
function layout_builder_plugin_filter_layout_alter(array &$definitions, array $extra, $consumer) {
  // Hide the blank layout plugin from listings.
  unset($definitions['layout_builder_blank']);
}

(layout_builder.module)
is not called, so the layout_builder_blank layout, which neither has a label nor a description is not being sorted out, which leads to this error!

Steps to reproduce

See above description. For this issue to appear, it needs

  1. layout_builder to be enabled, so the layout_builder_blank layout is added
  2. A form which uses FieldLayoutEntityDisplayFormTrait or directly calls $this->layoutPluginManager->getLayoutOptions(),

See #3089418: Layout selection weight sorting for another example and #3316811: strnatcasecmp(): Passing null to parameter #1 ($string) of type string is deprecated for an older (duplicate) report of this issue.

Simple code example:
As a contrib example, see https://www.drupal.org/project/layout_disable where this happens in
https://git.drupalcode.org/project/layout_disable/-/blob/2.x/src/Form/La...

It seems as like the LayoutPluginManager (DI-injected by $container->get('plugin.manager.core.layout'),) is entirely missing FilteredPluginManagerTrait, so that its alterations are never being called:

/**
   * Implements \Drupal\Core\Plugin\FilteredPluginManagerInterface::getFilteredDefinitions().
   */
  public function getFilteredDefinitions($consumer, $contexts = NULL, array $extra = []) {
    if (!is_null($contexts)) {
      $definitions = $this->getDefinitionsForContexts($contexts);
    }
    else {
      $definitions = $this->getDefinitions();
    }

    $type = $this->getType();
    $hooks = [];
    $hooks[] = "plugin_filter_{$type}";
    $hooks[] = "plugin_filter_{$type}__{$consumer}";
    $this->moduleHandler()->alter($hooks, $definitions, $extra, $consumer);
    $this->themeManager()->alter($hooks, $definitions, $extra, $consumer);
    return $definitions;
  }

meanwhile, they are being called in Layout builder (e.g. admin/structure/types/manage/page/display/default/layout) when adding a section.
So maybe layout_builder is doing something different or special?
If layout_builder is not installed, everything is fine!

Proposed resolution

  1. Find out why layout_builder_plugin_filter_layout_alter() is not being called and layout_builder_blank layout plugin is not being sorted out, when layout_builder is enabled.
  2. Make layout_builder_plugin_filter_layout_alter() work or sort out layout_builder_blank in another way

This should also solve the side-effect of layout_builder_blank appearing in selects!

Additionally, we might cast the NULL value to string, like in other similar issues (see related). But that doesn't solve the root cause, just prevents strnatcasecmp from running into this error.
Additionally, we might add a label and category to the layout_builder_blank layout so it never returns NULL for these values.
But these are not valid solutions to fix the root cause!

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem upgrading from D9.5 > D10

$
0
0

Problem/Motivation

I finished with instructions how to upgrade from D9 to D10. The Upgrade Status marks 100% completed all the migration issues.

When I preform test with composer update --dry-run without errors.
Preform composer update
Could not upgrade Drush. Composer notification:

- Upgrading drush/drush (10.6.1 => 12.4.3): Extracting archive
 89/92 [===========================>]  96%    Failed to extract drush/drush: (2) "C:\Program Files\7-Zip\7z.EXE" x -bb0 -y C:\xampp\htdocs\oz\vendor\composer\tmp-08798dca14f2a137d35b1ceb614f39ff.zip -oC:\xampp\htdocs\oz\vendor\composer\e2384ecc        

ERROR: Cannot create symbolic link : A required privilege is not held by the client. : C:\xampp\htdocs\oz\vendor\composer\e2384ecc\drush-ops-drush-8245ace\docs\contribute\CONTRIBUTING.md
ERROR: Cannot create symbolic link : A required privilege is not held by the client. : C:\xampp\htdocs\oz\vendor\composer\e2384ecc\drush-ops-drush-8245ace\docs\drush_logo-black.png
ERROR: Cannot create symbolic link : A required privilege is not held by the client. : C:\xampp\htdocs\oz\vendor\composer\e2384ecc\drush-ops-drush-8245ace\docs\img\favicon.ico
ERROR: Cannot create symbolic link : A required privilege is not held by the client. : C:\xampp\htdocs\oz\vendor\composer\e2384ecc\drush-ops-drush-8245ace\docs\misc\icon_PhpStorm.png

    The archive may contain identical file names with different capitalization (which fails on case insensitive filesystems)
    Unzip with 7z command failed, falling back to ZipArchive class

Run composer install (no issues)

Got error message on my website:
Thx for help.

Fatal error: Uncaught Error: Undefined constant Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL in C:\xampp\htdocs\oz\web\sites\default\settings.php:380 Stack trace: #0 C:\xampp\htdocs\oz\vendor\drupal\core\lib\Drupal\Core\Site\Settings.php(146): require() #1 C:\xampp\htdocs\oz\web\core\includes\install.core.inc(335): Drupal\Core\Site\Settings::initialize('C:\\xampp\\htdocs...', 'sites/default', Object(Composer\Autoload\ClassLoader)) #2 C:\xampp\htdocs\oz\web\core\includes\install.core.inc(116): install_begin_request(Object(Composer\Autoload\ClassLoader), Array) #3 C:\xampp\htdocs\oz\web\core\install.php(48): install_drupal(Object(Composer\Autoload\ClassLoader)) #4 {main} thrown in C:\xampp\htdocs\oz\web\sites\default\settings.php on line 380

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Viewing all 291233 articles
Browse latest View live