Quantcast
Viewing all 294548 articles
Browse latest View live

Remove Color module from core

Problem/Motivation

Remove Color module from core

Steps to reproduce

Proposed resolution

Check for @todo
Bye bye Color

Remaining tasks

Manual testing (See https://drupal.slack.com/archives/C014CT1CN1M/p1658772338310209)#3302799: Manually test color module removal
Patch
#3302976: Port remaining changes from core
Review
Commit, plan for removal before Bartik but in the same week as Bartik

User interface changes

API changes

Data model changes

Release notes snippet

The Color module as it is isn't matching the expectations of frontend developers in 2022. It was written before CSS custom properties existed which makes it seem clunky to integrate with. There's potentially need for a module like this, which is proven by having some Color module usage in our contrib ecosystem. However, this need could be still fulfilled by a contrib module.

The Color module was deprecated in Drupal 9.4 and the module moved to contrib at https://drupal.org/project/color.

If you need the functionality provided by the Color module, read the recommendations for the Color module.


Order image mappings by breakpoint ID and numeric multiplier

Problem/Motivation

There are numerous assumptions in the responsive image code of sort ordering of image multipliers. Including the following code comment:

  // Retrieve all breakpoints and multipliers and reverse order of breakpoints.
  // By default, breakpoints are ordered from smallest weight to largest:
  // the smallest weight is expected to have the smallest breakpoint width,
  // while the largest weight is expected to have the largest breakpoint
  // width. For responsive images, we need largest breakpoint widths first, so
  // we need to reverse the order of these breakpoints.

Steps to reproduce

Found this while working on #3192234: [PP-1] Apply width and height attributes to allow responsive image tag use loading="lazy".

Proposed resolution

Force the order of all responsive image mappings to a known (proper) order.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[meta] Fix and re-enable tests skipped for random failures

Problem/Motivation

Follow-up from #3267124: Temporarily skip failing tests.

The following JavaScript test methods are currently skipped for random fails:

Layout Builder

  1. AjaxBlockTest::testAddAjaxBlock()#3304371: Fix intermittent failure in AjaxBlockTest
  2. ContentPreviewToggleTest::testContentPreviewToggle(): #3268678: [random test failure] Restore ContentPreviewToggleTest::testContentPreviewToggle()
  3. LayoutBuilderDisableInteractionsTest::assertContextualLinksClickable()
  4. #3272540: [random test failure] Restore LayoutBuilderTest::testLayoutBuilderUi()
  5. #3274053: [random test failure] Restore LayoutBuilderNestedFormUiTest::testAddingFormBlocksToDefaults()
  6. LayoutBuilderNestedFormUiTest::testAddingFormBlocksToOverrides()
  7. LayoutBuilderUiTest::assertHighlightNotExists()
  8. BlockFormMessagesTest::testValidationMessage()
  9. MoveBlockFormTest::testMoveBlock()
  10. ContextualLinksTest::assertCorrectContextualLinksInUi()

Other

Proposed resolution

  1. File children to debug and un-skip each.
  2. Un-skip one method per issue and run the affected test 500x.
  3. Queue 8 test runs of 1000x against MySQL or MariaDB environments.
  4. Post a patch that un-skips the test without any attempted fix to get a baseline fail rate, and always test this patch at the same time as any proposed fix with the same environment.
  5. Skip other methods in the test if it becomes necessary due to out-of-scope fails.

Fixed

  1. \Drupal\Tests\ckeditor5\FunctionalJavascript\MediaLibraryTest::testButton: #3268368: Robustify and restore \Drupal\Tests\ckeditor5\FunctionalJavascript\MediaLibraryTest::testButton
  2. LayoutBuilderDisableInteractionsTest::testFormsLinksDisabled(): #3268680: [random test failure] Restore and fix LayoutBuilderDisableInteractionsTest::testFormsLinksDisabled()
  3. #3272797: [random test failure] Restore LayoutBuilderTest::testConfigurableLayoutSections()
  4. QuickEditIntegrationTest::testArticleNode()#3268244: [random test failure] Un-skip and fix QuickEditIntegrationTest::testArticleNode()
  5. QuickEditIntegrationTest::testCustomBlock()#3267258: Remove Quick Edit support from editor.module

Fix intermittently failing Functional Javascript tests

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[Meta] Tasks to remove Quick Edit from core and move to contrib

Problem/Motivation

In #3222947: Decide whether to move Quick Edit to contrib Dries, the committer team, and other stakeholders have signed off on removing the Quick Edit module from core in Drupal 10.

This meta issue is filed as critical because it also unblocks a required Drupal 10 issue for removing our dependency on Backbone.

This issue is to coordinate and track the steps needed to remove Quick Edit after it is deprecated. See Remove a core module and move it to a contributed project of the deprecation policy.

Proposed resolution

Do the work necessary to remove Quick Edit from core.

Remaining tasks

  1. Do a final subtree split of core QE from 9.5.x branch into the contrib Git repo.
  2. Release Quick Edit 1.0.2
  3. Open an issue against https://www.drupal.org/project/project_composer.#3266476: Ensure that quickedit does not get special core treatment
  4. Manually test upgrading from the core module to the contrib module. #3303780: Manually test QuickEdit module removal
  5. Remove Quick Edit module from core. #3227033: Remove Quick Edit from core
  6. Move core issues for Quick Edit module from the core queue to the contrib module. This was already done once, so it'd just be a final check for any new stragglers.
  7. Move all core documentation for Quick Edit module to the contrib project.
  8. When #3266476 is Fixed, update the documentation with the new composer command.

Related work:

User interface changes

No more QuickEdit.

API changes

TBD, possibly in child issues

Data model changes

TBD, possible in child issues

Release notes snippet

Needed.

[Meta] Tasks to deprecate RDF

Problem/Motivation

This issue is to coordinate and track the steps needed to move RDF to contrib. See Remove a core module and move it to a contributed project of the deprecation policy.

The removal of RDF was approved in #2152459: [Policy] Deprecate RDF module and move it to contrib

Proposed resolution

Remaining tasks

  1. Move integrations implemented by other modules to RDF module
  2. Handle RDF migrations. #3267513: Handle migration tests for removing RDF
  3. Remove RDF from standard profile, #3243121: Remove RDF module from the Standard profile
  4. Remove RDF from Umami. #3302984: Remove RDF module from Umami
  5. Create the contrib project, RDF, with a stable release.
  6. Deprecate the core RDF module

User interface changes

API changes

Data model changes

Release notes snippet

[Meta] Tasks to remove Color from core and move to contrib

Problem/Motivation

This issue is to coordinate and track the steps needed to remove color from core to contrib after it is deprecated. See Remove a core module and move it to a contributed project of the deprecation policy.

The removal of color was approved in #2808151: [policy] Move the Color module to a contributed project when Bartik is deprecated

Proposed resolution

Remaining tasks

  1. Complete work in #3270899: Remove Color module from core
  2. Update the contrib project: #3302976: Port remaining changes from core
  3. Open an issue, 'Ensure that module Color does not get special core treatment'.#3291601: Ensure that color does not get special core treatment
  4. Manually test upgrading from the core module to the contrib module.#3302799: Manually test color module removal
  5. Move core issues for Color module from the core queue to the contrib module.
  6. Move all core documentation for Color module to the contrib project.
  7. When the issue in https://www.drupal.org/project/project_composer is Fixed update the documentation with the new Composer command.#3291601: Ensure that color does not get special core treatment

User interface changes

API changes

Data model changes

Release notes snippet

Deprecate Seven theme

Problem/Motivation

We are working on a new admin theme here: #3066007: Roadmap to stabilize Claro. After the new admin theme has been made default experience on new installations, we should start the process to deprecate Seven. Seven might be used by existing sites which has to be taken into account.

This issue is to do the actual deprecation of Seven. See that parent for all the tasks that need to be done to deprecate Seven.

Proposed resolution

Deprecate Seven theme to be removed in the following major release.

Remaining tasks

Work on the patch is postponed on #3278124: Convert various tests that use bartik/seven to olivero/claro but there is other work that can be done.

  1. Create a section on Deprecated and obsolete themes and themes to provide recommendations for sites using theme Seven. The recommendation are to include instructions for sites using Seven and for contributed themes that depend on Seven.
  2. Set lifecycle to deprecated.
  3. Set lifecylcle_link to the section added above, https://www.drupal.org/node//3223395#s-Seven.
  4. The change record for this issue includes a link to the doc page.

User interface changes

API changes

Data model changes

Release notes snippet


SQLite database locking errors cause fatal errors

I've been running sqlite3 on my local dev environment (Ubuntu 10.04 Lucid Lynx, sqlite3 3.6.22) and have seen more than one of these fatal "database is locked" #fails. In each case, a page reload fixes it fine. I'll see if I can do an upgrade of sqlite and see what happens.

Error message
PDOException: SQLSTATE[HY000]: General error: 5 database is locked: INSERT INTO {variable} (name, value) VALUES (?, ?); Array ( [0] => rules_empty_sets [1] => a:55:{s:29:"commerce_cart_product_prepare";i:0;s:33:"commerce_customer_profile_presave";i:1;s:32:"commerce_customer_profile_insert";i:2;s:32:"commerce_customer_profile_update";i:3;s:32:"commerce_customer_profile_delete";i:4;s:26:"commerce_line_item_presave";i:5;s:25:"commerce_line_item_insert";i:6;s:25:"commerce_line_item_update";i:7;s:25:"commerce_line_item_delete";i:8;s:22:"commerce_order_presave";i:9;s:21:"commerce_order_insert";i:10;s:21:"commerce_order_update";i:11;s:21:"commerce_order_delete";i:12;s:36:"commerce_payment_transaction_presave";i:13;s:35:"commerce_payment_transaction_insert";i:14;s:35:"commerce_payment_transaction_update";i:15;s:35:"commerce_payment_transaction_delete";i:16;s:24:"commerce_product_presave";i:17;s:23:"commerce_product_insert";i:18;s:23:"commerce_product_update";i:19;s:23:"commerce_product_delete";i:20;s:19:"rules_config_insert";i:21;s:19:"rules_config_update";i:22;s:20:"rules_config_presave";i:23;s:19:"rules_config_delete";i:24;s:11:"node_insert";i:25;s:11:"node_update";i:26;s:12:"node_presave";i:27;s:9:"node_view";i:28;s:11:"node_delete";i:29;s:4:"init";i:30;s:4:"cron";i:31;s:8:"watchdog";i:32;s:11:"user_insert";i:33;s:11:"user_update";i:34;s:12:"user_presave";i:35;s:9:"user_view";i:36;s:11:"user_delete";i:37;s:10:"user_login";i:38;s:11:"user_logout";i:39;s:14:"comment_insert";i:40;s:14:"comment_update";i:41;s:15:"comment_presave";i:42;s:12:"comment_view";i:43;s:14:"comment_delete";i:44;s:15:"comment_publish";i:45;s:17:"comment_unpublish";i:46;s:20:"taxonomy_term_insert";i:47;s:20:"taxonomy_term_update";i:48;s:21:"taxonomy_term_presave";i:49;s:20:"taxonomy_term_delete";i:50;s:26:"taxonomy_vocabulary_insert";i:51;s:26:"taxonomy_vocabulary_update";i:52;s:27:"taxonomy_vocabulary_presave";i:53;s:26:"taxonomy_vocabulary_delete";i:54;} ) in variable_set() (line 804 of /home/rfay/workspace/d7git/includes/bootstrap.inc).

Problem

The SQLite database does not support row level locks. As a result we have to acquire a reserved lock on the database immediately.
For more information, see: https://bugs.php.net/42766.

contextual.js overrides any destination query param set earlier

Problem/Motivation

contextual.js adds a fixed destination query string param to the end of the URL even if it already contains a destination param set earlier, e.g. in a hook. The result with two destination params does not look correct and apparently the last destination takes priority over any others which makes it effectively impossible to set an alternative destination in a hook.

Proposed resolution

Fix contextual.js to only add a destination when one has not been already added to the URL.

Remaining tasks

* Ideally combine the change with #2760937: contextual.js produces an undesireable URL when a contextual link has a fragment in it as it fixes another bug in the same code.
* Write a test - unfortunately have no skills to do that

User interface changes

N/A

API changes

N/A

Data model changes

N/A

[Meta] Tasks to remove Bartik from core and move to contrib

Problem/Motivation

This issue is to coordinate and track the steps needed to remove Bartik from core to contrib. The steps to remove a theme and move it to contrib are in development, the steps for modules is being used as a guide. See Remove a core module and move it to a contributed project of the deprecation policy.

The removal of Bartik was approved in TBA

Proposed resolution

Remaining tasks

  1. Remove Bartik theme from core.
  2. Open an issue against https://www.drupal.org/project/project_composer. #3304860: Ensure that Bartik does not get special core treatment
  3. Move core issues for Bartik theme from the core queue to the contrib module.
  4. Move all core documentation for Bartik module to the contrib project.
  5. When the issue in https://www.drupal.org/project/project_composer is Fixed update the documentation with the new composer command.

User interface changes

API changes

Data model changes

Release notes snippet

When saving a form, it just reloads the form (nodes, other forms)

Problem/Motivation

When you try to save a node or another form, the data is not stored and you end up again on the form, with sometimes broken elements. There are no errors captured.

Steps to reproduce

The issue occurs because of the code inside the function buttonWasClicked in FormBuilder.php.
There's a check between the input and the element value in this function, to determine which button was clicked on the form.
But if you have a translation that contains a "\r\n" at the end of the translation, perhaps because the translations was copied from a word doc, the comparison does not work, as the first value only contains a newline, and the second also contains the carriage return.
Image may be NSFW.
Clik here to view.
Newline issue

Because the submit buttons fails to be discovered, the code keeps searching in sub-elements and eventually another button is used, as f.e. a file upload button.
But as this logic contains a form rebuild, the form thinks it is a multi-step form and it just loads the form instead of saving and returning to the correct destination.

Proposed resolution

The fix could be achieved by providing a trim around the values to ensure newlines and carriage returns are not part of the comparison.
If you have this issue, you could also just remove the newline from interface translation on the "Save" value, but that won't stop us from encountering this into the future again.

Remaining tasks

Please review the proposed solution.

Refactor Claro's form stylesheet

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward first issue to easily onboard the student.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/clar... needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

  • Use CSS Logical Properties where appropriate
  • Use CSS nesting where appropriate

Remaining tasks

  • We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
  • We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.

#states not affecting visibility/requirement of managed_file

Cannot affect the visibility or requirement of managed_file with states. Identical to #1118016: conditional visibility of a managed_file using #states attribute does not work so either the bug wasn't fully fixed before, or a regression happened at some point and broke this functionality.

With this definition:

$form['type'] = array(
  '#type' => 'select',
  '#options' => array(
    'video' => t('Video'),
    'audio' => t('Audio'),
    'post' => t('Text'),
  ),
);

$form['audio'] = array(
  '#type' => 'managed_file',
  '#title' => t('Audio File'),
  '#states' => array(
    'visible'  => array(':input[name="type"]' => array('value' => 'audio')),
    'required' => array(':input[name="type"]' => array('value' => 'audio')),
  ),
  '#upload_location' => 'public://',
  '#upload_validators' => array(
    'file_validate_extensions' => array('mp3 wac'),
    'file_validate_size' => array(1048576),
  ),
);

I expect the visibility of "audio" to change when changing the value of "type". What happens is "audio" remains visible and not required. Simply changing "managed_file" to "file" brings the expected behavior.

Remove Bartik from Drupal core

Problem/Motivation

See #3278332: [Meta] Tasks to remove Bartik from core and move to contrib and #3249109: Deprecate Bartik. Now that Olivero is the default theme for Drupal core, it's time to move Bartik to a contributed project.

Steps to reproduce

Proposed resolution

Remaining tasks

  1. The change record for this issue should include a link to recommendations page, https://www.drupal.org/node/3223395#s-MODULE_NAME. (For example, the CR for removing HAL)
  2. Tag this issue 'Needs release note.
  3. Remove the module ;-).
  4. Remove references from core/phpstan-baseline.neon.
  5. Check for references in @todo.
  6. Handle migration tests.
  7. In all the functional tests in migrate_drupal_ui make sure that MODULE_NAME is not installed. MODULE_NAME should also be removed from the methods getAvailablePaths() and moved to getMissingPaths() in the tests using those methods.

