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.
There will be one more dependency to fix: https://www.drupal.org/project/extra_field_plus → . It requires at the moment extra_field 1.x or 2.x, so 3.x will not be accepted. So, we have to wait a bit more
I have tried the MR and still there were some random results for alt images. But if the image is passed as inlineData with Blob class then the results are very accurate. I can confirm this with 1.5 Pro and 1.5 Flash models.
I have updated MR
a.dmitriiev → made their first commit to this issue’s fork.
a.dmitriiev → created an issue.
Add to new release https://www.drupal.org/project/frontend_editing/releases/1.8.10 →
I have added one more check before yours and merged.
Thank you!
Hi @damian.skiba,
Thank you for reporting the bug and also providing the fix right away. I will check the MR and release a fix shortly.
Thank you @teknocat. It is always pleasant to hear such a good feedback and suggestions. I will try to check the workflow/content moderation integration soonish.
I will also link this documentation page here https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
Hi teknocat,
Thank you for very detailed description. It really helps to understand your needs.
Workflow and content moderation has not yet been in scope for this project, but it would be really nice to have it. I would like to check this deeper.
Let's first discuss what you can do now already to make your experience better:
1. Install this module https://www.drupal.org/project/all_entity_preview → . There is a nice integration between frontend editing and it. The module allows to have the preview of your changes in the main window, while you are doing the changes in the frontend editing sidebar. This will at least help your editors to see how their changes would look like without saving the entity (paragraph or any other entity). Of course this doesn't solve all your issues but I hope it will be a good start.
2. Regarding revisions. I am a bit surprised about no revisions for the nested paragraphs even if the node requires the revision to be created every time. This part of the functionality is provided by paragraphs_edit → module, that is the dependency of frontend_editing module. When you save the paragraph there is a service that checks whether the host entity needs revision and if yes, it creates it and then goes up to the root parent (in case of nested paragraphs) and saves the root parent (most of the times it is node). I've heard couple of times about this problem from others, so this would need more attention from my side and probably some more verification to make it more stable.
3. Regarding wrong timestamp and author of node revision. This is also a bit complicated as it is not a direct feature of frontend_editing module, but paragraphs_edit. There is an issue https://www.drupal.org/project/paragraphs_edit/issues/2914976 🐛 Revisions log does not attribute author or timestamp correctly Needs work that should address this exact problem you have. The patch from the last comment applies cleanly on the latest version of the module, I use it in couple of projects myself. It would be nice if you could also test it and RTBC or give feedback in that issue, so that it is fixed in the upstream faster.
Please let me know if any of the above hints help in your case. I am willing to fix the revisions problem once and forever as it bothers me a lot. Maybe then it would be good to check the integration with workflow and content moderation as well as a follow up.
Preview and auto-refresh after save are different features. Preview allows you to see the results without actually saving the entity (paragraph, node, etc). After you hit "Save" button and the sidebar is closed, then the automatic refresh is in place, in case it is enabled here /admin/config/frontend-editing/ui-settings ("Enable Ajax content update"). If that checkbox is checked there should be on the page a link (a tag) with class frontend-editing-update-content and it also has text and title "Reload content for this field", but the link itself is hidden. So, when you hit the "Save" button and sidebar is closed, in the background the click on this "Reload content for this field" is triggered automatically and then standard Drupal ajax is running a request to url like this /frontend-editing/update-content/node/123/some_file_name/default (here instead of node will be the entity type of the parent of your paragraph, it might be also paragraph if your target paragraph is a nested one). The result of this request is inserted into a wrapper div that is created by the module around your paragraphs field, this wrapper has class frontend-editing-field-wrapper.
MR #5 was merged.
Normally entity autocomplete form element is used for setting entity id, not the title. So out of the box, it is not possible. But it is always possible to create your own autocomplete element that will return title instead of id (btw, entity autocomplete that is used in the dialogs is Drupal core element, this module has nothing to do with its functionality) and then later use that element in the dialog form with form alter hook.
Thank @cb for a hint, but composer patches version 2.x doesn't allow to have patches from MR links.
Uploading patch for using in composer based projects. Please ignore it and review the MR instead.
To avoid overriding construct and create methods, I suggest using parent::create call. This way any changes in parent classes will be covered still.
The issue is in EntityReferenceDisplayFormatterTrait class. In the parent issue methods __construct and create. Maybe it it would work in trait, but __construct completely overwrites parent constructors, so property fieldDefinition that is defined in FormatterBase is not set, because it is set in its __construct method.
a.dmitriiev → created an issue.
a.dmitriiev → created an issue.
Re-upload the patch with new line in the end of the file, as composer patches version 2 doesn't like when there is no empty line
As a workaround, to not mess up with plugin collections, maybe it is enough to sort the behavior plugins in the widget form? Please check the MR
a.dmitriiev → made their first commit to this issue’s fork.
Here is the proof that I have contacted the maintainers in Slack https://drupal.slack.com/archives/C1BMUQ9U6/p1734422515626019
There are also at least 3 messages in Slack #contribute channel from Ivnish:
https://drupal.slack.com/archives/C1BMUQ9U6/p1736425954066919
https://drupal.slack.com/archives/C1BMUQ9U6/p1732684301373429
https://drupal.slack.com/archives/C1BMUQ9U6/p1733723989226619
And from other people:
https://drupal.slack.com/archives/C1BMUQ9U6/p1735935169012749
https://drupal.slack.com/archives/C1BMUQ9U6/p1733935783496769
Unfortunately, there is no proof for contact form request, as I didn't set the copy to be sent to me.
I understand that there are rules, but having 13 maintainers and no one is responding and the module that has a lot of installations and people are waiting for Drupal 11 support. I think here could be some help from d.o admins to solve this problem.
At some point this module was considered to be added to Drupal CMS, but because of lack of Drupal 11 support, it was not added there too.
Here is a nice issue with examples from group module https://www.drupal.org/project/group/issues/2797845 💬 How to migrate content into group and group content Active . Be aware of the last comment in that issue, there is a difference between versions of group module
You need first migrate your groups, then media and then create another migration for group media relation. Media is attached to the group via the GroupContent entity type that is a group module functionality. Basically it is another content entity that has reference to a group and to the content that you want to attach to the group. So the third migration needs to create content items of entity type group_content with reference to your media item and group, and the bundle of this group content items will be the name of the plugin that corresponds to the bundle of the media.
I have updated the description of the issue. Are there any examples of how change record for new config action should look like? What should be included? Is content of comment https://www.drupal.org/project/drupal/issues/3305859#comment-15896386 📌 Add config actions for views Active would be enough?
Thank you, the MR was merged
There are also other public methods in src/FloodUnblockManagerDatabase.php class that query the same flood table. I think they also need this check.
a.dmitriiev → created an issue.
The fixed 1.x version was released https://www.drupal.org/project/frontend_editing/releases/1.8.8 →
Fixed for 1.x and 2.x versions. Now the "Cancel" button redirects back to the paragraph edit form.
Search recipe sets the items to be indexed immediately for "Content" index. But for content that was already there of course this doesn't help. Maybe some dashboard message should be added instead of setting the last cron run to 0? This will notify the user that the cron needs to be run in order to have all the items indexed. Or maybe the message can lead to the index page where the user needs to click on "Index" button even.
As dieterholvoet confirmed that he wants to maintain the module, can this move forward? A lot of users are waiting for the module to be updated to support Drupal 11, but this blocks it.
Thank you in advance.
The warning was added in version 2.x in this issue https://www.drupal.org/project/frontend_editing/issues/3473762 📌 Add warning when leaving form and changes would be lost Active . Also in that same issue there is a nice integration with "All entity preview" module found, that the changes can be kept in the form.
But yes, I agree, that there is a confusion that the preview displays the changed content, but form doesn't. This needs a second thought for version 1.x, but I wanted also to have only bug fixes there and have all new features in 2.x.
Thank you for reporting the bug, I will try to check it soon.
Adding the Change Record link for the reference
https://www.drupal.org/node/3404140 →
.
Thank you for the fix. I have modified the MR a bit, to make sure that the form works also for Drupal versions before 10.2, even if they are not officially supported anymore.
a.dmitriiev → made their first commit to this issue’s fork.
I have added backwards compatibility for Drupal < 10.3 and merged.
Thank you!
Adding a change record for the reference https://www.drupal.org/node/3450770 →
Thank you for the fix. I have modified the MR a bit, to make sure that the form works also for Drupal versions before 10.2, even if they are not officially supported anymore.
Adding the Change Record link for the reference https://www.drupal.org/node/3404140 →
a.dmitriiev → changed the visibility of the branch 3489217-node-title-is to active.
1.8.7 release contains this fix
Thank you for the fix, it was merged also to 2.x branch.
Merged
MR is merged. Thank you everyone
lostcarpark → credited a.dmitriiev → .
Yes, unfortunately the situation in the mentioned extra_field module issue is very strange and not likely to be moved forward easily :(
Please provide more details, if possible with links to the page and your version of Chrome at least. Also, are you checking as logged in user or anonymous user. Are there any logs with errors in "Recent log messages" in Drupal admin UI?
Delete confirmation page was also fixed. Please review
Updated patch with empty line at the end of the file
Also uploading patch for usage in composer based projects.
a.dmitriiev → created an issue.
Now this piece of code needs to be added to all default content items:
moderation_state:
-
value: published
Because now all of them are unpublished