🇳🇱Netherlands @eelkeblok

This fix for this is in the latest dev release. You might want to either deploy that, or bake a patch from the merge request above. You can get a patch by appending .diff to the MR URL, like this: https://git.drupalcode.org/project/disable_messages/-/merge_requests/8.diff

Mind, it is good practice to copy the content of that URL and not apply it directly, since in general, the content of an MR could change because people make changes to it.

Also, it would probably be good if there were a release for this module. The latest release is from april 2022, the latest commit is from september 2025.

As a new and interesting twist, the project page for Entity Track → says

This module is now obsolete
The latest changes in the Entity Usage module have mode this module obsolete. Entity usage now has much more generic support for generic tracking plugins.

However, I am unsure what changes those are. Looking for a way to speed up the indexing process.

I personally think not having to come up with a short name (or rather, a unique shortname that has not already been taken, with the added mental pressure of "I am now squatting this name, what if I'm not able to get it up to a reasonable status?") is a valuable feature. Having a low-threshold way of getting something up on Drupal.org quickly without having to worry about details yet is very useful.

What if it were possible to create projects on the GitLab side, in your own personal space (I think that's not currently possible)? What would be needed on the Drupal.org side would be documentation pages explaining how to do this, maybe how to get such code in your projects. Support from Drupal.org to promote such projects - or maybe any arbitrary public Git repo? - to full projects would be a nice-to-have, but not essential; you could also have a documentation page explaining how to get code from a personal project into a full Drupal.org project (add remote, push to the remote, etc.)

At this point, you could wonder what the added benefit is over pointing people to e.g. GitHub. Not sure, and maybe the documentation should acknowledge it as an option. It could lower the threshold for some.

eelkeblok → created an issue.

One more small tip: it's possible to detach the execution of the drush command using screen. It is a pretty common tool on many UNIXy OSes. "Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells." sounds pretty scary, but just think of it as a way to keep stuff running without being connected to it with a terminal.

I've actually been using it for this. I still came to this issue because on a site with a lot of entities, the reindexing slows down to a crawl (I'm at 1.8 M records in the bulk table right now).

I created an extra branch to check if the test is working for the unaltered code, but I just realised the test is incorrectly checking for this issue; since the test is asserting the output of the XML parser, the resulting string should not be escaped HTML, but the unescaped HTML, meaning that we are sucesfully bypassing the XML parsing and getting HTML out the other end. Adjusted the test accordingly (and amended a comment to explain this maybe slightly counter-intuitive point).

eelkeblok → changed the visibility of the branch 3535538-status-quo to hidden.

I created an alternative merge request that removes the CDATA from the description. Let's see how the tests like that.

I wonder if this should be marked with core compatibility somehow? Although it also seems there was only a brief period in the 10.4 run when this was actually working?

eelkeblok → made their first commit to this issue’s fork.

Is there some sort of list of tooling that people would want to use (or rather: are using)? Obviously GitLab, and I suppose also the drupalorg command line tool by @mglaman (but I suppose that last one is less of interest because it is "under our control"). Any other obvious contenders?

One thing i do need to write of me is the fact I'm kinda agreeing with dww and cmlara on the issue as scope, keeping is full conventional commit style.