User interface changes

API changes

Data model changes

Release notes snippet

The Bartik theme has been removed from Drupal 10.0.0, and is ">now available as a contributed theme. Sites using Bartik should install the contributed theme prior to updating to Drupal 10.


AJAX Command Feature to apply only if the selector not exist

Problem/Motivation

I want to display a status message in dialog form which is not render at the time of form built but in the form validation if some error occurs it needs to show error status message in form but if the user clicks again on the form the status message is
appended twice in the form.

Steps to reproduce

I am checking on this issue where I need this feature.

Proposed resolution

  1. To add an extra parameter exist in AppendCommand, PrependCommand ajax-commands to check and perform only if the selector is not exist.
  2. If the selector exist then replace it with the given response.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Unable to move fields to an empty area in the display mode.

Problem/Motivation

Unable to move fields in an empty area from the display mode.

Steps to reproduce

Using a clean Drupal 9.4 install

1. Choose a content type to edit (I am using Article content type).
2. Go to manage display mode.
3. Turn on the display mode: "Search result highlighting input" and navigate there.
4. Attempt to drag a field from the disabled to the enabled section (or vice-versa)

When you're trying to drag a single field for example "Links" into the other section, the mouse pointer stays on dragging mode and doesn't let you drop the field. Also this produces a console log error message.

