🇺🇸United States @will_frank

will_frank → created an issue.

It's hard for me to tell when you're going to be able to produce a new
release of this module that fully satisfies the upgrade_status module report.
It will need both the change to the yml file and what is in this merge request too:
nicolasgraph opened merge request !5
Fixes user_role_names() deprecation

Just as a reference I've produced a patch that satisfies both of these things.
I'm not trying to replace the work you seem to have almost ready but just in
case this might help. (see scn.patch file). Since we're trying to prepare for Drupal 11
for now we're using our patch but we would prefer to use your new fixed version
when it is available.

I've created a patch file which makes this module compatible with Drupal 11.
It fixes this file: web/modules/contrib/formtips/formtips.info.yml
see formtips.patch file

will_frank → created an issue.

will_frank → created an issue.

Hoping these comments might help further pin down the problem.

Using the upgrade_status via the UI and running scans
we see the most of these errors for themes, like
Seven 1214 problems
Bootstrap Barrio 1907 problems.
Might the problem have to do with twig code static analysis in particular.

We have updated Drupal Core to 10.3.5 and we noted this following in the
10.3.4 release notes:
The Twig templating library has issued a security advisory. Drupal core is not vulnerable, but previous versions of the drupal/core-recommended package only allowed insecure versions of Twig to be installed. This patch release upgrades Twig to 3.14.0 as a public security hardening.

We ran into the same error in our 'local' config split and when I applied the same fix
that @sp3boy used it works. I do think that *either* the fix in #1 should be added and/or
the hook fixed so it updates the appropriate stage_file_proxy.settings.yml files in
config splits. If this cannot be fixed soon, I urge that the previous version of this
module Stage File Proxy 2.1.4 be modified to stop reporting this following way:
"Release not supported: Your currently installed release is now unsupported, and is no longer available for download. Uninstalling everything included in this release or upgrading is strongly recommended!"
At least until this issue is fixed.

Followup question is the proposed fix I see here (see url below) considered a suitable patch
or is work going on to do a more complete fix?
https://git.drupalcode.org/project/stage_file_proxy/-/merge_requests/74/...

I can confirm that this issue exists and is blocking updating to 3.1.0 (2024-Jul-21).
This is troublesome because my "Available Updates" reports in relation to my currently
installed version of Stage File Proxy 2.1.4:
Release not supported: Your currently installed release is now unsupported, and is no longer available for download. Uninstalling everything included in this release or upgrading is strongly recommended!
This implies I must update but I'm blocked because of this issue.

batigolix → credited will_frank → .

I have produced a new patch that works for us on Drupal core 10.1.4
and Flood control 2.3.3.
see
flood_control_2.3.3_d10.patch (30.44 KB)

@KalaiyarasiThangavel yes you're right. I've been working trying to produce
a new patch for flood_control 2.3.3 but so far without success. If anyone has
a solution I would love to see it.

Hi @star-szr,

Thanks for the quick response!
I tested with the "Filter Pasted Content" unchecked.
The result was the same during pasting. I.e. the footnote number 1 was
removed from the a href tag. Note that if I then typed it back in while the
editor was in source mode and toggled back and forth in and out of source
mode the footnote number stays. The same when I save a draft of the article.
So the problem is only during the paste operation.

As for the actual footnotes at the end, for our purposes we aren't worried about
them. This whole initial pasting of an article for us is just so our content editors
can create footnotes a different way that we have created. I won't bore you with
the details except to say that our footnotes work across multiple paragraph articles.f
So if we could get your module to preserve that footnote number inside the a href tag
that would be great for us.

will_frank → created an issue.

@sonneworks
We have succeeded in creating a new patch based on your idea. Many thanks.
This works on Drupal 10. Likely this patch only will work with sites that are using
redis.

@sonneworks - is it possible that you might have changed other parts of the code
besides the FloodControlServiceProvider::alter method to get it to work?

One idea is that if you don't have a full patch file ready, perhaps you could
just zip up your entire flood_control module (all the files) and email it to me
at fwilliams7070@gmail.com and I'll try it - and if it works I could produce a patch.

sonneworks - I'm eager to try your new fix but so far have not been able to get
it to work. Could you either:
post your entire new FloodControlServiceProvider::alter method
or
if you have produced a new patch based on this fix could you post that? thanks will_frank

To add a bit to my previous comment, I've been getting the same error using
flood_control_2.3.2.patch (see #59) but the patch worked on Drupal 9.
Something is going on with dependency injection but I haven't been able to figure
out what the problem is. I hope you can figure it out for
patch (62) flood_control-support_external_flood-2928007-62.patch so it can work
on Drupal 10.

With Drupal 10.0.9, and Flood control 2.3.2
with this patch (62) flood_control-support_external_flood-2928007-62.patch
I'm getting this following error:
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "flood_control.flood_unblock_manager". in Drupal\Component\DependencyInjection\Container->get() (line 157 of core/lib/Drupal/Component/DependencyInjection/Container.php).
Drupal\flood_control\Form\FloodUnblockAdminForm::create(Object) (Line: 28)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition('\Drupal\flood_control\Form\FloodUnblockAdminForm') (Line: 48)
Drupal\Core\Controller\HtmlFormController->getFormObject(Object, '\Drupal\flood_control\Form\FloodUnblockAdminForm') (Line: 58)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 686)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

