Hi,
Why don't we spend any effort along these lines on existing areas we can make better for people as well as AI?
As in, better docs, more example modules?
I'm concerned that a bunch of disorganized slop that only an AI can consume lowers the quality... the previous comments about the junk drawer resonate here -- why don't we turn this energy into fleshing out more documentation?
I rebased this on 2.1.x branch, and merged everything in -- and then added config schema for this action.
I think this really needs a change record -- I got caught out updating ECA 2.x to 3.x, and it deleted a bunch of models I had that used 3rd party action plugins that did not have a schema.
Ok hitting circular dependency issues even on 2.0 -- this time in mailer_override. Still investigating.
I think there are some questions to answer here -
- How would someone (AI or human) find an appropriate "adaptable module" or snippet?
- How would you judge its quality, in terms of security, architecture, side effects?
- How do we keep out spam -- is this limited to people who have gone through the security review?
To me this all sounds like a bunch of work on things that might end up being orthogonal to the problem you're trying to solve -- make AI coding assistants work better with Drupal.
I've been using OpenCode for a month or so now, having switched over from Claude Code, and have tried out a bunch of models. I'm constantly prompting it to not touch contrib modules unless it's one that I maintain, or the problem can't be solved any other way -- and then I have it write up an issue description for me. I end up creating the issue at Drupal.org and doing all the branch setup/merge request creation myself because I have yet to have the AI do that correctly, or even create a patch that applies correctly.
It seems to me that if we want AI to write better Drupal code, we do need a library of code techniques illustrating how to do this in a way that isn't just slop. Is that a library of examples as we discuss here? Is that a RAG database we populate from somewhere? Is that a detailed custom prompt, or AI context we provide somehow? Or is it a custom model we train on a bunch of Drupal code?
All of those do need a library of custom code to put into the prompt, vector database, training content, or something -- but I think having more of that be rules, best practices, better and broader api documentation examples that are organized to make it easier to find would be far better than thousands of code examples, of which many probably use bad patterns, open up security vulnerabilities, etc.
Sorry, looks like this is already fixed on the dev branch, just not released! Duplicate of 🐛 TypeError: Cannot access offset of type array on array in Drupal\Core\Database\Query\Merge->key() (line 331 of core/lib/Drupal/Core/Database/Query/Merge.php). Active .
Hi,
It is happening on several sites running 10.5.6.
None of these sites have been upgraded to 11 yet...
Cheers,
John
This seems to be all that's needed for D11 compatibility, I was able to enable/use in D11 with just this.
Hi,
I'm reopening this issue because I've been hitting it on multiple sites for years now, and it's reached the point where it's super annoying.
The issue is that different environments for the same site export the same configuration in different order. This leads to this configuration showing "overridden" on one site or another. Because we check our production sites nightly for config overrides, this leads to a bunch of extra management and effort, or exceptions to our normal update processes.
Here's an example diff:
diff --git a/config/common/core.menu.static_menu_link_overrides.yml b/config/common/core.menu.static_menu_link_overrides.yml
index 2022a6ce6..4fa1d46de 100644
--- a/config/common/core.menu.static_menu_link_overrides.yml
+++ b/config/common/core.menu.static_menu_link_overrides.yml
@@ -14,44 +14,44 @@ definitions:
expanded: false
enabled: true
'admin_toolbar_tools__extra_links:media_page':
- weight: 5
menu_name: admin
parent: system.admin_content
- enabled: true
+ weight: 5
expanded: false
+ enabled: true
entity__microcontent__collection:
- weight: 6
menu_name: admin
parent: system.admin_content
+ weight: 6
expanded: false
enabled: true
trash__admin_content_trash:
- weight: 7
menu_name: admin
parent: system.admin_content
+ weight: 7
expanded: false
enabled: true
'admin_toolbar_tools__extra_links:media__add__icon':
- weight: 2
menu_name: admin
parent: 'admin_toolbar_tools.extra_links:add_media'
+ weight: 2
expanded: false
enabled: true
'admin_toolbar_tools__extra_links:media__add__image':
- weight: 3
menu_name: admin
parent: 'admin_toolbar_tools.extra_links:add_media'
+ weight: 3
expanded: false
enabled: true
'admin_toolbar_tools__extra_links:media__add__link':
- weight: 4
menu_name: admin
parent: 'admin_toolbar_tools.extra_links:add_media'
+ weight: 4
expanded: false
enabled: true
'admin_toolbar_tools__extra_links:media__add__video_remote':
- weight: 5
menu_name: admin
parent: 'admin_toolbar_tools.extra_links:add_media'
+ weight: 5
expanded: false
enabled: true
... on some site environments, "weight" is exported as the first key of each entry. On other environments, it's in the middle. And the "enabled" key also seems to shift around.
Importing the changed config using drush config:import appears to complete successfully (no errors), but it changes nothing -- the config continues to show as overridden on that environment. If we export and commit the change on that environment, it then shows as overridden on other environments.
Curiously, we are using exactly the same PHP configuration to export/import these configurations -- we're using a PHP CLI provided by Drupal Flake → which is hashed to be identical. Also, copying the production database into an environment that exports this differently also does not fix the issue.
The key question here: What is the canonical ordering of the keys of these menu overrides? Which is the correct ordering? I think the problem is, the schema for this is not specifying it, and the previous efforts to make these configs follow a canonical order somehow is not applying to this configuration.
This doesn't work in D11 -- the module_implements_alter code errors out with
\Drupal::$container is not initialized yet. \Drupal::setContainer() must be called with a real container.
I'm having whitescreens with ai_automator active, with ECA Helper enabled: 'TypeError: Drupal\ai_automators\Plugin\AiAutomatorProcess\DirectSaveProcessing::__construct(): Argument #3 ($messenger) must be of type Drupal\Core\Messenger\Messenger, Drupal\eca_helper\Decorate\Messenger given, called in /var/www/html/freelock.com/modules/contrib/ai/modules/ai_automators/src/Plugin/AiAutomatorProcess/DirectSaveProcessing.php on line 58 in Drupal\ai_automators\Plugin\AiAutomatorProcess\DirectSaveProcessing->__construct() (line 48 of /var/www/html/freelock.com/modules/contrib/ai/modules/ai_automators/src/Plugin/AiAutomatorProcess/DirectSaveProcessing.php).'
... this MR fixes it, and it looks like the correct fix to me.
We are now successfully adding local extensions on several projects, including:
- PHP extensions (redis, sqlsrv, others)
- PHP configuration (ini settings)
- Other nix packages (weasyprint, python packages)
- Extra devShell items (env vars, other things possible)
... so general extensibility is all working fine.
What's next - new services added to the Services Flake config for process-compose - mailpit, solr being top contenders. I think those will be implemented in a different way -- probably as optional plugins activated by setting values in the .env file.
Marking this issue as done.
This is substantially easier with the Group Purl → module. The 3.x-dev version supports Group 3 now, and is just waiting for a compatible version of the PURL → module to get released so the tests pass.
With Group PURL active, you configure pathauto for your groups, and set content types that go in groups to "keep context." And then you have a Views contextual filter default argument for the active group ("Group ID from Purl"). No need to muck about with relationships -- if a block is placed on a page in a particular group, this will set the default argument for you.
Aha! Our CI/CD logs show the problem...
> [notice] Update started: redirect_update_8110
> [error] Exception thrown while performing a schema update. SQLSTATE[01000]: Warning: 1265 Data truncated for column 'enabled' at row 1: ALTER TABLE "redirect" CHANGE "enabled" "enabled" TINYINT NOT NULL; Array
> (
> )
>
> [error] Update failed: redirect_update_8110
[error] Update aborted by: redirect_update_8110
[error] Finished performing updates. ... so it looks like the Schema alter worked but threw an error, and so it did not complete.
The site where I experienced this is running Drupal 11.2.4, php 8.3.25, MariaDB 11.4.7.
This does not work for existing redirects.
Looking at function redirect_update_8110(), it does add the field and set the default value for the field -- but THIS ONLY AFFECTS NEW VALUES GOING FORWARD -- it does not set the value on existing redirects. Looking in my database, I see the new "enabled" column has 2000+ rows where this is all set to null, and we had some consternation on our team when some redirects they rely upon suddenly quit working.
There should be a post update hook that sets existing redirects to Enabled.
A quick workaround for anyone affected by this is a sql query in the db:
`UPDATE redirect SET enabled = 1;`
... that will enable all your existing redirects.
Successfully added Weasyprint, a Python package, using this local-extensions.nix mechanism -- I did have to add support for adding to the php-fpm process's $PATH and fix a couple other internal issues.
Ok! This is now working -- but you need to apply the fix in 🐛 PHPUnit functional tests cannot connect to MySQL database with a specified unix_socket Active to run any functional tests that require a database. So far I have only used this on a Drupal 11.2 site.
What's now added to the flake, and how you use this:
1. Get your site up and running using Drupal flake.
2. In your shell, run nix develop or use direnv with the current flake installed.
3. If you have not installed phpunit or other necessary code to your site, use phpunit-setup -c to install the composer dependencies.
4. If you have not applied the patch, run the command given to you by phpunit-setup -c, to quickly add the patch to composer.json, and then run composer install.
5. Run phpunit-setup with no flags to set up the phpunit.xml file and the test directories.
You're now set up to run tests! Inside this shell you can use phpunit and give it a directory of tests to run, use --filter to specify particular tests, phpunit should work as is.
There are two additional helper commands available:
- phpunit-module [modulename] - specify a module you want to run tests, and this will search for the module in the current project, find the tests, and run them.
- phpunit-custom - run all phpunit tests in all custom modules and themes.
The code for this is committed and pushed -- it should be available right now after using "refresh-flake" to update your local flake, or "nix flake init -t git+https://git.drupalcode.org/project/drupal_flake .
Leaving this issue in Needs Review for two other features that I have not checked yet:
1. Setting up the environment correctly when the flake is not used -- e.g. on a dev server that uses Docker -- it is supposed to pick up the correct database connection from the running environment.
2. Browser-based tests -- have not tried running any of those yet.
It is working successfully for unit and functional tests!
Fixed code standard issues, moved the tests into an existing UrlConversionTest classes, limited the scope of the change to just "unix_socket" to fix test failures, and sorted out the gitlab MR challenges - thanks @cilefen!
Struggling with gitlab here... when I first opened a MR, it picked up the entirely wrong commit. And now when changing the branch target it's showing 1000+ commits instead of just the one!
Fix in merge request, along with test... still needs a little cleanup for code standards.
freelock → changed the visibility of the branch 3546633-phpunit-functional-tests to active.
freelock → changed the visibility of the branch 3546633-phpunit-functional-tests to hidden.
Created a merge request, including the fix for #9.
freelock → made their first commit to this issue’s fork.
This is working, and tests are passing when run locally with a patched version of PURL. The main test failures are due to the Purl module not yet compatible with Drupal 11.
Tests are currently failing mostly due to the purl module not yet compatible with Drupal 11. @rbrandon says he can review/publish a release with the various merge requests next week, which should lead to our tests passing.
Ok I'm not sure if this was an issue from the original, but the issue I hit was that the form alter was not correctly altering the menu item content form.
Fixed the form alter for the correct form id pattern, and now I get the ability to set the PURL context per menu link (using group_purl, at least).
It seems like this might be better handled as a field widget? As a form alter I have no control as a site builder on where to place it on the menu item form.
So this is just a minimal fix for broken existing code -- I think it should be refactored to provide a better UX (but probably as a new issue).
freelock → made their first commit to this issue’s fork.
Added a merge request to make this easier, bump up the list. Also sent to the collection route.
freelock → made their first commit to this issue’s fork.
Fixed the whitescreens and other validation issues making this module break in Drupal 11. With these fixes, module works for me!
Several things broken in D11. Updating the MR...
3.x-dev is working very well -- it does depend on the D11 fixes for the Purl module. Waiting to tag a release until we have the tests running successfully.
This was a big lift, greatly helped along by defining clear tests, and using Claude.ai for much of the legwork.
The result is far better than what we had before, where we're using this it has stopped the corner cases and made this module work as expected!
This is done -- although there might be some of the compatibility changes included on the fixes for 🐛 Refactor URL generation into its own processor to run after Purl Active . I tried to isolate the Group 3 compatibility to this issue/commit to make the other issue easier to backport for Group 1/2 support if desired.
This is done. The .module file has the suggested wrappers to maintain Drupal 10 compatibility.
Initial set of tests -- I gave Claude a bunch of scenarios to test to get this working for Group 3, covering all the issues we've seen in this module about multiple group contexts, switching in and out, generating entity urls, etc. And then I worked through fixing them. Some of the corner cases I don't have passing yet, so these are in the @failing test group -- but these are all corner cases not needed for actual correct functioning.
This is working, for adding php redis support. Leaving open to test other kinds of additions.
freelock → created an issue.
Hi,
I don't think the code in #4 will fix this issue -- the issue is not with the setNewRevision(), it's with the updateLoadedRevisionId() call.
Workspaces compares the loadedRevisionId with the RevisionId. It might work if we remove the $entity->updateLoadedRevisionId(); line entirely.
I think the loadedRevisionId is meant to contain the revision_id before the entity got saved, so changing that during the update hook is the crux of the problem here.
This might be a good use for a new Action plugin, which you could use with ECA -- a "send webhook" action could then be used with any conditions you want before submission...
Hi,
I think until recently, handling incoming webhook payloads involved code. The webhooks module simply published an event with the data, and any other module could subscribe to that event and do whatever it wanted with the data. I was using a custom module to do this, sending the data to code to sync with content in Drupal.
It looks like the 4.x development version of this module is turning each incoming webhook submission into a new Drupal entity, which can then be shown in views, hooked up to actions in ECA, or do anything you can do with any other entity. I don't know the status of that version, have not tried it out yet to know whether it works or not.
I just created an ECA plugin on 🌱 I suggest planning an ECA integration for D10 Active so you can create an ECA model that gets any incoming webhook, and can do whatever you want from there. If you create that event in an ECA model, you then get the payload in [event:webhook:payload], which you can then deserialize and do as you please!
This is working as expected! Tested with two different inbound webhooks.
New Webhook Received event, provides the full webhook structure as [event:webhook], with the payload under [event:webhook:payload]. You can use the "deserialize" action to turn the payload into a data structure for access to what's sent in the payload. And when you add the event, you can select from a dropdown which webhook to trigger on, or all webhooks.
Pushing up to a production instance for internal testing now.
So I wanted to actually use this, and am vibe-coding a plugin -- and I see a bunch of work going into the 4.0.x-dev branch around the new webhook entities? That seems like a great improvement -- and I see the text on the project page saying this now works with standard entity events so we get ECA integration for free.
How far along is this? Is it ready to go? Is a generic webhook handler event still useful?
Have a prototype created, going ahead and sharing. This is probably more relevant for the 3.x branch, so setting back to that...
Another option would be to change the module weight to make the update hook run after Workspace's hook...
I'm not sure what the correct solution is here -- but I'm thinking that the behavior here is wrong. This is inside the update hook, after an entity has been saved -- it says it's preventing any further changes from creating another new revision. Is that necessary to prevent infinite recursion?
If not, it seems like maybe it's best to go ahead and create a new revision, since at this point the node has already been saved? Is this a concern in many models? Generally it's a really bad idea to save a node inside its own update hook -- is this too defensive to have here?
freelock → created an issue.
Closed.
freelock → created an issue.
freelock → created an issue.
Hi,
Plugin looks basically fine, but should use dependency injection to get the bsky.post_service service on line 24...
Should be along the lines of implementing the ContainerFactoryPluginInterface with a create() method and a constructor...
Cheers,
John
Added some options to the nix run .#demo target, along with the start-demo script.
You can now pass a package name, project name, and composer args to the start-demo script to install packages for other site templates/projects. This does support the one-line approach, though to do anything further with the project (such as use drush, etc) you will need to install the flake to get the appropriate environment.
For example:
One-liner to start XB Demo
Make a new directory and cd into it, and then run this command:
nix run github:freelock/drupal-flake#demo -- phenaproxima/xb-demo xb-demo --stability=dev
On my laptop that takes between 2 - 3 minutes to run before it opens a browser window with the Experience Builder demo loaded up. At the end of the "cms" job in your terminal window, it prints the admin username and password you can enter at /user, and then the dashboard shows the XB page you can open and edit, and you're in Experience Builder!
Start a new project from this point
The one-liner is a slick demo trick, but to continue development on a new project, you need the nix flake installed. You can do this after running the one-liner, but you might need to reinstall to use a different project name. Installing the flake first gives you more options:
nix flake init -t github:freelock/drupal-flake
direnv allow (if you have Direnv installed), or
nix develop (if you don't have Direnv available)
... Then you can use the start-demo script to install/configure a project:
start-demo drupal/core-recommended my-new-project