feat(#3165412): do stuff
...

I did push on the issue in front for scanability, but i think i was wrong in pushing when its non-conform tooling. :(

I've tried finding what conventional commits says about including issue numbers, bot the "conventional" (pun intended..) wisdom is that issue referecnes have no business in the header (I diasagree, and so do many others in this thread, it seems). The standard says, though:

A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):

See https://www.conventionalcommits.org/en/v1.0.0/#specification, point 4. I think the current proposed resolution answers to this well (it seems to differ from fjgarin's last post, though):

task: [#999999] Convert MediaSource plugin discovery to attributes

This also leaves open the option to use scope what it is meant for, I guess. In short: I wholeheartedly agree with the current proposal, love that we are getting commit messages with an actually readable headline.

eelkeblok → created an issue.

Merged. Let's see if this really is all that is needed.

I guess you’re right, if this gets fixed one way or the other. I do agree it is a duplicate and the other issue has more history. Maybe that’s the problem. This one is more concise.

Looks like a duplicate of 🐛 Forum access table template breaks on Drupal 10 Closed: duplicate . Feel free to review that and/or make changes if required.

eelkeblok → created an issue.

eelkeblok → created an issue.

I'll update the MR, since it is still against 1.x and the changeset looks scary (it is supposed to be a one liner, I think the problem might be it would apply all changes in 2.x to 1.x).

Upgrading the priority to major, since this issue breaks the main configuration entrypoint of the module itself as well as the administration of forums.

Not sure why I said to reproduce with D11 while the issue title says D10, because it is reproducible with D10 just as well. I'll update reproduction instructions. I can only imagine in your product it was fixed by overriding the default template, or something.

I don't recall to have specifically compared them, but I have now and they are still different. IIRC, it has something to do with a newer version of Twig that is in D10 when compared to D9. I don't think the situation has changed since july, so I expect the problem to still be reproduceable on Simplytest.

Have you tried reproducing? What are your findings?

Since we ran into this issue in the tmgmt_deepl module, we've moved the solution there, see https://www.drupal.org/project/tmgmt_deepl/issues/3546185 📌 Implement life cycle for translated documents Active

It was pointed out to me that tmgmt_file is meant to import and export translations through files, which is something very different. So maybe this is the right direction after all.

So I *just* noticed there is a tmgmt_file module, that at least has the hook_file_download down... Back to the drawing board.

eelkeblok → created an issue. See original summary → .

eelkeblok → created an issue.

eelkeblok → created an issue.

eelkeblok → created an issue.

I did some spelunking in Git, but the patch - in some form or another - has been in the module since the first version of the code. I'd be interested to know what happens when the patch is not applied at all. Will it always break, or only sometimes? Still, I think a better solution is to solve this through documentation on the project page and in the readme (and optionally the mentioned hook_requirements, if it is possible to somehow find out of the patch has been applied or not). Depending on the outcome of the test whether the patch is essential or just recommended, the addition to the documentation could be more or less prominent.

When using cweagans/composer-patches it is possible to ignore patches from dependencies: https://github.com/cweagans/composer-patches/tree/1.x?tab=readme-ov-file

I'm not sure why the patch was actually added. If you will always need this patch when using this module, this might be a way to get as many people as possible on this patch, although it does introduce some headaches, as we can see here. Maybe it is better to point people to the issue in the installation instructions, instead of hoping the project has composer-patches installed (of course there is a fair chance, but not a 100% guarantee).

Maybe for a really fancy solution, I'm not sure if there is a way to somehow "test" if the issue is resolved through code. If so, this could be done in a hook_requirement, so it is possible to point people to a bit of documentation about this.

What is the reason for hiding the branch?

Actually, I was completely wrong. This particular project has been using Symfony Mailer since the start, so I am unsure what changed (but something must have changed; our lines didn't used to be stuck together like they are now without the patch I created).

FWIW, and as I pointed out before, it is not true that whitespace does not have any meaning in HTML. Sur, it has very little meaning, namely that any and all whitespace in between elements will be equivalent to a single space, but that can be an essential difference.
If we do the very minimal and actually add an actual line break, I don't think HTML mails will suffer any consequences;

will not have a significant difference with

\n

. However, for non-HTML mails there is a great deal of difference between "https://example.comThis is the next line." and "https://example.com\nThis is the next line."

I guess. We could create queue items that contain ID ranges to remove. Limiting the time spent on processing the queue is a built-in feature, so we wouldn't need to do that ourselves. We would loose the ability to report on the time limit being exceeded, which would be an indication that a system is producing more logging than can be removed. And we'd need to start to do some bookkeeping to prevent duplicate queue items being created, assuming the queue (and thereby the logging) hasn't been fully processed before the next time cron runs (which is a save assumption; why do all this, otherwise 🙂).

Or maybe I am missing something obvious and you had something else in mind 🙂

greggles → credited eelkeblok → .

Updated the issue summary.

Would you please assign credit? It is important to my company. Thanks!

Great idea.

To answer #15, I guess the generic use case is when files are generated on the system instead of uploaded. In our particular case, we are generating PDFs from Drupal content, using node titles (and other field values) to determine the file name. These may include characters that are not suitable for filenames. We are phasing out the filename_transliteration module, only to find that it is not possible to call the core logic like it is with that module.

Updated IS.

eelkeblok → created an issue. See original summary → .

Weird. I looked through my Git history, but no details. Only confirmation that it was for Platform.sh. I do see that the project is on Redis 6.0 and has been since we added Redis. That's not supported anymore, not sure what the status was when it was added.

FWIW, I can't reproduce the original problem anymore. 🙃 I had this patch for a site on Platform.sh, maybe they've changed something.

I'm a little doubtful, as 📌 Abstract info-collection RedisController to deal with special environments Active is still calling config() to retrieve the value. I have been running with #28 on a project for a while now, that eliminates that completely. But maybe the condition in there is enough to prevent that from happening.

🙏

Refactored to use the new OO hook pattern.

Sorry to bump a closed issue, but I think a new issue might be overkill. I just spent some time debugging why Linkit was no longer working on my site. Turns out, this issue is "to blame", because my input formats did not have the filter enabled; we were in fact relying on the filter being optional. Might it be an idea to add a snippet to the releases notes for 7.0.7 → stating as much? E.g. "Note: Any input filter where Linkit should work now must have the Linkit input filter enabled."

The project is on Drush 13. I did find mention of a global -u option to set the user ID and the batch processing in Drush is actually trying to set it somewhere, but apparently this was removed in Drush 9, so that can hardly be a factor. Something is still off, though, since tests are failing.

eelkeblok → created an issue.

eelkeblok → created an issue.

The patch in 3150 unfortunately resolves the merge conflict between this patch and D10.5 incorrectly. The conflict is that the FileWidget settingform introduces a warning if the upload progress PHP extension is not available. The patch in #150 removes that again.

Here is a patch for D10.5 that retains the notice.

I also created MR 16 that simply adds the missing load include. Feel free to use whichever you like.

I think this is now good to go. Maybe a bit ambitious for a simple bug fix, let me know what you think.

Very sorry to re-open an old issue, but I have been running with the patch for this issue for quite some time. I just realised I still had this patch while the current release is marked as compatible with D10, so I wondered whether there was something else that fixed the problem. Removing the patch got me right back to this issue. I reproduced on Simplytest.me to rule out it was anything in my setup, and it is reproducible with a plain D11.2 as well. I tried to clarify the steps to reproduce.

If you would prefer to open a new issue, I would be happy to do that, but because it seems the original issue is is simply not resolved, I elected to re-open this one.

Examining the code, it seems to be a simple matter of a missing moduleHandler->loadInclude() in that hook. Maybe, though, this is a good opportunity to start converting Drupal 7-style includes to a modern Drupal serviche architecture.

eelkeblok → created an issue.

The entire article looks quite outdated, because:

• It is leaving open not using https as an option, and is talking about mixed mode, which nowadays is basically just a hassle and not worth it
• It is talking about Drupal 7

I reworded the section "Why is it important to you (and when)" to take this into account, but I ran out of time, so the rest of the article needs to be done. I think it can basically be simplified quite extensively, by removing all explanations about how to get stuff to work in mixed mode.

eelkeblok → created an issue.

Looks good. The test verifies the content of the displayed diff. I triggered the test-only pipeline, but that's silliness, of course, since we're not solving a bug. I functionally verified the patch in our project, code changes are minimal.

Since I am having difficulty getting the issue reproduced (and the bug report in our project is a little old), submitting a branch with only the test changes to see if it is still broken.

I just submitted the most basic MR implementing this idea, because I was running into the exact scenario of the duplicate search form. I did include the test patch, but nothing in the way of deprecation code yet. I did ponder it for a bit, but it is not evident to me how to deprecate this properly. Do we include a whole new function that people should call instead? If so, should this issue cover all core use of the old function?

eelkeblok → made their first commit to this issue’s fork.

I would say this should be a config dependency: https://www.drupal.org/docs/drupal-apis/configuration-api/configuration-... →

Correct me if I'm wrong, but shouldn't Simple XML Sitemap keep track of dependencies to other modules when a plugin is added to its configuration?

🙌 Excellent. I'll see if I can take a crack at that soon.

I ran into what appears to be the same issue and I think it is mostly unrelated to migration. There is an easy workaround, which is to remove the plugin reference from the configuration. Nevertheless, it can give some nasty effects when disabling a module that contains UrlGenerator plugins that are in use. I added some steps to reproduce.

I *assume* the OP was having this situation too. If not, my apologies. Let me know, than I'll create a different issue. Of course, the same could happen if the "custom" plugin got its plugin ID changed, which is basically the same thing; the configured plugin is no longer available.

I just found 📌 Support OOP hooks Active and noticed there that currently most hooks are implemented using the OO class_resolver pattern, which makes the official OO hooks conversion much easier. So we should at least change that, possibly do it all in one go if 📌 Support OOP hooks Active lands first.

Ah, I had not noticed this issue before. I added a hook_cron implementation in ✨ Add a cleanup function Active and did not use this pattern because of the Drupal 9 support (although I may have used some PHP features that rule out D9, not sure🫢). Will probably depend on the sequence of merging what needs to be adapted to what.

As expected, this didn't go flawlessly, I ran into out of memory exceptions.

• I added a batching operation, deleting 100 log entries at a time, with an cache clear for the entity storage in between.
• I added a time limit, so the hook cron will not run longer than 10 seconds.

Typically, I would say this is enough for most setups. Maybe it is worth mentioning somewhere in the documentation that if you consistently get warnings that the time limit was exceeded, you need to either increase the frequency the cron hook is ran (maybe with a reference to ultimate cron) or reduce the amount of log entries created.

Added a quick implementation using Cursor. I am not convinced the "just delete everything older than x" through the entity interface is a great idea. Especially if there is a large backlog I don't think it will finish in a reasonable amount of time. But maybe I'm mistaken, needs a little more testing (like with a prod database from my example project :) ).

See https://www.drupal.org/node/3082634 → . What this issue seems to need is:

• An updated change record
• A call to Drupal.deprecationError() referring to said change record
• A follow-up issue to actually delete the functionality in Drupal 12

Updated issue summary.

Adding the issue that this MR is currently rolling back.

@steven jones Thanks for that clarification. Our use case does not rely on the file being managed, so your proposal sounds fine.

Strictly speaking, when this is a security vulnerability, this should have been reported through https://security.drupal.org. The impact is fairly small, although depending on site styling an "empty" section might still have some impact on a page, I suppose. Maybe best to do so still, just to be on the safe side. Maybe the security team has means to remove public reference to the issue (like also the Git commits).