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.
I read through the MR changes and unit including the kernel tests for the API change, looks OK. Also tested the hook_update_N() on HEAD. The change recored looks OK. We prob. still need initiative maintainers to step in? But except that, I think we might be done.
The MR is doing its thing correctly with a passing test. As the issue is still tagged with it needs we to pass a usability gate I feel I should not set it to RTBC, however, I think we are done in here.
After digging into this, I do not think we can fix it during the sprint, however there is a few things that worry me here:
It the assumed performance regression test fail we are seeing coming from taxonomy_term_data table and is now in the taxonomy_term_field_data table?
If I am reading this right, we dictate that ->setTranslatable(TRUE). Do we want to do that? Should this not be an option, most people might not want/need this behaviour?
Moving back to 11.x as we are addressing this in HEAD. As we are looking into this on sprint in Barcelona
This issue seems to have stalled out. Reading through and I get a feeling that it might be close to ready, but is in dire need of a manual rebase as #146 indicate. On the performance profiling, should not our Gander setup now be able to tell us if we have regressions based on changed to the registry size?
Tagging to make it easier for persons like @catch to spot it.
Needs a manual rebase against 11.x
Please not post on closed tasked. Open separate support requests if it is not working.
To help getting this committed have I applied this into one of our production sites. I'll also make sure to send testers in there and take if for a spin.
Driveby review, but the proposed changes makes sense, it should be there.
steinmb → changed the visibility of the branch 850600-postgresql-driver-doesnt to hidden.
I am a little confused here. In ✨ PostgreSQL driver doesn't support SSL option Needs work is there indication that there is no SSL support but in this issue we have
+ * For requiring an SSL connection to a PostgreSQL database add:
+ * @code
+ * $databases['default']['default'] = array(
+ * 'init_commands' => array(
+ * 'sslmode' => 'require',
+ * ),
+ * );
Going through older form API issues and found this. D9.x got
https://www.drupal.org/commitlog/commit/2/08ff47b5fd1e9ff1039dba129ac1c4... →
What is left in here? Are we done?
Found note on order reading up on 🐛 HTML5 validation is preventing form submit and not fully accessible Needs work
- Javascript validation first
- HTML5 validation for no-Javascript
- Server-side validation
Reviewing form API and found #2203649: Remaining Open Form API related Accessibility Issues → that took me here. This issue looks like it stalled, anything people can do to move it forward?
This simple oneliner have been sitting here for 2y, is there any active maintainers in here or? And, yes. RTBC.
Seems to be coming from #2508759: set default 'Image Size' (useful for responsive Picture settings) → - Any other suggestions than the MR guards?
Digging into a some performance issues on a site. Noticed this issue. Still needed or? The IS point to https://github.com/zendframework/zend-diactoros/blob/master/src/Response... that is archived and moved to https://github.com/laminas/laminas-diactoros/tree/3.4.x/src/Response that longer have this interface, could be renamed/moved though.
After 9y do I think we can unassign.
Thank you for the MR. Anyone know how to reproduce this error?
Assume this is a feature req. and as most of them, they are not critical. As the assigned person have not posted on about 7y, unassigned
Drive by review. RTBC
From my understanding does this module not support wildcards. I might be wrong, let's hear it from the maintainer.