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.
Version 2.0.x is Drupal 11 compatible. Please update the module.
Thank you for a nice feature. It was added to https://www.drupal.org/project/entity_events/releases/2.0.5 →
a.dmitriiev → changed the visibility of the branch 1.1.x to hidden.
a.dmitriiev → changed the visibility of the branch 1.2.x to hidden.
a.dmitriiev → changed the visibility of the branch 3519692-create-tools-function to hidden.
a.dmitriiev → changed the visibility of the branch 1.1.x to hidden.
My Setup:
Drupal core: 11.1.7
Gin Toolbar 2.0.0
Gin Admin Theme 4.0.6
Environment Indicator 4.0.22
environment_indicator.settings:
toolbar_integration: { }
favicon: true
version_identifier: environment_indicator_current_release
version_identifier_fallback: deployment_identifier
I have changed the UI/UX in the way that it is possible to add multiple instances of the same plugin. It is also now possible to remove and sort field widget actions in 3rd party settings form.
I have added `isAvalailable` method to base class, so that each plugin can perform any checks needed, for example user permissions, or whether some module enabled or not, etc.
For the 3 point, I have added the new multiple
property to plugin definition. In case it is TRUE, the button will be added to each single element of the field widget, if FALSE, only one button for widget will be added. TRUE is by default.
a.dmitriiev → created an issue.
a.dmitriiev → created an issue.
@sirclickalot, the MR from this issue is not yet merged, so the fix is not part of 1.1.0 yet.
Also cherry-picked to 1.2.x branch.
Thank you, Arthur!
Good catch, string_long
type was forgotten :) Merging
a.dmitriiev → created an issue.
a.dmitriiev → made their first commit to this issue’s fork.
I have also fixed several Drupal 11 compatibility issues.
I have included also some coding standards clean up.
a.dmitriiev → created an issue.
Indeed ✨ Add Javascript orchestration for each loop in the Chatbot/Assistants API Active fixes this already, so closing this one
I will check this issue
a.dmitriiev → made their first commit to this issue’s fork.
Uploading patch to be used in composer based projects.
a.dmitriiev → created an issue.
Thank you, Vincent!
Hey @vbouchet,
Any chance that you can review this change? I tried to make it compatible with current state of Project Browser version 2. Everything works smoothly. I haven't checked the change with "Package manager" (I haven't tried to require and install the package from admin UI) yet. But maybe first this needs to be fixed.
Thank you.
Unfortunately, there is no content_template formatter therefor the patch is not correct. I have added the missing type
property, but it is just entity_reference_label
from core, as content templates doesn't provide any field formatter plugin.
Update hook was added. MR is merged.
Sorry, but I can't reproduce the issue. The error trace says the problem is in line:
$template_operations = parent::getOperations($entity);
But $entity there is the entity from the list row. And the method getOperations
is even type hinted, so are you sure you haven't made any modifications to that file?
It is enough to clear the caches for the new link to appear in the list, no need to re-install the module. I will add the update hook to clean the caches automatically.
a.dmitriiev → created an issue.
The fix in the MR makes sure that the contextual (balloon/bubble) menu that appears on text selection is displayed ONLY when the corresponding button is added to the toolbar (though it is not visible in CKEditor toolbar itself, only in admin UI when you configure the toolbar). If the button is not in "active" toolbar items, the menu will not appear on text selection (also when the AI CKEditor features are enabled).
Toolbar button only enables or disables the plugin, it is not even displayed in the CKEditor toolbar itself, this button is only visible in the "Text and format" admin UI page.