🇩🇪Germany @a.dmitriiev

This will be a game changer I guess, as now a lot of operations will be done with AI and having a place where the prompt can be found easily is very important if you don't know from where to start.

I have a small concern about the storage though. Maybe until it is not too late, it is better to use the content entity? There will be more flexibility, and also the machine name as id will be harder to make unique when the number of prompts will increase with time. And of course with content entity it will be easier to track who and when created/updated the prompt, maybe even have some revisions (as while you are in a search of a good prompt, it could be that you have a couple of tries and maybe it is good idea that you can come back to some nice prompt that was 2-3 attempts before) and of course it would be easier to have some access restrictions. I understand, that this will not allow to easily create prompts on module installation like it can be done with config objects, but there are other ways to provide default content, especially with recipes.

What do you think?

I have refactored a bit the MR and all the plugins, so that they use the base class more, as most of the plugins use the same form elements, so it was easy to generalize the behavior.

a.dmitriiev → made their first commit to this issue’s fork.

I have split main plugin and balloon plugin in the way, that if you want the balloon menu you need to drag a new item to toolbar. This item is invisible. If you don't need it, the behavior will still be the same.

a.dmitriiev → made their first commit to this issue’s fork.

I have update MR with hook_post_update instead of updating all editor instances in the same hook_update. I have also noticed that individual plugins do not have schema definition. I have added the config schema for the plugin from this MR, but also added for all existing plugins.

a.dmitriiev → made their first commit to this issue’s fork.

I think as this issue prevents module features from being used, the priority should be raised to "Major", maybe even to "Critical" at some point.

Nothing against Spanish language, but I think for translating into other languages it will be easier with English string.

a.dmitriiev → created an issue.

Uploading the patch, so that it can be easily used in composer projects.

This is also a problem with chat assistant, as the stop sequence setting is displayed and if not set, then empty value is sent. I can confirm that fix from MR works and the request to LLM is successful

Previous patch was corrupted, sorry.

Updated patch, something wrong was with previous one

Uploading the patch also to use in composer based projects.

Uploading the patch, so that it can be used until the stable version is released.

a.dmitriiev → created an issue.

a.dmitriiev → created an issue.

a.dmitriiev → created an issue.

I have also opened a MR for easier collaboration.

I have now another use case:

The AI content suggestions would be nice to have as ajax callback, but the required field of the entity form could be skipped during validation, because for example you want the title to be suggested by AI and it is required.

I have re-rolled the patch for Drupal 11.1.x and removed the change in WidgetBase class, as it might be out of scope. Let's first create the possibility of skipping validation of required fields in general, so that contrib or custom modules can implement this in their code.

I have added the delete-form link template and added the "Do not use as template" button to operations dropdown on Template overview page. Please review MR.

a.dmitriiev → made their first commit to this issue’s fork.

I have adjusted the template to make sure that image wrappers are not rendered if there no image.

Method analyzeHtml allows $url as NULL. So it is reasonable to check the variable before using it. And the other saveReport method that is executed with this variable also allows it to be NULL. So, I think the MR should be merged. RTBC.

I will create some more issues, that I think can improve this module. There are not so many breaking changes that were introduced in the newest version of Project Browser, so I hope the transfer will be as smooth as possible.

It seems that project browser 2.x changed the sorting options structure and also the Project object. I made the adjustments and tested with Drupal 11.1.

There are some other improvements needed, as at the moment the project type is hardcoded to module and the `composer` commands are not always correct in case the project is in Gitlab's subgroup. But that should be in a separate issues.

a.dmitriiev → created an issue.

I have added the config folder with default settings and schema.
I have renamed ai_seo.configuration to ai_seo.settings so it follows the pattern of how normally modules name its config object.
I have made it possible to use the default AI provider and model even if no model is selected in ai_seo settings. So in case that you have already selected the default provider and model for chat operation type, there is no need to set it in ai_seo settings, unless you want to have different one just for this task. This way it is easier to start evaluating/working with ai seo functionality, as there is no need for additional step before you can start using it.

Please review MR.

a.dmitriiev → created an issue.

I have also noticed the prompt fields in all plugins are also set as required even if the plugin is not enabled, so I have added the Form API States to all plugins. Please review MR:

a.dmitriiev → created an issue.

+1 for the fix, as at the moment all routes return "Access denied"

The fix from the MR works.

I have also added the same fix to 3.x branch in this MR https://git.drupalcode.org/project/styled_google_map/-/merge_requests/8

I assume that darnold uses Drupal 11. For that version the ConfigFormBase needs one more argument, see change record https://www.drupal.org/node/3404140 → . MR includes the fix. Please check.

a.dmitriiev → made their first commit to this issue’s fork.

Fair point. The field_image is also used in Twig template. This also needs to be checked how it behaves without the field.

