- First commit to issue fork.
- 🇺🇸United States papagrande US West Coast
I forgot to mark this as fixed after I merged the MR yesterday.
Thank you for the reviews, but when reviewing patches and merge requests, you must also review the code for quality and test the functionality to confirm that no regressions are introduced.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
-
lobsterr →
committed 104c45d1 on 1.0.x
Issue #3430842 by lobsterr: Automated Drupal 11 compatibility fixes for...
-
lobsterr →
committed 104c45d1 on 1.0.x
-
lobsterr →
committed e75f8c52 on 2.0.x
Issue #3430842 by lobsterr: Automated Drupal 11 compatibility fixes for...
-
lobsterr →
committed e75f8c52 on 2.0.x
-
lobsterr →
committed d83482d3 on 3.0.x
Issue #3430842 by lobsterr: Automated Drupal 11 compatibility fixes for...
-
lobsterr →
committed d83482d3 on 3.0.x
- 🇬🇧United Kingdom scott_euser
In any case I tested upgrading to D11 and my form alters continue to kick in fine, so perhaps no harm in merging and releasing to give people time to transition to the new oop hooks.
- 🇬🇧United Kingdom scott_euser
That's probably fine, though I think there are still some unsupported hooks. For example I could not get Paragraphs ones to work with Core yet https://www.drupal.org/docs/contributed-modules/formalter-as-plugin/alte... → - so it could be that we need this module a little longer (or maybe I just haven't done it right!)
-
svendecabooter →
committed 1787f1bc on 2.0.x
Issue #3451130 by project update bot, svendecabooter, arousseau:...
-
svendecabooter →
committed 1787f1bc on 2.0.x
- 🇬🇧United Kingdom scott_euser
For maintainers, would suggest credit granted to username `skaught` for the deprecation fix of system timezone call per 🐛 core depractions of system_time_zones() in 10.1 Active which is now part of this (even if the MR author didn't use it, to acknowledge the efforts of `skaught` there)
- 🇬🇧United Kingdom scott_euser
This looks good to me but at the moment only you can unmark it from being a draft it seems @mnfriend.
- 🇬🇧United Kingdom scott_euser
scott_euser → changed the visibility of the branch project-update-bot-only to hidden.
- 🇬🇧United Kingdom daniel.j
I've made some changes and tests are now passing.
For the phpunit functional JS tests, in some places moving away from jQuery to native JS has allowed the tests to pass. Additionally, I've added a `composer.libaraies.json` file in order to add clarity to the library versions that are being used.
Please review, thanks.
- 🇫🇷France arousseau
Hi! It seems the webform_iban_field is missing the change to
core_version_requirement
to make it compatible with Drupal 11 Automatically closed - issue fixed for 2 weeks with no activity.
- 🇭🇺Hungary jan.mashat
Version 3.3.0 has been released with Drupal 11 support.
Automatically closed - issue fixed for 2 weeks with no activity.
- 🇧🇪Belgium bart lambert
any chance of pushing this to a stable version soon? would be appreciated!!!!
- 🇮🇳India vinodhini.e chennai
Applied the patch #2 and successfully installed the module on Drupal 11.0.1.
Attached the screenshot for reference.
Thanks for the patch!
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
@bramdriesen: there is an open issue encouraging D.O. to adopt the fork positive workflow: #3452328: Prohibit the ability to adopt a project. Never let a Drupalism stand in the way of better security. Just because it is how it has always been done does not mean it is a secure process. As a future Full DST member it is your responsibility to always argue for the more secure software development path not the easiest.
Oh yes, don't get me wrong here :-) I'm all ears and eyes for a more secure process around the whole project maintainership. I just stated what is currently in place and that someone else in fact can become maintainer without intervention of Lee. Hence why I also created https://www.drupal.org/project/securitydrupalorg/issues/3500263 📌 [META|POLICY] Think of a way to make it less easy to become a (co-) maintainer Active as a result of the bulk maintainer requests of TATA.
The issue title: ✨ Prohibit the ability to adopt a project Active does not sound like a thread to adopt forking. So that might need some work as well if that's the intent (didn't read the whole thread yet).
- 🇸🇮Slovenia icurk
Above patch didn't work for me. Here is a working patch.
- 🇮🇳India vinayakmk47
Hello, Thank you for providing the automated patch and details regarding Drupal 11 compatibility. I have manually tested the changes and verified that the module works as expected with Drupal 11. Automated tests were also run successfully.
The patch #2 updates the info.yml file and other compatibility changes correctly align with Drupal 11 requirements. Marking this issue as Reviewed and Tested by the Community. 🎉
check the before and after screenshot.
- 🇨🇭Switzerland tcrawford
I created MR 16 (against 2.x) that also contains the changes to the info file. This needs a review.
- @tcrawford opened merge request.
- 🇨🇭Switzerland tcrawford
This issue was created against 2.x and MR 15 does not apply against 2.x (only 1.x). MR 12 does not adapt the core version requirement. Therefore, I am placing this issue back to needs work. I suggest to create a separate issue for Drupal 11 compatibility for 1.x.
Automatically closed - issue fixed for 2 weeks with no activity.
-
papagrande →
committed 445b7317 on 2.0.x authored by
project update bot →
Issue #3435634 by papagrande: Automated Drupal 11 compatibility fixes...
-
papagrande →
committed 445b7317 on 2.0.x authored by
project update bot →
-
ahebrank →
committed daf5c82d on 2.0.x authored by
project update bot →
Issue #3429777 by project update bot: Automated Drupal 11 compatibility...
-
ahebrank →
committed daf5c82d on 2.0.x authored by
project update bot →
- First commit to issue fork.
-
ahebrank →
committed 27be6bc5 on 1.3.x authored by
project update bot →
Issue #3435389 by project update bot: Automated Drupal 11 compatibility...
-
ahebrank →
committed 27be6bc5 on 1.3.x authored by
project update bot →
- First commit to issue fork.
- 🇨🇦Canada danrod Ottawa
It seems like I don't have permissions to create a new release :( but you can always get the dev D10/11 version: https://www.drupal.org/project/brokenlinks/releases/8.x-2.x-dev →
- 🇨🇦Canada danrod Ottawa
It seems to be working, does anyone have a valid license that I can use? Otherwise I'll just create a new release and report the problems please.
- 🇨🇦Canada danrod Ottawa
I can't believe some people (2!!!) still use this module, of course I'll upgrade it to D11 (if that helps getting more users :))
- 🇬🇧United Kingdom leewillis77
@cmlara This is indeed, exactly my point (explained far more eloquently than I managed) and I can't see that any existing mechanisms mitigate that issue, hence my chosen course of action.
I do want to mention there is a good chance D.O. Staff will eventually override you either through site ownership queue or the Project Update Working Group and force either a D11 fix or a new maintainer into the project
To clarify, I have no issue with the project being passed on to a properly vetted user. I just don't have the time / resources to ascertain who that might be.
- 🇺🇸United States cmlara
As a security engineer I agree with @leewillis77 assessment.
Announcing you will not continue developing and allowing users a chance to find an alternative is basic secure maintainer ethics.
Won’t fix is a standard method to signal a patch will not be merged.
Despite how D.O. attempts to downplay it owners are indeed (ethically) responsible for any maintainers they add to a project.
The XZ back door last year is an example of a security incident that nearly compromised a major portion of the Linux community, the cause, overworked project owner adding a developer they could not properly validate and supervise.
@leewillis77 FYI this is originating out of
💬 Offering to co-maintain Active . The user came onto Slack seeking assistance to bypass your refusal to add them. @bramdriesen likely isn’t advocating for that user (we have an open abuse issue for TATA employees) however is expecting that some day the module will eventually be D11 compatible.More details in 💬 TATA Consultancy Services is bulk posting requests to gain maintainer access to modules Active .
While I agree with how you are handling this I do want to mention there is a good chance D.O. Staff will eventually override you either through site ownership queue or the Project Update Working Group and force either a D11 fix or a new maintainer into the project, messages like offering to become a maintainer are a step one in that forceful takeover process.
@bramdriesen: there is an open issue encouraging D.O. to adopt the fork positive workflow: ✨ Prohibit the ability to adopt a project Active . Never let a Drupalism stand in the way of better security. Just because it is how it has always been done does not mean it is a secure process. As a future Full DST member it is your responsibility to always argue for the more secure software development path not the easiest.
- 🇬🇧United Kingdom leewillis77
Or in your case: https://www.drupal.org/node/2332703#s-giving-up-a-project →
That still reads as though the onus would be on me (to manage an issue in this project's queue, and another in the Project Ownership project queue), and (more importantly) doesn't state anywhere how any such new owners would be vetted and whether I would need to invest time in the process. If there was a clear process for this I would follow it, but there's not and I've already spent *far* too much time debating this already.
I will be supporting this module until D10 goes end of life. I will not be accepting patches for D11 compatibility. I will not be releasing, or supporting a D11 version. This issue will remain as "Closed (won't fix)".
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
This is the process: https://www.drupal.org/node/2332703#s-strategies-for-finding-new-maintai... → usually other maintainers vet for each other over there.
My closing the issue doesn't stop someone taking the existing code and fixing up any issues if they want to, and it doesn't stop them releasing a D11 version of the module.
That would mean forking, which is by my understanding, a discouraged process for Drupal Contrib. Hence why there are project transfership processes and processes to become a co-maintainer if a module is no longer maintained or the user is no longer around.
- 🇺🇸United States tderego Starkville, MS
Successfully installed on a local Drupal 11 site with patch.
Confirmed functionality works as expected.
- 🇬🇧United Kingdom leewillis77
Abandoning means anyone could become co-maintainer without your intervention. They will be vetted by the projectownership team (Drupal.org site moderators).
I haven't seen any documentation that clearly states that that is a valid process. The document you linked to puts the onus on me to find and vet a suitable replacement. Perhaps https://www.drupal.org/node/2332703 → needs to be clearer if that is an option.
I don't understand why you keep closing it
Because I don't have the bandwidth to deal with it. My closing the issue doesn't stop someone taking the existing code and fixing up any issues if they want to, and it doesn't stop them releasing a D11 version of the module.
Also you can have other people do the vetting, you don't have to bother with that if you don't want to.
If there's a defined process for that happy to hear about it.
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
I am not offering a version at Drupal 11 or above. As I said previously in this thread I do not have the time to vet co-maintainers, and transferring ownership to an unvetted new owner would be a significant security risk.
Abandoning means anyone could become co-maintainer without your intervention. They will be vetted by the projectownership team (Drupal.org site moderators). Leaving an issue open does not implicate it will ever be merged (by you as you have clearly made that point). I don't understand why you keep closing it, just leave it open so others can find it and test it and if any issues arise, fix them here. If you merge them or not I don't care. But leaving this open invites other people to contribute. Even if you've set the status that the module is no longer maintained (by you).
Also you can have other people do the vetting, you don't have to bother with that if you don't want to.
- 🇺🇸United States tderego Starkville, MS
Successfully installed on a local Drupal 11 site with patch.
Confirmed functionality works as expected.
-
ahebrank →
committed 3c7a86ec on 2.0.x authored by
project update bot →
Issue #3433972 by project update bot: Automated Drupal 11 compatibility...
-
ahebrank →
committed 3c7a86ec on 2.0.x authored by
project update bot →
- First commit to issue fork.
- 🇺🇸United States tderego Starkville, MS
Successfully installed on a local Drupal 11 site with patch.
Confirmed functionality works as expected.
- 🇬🇧United Kingdom leewillis77
Please explain how an compatibility issue for D11 that is not merged, has the status needs work or needs review would make it look the module is compatible?
It sets an expectation that the changes will be merged at some point. They won't.
Well that basically means you are abandoning the module
I am not offering a version at Drupal 11 or above. As I said previously in this thread I do not have the time to vet co-maintainers, and transferring ownership to an unvetted new owner would be a significant security risk.
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
That's a big assumption.
Not really, that's how the past upgrade bot issues have tackled many module upgrades. It helps with deprecations and core changes for example. It does not actually test the module, but code wise it does verify any issues between major versions of Drupal.
That would set an expectation that the module is supported on Drupal 11, which it is not.
Please explain how an compatibility issue for D11 that is not merged, has the status needs work or needs review would make it look the module is compatible? It would only be compatible if there is a tagger release with D11 support.
Please just leave this open as the bot would also fix future incompatibilities if there are any to be added. Closing this won't help the module nor the community in finding this.
I am not willing to spend the time reviewing, testing and being responsible for contributions to this module. I no longer work with Drupal day-to-day and my open-source time contributions are focussed elsewhere.
Well that basically means you are abandoning the module, and thus you might want to have a read at this: https://www.drupal.org/node/2332703 → Other people might try to apply for co-maintainership then through https://www.drupal.org/project/projectownership → . Since you're not willing to maintain it, you should create a new issue in this queue that you are looking for new co-maintainers and see if someone who is more experienced with the module steps up to take up that role.
I don't track Drupal core development and I have no idea whether or not other changes would be required and I'm not willing to just push a release based on automated fixes without testing that it works myself.
Sure, that's your call to make. But please just leave this open, like all contrib modules do...
-
berdir →
committed 3dc2cdf6 on 8.x-2.x authored by
project update bot →
Issue #3430773 by berdir: Automated Drupal 11 compatibility fixes for...
-
berdir →
committed 3dc2cdf6 on 8.x-2.x authored by
project update bot →
- 🇬🇧United Kingdom daniel.j
daniel.j → made their first commit to this issue’s fork.
- 🇬🇧United Kingdom leewillis77
Just going to jump in here. As the upgrade bot is stating, just merging this patch/MR would make the module compatible with D11. That would take no more as 5 minutes, so in the time you've written those two comments, you could have probably merged it and tagged a new release 😉.
That's a big assumption. I have *no* idea of whether that is true or not, however in order to be a responsible maintainer I would have to spin up a Drupal site, and test in order to be happy to release. I don't track Drupal core development and I have no idea whether or not other changes would be required and I'm not willing to just push a release based on automated fixes without testing that it works myself.
Note that no one in this issue is asking for co-maintainership, the issue you are referring (which you closed) was indeed a bit... far fetched to be granted. But that should not hold back any other contributions being made to this module.
I am not willing to spend the time reviewing, testing and being responsible for contributions to this module. I no longer work with Drupal day-to-day and my open-source time contributions are focussed elsewhere. In the absence of that, contributions to this will not be accepted, beyond my existing commitments to support it on Drupal ^8.9 || ^9 || ^10 - hence the closure of this issue.
> So at least, let's keep this issue open so people needing it can use Drupal Rector to facilitate the patch from this issue to proceed with their upgrade path to Drupal 11.
That would set an expectation that the module is supported on Drupal 11, which it is not.
- 🇧🇪Belgium BramDriesen Belgium 🇧🇪
Hi @leewillis77
Just going to jump in here. As the upgrade bot is stating, just merging this patch/MR would make the module compatible with D11. That would take no more as 5 minutes, so in the time you've written those two comments, you could have probably merged it and tagged a new release 😉.
Note that no one in this issue is asking for co-maintainership, the issue you are referring (which you closed) was indeed a bit... far fetched to be granted. But that should not hold back any other contributions being made to this module.
Forking a module just to change the info.yml seems a bit excessive to say the least. So at least, let's keep this issue open so people needing it can use Drupal Rector to facilitate the patch from this issue to proceed with their upgrade path to Drupal 11.
-
voleger →
committed 073cf284 on 2.2.x authored by
project update bot →
Issue #3455260: Automated Drupal 11 compatibility fixes for mgv
-
voleger →
committed 073cf284 on 2.2.x authored by
project update bot →
- First commit to issue fork.
- 🇬🇧United Kingdom leewillis77
@hexabinaer Are you offering to fund my time to port & support it on Drupal 11?
In absence of that, I do not have the time to carry out the work, or to verify suitable stewardship* for the project going forward.The project is open source, so anyone willing to maintain it is empowered to fork it and release it with Drupal 11 compatibility.
*Simply signing it over to an unvetted maintainer would be a potential security issue for those 700+ active sites and is (in my opinion) a much worse option than deprecating it.
- 🇩🇪Germany hexabinaer Berlin, Germany
You are kidding, right?
That would mean you are planning to let the module die for currently 763 sites.
- 🇮🇳India preetam.chari
Expecting a compatible version of this module for Drupal 11.
- 🇮🇳India vinodhini.e chennai
Hi,
Reproduced this issue in Drupal 11 and applied patch #4. The module is working as expected.
Thanks!
- 🇮🇳India vinayakmk47
Hello, the module is compatible with drupal11 after applying the patch, Thanks
- First commit to issue fork.
- First commit to issue fork.
- 🇨🇿Czech Republic Bohus Ulrych Pilsen (Czechia)
It works. Tested with Drupal 11.1.2
version required_field_display : dev-1.x 3003de5 (from 20 May 2024)
no patch needed - 🇺🇸United States andysipple
CTools needs to be ^4.0 to be upgraded to D11.
Panelizer 5.x-dev is currently set to ^3.0.
I noticed that Panelizer version 4.x has CTools set to 3 or 4:
https://git.drupalcode.org/project/panelizer/-/blob/8.x-4.x/composer.jso...Reroll: #22 📌 Automated Drupal 11 compatibility fixes for panelizer Needs review patch
Running
composer why drupal/ctools
produces the following output:composer why drupal/ctools drupal/core_context 1.x-dev requires drupal/ctools (^3.15 || ^4.1) drupal/ctools_block 4.1.0 requires drupal/ctools (*) drupal/page_manager 4.0.0-rc3 requires drupal/ctools (^3.15 || ^4.1) drupal/panelizer 5.x-dev requires drupal/ctools (^3.12) drupal/panels 4.x-dev requires drupal/ctools (^3.15 || ^4.1) drupal/pathauto 1.13.0 requires drupal/ctools (*)
- 🇨🇦Canada joseph.olstad
We've been testing this merge request in a Drupal 11 upgrade for over a month now. Haven't had any issues with it yet.
With that said we haven't focused our testing 100% on layout builder but it is functional.
Could we please merge this and get an alpha tagged release?
This would allow us to replace one of our two remaining overrides in our distribution release build.
- 🇺🇸United States chucksimply
Here's a patch that includes the .info update along with the change from
Drupal\Core\Asset\libraryDiscovery
toDrupal\Core\Asset\LibraryDiscoveryCollector
. Working flawlessly on 1.1.0-rc4. - 🇳🇵Nepal sujan shrestha Kathmandu🇳🇵, Nepal
The compatibility issue has been fixed.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
- 🇬🇧United Kingdom darren.fisher
These tests are failing due to Button with id|name|title|alt|value "Use selected" not found. I have tried various attempts to resolve this and am at my wits end with it. I suspect it may be to do with the use of the iframe or something which has changed in entity_browser itself. Feel free to take a look.
-
andras_szilagyi →
committed 72e46d90 on 1.x authored by
piotrsmykaj →
Issue #3455218 by piotrsmykaj, msnassar, damienmckenna: Automated Drupal...
-
andras_szilagyi →
committed 72e46d90 on 1.x authored by
piotrsmykaj →
- First commit to issue fork.
Automatically closed - issue fixed for 2 weeks with no activity.
- 🇮🇳India arjak-mondal
The rector patch cannot be applied. I have created a new patch
- 🇧🇪Belgium weseze
abhi_khandelwal report that the patch from #2 works. There is no difference in the other patches/MR's.
When can we expect a Drupal11 compatible release? Automatically closed - issue fixed for 2 weeks with no activity.
-
doxigo →
committed 32ebb725 on 2.x authored by
project update bot →
Issue #3442626: Automated Drupal 11 compatibility fixes for...
-
doxigo →
committed 32ebb725 on 2.x authored by
project update bot →
- 🇳🇴Norway jonsimonsen
I tested this patch on a newly set up Drupal 11 site (more or less generated from scaffolding, but I had enabled a few other modules such as Admin toolbar, metatag, Gin admin theme.
I tested both left- and right-aligned and also with "show on admin pages" checked. I didn't see any issues with it. For the sake of allowing the module to be easily upgraded to D11, I suggest merging this in and then considering if it should still be a dev version or if that should be changed as well.
For the record, the equivalent PR for version 1 does not work for Drupal 11, so presumably that version is not meant to work on D11. I did not save a screenshot, but saw an error relating to themes and twig layouts for blocks.
- 🇵🇱Poland gpietrzak Wrocław
I reviewed the code and tested the module locally. I changed the image media type to accept remote streams and successfully added some new items. It worked fine (provided the image styles are not configured to use webp).
-
andras_szilagyi →
committed 362bb042 on 1.x authored by
msnassar →
Issue #3435271 by msnassar, gpietrzak, chewie: Automated Drupal 11...
-
andras_szilagyi →
committed 362bb042 on 1.x authored by
msnassar →
- First commit to issue fork.
- 🇮🇳India ankitv18
Already Drupal11 compatible and Site studio version 8 support is available on 1.0.3
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
- 🇷🇺Russia Chi
The patch may cause BC break on existing sites. However, I think it is acceptable in RC.
- 🇺🇸United States markie Albuquerque, NM
Note to self:
```
composer require "drupal/maxlength:3.1.0 as 2.1.3"
composer require "drupal/registration_role:2.x-dev as 2.0.1"
composer require 'drupal/event_platform:^1.0'
``` Automatically closed - issue fixed for 2 weeks with no activity.
-
foxy-vikvik →
committed 5f925fbc on 2.0.x
Issue #3430997: Automated Drupal 11 compatibility fixes for...
-
foxy-vikvik →
committed 5f925fbc on 2.0.x
- @foxy-vikvik opened merge request.
- First commit to issue fork.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
- 🇵🇱Poland gpietrzak Wrocław
It works fine, I tested it locally along with #3503983
-
andras_szilagyi →
committed 3dd68e10 on 1.x authored by
pawelgorski87 →
Issue #3482858 by pawelgorski87, joevagyok: Automated Drupal 11...
-
andras_szilagyi →
committed 3dd68e10 on 1.x authored by
pawelgorski87 →
- First commit to issue fork.
Automatically closed - issue fixed for 2 weeks with no activity.
- 🇵🇱Poland gpietrzak Wrocław
I have reviewed the code and tested the functionality locally, everything is fine.
Automatically closed - issue fixed for 2 weeks with no activity.
- 🇧🇪Belgium svendecabooter Gent
D11 compatibility now available in 3.0.x branch. I will create a new release as well.
-
svendecabooter →
committed c362e457 on 3.0.x
Issue #3431569 by omarlopesino: Fix Drupal 11.1 compatibility
-
svendecabooter →
committed c362e457 on 3.0.x
- 🇧🇪Belgium svendecabooter Gent
Created a new 3.0.x branch for D11 support, and to support semantic versioning.
- 🇧🇪Belgium msnassar
msnassar → changed the visibility of the branch project-update-bot-only to hidden.
- 🇧🇪Belgium kriboogh
Development on this module has stopped, since D11 uses a new navigation bar.
I'll refer you to our other D11 module (navigation_extra) currently in dev version, which is a rewrite and replaces this module to be used with D11's 'nagivation'-module. Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
-
junaidpv →
committed 0cdaef9f on 2.x
Issue #3499186 by project update bot: Automated Drupal 11 compatibility...
-
junaidpv →
committed 0cdaef9f on 2.x
- 🇦🇺Australia acbramley
This can be reviewed now, I've done some preliminary testing locally and the module seems to work well on D11.
I've dropped support for anything under D10.3 as that is the earliest supported version of core. Users on older versions of core can remain on version 2.1.0 of this module.
The settings form changes are required for 10.2 and above.
- First commit to issue fork.
- @acbramley opened merge request.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
- 🇺🇸United States jnicola
Tested, works. There's not even any code changes it's just adjusting what version of drupal is supported in the info.yml file.
- 🇦🇺Australia dpi Perth, Australia
Can we get a new release?
Can we change default branch in gitlab?