We are experiencing this same issue on Drupal 10.
I tried installing and enabling drupal/flexible_permissions first
before installing drupal/group:^2.0
What we still see is:
The service "group_permission.calculator" has a dependency on a non-existent service "flexible_permissions.chain_calculator".

We are currently on Drupal 9.5.7 and working to prepare to migrate to Drupal 10.
We use the formtips module 8.x-1.5 and the Upgrade Status module reports that formtips is not
yet compatible with Drupal 10. So I applied the patch you have for that:
https://www.drupal.org/files/issues/2022-12-30/Drupal-10-compatibility-f... →
and then the Upgrade Status no longer says it is not Drupal 10 compatible. So far, so good.

But when we try running composer to upgrade to Drupal 10 we still get this error:
Problem 2
- Root composer.json requires drupal/formtips ^1.3 -> satisfiable by drupal/formtips[1.3.0, 1.4.0, 1.5.0, 1.x-dev].
- drupal/formtips[1.3.0, ..., 1.x-dev] require drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but it conflicts with your root composer.json require (^10.0).

Perhaps I'm not doing something right.

So two questions:
1. are you going to release *soon* a new version of formtips that will be Drupal 10 compatible.
2. in the meanwhile can you advise me so I can get Drupal 10 installed with your current version but patched?
Any help appreciated.

We have produced a new patch that works for us with Redis on Flood control 2.3.2.
See attached flood_control_2.3.2.patch.

Original discussion of the issue of CKEditor5 *not* retaining non-HTML5 tags began
in this parent issue:
https://www.drupal.org/project/drupal/issues/3280124 ✨ [PP-1] [upstream] Consider allowing styles for non-HTML5 tags Postponed
and we have created this separate child issue to track this.

We have done further investigation into the issue of CKEditor5 *not* retaining non-HTML5 tags
and filed a separate child issue. For details see:
https://www.drupal.org/project/drupal/issues/3335991 🐛 [upstream] [GHS] CKEditor 5 does not retain custom HTML tags that are not defined by CKEditor 5 plugins whenever /.*/ is not allowed (e.g. when filter_html is enabled) Postponed

will_frank → created an issue.

To answer Wim Leers question:
"What tag are you using? Because AFAICT it never worked in CKEditor 4 either. If you can prove it worked in CKEditor 4, that'd change things."

Our site is currently Drupal 9.5.1, using CKEditor. We have used CKEditor since our launch a couple of years ago with Drupal 8.

Attempting now to upgrade to CKEditor 5, we are encountering that a custom html tag we have been using is now:
1) being stripped out from the content entered in CKEditor 5, and
2) the custom Style we've used to apply this tag is no longer allowed by CKEditor 5 and had to be removed before the text format could be saved.

The custom html tag is 'fnote'. We have had this tag is in the "Allowed HTML tags" filter of the text format.
The custom style for this (in the text format's Style drop-down) is:
fnote|Short footnote

As mentioned, this has worked fine for our site, using CKEditor, since our launch a couple of years ago now. The content of the tag is processed and transformed into footnotes during the page rendering (this 'fnote' tag is no longer present in the rendered, cached, content), having nothing to do with CKEditor anymore. The tag is entered by the user and saved, with the tag, to the database. Up until now CKEditor has allowed and saved this tag without complaint.

If we are not able maintain this functionality, the 'fnote' tag in our existing content will be removed the next time content is edited, and we would have to rewrite our footnote module and change thousands of pieces of content to correct it.

When we change the text format to use CKEditor 5, we find that the Style drop-down will now only accept standard html5 tags, and throws an error until the offending 'fnote' is removed from the Style list. We also find that other lines in the Style list are not allowed even though they are standard html. The message is that since these are in the Source editing list they can't be in the Style drop-down.

We could deal with that by manually editing, which we tried: In the new CKEditor 5, we added this 'fnote' tag to the new Source editing field of the text format (actually, the migration process from CKEditor->CKEditor5 added it there), and the tag is in the "Allowed HTML tags" field. BUT, when we edit content, select Source, and enter the 'fnote' tag, it is stripped out by CKEditor as soon as Source is clicked again.

Our main concern is that CKEditor 5 strips out the 'fnote' tag, which as mentioned would affect a great deal of our existing content. If we have to we'll have our users enter 'fnote' manually.

We see that CKEditor 5 itself (upstream) now seems to have no problem retaining a non-standard html tag. Is the problem related then to the Drupal module? Do we need to configure something? Are we doing something wrong?

As mentioned, this non-standard, custom, html tag ('fnote') has been allowed and accepted by CKEditor all this time until this upgrade.

Please see attached screenshots of existing functionality. (FYI, we have two choices with for our users: short and long. The long version is 'fnote class="fnotelong"'.)

I have a question. This issue is blocking us from adopting CKEditor 5
because we have a custom style that generates a non-HTML5 tag.

The question is given recent signs that this issue has been addressed
(see https://www.drupal.org/project/drupal/issues/3268306 → point 20
where Wim Leers states
But today (thanks to #3301495: Update CKEditor 5 to 35.0.1), it gets converted to:

p

yo

So … the bug has indeed been fixed upstream!

So is a patch already available for this issue to try a fix? Or is a fix
coming soon. I would be happy to test if something is available.