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?
Tested the Monolog module now again, yes - it is able to catch and store all the metadata to the log entry!
But it works only for monolog-related handlers, for the Drupal Watchdog and other Drupal-based loggers, the metadata still disappear, they are missing in the "watchdog" db table's "variables" column.
The initial idea of the "Logger" module is to fix this issue, to give the developers the ability to see the logs in the Drupal Admin panel including custom fields and all metadata, and the "logger" + "logger_db" modules now work well for this task!
Also, comparing with "Monolog", the "Logger" module is a very lightweight implementation with no dependencies, that just registers a new "logger" service in the Drupal services, keeping all other loggers work the same as previously.
The approach of the "Monolog" module is deeper - it overrides the logger.factory with the custom factory 'Drupal\monolog\Logger\MonologLoggerChannelFactory', which makes other Drupal-based loggers stop working, and we need to initialize the 'drupal.dblog' handler to make them work again.
So, in result, both modules are good and resolve the task with logging custom metadata, but with the "Logger" module approach, I see these benefits:
- Provides the ability to store logs directly in the Drupal database, providing Views plugins to view, filter, and sort by custom fields.
- Works out of the box without overriding the log channel implementation and keeping other Drupal loggers working as previously.
- Fully configurable through the Drupal admin panel with no manual editing of services yaml files.
- No dependencies on external libraries and a smaller size of the module.
- More lightweight implementation with registering only two services, instead of 20+ services like in Monolog.
- Better performance and less memory usage, because much less code and services are involved in the logging process.
So, from my point of view, the "Logger" module is the best solution for:
- production, where you usually need just "log everything to stdout" that will be processed later by log scrapers like Grafana, Elastic, etc.
- localhost development, where developers just want to see the logs in the Drupal admin panel, without installing and configuring any external tools.
- External modules that want to provide report pages in the Drupal admin panel, displaying custom fields from the database, like
https://www.drupal.org/project/request_logger →
- Drupal junior developers, who just want to find all the logs in the Drupal Admin panel with custom fields, and configure everything in the Drupal Admin panel, without creating custom YAML files.
And for more complex cases, yes, the "Monolog" module is still a great customizable tool!
So, in the module description, I will mark the "Monolog" module as a good alternative for more complex cases, does it sound good to you?
Before creating this module, I tried Monolog too, but could not achieve logging all the custom metadata using standard Drupal Logger interface. All the data just disappeared, only the rendered log message and other metadata came to the Monolog log entry.
If Monolog still able to log coustm metadata using a Drupal Log channel, could you please provide a working example?
murz → created an issue. See original summary → .
Created a MR with fix https://git.drupalcode.org/project/flexistyle_bootstrap/-/merge_requests/14 - please review.
Seems we got some progress in this area - this feature for compare URLs is merged: https://gitlab.com/gitlab-org/gitlab/-/issues/217206
But for merge requests - still no progress: https://gitlab.com/gitlab-org/gitlab/-/issues/373246 :(
Created a MR with fix https://git.drupalcode.org/project/flexistyle_bootstrap/-/merge_requests/13 - please review.
Fixed this issue in the MR https://git.drupalcode.org/project/flexistyle_bootstrap/-/merge_requests/12 - please review.
Also, in the online demo profile, set the site name to "commercetools" and set the site logo as commercetools.
And to make the list of themes more compact, let's show them as a horizontal list separated by '|' like this:
Bootstrap [Used as default] | Bootstrap5 [Set as default] | Bootstrap Barrio | Radix | ...
Seems this is not possible from the technical side because of the limitation of the initial architecture of the Layout Builder components. So, the Drupal community rethought this approach from scratch and re-implemented it as Drupal Canvas https://www.drupal.org/project/canvas →
Therefore, seems all new efforts will be invested into developing Drupal Canvas, instead of improving the Layout Builder ;(
I would like to opt-in this module:
https://www.drupal.org/project/commercetools →
- it has 84 issues, and all maintainers agree we are ready to try GitLab issues.
We understand we cannot revert this change and there may be some unexpected issues as early adopters.
I prepared a MR with adding the langcode: en to the config/install, please review.
Seems I found the source of the problem! We have the logic that adds the missing items that are active inside the "if" condition in the file src/Plugin/facets/query_type/SearchApiString.php:
public function build() {
...
if (!empty($this->results)) {
// Add unprocessed active values to the result. These are selected items
// that do not match the results anymore.
foreach ($unprocessed_active_items as $val) {
...
}
}
}
So, it is simply skipped if no results are retrieved from the facet. And moving it outside of this condition fixes the issue.
I created a fix in the MR https://git.drupalcode.org/project/facets/-/merge_requests/341 - please review the approach, is it right?
Alexey Korepov (@murz): working on AI Observability, logging, and Usage Reports ( ✨ Add default views to the AI Logging module Active ).