field_ui.js?v=9.4.2:173 Uncaught TypeError: Cannot read properties of undefined (reading 'value')
    at Drupal.fieldUIDisplayOverview.field.regionChange (field_ui.js?v=9.4.2:173:122)
    at Drupal.tableDrag.onDrop (field_ui.js?v=9.4.2:99:40)
    at Drupal.tableDrag.dropRow (tabledrag.js?v=9.4.2:493:12)
    at HTMLDocument.<anonymous> (tabledrag.js?v=9.4.2:95:19)
    at HTMLDocument.dispatch (jquery.min.js?v=3.6.0:2:43064)
    at v.handle (jquery.min.js?v=3.6.0:2:41048)

I have included screenshots as well

Invalid machine name for system block - uppercased theme name

Problem/Motivation

Using Drupal 9 on production. Trying to config 'Page title' block but can't save any changes as I get the following error message 'The machine-readable name must contain only lowercase letters, numbers, and underscores'.

Steps to reproduce

1. Create a theme (subtheme) with capital letters in its name. 2. Try to config 'Page title' block

Proposed resolution

Warn (and block) before accepting a theme with capital letters in its name.

Remaining tasks

User interface changes

API changes

Data model changes

First published and patched here: https://www.drupal.org/forum/support/post-installation/2022-06-29/invali...

