I moved 📌 Offering to maintain Edit UUID Needs review to the Drupal.org Project Ownership queue. Shouldn't be too much longer. I've closed this issue as it will never get resolved in it's current form. Works as designed seemed appropriate.
After starting the fork I learned about https://www.drupal.org/project/config_pr → . Going to give that a try before continuing to work on the fork.
Attempts to reach out to the maintainer of this project started back on 2024/12/6. I only got involved a few weeks ago, but there has been no response to this request after 2 weeks either.
As I have required security related requirements, I'd like to take over maintaining this module so a release for D10 can be created.
Unless I'm missing something, https://github.com/GouvernementFR/dsfr/blob/main/LICENSE.md is licensed as MIT which could be legally relicensed as GPL-2.0, but doesn't have any use restrictions either. The restrictions on how this is used is not coming from how the code is licensed.
The DSFR (French State Design System) is to be used for digital projects within the French State : central administrations, their departments, interministerial delegations, prefectures, embassies and all decentralized services.
IMHO, the updated text walks the line between urging users not to create fake French Government sites that would likely violate the French equivalent of US trademark or fraud laws and implying that someone doesn't have the freedom to do that with the GPL portion of the project as well as anyone could do.
Unless someone else has strong feelings that additional changes need to be made, I'd consider this fixed.
IANAL either, but I helped write the DA's Drupal.org policies and contributor agreement which were reviewed by DA's lawyers and outside FOSS experts. If a developer doesn't have permission to redistribute the code as GPL, they are violating https://www.drupal.org/docs/develop/git/setting-up-git-for-drupal/drupal... → . Every developer must agree to that before they can push to https://git.drupalcode.org/.
All code submitted to the repository that is a derivative work of Drupal must be and it will automatically be redistributed as GPL-2.0-or-later.
> Implying that it is too late for the user to have the code removed is misleading to both the code owners and others who may consider using the code as a base for other modules.
That's fair. My point was that despite the fact that the project maintainers likely do not have the authority to relicense code that is trying to limit use to one specific company, the project is already being distributed as GPL-2.0 from Drupal.org. Drupal.org policy is not the same as what can be done legally within the requirements of the GPL. We have tried to keep things as simple as possible. I emphasize tried because I know it is not simple. Even doing something like distributing a Drupal module as GPL-3.0 or including code that isn't compatible with GPL-2.0 (only GPL-3.0) isn't allowed on Drupal.org, but is perfectly legal under the "GPL 2 or later" terms Drupal itself uses. I know. Clear as mud.
Part of the reason the LWG and these policies is exists to avoid licensing surprises like this. If someone runs composer require 'drupal/dsfr:^2.1@RC' and then runs composer licenses, they should be able to trust that the report is accurate including...
doctrine/lexer 2.1.1 MIT
drupal/core 10.3.2 GPL-2.0-or-later
drupal/core-composer-scaffold 10.3.2 GPL-2.0-or-later
drupal/core-project-message 10.3.2 GPL-2.0-or-later
drupal/core-recommended 10.3.2 GPL-2.0-or-later
drupal/dsfr 2.1.12-rc1 GPL-2.0-or-later
drush/drush 12.5.3 GPL-2.0-or-later
egulias/email-validator 4.0.2 MIT
grasmash/expander 3.0.0 MIT
grasmash/yaml-cli 3.2.1 MIT
I shared this example of how to achieve what the DSFR is trying to do with Joeri and Rachel on Mastodon, but I'll share it here too. When I managed the University of Colorado Boulder's Drupal as a Service offering, we maintained our Install Profile publically on GitHub, but also maintained https://www.drupal.org/project/express → on Drupal.org. We did this in part to avoid another project injecting a different project into our namespace, but also because Updated Status reported the number of sites we maintained back to Drupal.org. When we did this, there was some concern expressed that we were making it too easy for someone to create a "fake CU site". While sharing the Install Profile could in theory make it easier than trying to reverse engineer the modules we used from the HTML output, installing our Install Profile was still MUCH more complicated than just scraping the already public HTML and editing that.
Using scraped HTML or our Install Profile wouldn't be a violation of the GPL, but it would be an unauthorized use of CU's trademark (and possibly copyright).
There are ways to enforce an "It is strictly forbidden to use logos and branding outside of the French State's websites", but it is NOT be posting a statement like that on the Drupal.org project page of the theme that IS licensed as GPL-2.0 and can be used by anyone, anywhere. It is also NOT by licensing DSFR itself as MIT.
The (hopefully) final thing I'll say about this is that it is trivial to connect GitHub to automatically publish releases to Packagist and distribute custom projects directly from your own namespace. Many universities using Drupal do this; University of Denver, University of Texas, University of Maryland, etc
If someone wants to make statements trying to limit the rights the GPL allows somewhere other than Drupal.org, that would be beyond the scope of the LWG's charter to do anything about it. It still isn't legal to restrict the use of distributed, derivative code that inherits the GPL, but we wouldn't be discussing it.
<a class="toc-anchor" title="Permalink to this headline" href="#content"></a>Does not work as an anchor within the content because it conflicts with the existing content anchor.
<a class="element-invisible element-focusable" href="#content">Skip to main content</a>If the statement attempting to restrict a user's rights under the GPL isn't removed in a week, move the issue to https://www.drupal.org/project/drupal_lwg → and we will take care of it.
We've had dozens of attempts to claim a commercial license is required, but I think this is the first geographic limit someone tried to enforce on a Drupal module or theme.
https://github.com/GouvernementFR/dsfr?tab=License-1-ov-file needs to be updated as well, but I'll open a GitHub issue about that.
Created project at https://www.drupal.org/project/config_patch_github_api → . Started fork retaining existing commit credits. Building on the shoulders of giants :)
A week has passed, still no response from the project's maintainers.
If there is still no response next week, I'll move the issue to https://www.drupal.org/project/issues/projectownership →
I too was there.
Every project that only had a D7 (or even D9) release had had they releases unpublished and will show up as unsupported if you are using a module like Update Status to check Drupal.org for updates.
There is really no need to go back and retroactively mark projects as unsupported at the Drupal.org Project level.
@cmlara GREAT point! Forking is WAY more controversial in Drupal than it should be, but that is in part because of how the namespace is used. Composer/packagist made forking outside of the drupal namespace an option (the way most of the PHP ecosystem works off our tiny island), but that is RARELY used in Drupal. Many universities have shifted from maintaining code on Drupal.org to registering their own namespace on Packagist, but this is primarily for modules so custom they serve no value beyond as an inspiration/example outside of our codebase.
https://packagist.org/packages/az-digital/, https://packagist.org/packages/uriweb/, https://packagist.org/packages/utexas, https://packagist.org/packages/ucdavis/, https://packagist.org/packages/cu-boulder/ and (of course) https://packagist.org/packages/university-of-denver/ are just a few of the organizations I know of managing our Drupal (and WP) code outside of the official project namespace.
Managing forks that way does get confusing as Drupal core would assume that myforkedprojects/edit_uuid was actually drupal/edit_uuid if you were using something like Update Status.
I did exactly what you are describing with https://www.drupal.org/project/webform_pardot_handler → when a maintainer would neither update, nor add co-maintainers to help. I was eventually given control of https://www.drupal.org/project/webform_pardot → and backported the improvements I had made in the fork so they were available to everyone using the module at the drupal/webform_pardot namespace.
I no longer use Pardot and handed the project off to baikho → when it was clear he was committed to moving more of the issues forward than I had time/interest to look at. This is the way to keep the drop moving.
This isn't pressing for me, so I'm willing to wait 2 weeks before escalating [#350439]. I hate it when people try to put pressure on me to bypass process, so I try to follow any process any group willing to volunteer time maintaining the Drupal infrastructure has decided they need to stay sane/have some work/volunteer/life balance.
📌 Offering to maintain Edit UUID Needs review
I have always hated seeing developers who offer to help get turned away because they haven't developed a unique module from scratch meet the requirements of the `permission to opt into security advisory coverage` process. I understand that process has made Drupal more secure which increased government adoption, but at this point in the Drupal project arc can we really afford to turn away people offering to contribute?
@makbay has been a member of the community for almost 8 years with a number of credits for fixes.
@avpaderno would it work if I took over the project and added @makbay as a co-maintainer?
I honestly don't even know if I need this module yet. I came across this issue while looking at the options for dealing with a UUID problem I have, but I'm willing to work with @makbay to get a D10 version released and work with him to clear up the code to the point he could use it for https://www.drupal.org/node/1011698 →
1. Obtain basic Git access and create a project for your code.
2. Get your project into a state you feel is release-ready; ideally, you would commit the project early and have a track record of several weeks/months of commits so that application reviewers can get an idea of your development and maintenance style.
always looking for some non-code credits :)
I didn't think a user would search for what the term Add-ons meant as much as what Add-ons are available WITHOUT having to do that within a Drupal CMS instance. That seems like a pretty reasonable scenario
I don't think the issue is confusing users while adding functionality within a Drupal instance. I'm sure Add-ons will test fine in that scenario.
I think the issue that isn't "sitting right" with @ultimike is consistency in how we describe the building blocks of a Drupal configuration.
I completely agree that referring to the feature a CMS user is browsing to add to their sites "projects" isn't ideal. The module, recipe or theme is created and maintained as a project. Project makes sense in that context as the creation and maintenance = work, but you don't want to imply to users enabling a module that there will be work.
The Salesforce version of Project Browser is now called AppExchange. There used to be Marketplace for closed source, commercially supported packages and Open Commons for free, open source packages, but the packages are now combined in AppExchange. You can now find an open source package like Education Data Architecture, Summit Events App maintained by staff at the University of St. Thomas and ascend Advancement Suite which requires a license. The UI users use to browse Managed Packages is very consistent regardless of whether happens through the website or in the CRM.
In CU's D7 install profile, we had our own version of Project Browser and called the combination of Features and Modules we allowed Site Owners to enable Bundles. I completely understand that using terms like projects, modules and recipes is meaningless to some site-building communities, but in our case we were using bundles to hide which modules were used from our users. In our SaaS offering, we did not want users trying to find support on Drupal.org directly since so many of the options were preconfigured and locked down.
It really goes against the "come for the code, stay for the community" ethos if we use different terms for users vs. contributors, but the more I think about this the less I see the use of Add-ons in the Drupal CMS profiles as the problem.
One potential solution to the consistency problem actually solves a few other problems is to replace the dated Downloads top level nav on Drupal.org. with Add-ons. Implying that someone should download Drupal core or even a module in 2025 is unnecessarily confusing.
With D7 fully EoL and #3277250: Distribution packaging sunset in November 2022 → complete, I'd push to remove Distributions. At some point we lost the link to Downloads > General Projects → which is the project type being used to create and maintain Recipes. The General project type was originally created for js projects like https://www.drupal.org/project/drupal_js → that didn't require the GPL inheritance like a derivative module or theme, but is now being used for many things... including the Drupal CMS. Creating a new project type specifically for Recipes would be a lift, but adding a field and filter to separate the General projects by Recipe, Javascript or Install Profile type would be relatively easy.
We'd also need to address the Download > Download link that is Drupal core, but that is already happening with the Try links. I think everyone who has been involved in the evolution of install profiles > distributions > install profiles + recipes agrees that we took install profiles too far in D7 and understands the technical reasons why https://www.drupal.org/project/cms → was created as a General Project.
@ultimike If the top level Drupal.org nav was updated to...
- Add-ons
- Modules
- Themes
- Recipes
- Javascript
... and we continued to describe the different types of Add-ons the way it already is in https://new.drupal.org/node/10000037, would that address your consistency concerns?
social space owned by a literal saluting nazi
I have never accidentally or intentionally saluted to fascists
@mikemccaffrey @johne He is making it so very hard to spend time or $$ on anything he is involved in. It's to the point I question whether doing the most outrageous things to anger your customers and still make money isn't the 1% equivalent of a TikTok challenge. Elon won the rocket/barge golf challenge and isn't going to let Matt Mullenweg win the latest challenge with his silly "wordpress.org is mine" and "Automattic is shifting 95% of our dev time to closed source, commercial projects" statements to a FOSS community that made WP so successful. Elon's response is going full Nazi? I'd say we live in strange times, but people are still driving Fords.
It's amazing how far a mind will go to justify reactivating a Starlink while living out of a van each summer.
I argued against re-using the term recipes in the early days of the Distribution Modernization Initiative. I conceded in part because very few current Drupal developers knew about/remembered drush recipes, but also because the word "recipe" described what these were to novice users as well as how they were different from modules AND implied that they are designed to be mixed and altered at the same time.
The name worked on many levels.
Renaming recipes as add-ons is misguided unless the goal is to prevent Drupal CMS users from being able to use Drupal.org documentation to learn more about Drupal.
Because add-ons really have to no meaning in Drupal, this is the top result when someone searches "Drupal Add-ons"
https://www.drupal.org/node/1990588 →
Vs the useful information you find when searching "drupal recipies".
Is there any data that shows users find add-ons more descriptive?
I see both sides of this. Does anyone remember how quickly the community was willing to trade our freedoms and data ownership for the UX polish and emojis Slack offered? Many of us bleed GPL, but we fell for the allure of Slack.
I enjoy Mastodon. It reminds me of the early days of Twitter, but I don't hold using a platform that doesn't align with my personal morals against someone else.
At this point in the Drupal arc, we have to reach out to people where they are. A PHP CMS isn't enough of draw to ask people to create yet another social account to prove they are worthy of our replies, reposts or likes.
I'm not very active at @kreynen@fosstodon.org, but I'm more active there than Xwitter.
Thanks for the quick reply. After checking with some of the other large EDUs who worked through the same "lack of motivation" to support an updated version of Symfony in #3306294: Plan for 3.x release of the simpleSAMLphp library → , I'm going to also move to https://www.drupal.org/project/samlauth → .
@mingsong are you saying you were able to get simplesamlphp_auth to at least install with those aliases?
I thought it would be "neat" to spin up an instance for the new starshot/drupal_cms project for our marketing team to look at. I downloaded a copy of this branch to web/modules/custom. Along with your aliases and I added...
"simplesamlphp_auth": {
"type": "path",
"url": "web/modules/custom/simplesamlphp_auth"
}
If I run composer require drupal/simplesamlphp_auth, I still get...
Problem 1
- Root composer.json requires symfony/cache 7.2 as 6.4.0 -> satisfiable by symfony/cache[v7.2.0].
- symfony/http-foundation[6.4.0, v7.2.0] conflict with symfony/cache <6.4.12|>=7.0,<7.1.5.
- symfony/cache 6.4.0 is an alias of symfony/cache v7.2.0 and must be installed with it.
- Root composer.json requires symfony/http-foundation 7.2 as 6.4.0 -> satisfiable by symfony/http-foundation[v7.2.0].@miiimooo thanks for linking to the DER issue. It would have taken me a long time to figure out that in 2024 a module would attempt to store username for a SQL connection in a database. The idea that database connection information never changes when most Drupal hosts now provide a dev->test->live deployment with database connection information populated in the settings.php files from environmental variables BECAUSE THEY CAN CHANGE AT ANYTIME is just a fundamentally flawed approach.
I understand that this is only an alpha, but the steps to reproduce this error on a host like Pantheon are very simple.
- In the live environment, create a Preview Link with a URL like node/123/generate-preview-link
- Clone the live environment's database to test
- Attempt to access node/123/generate-preview-link
I haven't looked into why the module is stashing the db credentials in a table and to determine if it is worth fixing that, but my solution was to simply to uninstall the module and reinstall it.
kreynen → created an issue. See original summary → .
This patch was used in a project we inherited. I don't know enough about the Group module and the updates to this project to know how much of this is still needed, but the MR I suggested in 🐛 Drupal\field_permissions_group\Plugin\FieldPermissionType\CustomGroupAccess::create(Object, Array, 'custom_group', Array, Object) (Line: 58) Active is enough to get the admin/modules UI rendering again.
Found another related issue with 📌 Add compatibility with Group v2 and v3 Fixed with a partial fix. Might be as easy as making the same change from plugin.manager.group_content_enabler to group_relation_type.manager https://git.drupalcode.org/project/entitygroupfield/-/merge_requests/4/d... and
use Drupal\group\Plugin\GroupContentEnablerManagerInterface;
use Drupal\group\Plugin\Group\Relation\GroupRelationTypeManagerInterface;I'm getting the same error from field_permissions_group. I posted more details in 🐛 Drupal\field_permissions_group\Plugin\FieldPermissionType\CustomGroupAccess::create(Object, Array, 'custom_group', Array, Object) (Line: 58) Active
kreynen → created an issue.
kreynen → created an issue.
WOW. @bhanu951 Thanks for flagging this in Slack. I've read about the BSL, but this is the first time this has come up in a Drupal project that I know of. If you look at https://github.com/fingerprintjs/fingerprintjs/blob/master/LICENSE#L6, the will license from BLS->MIT "four years from first release for the specific version". So for 4.x releases, that would be July 2027.
https://mariadb.com/bsl-faq-adopting/#gpl has a good explanation about how GPL compatibility work.
FingerprintJS obviously isn't a derivative work of Drupal, you can't distribute FingerprintJS 4.x as part of a GPL-2.0 licensed module because Drupal's policies require everything distributed from Drupal.org to be GPL compatible (or GPL-firendly for non-code). That said someone who wanted to use FingerprintJS 4.x could purchase a license and run that version with Drupal and not be violating the GPL or BSL. The distinction is between use and distribution.
@greggles is going hate that I'm even bringing this up, but back in the dawn of time the Drupal project didn't allow ANY "3rd party" javascript. Everything module that required javascript required the person building the site to download the js and place it in a specific directory. I was threatened with being banned over suggesting we put a small 5K version of TinyMCE into the module so it would work "out of the box" and then tell users how to replace it with the larger, full TinyMCE packages.
I don't know if that's even practical with this project, but could you include 3.x and give users the option of using 4.x?
I ran into this error, Googled and ended up here. After applying https://www.drupal.org/project/webform/issues/3470339#comment-15829504 🐛 Error: Attempt to assign property on array in WebformLibrariesCommands->setComposerLibraries() Active I was able to run `ddev drush webform:composer:update`. I tried creating a patch from the latest changes, but that wouldn't apply. Could be an issue with the way I generated the patch.
The latest changes from https://git.drupalcode.org/project/webform/-/merge_requests/535.diff as a new patch
David hasn't been involved in this project for many years. I don't think anyone else involved in the project from the University of Colorado Boulder is still interested in maintaining it, but I'll give it a few days. If no one voices any concerns, I'll add you as a co-maintainer.
@fago it's taken many years and countless discussions over the years, but I think everyone who would weigh in on these changes are now all on the same page. We went through this when JQuery updated that project's licensing back in 2012 and we revised the contributor agreement to clarify that non-code assets didn't require a GPL, but a "friendly" license that had similar clauses protecting the same freedoms as the GPL like MIT. We had the same discussion again when general projects were first offered on Drupal.org... and again with Distribution Modernization/Recipes when we looked at how Ansible treats Playbooks as non-derivative work. Every time we've had this conversation in the last 4+ years, we were "only months away from D7's EoL" when we'd no longer need to package D7 code and could rely on features like `composer license` to understand the licensing in a build... only to have the EoL deadline pushed again.
We managed to #3266927: End Install Profile Packaging on Drupal.org in August 2023 → , but the larger shift to an "off the island" approach to licensing has been on hold until Drupal.org support for D7 finally ends. The WP Engine drama should only help motivate the Drupal Association to further clarify the Drupal.org licensing and project ownership policies. My understanding has always been that what happened with WPEngine customers being blocked from updates and the Advanced Custom Field plugin being hijacked could never happen on Drupal.org.
It's worth calling out that the WordPress has always allowed plugin maintainers to mix incompatible licenses while still linking https://wordpress.org/about/license/ to Drupal.org to explain licensing inheritance and derivative works.
Fully embracing a more nuanced approach to licensing has been hampered by legacy tooling, but that finally changes in January!
No apologies are necessary. We're all just trying to keep the trains running until we can finally disable more of the D7 packaging and update the Drupal.org project page UI so we're no longer assuming that a copy of the GPL license text was added to a .zip during the packaging step.
What you've already configured in GitLab using the normal/off the island approach to licensing is the correct way to handle this for now.
the_g_bomb → credited kreynen → .
If you match the Webform field names to the Pardot field names, you can use the core Webform Post Handler. Submissions are still stored by Webform, but the form is posted to Pardot on submission. The biggest benefit of this module is field mapping when posting to existing Pardot handlers. If you can coordinate the Pardot and Drupal work, the module isn't required.
This is not as simple as modules, themes or even install profiles/distributions.
Is it possible to sell recipes?
Regardless of whether they are required to be distributed as GPL, you can sell Recipes the same way you could sell a install profile/distribution.
Before we dig into the details, I will say that IANAL and the LWG does NOT dictate DA/Drupal.org policy. This group exists to advise the DA and help explain and implement policies... and we're always looking for more members!
Back when Drupal started figuring out how to manage the licensing requirements of the project, we were often the first and largest project to define these policies. If you look at https://wordpress.org/about/license/, it STILL references Drupal's interpretation of modules/plugins as derivative work.
Today, the FOSS landscape is much bigger than PHP CMS projects.
When discussing Resipes, we have well-established projects we can look at. Ansible is a GPL-3.0 licensed project with a feature that is similar to Recipes they call Playbooks (https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html). Playbooks are YML files are distributed with a variety of licesense
MIT
https://github.com/Azure-Samples/ansible-playbooks/blob/master/LICENSE.md
https://github.com/ansible/ansible-examples/blob/master/tomcat-memcached...
CC-BY-3.0
https://github.com/ansible/ansible-examples/blob/master/wordpress-nginx/...
Apache-2.0
https://github.com/opensearch-project/ansible-playbook/blob/main/LICENSE...
https://github.com/confluentinc/cp-ansible/blob/7.6.1-post/LICENSE.md
This was discussed when the Distribution Modernization Initiative was just getting started, but the stars didn't align as well as we'd hoped with...
- the shift to using more GitLab features
- shift away from only adding the GPL-2.0 license text in projects when packaging the .zip
- use of General Projects for Drupal adjacent code that is not a module/theme/derivative work
When we updated what is essentially the Drupal project's CLA at https://www.drupal.org/docs/develop/git/setting-up-git-for-drupal/drupal... → , back in 2020? to finally clarify what was considered derivative work and acknowledge that a "GPL only" approach wasn't compatible with the variety of FOSS licenses now being used "off the island", the changes to...
All code that is a derivative work of Drupal (typically PHP code, including but not limited to: core patches, modules, themes, etc) committed to Drupal.org's git repository is licensed as GPL version 2.0 and later (official short identifier: “GPL-2.0-or-later”).
...and...
In general, all code downloaded from Drupal.org is distributed as GPL-2.0-or-later and includes this license. In some cases, code that is not a derivative work of Drupal may be distributed "in-aggregate" with Drupal code. Any permissively licensed 3rd party code that allows relicensing is automatically relicensed and distributed as GPL-2.0-or-later.
... were intended to address that and add more clarity to was legal under the GPL and what was allowed by DA/Drupal.org policy.
A Recipe is essentially install instructions in YML. Whether this is considered a derivative work isn't clearly stated anywhere. When discussing javascript dependencies back in the D6, D7 era, the decision to require javascript to be licensed as GPL-2.0 or a permissive license like MIT wasn't based on all javascript being a derivative... but simplicity and resource limitations. Hopefully everyone agrees that a module project could include javascript that is in no way derivative of Drupal. Trying to figure out which .js files were derivative and which weren't FAR exceeded the resources of the LWG volunteers.
With General Projects, the topic of the GPL requirements came up again. The case was made that the javascript ecosystem simply wouldn't accept a GPL-2.0 requirement. Because these projects weren't necessarily packaged and distributed through Composer, many included their own license text in GitLab and then referenced that license in the related packaging manifest. If you review the ~150 General Projects now in https://www.drupal.org/project/project_general → , you'll find a variety of licenses. You'll also find projects with no license that don't contain any PHP or javascript that could be considered a derivative work. While the project node links to GPL-2.0, it is possible (even likely) that someone would download or clone one of those projects without ever seeing the project page on Drupal.org.
ISC
https://git.drupalcode.org/project/react_menu_component/-/blob/1.0.x/pac...
GPL-3.0
https://git.drupalcode.org/project/drupal_extend_phpstorm_plugin/-/blob/...
https://git.drupalcode.org/project/drupal_svelte_component_menu/-/blob/1...
https://git.drupalcode.org/project/open_project/-/blob/9.2.x/LICENSE?ref...
NO LICENSE
https://git.drupalcode.org/project/core_logs
https://git.drupalcode.org/project/growmark
https://git.drupalcode.org/project/gitlab_templates
https://git.drupalcode.org/project/next_webform
https://git.drupalcode.org/project/phpstorm_code_style
https://git.drupalcode.org/project/openculturas_project
https://git.drupalcode.org/project/cacheable_types
https://git.drupalcode.org/project/ui_suite_bootstrap_demo
https://git.drupalcode.org/project/formgeneratetrait
https://git.drupalcode.org/project/drush_sqlsrv
https://git.drupalcode.org/project/wisski_docker_image
https://git.drupalcode.org/project/drupal_contrib_docksal
General Projects are still a bit of a secret, insider-only option on Drupal.org. They aren't linked under the Download menu, but the DA is going to need clarify the licensing requirements for these projects and whether the view that we've based our policies on about all modules and themes being derivative works also applies to Recipes.
There is a lot to clarify here, but this isn't as easy to define as a PHP module.
I got sidetracked and made more changes than I should have to the branch. I'll create a clean commit of just the menu path changes to the branch tomorrow morning.
Since the module was already under Web Services in in https://git.drupalcode.org/project/formassembly/-/blob/2.x/formassembly...., I used /admin/config/services instead of /admin/config/content
The default branch for the project is still set to 8.x-1.x so new branches default to that. Because this was a single line change, I was able to create a valid MR from 8.x-1.x -> 2.x, but updating the default branch would help potential contributors avoid that mistake.
kreynen → created an issue.
It looks like the CKEditor 5 work is being done in the 3.x branch https://git.drupalcode.org/project/countup/-/tree/3.x. If you're going to contribute a MR to try to move this forward, I think that would be where you'd want to branch from.
It would be really helpful to publish releases on https://www.drupal.org/project/countup → and include a note that current releases of the module are NOT compatible with CKEditor 5.
Because these icons are fonts, the color can be controlled with styles. This approach can conflict eith the recent changes to fix linking the icons in 🐛 Icons cannot be child element of links Fixed . In many cases, applying the color to the icon is overridden by the color applied to the link.
I provided some background information, but mainly based US copyright law and our Work for Hire Doctrine. I'll leave this open for a few days to see if any of the other LWG members want to weigh in, but contract/copyright ownership conflicts really falls outside of the LWG's Charter.
IANAL, but I don't think this really has anything to do with Drupal's GPL policies or even the GPL license itself. This really isn't a code licensing question as much as work for hire/copyright ownership dispute and will depend almost entirely on language in the contract and where the client and agency are located. While you mentioned that the contract doesn't specify how an issue like this would be arbitrated, unless the contract specifies that the work done for the project must be licensed as GPL and distributed, there is no legal requirement in the GPL to do that.
See https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.
The GPL's requirements are only "triggered" by distribution Again, IANAL and we're getting into legal precedent now, but my understanding and the way agencies building solutions with Drupal and WordPress for the last ~20 years have largely operated is that an agency writing PHP for a module or theme for a client does not qualify as distribution. If it did, anyone with standing would be able to demand all module and theme source code for every Drupal and WordPress project.
If you read about the Work for Hire Doctrine in the US, you will see statements like this one from https://gct.law/news/Work-For-Hire-Doctrine-as-Protection-for-your-Software
in recent developments, courts have expanded the scope of the “work-for-hire” doctrine to include the independent contractors of the technology field, software developers.
Unfortunately for the client, unless their contract with the agency specifies that they own the code and/or the agency will provide access to it, this will probably have to be settled by the lawyers.
The link example in https://dequeuniversity.com/library/aria/tooltip looks like it would be easy to implement in https://git.drupalcode.org/project/glossify/-/blob/3.x/templates/glossif...
The use of a tooltip role in https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/to... looked promising, but then https://sarahmhigley.com/writing/tooltips-in-wcag-21/ says "While it's not a bad idea to add it to the tooltip element, it doesn't seem to do much good either. The tooltip role does not appear to affect screen reader announcements in any meaningful way".
At this point, I'm not sure what the right way to fix this is, but I'm also noticing that the tool-tip only link doesn't work in mobile. Clicking on the underlined term just selects it.
Somehow this got overlooked from 1.x->2x->3.0.0.
Testing to see if this change can be made in https://git.drupalcode.org/project/glossify/-/blob/3.x/templates/glossif...
@BramDriesen You are correct. This is no longer relevant. #3266927: End Install Profile Packaging on Drupal.org in August 2023 → forced the handful of D7 distributions still active to shift to using their own packaging process somewhere other than Drupal.org.
This is still an issue in the rc1. If there is an issue with the updated patch and/or a single version that can run on >=8 and current versions of D10, that should be specified in the https://git.drupalcode.org/project/site/-/blob/2.x/composer.json and/or https://git.drupalcode.org/project/site/-/blob/2.x/site.info.yml in different versions.
Putting out an RC that can't even be installed in the current version because it requires a patch that can't be applied is not really a great indication that this project is really ready for a release.
Thanks @AaronMcHale. I thought about responding to @bserem's comments, but when the decision was made to move forward with this, I was just going to let it go. Since the debate/discussion seems to be continuing here, I'd like to clarify a few things.
Alternatives died because they were not up to the competition.
This is not true. If you know much about the history of this decision, you know that the core team's original decision was to include Aloha. As someone who used TinyMCE on most projects, it was less about major differences between the WYSIWYG options and more about the custom buttons and integration work that needed to be done for one or the other on every project. It was less that the Aloha or TinyMCE weren't "up to the competition" and more that once an "official" recommended solution was chosen, you were swimming upstream to ask users to disable CKEditor and add jump through the hoops required to add a different editor module and javascript library. It no longer made sense to use an alternative so we gave up on TinyMCE and started contributing and customizing CKEditor instead.
And like said above, DDEV is a non profit: https://ddev.com/foundation/
Now. The origin story of DDEV is similar to Slack. DDEV is managed through a non-profit NOW, but it started within https://newmedia.com/ and was spun out with https://web.archive.org/web/20210926102655/https://ddev.com/news/ddev-co.... DRUD ultimately failed to gain traction in the competitive PHP hosting space. I love Randy, but he maintains DDEV as a Platform.sh employee. I've attended several of the sessions in the series of live training Randy has been doing to increase the size of the DDEV contributor community, but I think Randy would be the first to admit that if he were to step away from DDEV right now, the project would struggle. It is not yet self-sufficient.
Why would you fear DDEV more than Acquia?
I don't. I've been sponsoring Randy's work at https://github.com/sponsors/rfay long before it was even possible to sponsor DDEV directly. I DO worry about Acquia's influence and post about it often, but until FOSS funds and direct sponsorship become more popular, adding value on top of an open solution through closed, commercial services is still a very effective way to fund open source development.
In the "great WYSIWYG wars", I found myself on the losing side having to redo work. When it comes to local development, I've been using DDEV for years and would rather contribute DDEV configurations like https://www.drupal.org/project/operations/issues/3389217 ✨ Add DDEV install option Needs review or https://github.com/EqualifyEverything/equalify/issues/40#issuecomment-12... than get involved in a project I can't run in DDEV.
All of that said, the Drupal community needs to learn from history and be prepared for what is likely to happen when an official/recommended solution is chosen. If DDEV or Drupal pivot in a way that no longer aligns in the future, it's possible we'll find that Lando went the way of Aloha rather than continue swimming upstream competing with a recommended solution.
Imagine if we included an official WYSIWYG editor in core... no... wait. That's actually an example where the overhead required to avoid choosing a default direction was a constant drain on limited resources for many years. Including CKEditor in core didn't completely exclude alternative WYSIWYG editors, but it certainly made the work required to maintain them MUCH less appealing and the projects stalled and died fairly quickly after the decision to include CKEditor in core was made.
I think this is a healthy conversation to have, but I'm not sure that local development environments are in the same place WYSIWYG were when we compared CKEditor to TinyMCE and Aloha (remember Aloha?). While I have a lot of confidence in Randy Fay and the DDEV Foundation not to pivot towards a less open licensing/service model, picking a default anything for the project/community that kills alternatives only to see the default pivot to a less open structure that limits features and choice is a lesson I'd like to believe we learned from.
kreynen → created an issue.
After confirming the drush si just doesn't work even when defining the databases of multisite instances in multiple settings.php files, I added -dev versions of commands without touching the Lando configuration. I'm still working through all of the commands and testing, but the initial install can now be done in DDEV from this branch with just...
git clone git@git.drupal.org:issue/operations-3389217.git
cd operations
composer install
ddev config
ddev composer operations:install-ddev
This configuration uses FAR fewer resources than Lando since the web and db containers are shared between the 4 sites in a multisite configuration.
I have NOT tested these changes with Lando. I am also NOT completely happy with the duplicate commands and needing to prefix aliases, but I think this is progress making it easier for more people to spin up a demo of an operations site running Site Manager and 3 planet sites running just Site.
Making progress.
git clone git@git.drupal.org:issue/operations-3389217.git
cd operations
composer install
ddev config
This is where an alias naming trick would need to be addressed to lack of .ddev in the aliases of the composer scripts.
ddev drush @ddev.operations si ox_stock --site-name=Operations.Local --yes
ddev drush @ddev.operations key:set admin 123testingkey
If I use the browser install for the planet sites, they are installed in the correct databases. Unfortunately ddev drush @ddev.mercury si standard --yes is still trying to install in database named db which overwrites the operation site install. Even after updating the alias names in the composer install scripts, it does the same thing.
I found https://stackoverflow.com/questions/53525456/getting-ddev-and-drush-site...
If I use ddev drush si standard --sites-subdir=mars --db-url=mysql://db:db@db/mars, the site install works as expected.
It might more sense to include the settings and use ddev config --disable-settings-management.
Not sure it's possible to preconfigure both Lando and DDEV to both work with the same site aliases. If it is possible, I'm not sure that's a good idea.
I've never seen wildcards like https://git.drupalcode.org/project/operations/-/blob/2.x/drush/sites/sel... done with DDEV. If I need aliases in a project, I'd add a ddev.site.yml with...
operations:
root: /var/www/html/web/sites/operations
uri: https://operations.ddev.site
mercury:
root: /var/www/html/web/sites/mercury
uri: https://mercury.ddev.site
mars:
root: /var/www/html/web/sites/mars
uri: https://mars.ddev.site
venus:
root: /var/www/html/web/sites/venus
uri: https://venus.ddev.site
That technically allows you to use ddev drush @ddev.mars si standard --yes, but you can't actually do that because the database is shared with just prefixes. So dropping all tables isn't just the mar tables, it's all tables in the database named db. Something like ddev drush @ddev.mars key:set admin 123testingkey works fine.
Another option is to add 4 .yml files named named mars.site.yml with ddev as the namespace in each file like...
ddev:
root: /var/www/html/web/sites/mars
uri: https://mars.ddev.site
Then you end up with aliases like @mars.ddev. Either way, there you'd need a 2nd set of composer commands in https://git.drupalcode.org/project/operations/-/blob/2.x/composer.json?r...
I'm going to try creating additional dbs in the DDEV onfig.multisite.yaml like https://github.com/ddev/ddev-contrib/blob/master/recipes/drupal8-multisi... and then use $databases['default']['default']['database'] = 'mars';instead of $databases['default']['default']['prefix'] = 'mars';.
If that works, the best solution might a 2nd set of composer install commands that use the ddev aliases for DDEV users.
The steps for installing operations in a multisite configuration with DDEV when you already have Composer installed locally is fairly easy. These are the steps to get the structure. While the settings.php for the planet sites includes some Lando specific settings and there are composer install steps, I'm not incorporating any of that yet.
git clone https://git.drupalcode.org/project/operations.git
cd operations
composer install
composer require drush/drush
ddev config [select the defaults for prompts]
Project name (operations):
Docroot Location (web):
Project Type [backdrop, craftcms, drupal10, drupal6, drupal7, drupal8, drupal9, laravel, magento, magento2, php, shopware6, typo3, wordpress] (drupal9):
ddev start
If we include a .ddev directory in the repo, users wouldn't have to do this next step. Because DDEV uses PHP8.0 for D9 installs and this project requires PHP8.1 or >, we need to edit the .ddev/config.yml to change php_version: "8.0" to php_version: "8.1".
Congratulations, the container for https://operations.ddev.site is now configured. If you go to https://operations.ddev.site, you could now complete the install using the OX Stock install profile...
...but to see Site Manager working we also want to configure 3 subsites for https://mercury.ddev.site, https://mars.ddev.site and https://venus.ddev.site.
A lot of this can be scripted, but to manually configure this with DDEV we still need to do the following steps.
First, add a file named .ddev/config.multisite.yaml with the following contents...
additional_hostnames:
- mercury
- mars
- venus
The same PHP container is also used to answer all routes so with the Drupal sites.php configuration, we need to add the following to sites.php so the multisite operations knows which directory in the Drupal sites is handling each request.
cp web/sites/example.sites.php web/sites/sites.php
Add the following to sites.php.
$sites['mars.ddev.site'] = 'mars';
$sites['mercury.ddev.site'] = 'mercury';
$sites['venus.ddev.site'] = 'venus';
Now create 3 empty directories for each site in web/sites and copy the DDEV database configuration from default into each site.
mkdir web/sites/mercury
mkdir web/sites/mars
mkdir web/sites/venus
cp web/sites/default/settings.php web/sites/mercury/settings.php
cp web/sites/default/settings.php web/sites/mars/settings.php
cp web/sites/default/settings.php web/sites/venus/settings.php
At the end of each settings.php, replace...
// Automatically generated include for settings managed by ddev.
$ddev_settings = dirname(__FILE__) . '/settings.ddev.php';
if (getenv('IS_DDEV_PROJECT') == 'true' && is_readable($ddev_settings)) {
require $ddev_settings;
}
with...
// Automatically generated include for settings managed by ddev.
if (file_exists($app_root . '/sites/default/settings.ddev.php') && getenv('IS_DDEV_PROJECT') == 'true') {
include $app_root . '/sites/default/settings.ddev.php';
}
$databases['default']['default']['prefix'] = 'mars';
That change allows each planet site to create tables in the database created for the operations site using the table prefix method. This is not ideal, but it's quick.
Restart DDEV using ddev restart. When you restart the project, the routes and databases will be created for the planet sites.
Restarted operations
Your project can be reached at https://operations.ddev.site https://mars.ddev.site https://mercury.ddev.site https://venus.ddev.site https://127.0.0.1:61302
Now when you visit the 4 sites, they are all responding from a single DDEV application.
The next steps are to figure out how to deal what's currently wrapped in a check for getenv('LANDO') in https://git.drupalcode.org/project/operations/-/blob/2.x/web/sites/defau... and see which of the files that DDEV is creating and altering can just be included.
Progress. It looks like the command has changed again to just `lando composer operations:install`. That is working for https://operations.lndo.site/, http://operations.lndo.site/ and http://mars.lndo.site/. https://mars.lndo.site/ is still a 404. The HTTP requests for Venus and Mercury still return Mars and the https for all the "planet" sites return 404s.
Thanks. I have some time carved out on Monday to look at this again.
If the goal is to add a configuration form, I created a MR from @sidharth_soman's patch. That is RTBC.
However, there is still nothing in this form. Is it necessary? Are there issues defining the settings that should be configurable?
Because this is only adding static files, you might still be able to get it into 10.1.x. That said, my guess is the blockers will be related to the process of managing what is in these files.
What I'd recommend is to maintain a patch that organizations interested in accessibility can add their current D10 build process with something like...
"extra": {
"patches": {
"drupal/core": {
"Add Drupal core ACR files": "https://www.drupal.org/files/issues/add_acr-3335955-19.patch"
}
}
}Focus on the process of maintaining the ACR as if it was already in core through the D10 releases and then shift to getting the files into D11 as that gets closer to a release.
Right now it's just you and I having this conversation and I'm already sold on the advantages of including ACR files in core and contrib. Having a patch that is easily added to a build will make it easier to socialize this.
We have nothing running for role-based feature testing for D10.
With D7, we ran Behat with Travis.ci at https://github.com/cuboulder/express. We also hosted that at https://www.drupal.org/project/express → , but didn't do any testing with Jenkins/Drupal CI.
We used Cypress to do testing of front-end projects like https://github.com/CUCentralAdvancement/giving-frontend.
We've added some basic testing to the contrib projects we maintain like https://www.drupal.org/project/webform_pardot → , but haven't shifted those to GitLab CI yet.
We also recently shifted from an on-prem GitLab with limited CI minutes/integration options to GitLab SaaS with nearly unlimited minutes. While we were waiting for that to happen, we shifted our workflow to leverage Pantheon's Autopilot for VRT before using a Pull Mirror to pull those changes back into GitLab for additional testing. We can also create Pingdom Advanced Transaction tests that can be run by Solar Winds Web Performance Monitor, but those have to be paused any time we are updating a DOM element used in the test. The test cannot be updated with the code.
Everything we're doing with Playwright is green field.
Can you clarify how you'd see the ACR files being maintained in different releases? According to https://git.drupalcode.org/project/drupal/-/blob/34162e77f14553bebba1dd8... and https://git.drupalcode.org/project/drupal/-/blob/bc2fa363c69549326c69170..., the version reviewed is drupal-10-16... which I'm assuming translates to 10.0.16, but it could also mean 10.16.0.
I think the file names and versions in the ACR need to reflect semantic versions. drupal-10-0-16.html would allow for drupal-10.1.16.html. Not sure how you'd support that otherwise.
Regardless of the version of D10 reviewed, MR is for 11.x-dev.
I'm assuming that you wouldn't just role the version forward with each as part of the release process like https://git.drupalcode.org/project/drupal/-/commit/1c5335de2322b7c232d9a... as the ACR is the version that was reviewed, but including a review of 10.0.16 in the 11.x-dev branch seems odd too as the major version number change indicates major changes in the versions of the code previously reviewed.
Wouldn't it make more sense to target the 10.1.x-dev branch?
Does it make sense to include any 10.x.x review in the 11.x-dev branch? Would it make more sense to remove it at the start of each major version release and add it as part of the beta process?
The /sitemap.xml returning a 200 that is valid XML is obviously important, but valid XML with URLs that aren't valid because of a bad base URL or permissions is something of a false positive.
2. Run through each sitemap.xml file and test every URL. Don't validate URLs that match a pattern.
I'm thinking more of a 1½... Is the sitemap.xml accurate after events like a page is published, a page is unpublished or the anonymous role's permissions for a content type is changed?
Because Google doesn't like to get 404 and 403 from URLs included in the sitemap and you've already added 📌 Add 404 test Fixed and 📌 Add 403 test. Fixed , it would make sense to me to confirm that these URLs have been removed from the sitemap.xml in addition to the HTTP response check.
That wouldn't get into which contrib module generates the sitemap.xml, but would verify that the XML is updated as part of the publishing and permission changes.
Does that make sense?
We are dealing with this now. Went ahead and created an issue since it's listed as "coming up" on the project page.
We are using https://www.drupal.org/project/xmlsitemap → . To be able to render sitemaps on every site instance on Pantheon with the correct base URL, we've added this to our settings.php...
if (isset($_ENV['DRUSH_OPTIONS_URI'])) {
$settings['xmlsitemap_base_url'] = 'https://' . $_ENV['DRUSH_OPTIONS_URI'];
}
That works when dev, test and live have domains configurated as well as for multidev instances without a DNS entry, but still requires something to trigger the sitemap to be rebuilt.
It seems wrong to use a test to do that. Looking at potentially using https://docs.pantheon.io/guides/quicksilver/install-script to call a PHP script to facilitate the rebuild, but it seems unlikely that would get added to the XML sitemap project. We could write our own script to do a rebuild after any clone workflow step on Pantheon, but I figured I'd ask what the plan was to be able to test the sitemap.xml here.
Is the plan for keep ATK contrib agnostic? I'm not sure if https://www.drupal.org/project/simple_sitemap → has this base URL issue or not, but it doesn't have the features we want.
Would the sitemap rebuild script for the xmlsitemap module be something that could be added to https://git.drupalcode.org/project/automated_testing_kit/-/blob/1.0.x/mo... ?
Woot! ✨ Add Status to OverviewTerms.php form Fixed was merged into core! Small step, but it improves the core UI when using this patch.
THANKS! kbin.social is just coming back online now, but I'll dig into this as soon as their upgrade is complete.
> is that some sort of internal feed it's getting content from ?
As far Kbin's terminology, it is confusing. Lemmy's terminology makes more sense to me personally, but the tech stack (Rust/TypeScript) makes less sense... so here we are.
Kbin Microblogs are basically aggregated content from the fediverse posts (Mastodon = Toots, Kbin = Articles, Lemmy = Posts), based on the hashtags a Magazine user is configured to follow. In this case, you can follow @drupal@kbin.social on Mastodon. A Kbin Magazine = Reddit sub or Lemmy community. When creating a new magazine, it automatically displays the hash of the m/name. In this case everything #drupal. Everyone using that hash shows up as active members of the Magazine even if they have no idea it exists. What Kbin adds to the Mastodon posts is the ability to upvote. Those are Kbin specific and require a Kbin.social account to do... while replies, boosts and favorites are all federated.
To "prime the pump" on Kbin, I've been manually creating Articles with a links to everything appearing in the Planet feed. I've also created https://feedsin.space/feed/drupal-planet, but I'm intentionally using only #planetdrupal to avoid duplicate posting.
Now people like have started posting @kanapatrick@techhub.social have started posting Articles about their own Drupal related blogging themselves https://kbin.social/m/drupal/t/131850/Challenges-and-Concerns-Holding-Ba....
I'm assuming most people are aware of https://techcrunch.com/2023/03/13/wordpress-com-owner-automattic-acquire.... I'm seeing more content in the fediverse coming directly from WP posts. I'm hoping to add some logic to a Drupal instance as Drupal Planet reposter. So rather than posting everything in the RSS like https://feedsin.space/feed/drupal-planet, it would look at the Magazine/Community to see if the URL had already been posted.
What I'm hoping to do is the opposite of what I did with the original post of https://dev.to/kreynen/change-my-view-d8-isnt-the-best-upgrade-path-for-... where I directed users to r/drupal to discuss. What I'd like to see is the conversation about Drupal related content taking place outside of 3rd party comment services like https://disqus.com/ or the blog/CMS itself where yet another account is likely required to participate in the conversation.
It seems unlikely that Twitter will ever adopt ActivityPub, but with Meta's Threads launching this seems like it would give everyone an opportunity to participate in the discussion regardless of the client/services they choose to do it on.
@baikho now that #3261803: Using GitLab CI instead of Drupal CI → no longer requires opting into GitLab CI testing, we might consider adding that as a goal for 2.0.0 release. There is a lot that can be borrowed from the webform_civcrm project to improve the test coverage with a more modern approach https://github.com/colemanw/webform_civicrm/actions/runs/5177246512/jobs...
THANKS!
I granted you maintainer rights. We are likely shift to using Webform->Marketing Cloud Data Extensions for future projects. We're still using this, but it has been meeting our needs in the current state so I haven't been very motivated to push this forward. Glad to have the help!
hestenet → credited kreynen → .
hestenet → credited kreynen → .