Will need a follow up for 2.x
Merged and cherry picked to 2.x
I have slightly modified the MR, please check.
a.dmitriiev → made their first commit to this issue’s fork.
PR was created https://github.com/mkalkbrenner/search_api_solr/pull/110
Also attaching the patch.
a.dmitriiev → created an issue.
If everyone agrees at least adding the warning, could there be an option at least to list the patches that were found in the recipe/s that was/were unpacked? For technical person it will not be difficult to add those patches to the root composer, but I think the most difficult part (or the most time and effort consuming) is to collect those patches from the packages (also maybe nested recipes that make it even more difficult). If unpacker command will return the list of patches that were in the unpacked recipes back (maybe optionally with some command key) that would be great. Then a technical person will decide on their own which patches to add and all the conflicts that this can bring will be their responsibility. But the list of patches would be very valuable in my opinion.
a.dmitriiev → created an issue.
Merged. All is green in the pipeline
I have tested logging, chat with streamed response, normal chat. Everything works now and now it is so easy to maintain and expand the functionality, as all OpenAI based providers will get the updates directly from AI Core.
MR is approved.
Of course the tests are failing :( now the built render array of a message has a Markup object and not the array anymore.
I suggest to slightly modify the order of message text processing. The getText
method in MessageTemplate entity class should not be rendered yet, but instead the getText
method in Message entity class should do this, and the token processing should be done before the rendering. This way there will be also additional filter processing of the values that were replaced by tokens, for example if message template uses basic text format, but the token might have some not-allowed html tag or something, this way if rendering happens after the token replace, this makes the solution more secure (I might be wrong of course).
To not break all other contrib modules (like message_ui), that rely on certain structure to be returned by getText
method of MessageTemplate entity class, I have added one more optional parameter to it, that indicates whether it is a preview of text or real processing withing Message entity class.
I hope this change will not break the tests.
a.dmitriiev → made their first commit to this issue’s fork.
Ooops, the patch is actually from another issue, sorry. Uploading the correct one.
I was thinking about the triggering element as well. It would be nice of course to delegate this to the base class. Need to find out the best approach though.
Regarding required fields, there is a core issue 🐛 Suppress validation of required fields on ajax calls Needs work . The problem with limit validation errors parameter that is now available, it will disable any kind of validation that is not listed, and this of course is not know to Field Widget Actions. So I guess we will have to wait for the core issue to be fixed.
I will check the warning regarding display_on_focus, this was recently added and there is a default value in the configuration of the plugin, strange that it was not picked up.
Ok, with clean Drupal installation I found the problem. The dialog library was missing. For some reason I thought that ajax command adds the library on its own. Please check the updated MR.
Also uploading the patch.
Moreover I see that the SubformState is already used in massageFormValues for submitting the block settings. So it totally makes sense to also use it for form creation.
a.dmitriiev → created an issue.
aiContentSuggestionsAjax
has return $this->returnSuggestions($suggestions, $selector);
as a last line https://git.drupalcode.org/project/ai/-/merge_requests/763/diffs?file=60... . It is not returning the array of suggestions, it passes the array of suggestions to the returnSuggestions
method. And returnSuggestions
calls open dialog command. Are you doing the same in your Plugin? Maybe you can send a link to your MR?
Indeed the code snippet from version 1.x was not transferred to 2.x. Now it should be fixed, please review MR.
Please check as an example the plugin from ai_content_suggestions module.
It seems that something from 1.x was not cherry picked. I will check
Looking forward to your feedback! Thanks!
The component "Frontend Editing: Actions" on "Manage display" is actually still needed, because if you move it to "Disabled" section, then no frontend editing actions will be available for this view display anymore. This element is more for you to decide whether you need the element or not. Let's say you have paragraph in view mode "Only label" and another one "Default". For "Only label" you don't want to have a frontend editing, as it would be clumsy. So for this view display you just need to drag the element to "Disabled" and it will not be shown anymore, but for "Default" it will still be there. This is on of the differences between version 1.x and 2.x, that it is possible to control in UI for what view modes one wants to display frontend editing actions, because in version 1.x it was only possible with module hooks.
The method `returnSuggestions` accepts suggestions as string or array. If it is string - then it is just shown in the ui dialog, if it is array of strings, then they are rendered as list where one can select the item and it will be automatically set as value in the corresponding field (that triggered the action).
So the array should be just array of strings, either associated or normal list, it doesn't matter, as in the twig template it will just loop through all values.
I am still not sure how this would work in case the button is one for the multivalue field (of course if it is a realistic use case).
a.dmitriiev → created an issue.
I would like to hear some feedback for the initial work that was done. What can be done more? Please check MR and review. It is still in Draft as I am not sure that the issue is done in full. Waiting for suggestions ;)
The move up and down and add new items buttons are the settings from the entity reference field, where your paragraph (for example) leaves. As this functionality is connected to the field itself, not to the entity. So if your paragraph is inside the node of type "Page" field called "Paragraphs", then you need to go to "Manage display" of "Page" content type, find "Paragraphs" field and click the settings button, there you will see the ON/OFF toggles for move up/down and add new items.
I have left optional way (disabled by default) to still have button on focus with some warning that it is not good for accessibility. Some refactoring will be done in the follow up issue ✨ Add a common method for suggestions in Field Widget Actions Active to allow others to create new suggestion plugins even easier.
a.dmitriiev → made their first commit to this issue’s fork.
I have adjusted the function frontend_editing_enable_preview
(in frontend_editing module) to skip node entity type, as it is not supported by all_entity_preview module.
valthebald → credited a.dmitriiev → .
a.dmitriiev → created an issue.
I have changed the target branch to 1.1.x and rebased the branch from MR. The spelling and phpcs issues were fixed. But now there is a problem with composer
step. Command to expand_composer_json fails.
I have added the property category
to the plugin attribute and also the options in third party settings now have the categories as groups. If no category is set, the plugin will be under "Other" option group. Please review.
a.dmitriiev → made their first commit to this issue’s fork.
As a temporary workaround I have added the following lines to phpstan config:
ignoreErrors:
# new static() is a best practice in Drupal, so we cannot fix that.
- "#^Unsafe usage of new static#"
-
message: "#extends @internal class Drupal\\\\Core\\\\Render\\\\Element\\\\FormElementBase#"
reportUnmatched: false
Fixed phpstan problems!
The all_entity_preview module (or just preview as machine name states) is not taking care of node entity type preview. It handles all other content entity types, BUT node, because node module already has a preview functionality. That is why the configuration for node is skipped in the settings form and that is why there are some checks in the frontend editing module.
Nodes have their own settings to enable/disable the preview and frontend editing respects those settings. To be more clear, the "Preview" button on node form is added by node module and if it is present, then frontend editing tries to process further. Actually the same is for other entity types, but for them "All Entity Preview" module adds that "Preview" button to the form.
It seems that function frontend_editing_enable_preview
accidentally adds node entity type to the preview module settings, because in your case the node entity type is allowed to be used by frontend editing. That is definitely a bug and needs to be fixed. Thank you for noticing.
To fix your problem with node preview try to enable it for a content type. You can do this on content type edit page, for example here /admin/structure/types/manage/page
for content type "Page":
"Preview before submitting" should not be "Disabled".
Please let me know if it helps and for the function frontend_editing_enable_preview
, I will fix it in the frontend_editing module.
@jacobbell84 please share the Drupal version, Gin version and Frontend Editing version that you are using. This will have to review your patch. Thank you.
The same problem is now with FormElementBase:
------ -------------------------------------------------------------------------------------------------------------------------------------
Line src/Element/ToolsLibrary.php
------ -------------------------------------------------------------------------------------------------------------------------------------
28 Class Drupal\ai\Element\ToolsLibrary extends @internal class
Drupal\Core\Render\Element\FormElementBase.
🪪 classExtendsInternalClass.classExtendsInternalClass
💡 Read the Drupal core backwards compatibility and internal API
policy:
https://www.drupal.org/about/core/policies/core-change-policies/drupal-8... →
------ -------------------------------------------------------------------------------------------------------------------------------------
I have this issue now in AI Core module pipeline with level 1.
marcus_johansson → credited a.dmitriiev → .
I converted this MR to enable usage report for OpenAI based provider with streamed responses and also cherry pick the change from here https://www.drupal.org/project/ai_provider_openai/issues/3535032 🐛 Add trigger of the poststreamevent for logging Active to the base class of Open AI based message iterator.
Also attaching updated patch
I tried to address all comments. There are phpcs and phpstan issues, but they are not related to the changes from this MR.
a.dmitriiev → changed the visibility of the branch 3519692-create-tools-function to active.
a.dmitriiev → changed the visibility of the branch 3519692-create-tools-function to hidden.
I guess the plugin class for field_widget_actions might be moved to AI Core when AI Agents are in core, but for now it should probably stay here, not to mess up with dependencies.
Regarding the phpstan findings - it complains about field_widget_actions classes, because they do not exist in AI Core 1.1.x. Probably this could be ignored at this point, or do you really want to bump up the AI Core requirement to 1.2.x?
PHPCS findings were fixed and the comments addressed.
The MR conflicts were resolved.
Probably the same changes would be needed in other places where Streamed output is used, but let's start with CKEditor submodule, as an example.
Be aware, there is a change in this MR that is done to OpenAIProvider base class. In the MR from this issue
https://www.drupal.org/project/ai_provider_openai/issues/3531260
✨
Remove OpenAI SDK dependency and extend it from Drupal AI core module
Active
the plugin from ai_provider_openai now extends the base class, but method chat
is still the old one and there OpenAI iterator is used, not the one from the AI Core module and also the stream output usage settings is not passed. So when testing, using the code from MR https://git.drupalcode.org/project/ai_provider_openai/-/merge_requests/4... but also comment out chat
method, so the one from base class is used.
a.dmitriiev → created an issue.
Thank you all, now it is more clear.
Re-rolled patch for 1.1.0 stable version. Also MR is updated
Some features not necessary require AI to be involved, the packages like this https://github.com/jenssegers/imagehash can help to achieve the goal with PHP only without spending tokens and calling LLMs. Just a remark.
This change is in MR https://git.drupalcode.org/project/elasticsearch_connector/-/merge_reque... . Should then this be merged and also Drupal 11 compatible version released? As the module fixes are already there, only tests are still pending
a.dmitriiev → created an issue.
I checked some examples from here https://llmstxt.site/ and people sites do not have the link pointing to MD format actually. But what is the best approach? Will LLM find the MD format itself with link rel="alternate"?
a.dmitriiev → created an issue.
I also had the same confusion. But there is a configuration page here /admin/content/llms-txt
where you can use various tokens to create the structure you need. Also you can create sections here /admin/content/llms-txt/sections
that will be automatically added to llms.txt file. For example you can create a section for Main Menu and use the token [llms_txt_markdown_menu:main]
inside (you might need the token_filter module). But you can also add the token directly on configuration page. You can use any token, so this makes it generic.
Uploading patch to use in composer projects.
a.dmitriiev → created an issue.
More over extra field settings allow to choose what form display you want to use in Frontend Editing sidebar. In 1.x it is only "Default" form mode, in 2.x you can choose yourself.
Here is the meta issue that was created when 2.x was only an idea https://www.drupal.org/project/frontend_editing/issues/3436684 🌱 [Meta] Plans for 2.x Active . It explains what benefits are there when using extra field.
The tools library is done in the same way the core media library is done, so this design and look should be familiar to all Drupal users.
Tools form element with 1 tool selected:
Modal dialog that is opened when clicking on "Select tools":
Filtering and selection of tools inside modal dialog:
Tools form element after tool selection:
I have rebased the branch, as predefined filters functionality from ✨ Add pre-configurable filters to endpoint Active was merged in already.
I have rebased MR because of this issue ✨ Add processor and field widget assist plugin system to AI Content Suggestions Active
Thank you, @marcus_johansson! Now it would be nice if others join and create more plugin implementations in their modules. This will broaden the usage and of course testing. It is worth mentioning that this is not an AI specific feature, any task that can be done with a click of a button fits here :)
By the way, there is already an example plugin in this issue ✨ Add field widget action plugin based on agents Active that does the similar thing like https://www.drupal.org/project/ai_image_alt_text → module with Field Widget Actions and Agent.
The MR is 1 year old, no objections :) So I merged it.
The changes look good so far. I will need to verify how they work together with UI module. Definitely it should be possible to change the sorting with query parameter even if the default sorting rule(s) are set. But it is a very good start. I have opened the MR so that it is easier to see and review the changes.
Thanks @aaronpinero !
marcus_johansson → credited a.dmitriiev → .
Maybe we should really merge this issue with 📌 Avoid relying on LLM for markup in the content suggestions modal Active as we are changing the same things now and even creating the update hooks.
I have changed the system prompt for content suggestions and created an update hook. In case the response from LLM is valid json, the suggestions are returned as structured HTML markup with twig template, if it is just a string, it is displayed in the modal dialog.
I think this can be also in 1.2.x, as with update hook it is possible to change the system prompt.
Rebased MR on latest 11.x, adjusting the hooks to be placed in classes.
a.dmitriiev → made their first commit to this issue’s fork.
I have rebased the MR on latest 11.x changes.
Uploading re-rolled patch
Works properly now, merging.
"require": {
"drupal/key": "^1.18",
"league/html-to-markdown": "^5.1",
"yethee/tiktoken": "^0.5.1"
},
Library league/html-to-markdown
is a requirement, so it has to be installed with composer. Are you sure that you have installed the module code with composer?
a.dmitriiev → created an issue.