Release notes snippet

Drupal.ajax does not guarantee that "add new JS file to page" commands have finished before calling said JS

Problem/Motivation

It is impossible to load additional JS libraries in an Ajax response and then call that code through Ajax commands, because Drupal.ajax does not guarantee that the JS library will already have loaded.

The issue is more apparent when there is an \Drupal\Core\Ajax\InsertCommand"insert" AJAX command containing <script> tags which should be loaded in a specific manner (as it would on a normal DOM load), but aren't due to how jQuery currently works, and will result in a crash when the scripts are ran out of order.

Quick Javascript snippet to showcase the current behaviour:

var $el = jQuery('#element').length ? jQuery('#element') : jQuery('<div id="element"></div>').appendTo('body');
// https://javascript.info/script-async-defer
// long.js should ideally be loaded first, before small.js is. But currently doesn't.
$el.html(`
<script src="https://javascript.info/article/script-async-defer/long.js?speed=1"></script>
<script src="https://javascript.info/article/script-async-defer/small.js"></script>
`);

References:

See #23 and #31 for further details.

Proposed resolution

Create a new add_js ajax command that uses the loadjs library to ensure all external JS resources are loaded before continuing execution.

Remaining tasks

User interface changes

None.

API changes

Ajax commands can now return Promises to ensure command execution will wait for the promise to be resolved before continuing execution.
The ajaxing property of Drupal.Ajax objects is now set to falseafter all ajax command have been executed. Previously it was set to false as soon as the request came back from the network.

