If we define #9 as a valid config, then the tests needs to be updated to fail on this type of config. Personally I have I never created such a config and my knee jerk reaction to it is, its sort of a hack.
@xlyz #21 yes, perhaps that is a feature that can be added later in the stable phase.
There is discussion in 💬 Is 3 alpha ready for production and what is the roadmap for a production release Active about what issues that needs to be fixed before 3.x get stable. Please join the discussion there. It might be the fastest way forward to a stable and covered release for Drupal 11, though I am only guessing.
Thanks for sharing your configuration.
Unable to reproduce on the latest versions, did not see the point of stepping down to the reported version. Looking at the code scopes default is 'scopes' => ['openid', 'email'] not sure with todays code that it could end up as a string.
Please re-open if you still can reproduce it.
I do not fully understand how this deprecation warning from core is related to PHP 8.2?
For running on a MariaDB backend perhaps I would work better with 📌 Create the database driver for MySQLi for async queries Active
So it stopped working after you upgraded to Drupal 11? If so, does it work if you duplicate this configuration of D10?
Please include the Search API reindex error and all module versions used related to Search API.
+1 to improve the out of the box accessibility. Changing this might break some people very specific styles but I think if we document how to alter the input type. I find the change too small to justify branching to 8.x-2.x.
I believe that the feature request for this is solved in 🐛 "Experimental" autosave on form change is enabled, but doesn't work. Active - I suggest that we close this and move activity to that issue.
Can this error be reproduced by only enable autosave and leave the node edit form open for a "long" time?
Is there anything holding this back from getting merged? Looks RTBC to me.
Confused. Is this issue about Drupal core Workflows module or are this about the contrib module https://www.drupal.org/project/workflows_field → ?
Regarding #45 - https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup could alter this specific deprecation
8 years have passed since last comment, something that made me wonder. Is this outdated? Do we have a way of protecting forms and/or CKEditor 5. Does CK5 have its own plugin that does this, or is autosave the way forward?
Contributed modules
- https://www.drupal.org/project/js_confirm_pop_up →
- https://www.drupal.org/project/saveguard →
- https://www.drupal.org/project/dirtyforms →
- https://www.drupal.org/project/node_edit_protection →
- others?...
Some projects dead, some with apparently very little maintenance and development, lacking CK5 support.
As 2.x no longer looks supported, I assume the supported upgrade path is from 8.x-1.4 to 3.x.
Perhaps when testing a code change we should recommend using drush deploy -v to make user testing more predictable? Here is a link to the order it run in https://www.drush.org/13.x/deploycommand
We are collectively moving away from patch to merge request - https://www.drupal.org/community/contributor-guide/task/create-a-merge-r... → Converting the patch to MR increases the changes for this be included.
Our production have been running the MR for about 20 days without any problem. I guess this is RTBC.
Thank you for moving this old issue to MR.
We are currently seeing this on Drupal 11.2.3 with both Olivero and/or Gin. What confuses me is apparently only a few seems to have found/triggerd this in 9 years. Anyone have a theory why this is? As tests does not pick this up, we might be missing? I was kind of expecting ::testEntityFormSharedElements() to fail.
Drupal version : 10.5.2
PHP version : 8.4.10
Fix our staging systems from failing, however, I suggest that this module drop support for Drupal Console Command for export synonyms. Drupal console is dead and as the 3.x is a new branch/version dropping it should be fine without breaking existing sites.
Bumping to critical as it as now, upgrading to 3.x stops sites from working.
PHP and field_permission create a lot of noise. Can we get this committed and a new release rolled? https://git.drupalcode.org/project/field_permissions/-/commits/8.x-1.x contains no other commits after tagging the current release making rolling a new release pretty quick.
Coming here from 🐛 Paragraph access check using incorrect revision of its parent, leading to issues editing and viewing paragraphs when content moderation is involved. Needs work . Regarding the recursive problem, I am reading this right that the first suggested change did not have any failing tests https://git.drupalcode.org/project/drupal/-/merge_requests/7063/pipeline... as the simplified approach have?
This is interesting. Bot still finds issues with 3.x on Drupal 11. If this is not a false positive, perhaps a new version should be rolled?
https://www.drupal.org/project/projectapplications/issues/3528842 📌 [1.x] & [2.x] Edit Media Entity in Modal Active was closed due to the maintainer not replying in issue. It needs to be re-opened.
Making the patch into a merge request (MR) increases. As the issue is tagged with needs tests and patch(es) contains none do I push this back to NW.
Thank you for your swift reply!
I have not got around to do a code review though it is a small module and I think it might be wise to keep it like that for now and if more people pick it up, grow on demand. We are currently in the process of exploration, I know that we would like to catch from production. For sure request time on specific routes perhaps with Drupal dynamic cache state. Generating performance base line for Graphana etc.
For us org. a stable release and perhaps a opt in of https://www.drupal.org/drupal-security-team/security-advisory-process-an... →
https://thephp.foundation/blog/2025/06/08/php-30/ - 30 years of PHP: FrankenPHP is now part of the PHP organisation
Lets try a keep PHP 8.4 happy, RTBC
Lists like this is not really useful to the maintainers. You should create separate feature requests, with details why this is a good idea.
Old, if issue is still something to implement, I guess 3.x is where it will happen.
+1 to default setting match current behavior. If we want to change the default in the future, what about including a message in watchdog or status-page that there now is a new setting that controls the module role behavior, that should be verified? I provide admins ample time to review and test the implementation. The module can through the issue queue get feedback on this new behavior before changing the default in the future. Though it should perhaps be done before rolling the first beta of 3.x.
Drive by review, but our sites have been using the change to src/PathProcessor/TvpProcessor.php for months with no problems. It solved the issue for us.
The MR contains some changes perhaps unrelated to the issue, but as the module currently are lacking these changes, it is doing not harm. Perhaps they should be part of another MR though. Looking at 📌 Integration with Gitlab CI Active
The module seems a little dead tough it would be nice if we merged this making it easier for sites to test the module on Drupal 11. Support for 8.x should it be fine to drop, though, it should be in a 2.x release.
Thank you for contributing. It would help the maintainer and increase your changes for getting the change in, if you create a MR instead of a patch https://www.drupal.org/community/contributor-guide/task/create-a-merge-r... → The MR should apply against dev. not a specific version.
I nominate ✨ Add _csrf_confirm_form_route option for to the user/logout route Active To a list of issue that should be fixed before first beta. Maintainer needs help there doing manual testing.
Moving this to RTBC. The code change is small and MR 99 still apply. Multiple people have confirmed it works for them though we have no details about what site config they had.
- #34 have not been answered, but the change seem to address the problem for those that have it.
- Do we need tests?
@frob wrote:
I think the worry is around how you define Alpha.
My worry is if there are going to be any significant, backward incompatible, changes to the software. I'd say if you consider this to be Feature Frozen then it should, at least, be considered a beta --even in it's current state.
Here I have to agree. Alpha to me, indicate that there is more than bugs and missing tests needed to be fixed, but non of that mention in #10. If not, I would love for us changing to a beta tag.
Eh. looking at the 4.x branch and there from what I can see there is nothing to do.
Bot changed status, but I think it is ready for review?
So.... it some kind of race condition perhaps from these two?
$page->pressButton('Save and continue');
$page->pressButton('Create group');
+1 from me. Perhaps make the change to only 3.x, avoiding potential breaking sites with exiting functionality?
Excellent, we was looking for a branch that supported and was a little confused why 📌 Automated Drupal 11 compatibility fixes for search_api_synonym Active was closed.
I am guessing you would like some feedback on this patch from the maintainers. To make increase changes for it to be merged you should consider changing it to a MR (merge request).
Assume that feature request goes against 2.x. The issue also needs to stop the patch rolling and make a proper MR.
We should close this as outdated
It is simple module, but as now, it lack maintenance, so perhaps adopting it to core would be good thing? The uniqueness support should be useful in core. We currently we roll custom code making sure we do not queue identical items coming from an external RabbitMQ system.
Should we block this issue on 🐛 Fix PHP 8.4.x deprecation and other warnings (PHPStan) Active that I think should be committed first?
Reopen. This issue was closed as a duplicate of [##3106445] but clearly it was not fixed. We see this (Latest stable version of Drupal 10) and other.
There is a new MR that seems to address this that needs a review.
It would be nice getting this merged and a new release rolled supporting PHP 8.4 without the deprecation warnings.
https://www.drupal.org/project/datetimehideseconds/releases/8.x-1.5 → contains a stable D11 release. Closing as outdated.
The module looks a little dead. We moved away from it and simply just used php-amqplib/php-amqplib directly in a custom module. We needed custom code anyway.
Is there anything that is holding this back?
@vincent signoret Already fixed, though a new release new release containing the fix have yet not been rolled
✨
Support for Gin Admin Theme 4.x
Active
Fantastic work @mondrake! Great idea.
Think it is safe to classify this as a bug in hook_update_N() running upgrade from D7. Also seems to be a 8.x beta blocker.
A feel it is little unclear, should the MR be moved back to "needs review"?
A release plan of first beta/RC allowing the maintainers to list what is currently "blocking" a stable release? Would also allow users to jump in on those issue and perhaps help out getting them tested and merged. The maintainers are very active, but it would be helpful (at least to me) to see a release plan. Still on alpha often means there are features missing...
Looking at the MR, I think this is ready for review by maintainers.
Thank you :)
I think we safely can close this with won't fix
For what it's worth, confirm that this two liner addresses the problem.
Tagging with Performance. I think @catch have the habit of checking that tag, might have some valuable feedback on the MR. I have none.
We are also seeing this, and yes, we are using the Features module.
Thank you for bumping issue. Linking a still open issue, though perhaps issue should just be closed as wont fix/outdated? A drive by review of the MR, small and clean with passing tests. The IS would do with some love though.
Does anyone know if if hybridauth library 2.x is getting any TLC? The releases seems to have stopped in 2019 with https://github.com/hybridauth/hybridauth/releases/tag/v2.17.0
I am not fully up to date on how https://www.d7security.org/ workflow is suppose to work. How we get an module moved there. But if more than us still rely on this module, and are at the same time, as we are, pushing PHP version up to minimum 8.1 perhaps we should apply the project here and try to get the MR in and roll a new update? User login and EOL is an attach vector.
Here is the link to first 3.0 for anyone looking for it. https://github.com/hybridauth/hybridauth/releases/tag/v3.0.0
It is very noisy, this change would be good to have heading into EOL for us all.
Issue 🐛 Ensure visibility of invalid fields (JS) Fixed is now fixed in 4.x. and there is follow up issue from that that might be useful to keep an eye on 🐛 Multiple required fields on multiple tabs do no trigger frontend validation Active . Not sure if we should postpone this issue on that. Changing to NW.
Thanks for working on this. Ended up here coming from 🐛 HTML5 Validation Prevents Submission in Tabs Postponed: needs info
I noticed that the MR target changed from 8.x-3.x to 4.x and as result, non of the changes here was committed to 8.x-3.x. Is the plan to only fix this in 4.x? If so, I am a little concerned, as 4.x is only in alpha1 and site policies will probably block them from upgrading to an early alpha, if alpha at all and I guess most field_group installations is on 8.x-3.x branch. Can you elaborate on what the plan is. Sorry if I missed this in any of the comments above.
Unable to reproduce. Could have been related to the editor not loading if only a single input format is available. That could explain why admin did not see this. Current 7.1.x or 7.2.x doe not have this problem.
One liner that fix the issue with PHP 8.x
+1 to get a Drupal 11 version.
Thank your working on a D11 version of this. Should not dropping D9.x support require a new major version (2.x.x) ?
+ core_version_requirement: ^10 || ^11
Unblock as 📌 Fix PHP 8.1 compatibility issues Fixed is fixed.