#Needs issue summary update

Still a few unsresolved comments on the MR

Based on #22 I search for am issue to postpone this on and didn't find anything in the Drupal CMS project or automatic updates.

Anyone know of a place for this?

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

Until this gets ready, @keshav patel created a Drush command (theme:dev) which toggles Twig debugging, caching and aggregation, included in the latest Drush 13.6 release.

Drupal Documentation page: Disabling and debugging caching > Toggle Twig debug, caching and CSS/JS aggregation with Drush → .

🐛 Move CSS/JS aggregation settings to "Development settings" form Active could also be of interest, it's using states for CSS/JS aggregation and aggregation.

Postponed 🐛 Dependency from core block plugin to block module Active on this issue.

Offering a fly by opinion as it was linked in #3524897-6: Dependency from core block plugin to block module → .

A "development" yes/no toggle sounds great.

Re the current issue title: "Add a Production/Development toggle". In some clients or projects there you might find terminology and a setup describing development, non-production, production.

A toggle as provided here I imagine would refer to mainly local-development related activities. So I think to avoid the binary labels being confused with non-prod vs production, this should simply be referred to as "Development mode".

The Contact Module was approved for removal in 🌱 [Policy] Move Contact module to contrib Active .

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project → and the Extensions approved for removal → policies.

The deprecation work is in 📌 [meta] Tasks to deprecate the Contact module Active and the removal work in 📌 [12.x] [meta] Tasks to remove Contant module Active .

Contact will be moved to a contributed project after the Drupal 12.x branch is open.

The Contact Module was approved for removal in 🌱 [Policy] Move Contact module to contrib Active .

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project → and the Extensions approved for removal → policies.

The deprecation work is in 📌 [meta] Tasks to deprecate the Contact module Active and the removal work in 📌 [12.x] [meta] Tasks to remove Contant module Active .

Contact will be moved to a contributed project after the Drupal 12.x branch is open.

For the tests

I merged the latest 11.x and tried to improve the issue summary.

prudloff → changed the visibility of the branch 2409107-do-not-prepopulate to hidden.

nod_ → reopened merge request !11394

nod_ → closed merge request !11394

In order to stop having to keep creating patches you can do this instead:

composer config --json extra.patches-ignore '{"drupal/lightning_core": {"drupal/core": {"2869592 - Disabled update module shouldn't produce a status report warning": "https://www.drupal.org/files/issues/2869592-remove-update-warning-7.patch"}}}'
composer require 'drupal/update_notifications_disable:^2.0@RC'
drush en update_notifications_disable

Adding new patch for 10.4.7

Updated issue summary.

@berdir: I confirm the changes in the MR are still needed.

The issue I encountered was that on a form submit containing a datetime-local element, I always had an Exception "The date cannot be created from a format."

Dateime::valueCallback() was calling getHtml5DateFormat<code> which returns <code>DateFormat::load('html_datetime')->getPattern(); for datetime-local and datetime elements.
But 'html_datetime' (ie. Y-m-d\TH:i:sO) is not a valid format to pass to \DateTime::createFromFormat() in the following try / catch block.

Perhaps not handled in the most elegant way possible ; the fix I provided was very specific to the datetime-local element but datetime element might have the same problem.

The test results in #18 demonstrated the bug for many years, until patch testing got turned off.

I'm not disputing that, just trying to help make it easier for anyone interested in picking this up. Without this it's hard to know at a glance if anything has changed in core that might have fixed this over the last 5 years.

This absolutely needs test coverage.

I haven't thoroughly looked into this issue yet, would it would to have a test module that provides a layout, add that layout to a page, then uninstall that module and verify everything still works as expected? If I get a chance I'll look into this.

Thanks everyone!

Hello , I have tested the MR on Drupal 11.0.x and it is working as expected.
Steps:
1. Added a link field to article content type.
2. Added Allowed protocols field value as "mailto, ftp"
3. Created a article and added value to the link URL field mailto:example@example.com
4. Added a field label value 'Mail this to'.

Added screenshots for reference

This needs an issue summary update, let's start with the standard issue template. I think it's also not clear from the title what is the bug that needs fixing, i.e. the is-active class is not added. Let's get 2525830-18-комацу.patch converted to an MR so we can see the test fail, then we can work on a fix for this.