Thank you for fixing the bug. This was added to develop version of the module and will be added to the next release.

Let's have MR here as well.

a.dmitriiev → made their first commit to this issue’s fork.

The module is now opt-in for security advisory policy.

I have updated the MR with some fixes for library dependencies and code standards, please review.

I converted your patch to MR, so that it is easier to review and collaborate.

a.dmitriiev → made their first commit to this issue’s fork.

Released in https://www.drupal.org/project/frontend_editing/releases/1.8.12 →

Great, thank you, that was fast :)

The plugin manager that is used in the config action is from CKEditor5 module and it assumes that the plugins will be for CKEditor5. Is there a generic plugin manager for any editor? I think that each editor has its own plugin type, or?

a.dmitriiev → created an issue.

+1 for allowing admin theme to be used, as anyway the permissions will not be given to all users, but only for some privileged roles.

+1 for allowing admin theme to be used, as anyway the permissions will not be given to all users, but only for some privileged roles.

I have opened MR based on patch #47 for easier review process and maybe it will speed up the merge of the changes.

I have updated MR (also updated the fork branch as it was behind because of the last committed changes to the module).

Attaching the patch with the diff for the reference and composer projects.

@itothegore, what admin theme are you using? It looks like it is Gin, right? Here are the screenshots from Gin (in blue colors) and Claro (in grey colors) from my installation. Don't you see the sidebar the same? I made even the screenshot from wide state, where the buttons are placed in columns. Maybe browser cache?

Please check the permissions for Anonymous and Authenticated users here /admin/people/permissions. Search for "Search API Autocomplete". The permissions should be like this:

Search API Autocomplete has a granular access control per each autocomplete entity. Make sure you have allowed to use autocomplete for the roles you need to have access.

I have fixed some more style linting issues and removed div from li element, as the idea was to mimic what paragraphs widget does, and it has li with class and inside only input.

Please check and review.

I am not quite sure what model should be used as default for chat. I have set llama-3.3-70b-versatile but just because it seems like it is the latest version.

a.dmitriiev → created an issue.

I think that having patches in one place is still a good idea for having and overview. So when all the patches are listed in root `composer.json` then it is easier to find them and to manage them when they need a re-roll or should be removed. This is partially fixed by composer patches version 2, as there is now the patches.lock file. But once the recipe is unpacked and the list is relocked, all the patches that were in the recipe will be vanished.

I have tested the unpacking with nested recipe (more than 4 levels) and it worked correctly. Unfortunately the patches unpacker was moved to follow-up issue, so this is still not completely covering my use case, as some recipes Do have patches, and transferring them manually is quite a big task.

I have a silly question: how to unpack already installed recipe? The recipe that was added before the core-composer-update package. Is there a command to manually trigger the unpacking? I believe all users who were waiting for unpacker in core and had there recipe in composer.json would like to get rid of them when it is possible. So it would be nice to know how to trigger the command for certain package manually, if it exists, if not - I think that would be a good addition to this feature.

I would love to move it to RTBC, but there is some non-addressed feedback in the MR.

As an idea, maybe CSRF token should be passed by the client in a header instead? At the moment the cache max age is set to 0 only because of this token in the url, right? Or is there any other reason to have the block itself non-cacheable?

The client (JS part) can obtain the token by visiting the url session/token and then use it in X-CSRF-Token. This way there will be no need to url to have the token as query parameter.

Maybe I am wrong, of course.

Hi @marcphilipps,

Thank you for your suggestion, I think this would be a valuable improvement of the module. Please next time create a merge request of your changes as it will be easier for review. I have created the MR myself from your branch, but there is one problem: https://git.drupalcode.org/project/frontend_editing/-/jobs/4457641 - your changes do not pass coding standards check and therefor the MR shows many changes that are not relevant to the issue and they also break coding standards. Could you please check the changes again and make sure that you follow the coding standards? You can always check whether MR passes all checks in MR pipeline.

Thank you again,

Looking forward to see this merged.

Merging MR, will release a new patch version now

Please check MR, now for paragraphs Gin sidebar should not be displayed and cover the space.

Thank you for reporting the issue. I have seen this as well. In order to support the Gin content form styles for paragraphs I had to mark the form that is inside sidebar as "Gin content form" and this is the side effect of that. This will be checked.

a.dmitriiev → created an issue.

I have removed the moderation operation support to unblock this issue as it was a bit out of scope and not ready.

I agree that it might be too late to change, but as it is still alpha, maybe it is time now or never. It is of course too late to change the module name :)
This issue purpose is a discussion first as it is not a requirement to follow AI module naming convention. So maybe this change is just "nice to have".

a.dmitriiev → created an issue.

