Maybe we can try another side and somehow ask AI to safely extract and generalize the most interesting parts and approaches of the current site setup, following the security rules, to not extract any security-sentitive information?
Is it mainly a dumping ground for AI to consume Drupal code or for humans to look through ?
If it's a dumping ground for AI, we can name the category as "slop"™ to pay back to AI by a human-generated content 🤣
By the way, Drupal.org can provide a personal repository for Composer packages to motivate people share the code. Because very often developers have some modules that need to be shared between their own multiple websites, but they are not ready to be a full universal project to reuse with the community.
In my projects, I usually create a separate directory modules/shared for modules that are used in multiple projects, or not yet, but intended to be reused later.
For that cases, people usually start their own self-hosted Composer repositories and have to manage them manually. But with Drupal.org, they can just publish those modules to the Drupal.org private space, and configure websites to install modules from it.
By personal repositories I mean not private access, but personal namespaces per Drupal.org account, to not have conflicts with the public modules' names. Something like in NPM - @wondrousllc/fractal-twig-drupal-adapter, etc.
By the way, together with this, Drupal.org can provide paid services for private Composer repos ;)
The idea of sharing such modules is great, but usually they are useless without the full site configuration, because very often developers do not spend time on the installation flow for the new websites, and modules have a lot of dependencies on other modules and manual configuration, which makes them impossible to install and test.
So, it's better to share the full setup with the whole site configuration, not only separate modules without context. But there comes out the security context :)
By the way, how will the issue credits be calculated after moving to GitLab issues - the same way as with Drupal.org issues?
Try to analyze the module https://www.drupal.org/project/external_entities → and reuse its API, or reimplement the same.
Also, for the reference, other related modules:
https://www.drupal.org/project/remote_entity →
https://www.drupal.org/project/views_remote_data →
https://www.drupal.org/project/entity_remote →
Seems it was related to Drupal.org issues, not reproducible now, closing.
Probably, we can combine loading an entity by ID and UUID, and in both functions, fill both static caches (per-id and per-uuid) at once with the same loaded entity object. So, it will be one object storage with two mapping arrays - by ID and by UUID, that will not increase the memory usage significantly.
Seems in the last release everything is fixed in the scope of other issues, closing.
@anoopsingh92, could you please review and merge this fix? It breaks all the Bootstrap dropdowns in the header :(
And https://gitlab.com/gitlab-org/gitlab/-/merge_requests/211410 is merged, so the feature of making a direct URL to a specific commit in the MR should be available on the next GitLab release, yay! So, let's wait for Drupal.org infrastructure to be updated to GitLab 18.7, and start using it!
Implemented - works well now using a helper module here https://www.drupal.org/project/commercetools_online_demo →
Now looks okay, fixed and merged, and even presented at the DrupalCon Nara 2025! ;)
Also, providing bridges from Slack to other messaging networks will make the general Drupal Community available for people in other countries, who have access to Slack blocked: China, Iran, Korea, Russia, Cuba, etc.
As I know, we have a pretty large Drupal Community in China, but they use WeChat for communication instead of Slack. But we have bridges from Matrix to WeChat here https://matrix.org/ecosystem/bridges/wechat/ that can connect the separated-by-service Drupal communities!
Mentoring on it at the DrupalCon Nara Contrib Day 2025.
As we have a lot of occurrences of the target="_blank" - it will be hard to manage in the issue text, I believe.
But I came up with an idea that we can prepare a merge request with the first commit that removes all occurrences of the target="_blank" in all files, and then, step by step, we will make a decision on what to keep and what to revert.
This way should me much more convenient because:
- We will have an actual dynamic list of changes.
- Each changed line will provide an easy way to look on the code around it to understand the context.
- We will be able to comment and discuss each case in a separate thread to make the final decision.
So, we in the Nara contribution room will prepare a merge request with this to start.
Faced this bug too, when we add any Bootstrap Dropdown to the page, it starts to behave wrong: instead of "onclick" it opens on the hover, because of this CSS override. The MR fixes the issue well, so marking as RTBC.
By the way, we also have this CSS, related to dropdowns above the removed rules:
.header-style-3 .dropdown > .dropdown-menu {
display: block;
}
Do we really need it? I think it's better to keep the default Bootstrap Dropdown behavior, and use Bootstrap-related classes in Twig, instead of overriding the behavior by CSS.
Yeah, sorry for delay, with CKEditor 5 everything works fine!
That commit was reverted in the https://git.drupalcode.org/project/drupal/-/commit/9ce9ba1c8d0c4d13dd0a3... so the issue is fixed in the Drupal Core 11.2.6, released today, yay!
The issue is affected by this commit https://git.drupalcode.org/project/drupal/-/commit/bffe96901e132b5032621... - in it new CSS styles were added:
td > .form-item {
display: flex;
align-items: center;
}
that breaks the field layout.
Faced fatal errors in custom Twig templates on several websites after upgrading to Drupal Core with this change, because the Twig function "render" started to return an object instead of a string for translated strings. Reported a separate issue 🐛 The Twig "render" function started to return TranslatableMarkup object instead of string for translations Active about this.
Here is a fresh documentation about configuring the Matrix Slack bridge: https://ems-docs.element.io/books/element-cloud-documentation/page/publi...
The feature will be implemented in the Logger DB module scope, here is the issue: ✨ Export logs to file and import with deduplication Active
By the way, users right now can already start using the Matrix protocol to talk in Slack with Drupal Community, using a Beeper client - I have been doing this for several years already, and happy to use only one single app to talk with Slack users, Telegram users, WhatsApp, Facebook, etc.
Mentioned this issue in the remaining tasks of the main issue 🌱 Slacking Off Active , linking it here as the parent issue.
I updated the main issue about Matrix integration 🌱 Slacking Off Active so let's close this one and move all initiatives there?
Let's close this as a duplicate of 🌱 Slacking Off Active as Gitter is now uses Matrix.
Started to fill the "Remaining tasks" section, but in the end, reworked the whole issue summary to match the current situation and with more motivation points for slacking off, because the original one from 2019 looked pretty outdated.
@pasqualle, feel free to revert some parts of the initial message if needed.
Seems SSO on Drupal.org is finally done well using Keycloak on https://accounts.drupal.org/ - so, maybe now it's the best time to start migrating chats from paid Slack workspace to free, decentralized, and opensource Matrix protocol? Starting with allowing bridging, at least, and then - 📌 Setup a dedicated drupal.org dedicated matrix server Active .
Alternatively, I can introduce a new submodule logger_db_monolog or a separate project, but I think it's too much for such a simple task.
Yes, just +1 definition for 1000 already existing ones will not make the things worse :) Alternatively, we should implement the dynamic service provider or hook, that will just overcomplicate the things with no benefits.
So, let's keep it as is. Who use Monolog on real projects, could you please check if this works well and provides suitable format of the log entry in the database? Cuz I use only Logger on my projects ;) and has not a lot of experience with Monolog.
I have some ideas on how to postpone the initialization of the monolog handler when monolog is not enabled on the project
But in what cases the service monolog.handler.logger_db can be initialized if Monolog is not is not enabled? It will be just a definition in the list of services, with no initialization, as I understand.
This was related to issues on the local setup, not related to the module. Closing.
This is a task for another module - here is the actual issue ✨ Allow optionally storing the request and response body to logs Active - please review and test it.
Made a quick implementation - it seems to work well, but needs review and deeper testing, so would be great to receive feedback from Monolog users, moving to "Needs review".
In addition to this, I also implemented a Monolog handler in the Logger DB module in the issue ✨ Implement a handler for Monolog logger RTBC ! The implementation looks pretty simple and seems to work well, so @mxr576 and @lussoluca - could you please review and test it too?
@murz, could you please update the project page with the changes from the README.md?
Updated too.
Created a MR with fix https://git.drupalcode.org/project/ai/-/merge_requests/989 - please review.
Why Extended Logger? Why not Monolog?
Tested with Monolog, all the token usage and other AI metadata are coming to the Monolog Record too! So, the ai_observability can be used with the Monolog module too, thank you, mxr576, for the details!
Will add it to the list of recommended loggers in the issue 📌 Add Monolog as a compatible logger for the AI Observability module Needs review but will keep Logger as the first recommendation, because it provides more simple setup with no dependencies, and the ability to view logs directly in the Drupal admin panel.
I updated the module's description (README.md file) to recommend Monolog as an alternative in the MR https://git.drupalcode.org/project/logger/-/merge_requests/7 - please review, and maybe add more details to the comparison?