It's a bit of an edge case, but I'll share it here, since this issue pops up when searching for changing default language.

I have originally started my web site in the standard English language, but now want to change to Danish as the default language, because I want to translate block titles and other user interface elements, with a base in Danish. What makes this case special, is that all content is migrated into Drupal from JSON-files, so there is no existing content to change language for, only configuration.

I updated and renamed these configuration files, to change from English to Danish:

sed -i "s|langcode: en|langcode: da|g" *.yml
sed -i "s|en: ''|da: ''|g" language.negotiation.yml
mv language.entity.en.yml language.entity.da.yml
sed -i "s|id: en|id: da|g" language.entity.da.yml 
sed -i "s|label: English|label: Dansk|g" language.entity.da.yml

I then installed a fresh instance of Drupal in Danish, importing the config:

drush site:install minimal --config-dir=../assets/config --locale=da -y

I installed the language modules, to allow adding English language, as an additional language:

drush install content_translation locale config_translation

Before finding this method, I tried to create Danish language, set it as default, and delete English. But in the exported config files, there were still many lingering langcode: en strings in the config files (maybe ~50?), so I thought it better to switch all instances manually. It seems to work well, so far ...

Rebased the MR.

Hi all,
Patch #34 works for me.

Drupal version: 10.4.7
Inline entity form version: 3.0.0-rc21

Thank you so much!

The filter-tips.html.twig and accompanying template_preprocess_filter_tips() that ships with Drupal 11 do use Attributes appropriately and provide no default classes anymore.

Since there were no other templates identified that don't follow the recommended use of Attributes, this issue seems irrelevant at this point.

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Patch for the 3.0.2 tag

Here's the explain on the query from loading the view and clicking the tablesort.

MySQL [local]> explain SELECT node_field_data.nid AS nid, users_field_data_node_field_data.uid AS users_field_data_node_field_data_uid
    -> FROM
    -> node_field_data node_field_data
    -> INNER JOIN users_field_data users_field_data_node_field_data ON node_field_data.uid = users_field_data_node_field_data.uid
    -> WHERE (node_field_data.status = 1 OR (node_field_data.uid = 1 AND 1 <> 0 AND 1 = 1) OR 1 = 1)
    -> ORDER BY users_field_data_node_field_data.name ASC
    -> LIMIT 50 OFFSET 0
    -> ;
+----+-------------+----------------------------------+------------+------+----------------------------------------------+---------+---------+---------------------------+------+----------+---------------------------------+
| id | select_type | table                            | partitions | type | possible_keys                                | key     | key_len | ref                       | rows | filtered | Extra                           |
+----+-------------+----------------------------------+------------+------+----------------------------------------------+---------+---------+---------------------------+------+----------+---------------------------------+
|  1 | SIMPLE      | node_field_data                  | NULL       | ALL  | node_field__uid__target_id                   | NULL    | NULL    | NULL                      |    1 |   100.00 | Using temporary; Using filesort |
|  1 | SIMPLE      | users_field_data_node_field_data | NULL       | ref  | PRIMARY,user__id__default_langcode__langcode | PRIMARY | 4       | local.node_field_data.uid |    1 |   100.00 | NULL                            |
+----+-------------+----------------------------------+------------+------+----------------------------------------------+---------+---------+---------------------------+------+----------+---------------------------------+
2 rows in set, 1 warning (0.000 sec)

So yeah we're using temp tables.

Setting to PMNMI for the decision on whether we want to do this. Personally I'm happy to close.

Now that 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active and child issues are done, all this code is deprecated and will be removed in D12.

There isn't a proposed resolution section in the issue summary, so I am tagging this for an update.

https://www.drupal.org/project/update_notifications_disable/releases/2.0... → is now out.

Note that there may need to be a follow up to tie the uninstall of implicit dependencies like block_content in this example to dependency calculations for configurations using the plugin.

Follow up for this: https://www.drupal.org/project/drupal/issues/3524219 📌 Add plugin class module dependencies to dependency calculation Active

The example actually helped make this click.

We are now caching the dependencies of given plugins and skipping loading them if they are missing, and if I understand correctly it is now handling the uninstall case.

