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 → .
There isn't any precedent for putting this in a robots.txt or humans.txt file.
Sorry. I didn't mean to put the information from the ACR in those files. I was just using those files as an example because they are public. Anyone can access https://www.drupal.org/robots.txt → and https://www.drupal.org/MAINTAINERS.txt → . While many organizations harden their codebase by removing those files or block access with a WAF rule or something like that, the information in the ACR is more akin to keeping a file called /KNOWNSECURITYISSUES.txt. I know that sites are already fingerprinted and probed for known vulnerabilities, but I'm worried organizations aren't going to be keen on publicly sharing the known accessibility issues in their codebase.
To be clear, I'm all in on the direction you are going with this and machine-readable accessibility reporting in general. I'm just concerned about the reaction even organizations leaning into accessibility (like every entity doing business with the state of CO impacted by HB21-1110 next year) will have if the ACRs are publicly accessible by default.
I'm also jumping ahead and thinking about tooling that could provide an aggregate of ACRs in a project if these were included in both core and contrib similar to how we can now report on all the licensing and known security issues in the PHP dependencies of a project. We have the same issue there that if a contrib maintainer chose to include an ACR in their module, it could have real legal consequences or generate nuisance filings.
THANKS! Applying the patch from #20 fixed the issue for me.
Where would these files be located in the project directory structure? Is the idea that this would be public like the output of a robots.txt or humans.txt file or would they exist at the same level as the composer.json? I can see a lot of advantages to being able to leverage these internally, but I'm guessing large orgs aren't going to want to publicly declare their accessibility shortcomings.
missed adding the column in foreach ($current_page in the first patch
Happy to continue chipping away at this, but I'm going to need some direction on where to add tests.
A logical place to test this might be https://git.drupalcode.org/project/drupal/-/blob/9f0d07d02cb7055f550fbe5...…]/tests/src/Functional/TaxonomyTermContentModerationTest.php… which doesn’t exist yet.
The way published/unpublished content is tested in https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/modules/nod... isn’t really a UI test.
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/modules/tax... is only testing published terms. https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/modules/tax... is testing unpublished functionality... but in Views.
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/modules/tax... gets into testing the admin/structure/taxonomy/manage/[vocabulary]
Does it make sense to add published and unpublished terms to test the new UI elements there?
The current MR solved my original issue, but our use case is only using moderation on a single vocabulary. I agree with @slydevil that it makes more sense to use view terms revisions in $id, but then we just get to the next place where the experience of managing drafts of terms doesn't have feature parity with content.
I added ✨ Add Status to OverviewTerms.php form Fixed and proposed a patch to add Status to the Terms Overview UI. Unlike the Content Overview, admin/structure/taxonomy/manage/[tid[/overview is not a View and there is no support to filter terms by moderation state making it hard to add the UI users are used to seeing in Content.
I'm not sure if the goal is to make incremental progress on this in multiple issues or propose a single MR that would provide the type of features users will expect to see when enabling moderation on a specific Vocabulary.
Yep. The draft version is "ahead" of the currently published version until it is published.
@ThomWilhelm Sorry, yes. All versions of PHP7 are already EoL as far as PHP. It's 8.0 that ends in November 2023. It's hard keeping up with the pace of life off the island. I'm mainly focused on D10 compatibility right now.
I made a MR that adds https://git.drupalcode.org/issue/shs-3354549/-/compare/2.0.x...3354549-d...
I think this would prevent composer from including a new rc5 release in builds that require PHP 7, but I think composer would still include rc4 because it doesn't have a PHP version requirement. I can't really test this without the PHP requirements being committed to a release. I tried looking at the metadata packages.drupal.org is returning about releases by following https://drupal.stackexchange.com/questions/259157/how-to-get-projects-da..., but I can't get to the project details using the pattern returned in https://packages.drupal.org/8/packages.json
When I try to access the project using drupal\/provider-2023-1$%hash%.json replacing the %hash% with d2b5f2c655ff47e88aeab86f02a3325319b9337ab824d5d6147a5b1709fa5e16, I get redirected to drupal.org. I was hoping I could see that Composer is seeing when it comes to projects that include a PHP requirement like https://git.drupalcode.org/project/metatag/-/blob/2.0.x/composer.json#L27.
I'm really not sure that adding a composer.json to a new release in the 2.0.x branch is going to fix this.
@Aneida brought this up in 🌱 D10 Support Fixed
The issue is 'static' return type declaration is only allowed in versions of PHP ^8.0. The underlying problem is that support for PHP7 ends in November and anyone working in D10 is already working in ^8.1.
I see 3 potential options
- Rollback the D10 changes in the 2.0.x branch, create a 3.0.x branch and make the changes necessary for D10/PHP8.1 compatibility there
- Add the minimum php requirement to the composer.json (@Aneida suggestion). I believe this results in Composer keeping the rc3 releases for projects where the PHP version is set to 7 in the root composer.json, but the module would still be flagged as needing an update by Update Status since on the rc4 release is supported
- Rewrite the static declaration so it works with both D9/PHP7 and D10/PHP8
@Aneida That's what I was afraid of. There's only 4 months of D7 support left, but trying to keep everything work with D9/PHP7 and D10/PHP8.1 is challenging. Probably should have gone with a 3.0.x release for D10.
@jhedstrom THANKS! It would have taken me a while to get to final classes not being mock-able.
Drupal\Tests\webform_pardot\Unit\PardotHandlerTest::testSubmitDataToPardot
Prophecy\Exception\Doubler\ClassMirrorException: Could not reflect class GuzzleHttp\Psr7\FnStream as it is marked final.Progress?
I'm not entirely sure if I'm just trying to debug an issue with a newer version of Guzzle or something specific to Drupal.org Guzzle errors ( #3292980: Testing system should explain why Guzzle responses can be unreadable → ) yet.
https://www.drupal.org/project/drupal/issues/3285230#comment-14599150 →
https://github.com/guzzle/psr7#fnstream
https://github.com/guzzle/guzzle/blob/7.5/UPGRADING.md#headers-event-has...
If anyone more familiar with the Guzzle changes can point me in the right direction, I'd appreciate it.
I think we're just chasing https://git.drupalcode.org/project/webform/-/commit/fff74893de8a6e2b14d2..., but I'm not sure the same test are going to run on D10 and D9. As D9 is nearing EoL and this project only has < 100 installs, I'm just going to update the testing to run only with Webform 6.x on D10.
Testing is failing with...
PHP Fatal error: Access level to Drupal\Tests\webform_pardot\Functional\ConfigurationTest::$modules must be public (as in class Drupal\Tests\webform\Functional\WebformBrowserTestBase) in /var/www/html/modules/contrib/webform_pardot/tests/src/Functional/ConfigurationTest.php on line 14
I found a few related/similar issues in other projects, but I haven't dug into what's actually happening or how it was fixed yet.
#3231016: Access level must be protected →
#3223667: Testing modules property Access Level →
#3145078: Possibly wrong use of $modules array in setUp() for functional tests. →
specifically,
https://www.drupal.org/project/metatag/issues/3145078#comment-13669740 →
I've only tested with D10.0.7, Webform 6.2.0-beta5 and SHS 2.0.0-rc4, but the form UI is rendering and the values are saved as expected.
It would be great if someone else could give this a once over before it's merged.
closing as fixed. the RC4 release now supports D10... woot, woot!
There is a MR in 🌱 D10 Support Fixed now for the 2.0.x release, but I'm not testing backwards compatibility. I'm not sure we shouldn't create a 3.0.x branch and make that only ^10.
Chosen still seems buggy, but core SHS functionality seems to be working as expected in D10. I haven't tested in D9 yet. I opened an MR to the 2.x branch. Not sure if that's the direction @stBorchert and @jhedstrom want to do with this, but this unblocks me on 📌 Automated Drupal 10 compatibility fixes Fixed . If we want to push these changes to a 3.x branch and make that D10 only, I'm happy to help with that.
HUGE thanks to everyone who has contributed!
"No issues" meaning SHS is fully functional?
@rahul1707 was that patch created from the current 2.0.x branch?
shs_d10_compatibility_issue_fixes-3349877-1_0.patch:153: trailing whitespace.
$parents = [];
error: patch failed: modules/shs_chosen/src/Plugin/views/filter/ShsChosenTaxonomyIndexTidDepth.php:6
error: modules/shs_chosen/src/Plugin/views/filter/ShsChosenTaxonomyIndexTidDepth.php: patch does not apply
error: patch failed: src/Plugin/Field/FieldFormatter/EntityReferenceShsFormatter.php:69
error: src/Plugin/Field/FieldFormatter/EntityReferenceShsFormatter.php: patch does not apply
error: patch failed: src/Plugin/views/filter/ShsTaxonomyIndexTidDepth.php:42
error: src/Plugin/views/filter/ShsTaxonomyIndexTidDepth.php: patch does not apply
I've created an issue branch and started making the changes there. If you could use that as a starting point, I'm happy to review.
When I started looking at this, I was originally thinking that the autocomplete options wouldn't provide much value.
Then I realized that autocomplete suggestions are CSE instance specific... to a certain extent.
If there is no top content related to a term, it will just throw general suggestions. Even when there is CSE instance relevant suggestion, if there aren't enough it will start loading general suggestions.
Good: On https://cse.google.com/cse?cx=17a13377043fa47f9 if you start typing terms with results on cu.edu like "serv..." or "ecom..." you will be prompted with more specific terms related to content on sites defined in scope of the CSE instance.
Less Good: If you start typing something like "reynen", the autocomplete suggests "Reynen Court" or "Reynen Luxury Homes" and "Reynen Bardis LLC". These autocomplete suggestions are similar to what you get when using https://www.google.com/ and will not result in any content.
Mixed Bag: The current President of the University of Colorado is Todd Saliman. If you start typing "tod..", it does prompt you with relevant terms at the top, but suggestion #5 if Todd Chrisley. There is no content about Todd Chrisley on any cu.edu site... and I'm not sure we want to imply there is.
Not sure this information would influence the decision to add support for the feature one way or the other, but I didn't know how this worked until now so I'm guessing there other people who don't know the autocomplete suggestions are (to a certain extent) specific to the CSE instance.
I can't see how this could get merged without resolving #3145661: Users without "administer taxonomy" permission can't see unpublished terms canonical pages → . The expectation of enabling Content Moderation on Taxonomy Terms is going to be that the responsibility could be assigned to the same roles as other types of content. Requiring Administer Taxonomy for this seems wrong.
Not sure if the lack of a View filter would get resolved here or in a follow-up issue, but this is another place where it won't work the way most people expect.
I think this fixes the issue in that users with only the authenticated user role do not generate an error... but they aren't logged out either.
Testing this is simple. With the patched module installed, create a user with no additional roles called test-user. Log into Drupal with test-user.
In another browser, log in as an admin user with permission to admin/config/force-users-logout/otheruserslogout. Check the checkbox next to `This setting will force logout all users except admin` and submit the form by clicking the Force Logout button.
Go back to the browser where you are logged in with the authenticated test-user. You will still be logged in.
Now add test-user to a role. As the admin user, run admin/config/force-users-logout/otheruserslogout again.
The test-user is now logged out.
The underlying issue remains. Users with just the authenticated user role really have no role. They are simply authenticated.
This module is using roles to get the list of users to log out instead of logging out everyone except the current user.
As of 1/21, Key now has an 8.x-1.17 release → . I haven't tested it yet and I wish they would fork the D8 and D9/10 branched into a true semver release, but this is progress.