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.
RTBC, should be a easy merge. Can we get this in? LGTM
Very interesting work. Xhprof lead me to this issue, as I am tracking down a performance issues in a D10.2.x —site.
select name, length(value) from key_value where collection='state' and length(value) > 10000;
custom_fs_connector.basic_data | 808712
custom_fs_connector.info_type_name_list | 27342
custom_room_info | 304317
custom_fs_connector.course_code_list | 101678
This is information that not often change, tough by reading through the issue and try to understand what is going on, I would say, this data should not be stored here but the site custom module. From my understanding is this data that not often change.
Thank you for testing, however, the failing tests with patch needs to be addressed to make this pass code quality. Manual tests alone is not enough.
As both D8 and 9 is EOL, this alone should be enough to tag a new official release.
Thank you for the detailed feedback, will try to follow your workflow. Note: CK4 we up to now we install by using composer, example: "ckeditor/ckeditor": "dev-full/4.21.x" giving maintainers more control of libraries floating around in libraries.
We just got an quotation from https://ckeditor.com/ on 4.x support on a yearly contract. It is expensive, I mean really expensive. We are considering spending the money on developer time getting CK5 supported here in stead.
Thank you for all your hard work!
LGTM
Move this here. Not sure if this still is an issue? PHP execution timeout can be tricky with `max_execution_time` and `max_input_time` by PHP and other limits introduced by userspace.
Even if this was created by Sun, I suggest we close this as "won't fix" or outdated.
Is this something worth spending time on keeping up2date? Not changed since 2017 - https://www.drupal.org/node/417166/revisions →
Old and solved.
This change was not committed to the 7.x-1.x branch and unfortunately was not part of the 1.0 release. @joseph - Got time to cherry-pick and tag a 1.1 version?
Given the current activity on D7 modules it might be difficult to legitimise the use of developer/maintenance time doing so. The issue is marked with "needs tests" though the patch introduce a single test with two assertions. Not sure if the tag was not removed or that this is too little tests. That might tip the scale. We could create a new branch and move this to, 7.x-2.x as an experimental feature. Not sure we win anything by doing so?
+ 1 I guess quite a few of us is going to have D7 around until at least jan 2025 and beyond as we are working through backlogs getting sites to D10/11. I am mostly worried for PHP comparability against newer versions of PHP as PHP 7.x is EOL and infrastructure is getting upgraded around us.
We always roll patches against dev. to make sure it safely can be applied and works with the latest changes.