See the long list of related issues.

Release notes snippet

The processing of Ajax commands has changed. Ajax commands can now return promises when they need to ensure some code has been executed before executing the next Ajax command in the list. This is used for the new add_js command that ensures Additional JS files have been loaded before executing the next Ajax command.

When altering the success method of a Drupal.Ajax object please make sure a Promise is returned to ensure proper execution.

Conditional comments for IE will not be honored for JavaScript files with the new add_js command, all JS files will be added regardless of the value of #browsers. There are no changes for conditional comments on CSS files they will still work on Drupal 9.

Original report by [username]

Hi,

Thanks for your module, it works perfect for me.

But I found there one small bug there: if all my .js files are mapped to the external CDN, ajax redirects doesn't execute. After some tests I found that CDN rewrites all js urls, even for ajax. So I attached a small patch that solved this problem for me.

Best regards,
Spleshka.

Make browser tests use the browser only for assertions

Problem/Motivation

Since the introduction of Simpletest, we've been plagued with issues around keeping the parent (testing) process in sync with changes in the child (tested) processes.

Even now $this->container \Drupal::container() and the container in the child processes aren't necessarily the same thing.

Proposed resolution

Refactor tests to be either pure integration tests with no browser requests, or pure browser requests with no API access. You'd be fine to use the API during setup since that all happens before the child site is requested, but once you start making browser requests, should stick to that (which means losing some shortcuts for assertions generally).

Remaining tasks

Decide if this is the course of action we want to take, then start identifying and re-factoring problematic tests.

User interface changes

API changes

Data model changes

Viewing all 294548 articles
Browse latest View live


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