Hi @das-peter, thank you for a nice improvement. It would be of course better to know how to reproduce this problem, but I will try to check this asap, as it seems that it can cause problems like you describe.

Hi @kreynen,

Github integration should definitely be its own module, like other integrations (Azure, Gitea, etc, see https://www.drupal.org/project/config_patch → "# Available output plugins:" section). As this module is an extension of Config Patch module and just creates the output plugin for that module, the same approach can be used for Github implementation. You can also check other output plugins as a reference.

Failed test seems to be unrelated to the changes from this issue.

Attaching also patch for using in composer based projects.

Change record was added. I have also added the ability to place field/filter after or before defined field/filter for more flexibility

Attaching the patch also, so that it can be used with composer patches version 2, as it doesn't allow patches from MRs.

I have created a MR based on the changes from the previous patches. I had to do some modifications, as the patches were for module version 2.x. Also instead of list field type I am using entity reference field type for Roles selection and also the check is now on query level, so query selects all alerts that do not have role restrictions or it is for the roles that current user has.

I think that adding cache context user.roles should exactly make sure that the cached alerts will be served to correct users. Do we really need a test for this?

a.dmitriiev → made their first commit to this issue’s fork.

Definitely the requirement in composer json is needed, as the module states in .info.yml file that it has dependency on AI module. Moving to RTBC.

+1 for this improvement. It is now clearly visible in pipelines https://git.drupalcode.org/project/gemini_provider/-/merge_requests/12/p... that there is work needed, at least for PHPCS and PHPStan, and of course the compatibility with next major version will be shown in the first job (composer build).

Let's also delete the wrongly named file from config/install folder. Please check my new MR

I have also added moderation operation type support to the provider. There is still some work needed. For some reason the request with safety settings fail with the error:

* GenerateContentRequest.safety_settings[0]: element predicate failed: $.category in (HarmCategory.HARM_CATEGORY_HATE_SPEECH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT, HarmCategory.HARM_CATEGORY_HARASSMENT, HarmCategory.HARM_CATEGORY_CIVIC_INTEGRITY)
* GenerateContentRequest.safety_settings[1]: element predicate failed: $.category in (HarmCategory.HARM_CATEGORY_HATE_SPEECH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT, HarmCategory.HARM_CATEGORY_HARASSMENT, HarmCategory.HARM_CATEGORY_CIVIC_INTEGRITY)
* GenerateContentRequest.safety_settings[2]: element predicate failed: $.category in (HarmCategory.HARM_CATEGORY_HATE_SPEECH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT, HarmCategory.HARM_CATEGORY_HARASSMENT, HarmCategory.HARM_CATEGORY_CIVIC_INTEGRITY)
* GenerateContentRequest.safety_settings[3]: element predicate failed: $.category in (HarmCategory.HARM_CATEGORY_HATE_SPEECH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT, HarmCategory.HARM_CATEGORY_HARASSMENT, HarmCategory.HARM_CATEGORY_CIVIC_INTEGRITY)
* GenerateContentRequest.safety_settings[4]: element predicate failed: $.category in (HarmCategory.HARM_CATEGORY_HATE_SPEECH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT, HarmCategory.HARM_CATEGORY_HARASSMENT, HarmCategory.HARM_CATEGORY_CIVIC_INTEGRITY)
* GenerateContentRequest.safety_settings[5]: element predicate failed: $.category in (HarmCategory.HARM_CATEGORY_HATE_SPEECH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT, HarmCategory.HARM_CATEGORY_HARASSMENT, HarmCategory.HARM_CATEGORY_CIVIC_INTEGRITY)
* GenerateContentRequest.safety_settings[6]: element predicate failed: $.category in (HarmCategory.HARM_CATEGORY_HATE_SPEECH, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT, HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT, HarmCategory.HARM_CATEGORY_HARASSMENT, HarmCategory.HARM_CATEGORY_CIVIC_INTEGRITY)

a.dmitriiev → made their first commit to this issue’s fork.

I have set models/gemini-1.5-pro as a default model. I am not sure whether it should be like this, any feedback would be appreciated. Anyway, this is just the default settings that can be changed any time. I believe that at the moment this would be the best model to use.

Ok, I see that config action setupAiProvider was added in AI module to use in recipes in case you have an API Key input. I will add the method to Gemini Provider.

Ooops, I haven't noticed that the file was in the wrong folder. Thanks @vasike for fixing it.

Regarding getSetupData() I will check it, but I am not sure that this is a requirement, as I am already using gemini_provider in the recipe and it works fine. I guess that method was added to those providers because of Drupal CMS integration. But I will check anyway. Thanks for pointing this out, @jibla.

Created the issue 📌 Drupal 11 compatibility of dependency (extra_field) Active in extra field plus module.

a.dmitriiev → created an issue.