The only concern I have is how much will end up in these dependency trains, but I don't see a better way to do this, and it does seem pretty straightforward all things considered.

I've also reviewed the CR, I think it's clear but the committers can confirm as well.

I've asked @godotislate to create a follow up for

*Note that there may need to be a follow up to tie the uninstall of implicit dependencies like block_content in this example to dependency calculations for configurations using the plugin.

but I'm not going to block this on that, I'll keep an eye on it and follow up if it's not created shortly.

getValue() is still a major DX issue, so I think this is still kind of valid, keeping of for now. Renaming getValue() is something I'd love to do, but I'm also aware about the impact that would have.

Automatically closed - issue fixed for 2 weeks with no activity.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Wonder if the summary could be updated with what's next?

https://drupal.slack.com/archives/C079NQPQUEN/p1747131446995239 slack thread

Added the requested docs.

Missing docs...

I keep on pondering whether we should decouple the config removal from the other changes here. Like decouple views RSS and make the system config completely unused and deprecated and then remove that in a separate 12.x issue. I would mean that we also have the previous value around for module updates.

Not sure - going to ping @catch and @longwave for thoughts.

Mis understood, RTBC was referring to the change record.

Updated patch in #54 to be compatible with Drupal 10.4.6.
I might take a stab at D11 soon.

Adding 11.2.0 release priority tag for #29 and bug in #34.

I ran into this error, but replacing my site config with the default media library view fixed it.

I had changed the view display to use responsive grid.

But that display doesn't support row classes, relating to https://www.drupal.org/project/drupal/issues/2474491 →

I made a custom display that extends responsive grid to add custom classes back in, and it's working again.

Super nice @elimw! Great job! 🥳

Looks like everything requested above is now in the MR, with the added Unit Test 👌

Let's see if reviewers and maintainers could take another look at this issue.
Thanks again for the great help and work @elimw!

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Added test coverage, incorporated the latest fix from #13.

Things changed since the last discussions on this: at the time, many projects were still having drupal at the project root, but with the usual scaffolds, Drupal is most often under (root)/web these days, so there is no longer really a good reason not to create the config outside, e.g. in (root)/config. The same actually applies to the private file system, logs, and temporary directories, I think : we could easily have more security by default by setting these instead of just documenting to users how to create them.

Updated CR

I normally search like this: https://git.drupalcode.org/search?group_id=2&scope=blobs&search=-path%3A...

Since when are we opening issues on contrib projects for deprecations/removal? I've not seen that before :)

Search link that found the modules that need fixes... http://codcontrib.hank.vps-private.net/search?text=system.rss&filename=

MR updated with latest 11.x + some feedback for MR review.

Let's try again a review. thanks

We have two modules that will need issues against when we remove system.rss. https://www.drupal.org/project/knowledge → and https://www.drupal.org/project/support → - the Knowledge project is the only one with a stable release against 11.x ... some other modules will require updating but it is

The change record needs to be updated to explicit mention that system.rss is going away and what modules should do to replace it. Setting to needs work to address this. Once done can be rtbc'd again.

Oh, will rebase later today.

It has been 3 years since a committer asked for more information and none has been supplied. @acbramley suggested waiting a few more months, and that was about 1 year ago and still no comment. Therefore, I am closing this.

If there is work to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.

Believe all feedback has been resolved on this one. Test coverage is failing in 2 spots https://git.drupalcode.org/issue/drupal-2847425/-/jobs/4682940

IS seems to line up to me.

LGTM

May be the right status?

Works for me

I think that @berdir in #15 is right and we should avoid this, modules installing other modules should let the newly installed module handle updates to itself.

GitLab also says there is a merge conflict?

Just following up 1 more if this is still a valid task? If no follow up in 3 months could close out.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Bot is broken

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Time has passed, new perspectives and such.

Following on a suggestion and discussion @ #3522410-11: Using instances of classes defined by modules in service container parameters causes fatal errors →

What if we did the inverse to what is currently proposed here, back to the original intent of the ticket before direction change in #2536610-6: Ensure all modules are autoloaded with PSR-4 only if enabled →

Always have all modules available in autoloader.

Then, the concept of "installed" means whether a modules hooks/services/discovery/plugins etc etc is loaded.