Use data-* to check modules dependencies before submit

me no right spelling.

forgot this too.

@nod_ I looked into doing something like this a while back as well. But quickly got distracted by all the markup that is injected into the render array for the module page and sought out to search and destroy all instances of from that page.

Find the code that builds up the markup for the module page and you'll see what I mean.

IMO, the addition of data attributes gives us a great opportunity to work on the markup being output here. I think a refactoring of the markup should be apart of this patch.

As a next step, I'll try to put out a patch that shows what I mean.

#1: core-js-modules-dependencies-1473760-1.patch queued for re-testing.

Wow, this would be great to have in ...

reroll for the fun of it :)

I think this can happen post-feature freeze?

I am a little skeptical about this, could this have some screens on the intended flow?

#7: core-js-modules-dependencies-1473760-7.patch queued for re-testing.

The last submitted patch, core-js-modules-dependencies-1473760-7.patch, failed testing.

Re-rolled.
And added modal with a list of modules being marked.

Replaced $.ui.dialog() by Drupal.dialog();

Replaced wrong library "drupal.dialog.ajax" by "drupal.dialog"

The patch includes the patch file itself... :-)

Fix patch loop o_O

The last submitted patch, 16: core-js-modules-dependencies-1473760-10.patch, failed testing.

Re-rolled.

the dialog dependency should be in the library definition of drupal.system.modules, not attached with it.

Can you put gettingDependencies: false outside Drupal.behavior? We should only have attach/detach in there.

$that.is(':checked') to replace by $that.prop('checked')

Drupal.dialog expects a HTMLElement, not a jQuery object.

Can you use the Array version of the button option? (We're told it's the preferred way to declare them http://api.jqueryui.com/dialog/#option-buttons).

Drupal.system is useless after all, I can bet people will confuse it for something it's not. Let's drop it and have the getDeps as a banal function in the closure.

The wording could use a little help. Feels different than the usual confirm step.

Can you also make the click handler a function instead of anon function? and also separate the declaration of the dialog options from the call of Drupal.dialog? There is too much nesting, we need to bring it down.

And as an optimisation for getDeps, we could try to use CSS selectors to do the work, kinda same way it's done in #2180921: [META] Use data attributes rather than classes wherever possible → .

Thanks!

"The wording could use a little help. Feels different than the usual confirm step."
In fact, I copied the confirm step.

"And as an optimisation for getDeps, we could try to use CSS selectors to do the work..."
Sorry, I dont understand what you mean.

What changed exactly, still seeing extra stuff in Drupal.behaviors, anon functions, not a HTMLElement in Drupal.dialog call and too much nesting.

We can delegate the event as well here.

reroll

The last submitted patch, 22: use_data_to_check-1473760-22.patch, failed testing.

sorry. wrong patch added earlier.

Drupal 8.2.6 → was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. ( Drupal 8.3.0-alpha1 → is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

Drupal 8.1.9 → was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 → is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

Drupal 8.0.6 → was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 → is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

The last submitted patch, 24: use_data_to_check-1473760-24.patch, failed testing.

Drupal 8.8.7 → was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 → or Drupal 9.0.0 → for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule → and the Allowed changes during the Drupal 8 and 9 release cycles → .

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule → and the Allowed changes during the Drupal 8 and 9 release cycles → .

Drupal 8.5.6 → was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. ( Drupal 8.6.0-rc1 → is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

Drupal 8.4.4 → was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. ( Drupal 8.5.0-alpha1 → is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

Drupal 8.3.6 → was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. ( Drupal 8.4.0-alpha1 → is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

we MUST no longer be modifying *.js files directly

We modify *.es6.js and then transpile as described here :-

https://www.drupal.org/node/2815083 →

as a ultra trivial point new code in ModulesListForm uses array() when [] is preferred.

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened → , as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 9.5.0-beta2 → and Drupal 10.0.0-beta2 → were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 9.4.0-alpha1 → was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 9.3.0-rc1 → was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 9.2.0-alpha1 → will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

hesitating on closing this one. Is there really a UX benefit of doing this?

Let's see what Usability thinks of removing the confirm step.