TBH at some point we need to bite the bullet and make these a Drupal Plugin, surely?
We've got ai/src/Cache/Context/AIProvidersCacheContext.php that gets invalidated every time a new provider is added (VDB or otherwise) so it should just be a case of ensuring that context is added to the search api form?
If the AI recipe was only setting up the AI Provider then I'd agree, but it also sets up the configuration for the chatbot. Given how complicated and difficult it is to get the prompts right for the chatbot, there will be cases where people want that configuration but don't want to use the two providers configured. The only options I can see are to allow people to set up a provider separately afterward (the request made here) or to have the wizard show every possible provider, which will add a lot of modules users don't need (given that as I understand it the recipes are intended to enable every module included in the recipe regardless of whether they are needed).
So this is different to GA - a recipe that has no additional configuration you might want if you aren't also using the mandatory GA key - and may well be something that only applies to the AI recipe. But it does apply, and represents a barrier to a section of people being able to use the recipe.
It would be good if we could come up with a solution that works for all cases, but I'm not seeing how making some stages of the wizard option would be that much of a breaking change.
mrdalesmith → created an issue.
Yep, I can recreate the issue using those instructions. Interestingly, if I recreate MY test, the Featured Image field is correctly copied across as a media reference field.
What I notice going through the code itself that that the FieldType Agent does not provide details of existing fields to the AI when it makes its initial assessment of how to respond to the query. In fact the FieldType agent is never given details of existing fields, which means it is very unlikely that it is using existing settings to create the new field: it looks like my original test may have accidentally passed because for unknown reasons the AI determined in this case that a Media Entity Reference field was required and it was just coincidence that it was right.
It may be that the simplest fix for this would be to provide the AI with details of existing fields along with the rest of the context, but that may be too much data for most use cases. Possibly we might be better to create a "copyField" Agent that the AI can use when it is asked to copy fields.
Either way, this looks to be an issue at the AI Agent level so we'll need to move this issue over there at some point, but I'll leave it here for now to give the maintainers a chance to pitch in on possible solutions.
Changes all good. Tested the new plugin and it correctly found the address and set it in an address field - managed to get the full address from a mention of "10 Downing Street, SW1A 2AA" in the text which is good (but might suggest it's augmenting the addresses from its own training data, but I think we should cross that bridge if we reach it).
mrdalesmith → made their first commit to this issue’s fork.
Changes look good and tests all passing.
Looks good to me.
mrdalesmith → created an issue.
I've tried to recreate this issue on the Drupal CMS, asking the AI first to create a Test content type and subsequently giving the request:
Can you copy the featured image field from the Blog post to the Test content type?
This is a media reference field provided by the Blog recipe in Drupal CMS. The Chatbot responded with:
Here's what I'll do:
Identify the Featured Image Field: I will find the featured image field from the Blog post content type.
Copy to Test Content Type: I will create a similar field in the Test content type with the same configuration as the featured image field from the Blog post.
Configure Form and View Display: I will set up the form display to use the Media Library widget and configure the view display to render the media entity.
Would you like me to proceed with this plan?and when asked to proceed it reported:
I have successfully copied the "Featured Image" field from the Blog post content type to the Test content type. Here are the details of what I've done:
Field Configuration Created: A new field named "Featured Image" has been created in the Test content type using the same settings as the Blog post. You can manage it by visiting Test Content Type Field Configuration.
Form Display Configuration: The form display for the Test content type has been set to use the Media Library widget for the Featured Image. You can view/manage this at Test Content Type Form Display.
View Display Configuration: The view display has been configured to render the media entity for the Featured Image. Check it at Test Content Type View Display.
If you need any further assistance or modifications, feel free to ask!Checking the Test content type, it has correctly created a Media Reference field as reported.
At the minute I can't recreate this bug: hopefully @zengenuity can add steps to recreate (including whether the set-up of the Chatbot came from the Drupal CMS or whether it is using custom configuration) so we can investigate again.
mrdalesmith → created an issue.
Yeah those changes were because of work getting merged in after this MR was opened, not a deliberate removal: the bugfix only branch works fine too.
I think that issue would be worthy of its own support issue - at least partly so we could get the improvement in this patch in as quick as possible. Would you be able to raise a new ticket for that? It sounds like something we should at least be able to replicate.
The MR is made against the dev version of the module by default: have you tried testing against that?
We're back to "looks good to me" :)
This feels to me like quite a specific use case and I'm not sure it's general enough to be included in the AI search module - possibly it would make more sense as a separate contrib module?
mrdalesmith → made their first commit to this issue’s fork.
Actually - the changes you're making don't appear to relate to the description of this ticket, and are duplicating work in https://www.drupal.org/project/ai/issues/3499412 📌 Make selection of AI Provider clearer on module homepage Active - it might be better to remove them completely so this ticket can be closed and then address the other issue on its ticket.
Code to resolve this issue appears to be being added to https://www.drupal.org/project/ai/issues/3498893 🐛 Default option for Media type can be wrong if not selected in Ai Automator Advanced settings Active so to avoid confusion, I'm going to close this as a duplicate.
Still doesn't seem to have a config/schema/*.schema.yml file.
Looks good.
You've got failing PCS issues, and I personally don't like the idea of the permission change: this means that a menu item where you can't do anything will appear in your admin menu. I appreciate that's so you can show the message on the page, and that the maintainers may decide that's a better UX. Have you checked whether that custom access check is being used anywhere else? Because if it isn't, the code probably wants removing as well.
Looks good to me, and seems like a useful thing to get in ASAP.
Yeah line 177 for me in the 3480861-translate-with-ai-retake branch is the start of a comment - it looks like you may be using a version of the code that doesn't have the
if (isset($option['data'])) {
line? This section of the form isn't actually edited in the MR just moved inside an additional if. I also don't need to adjust the weight of the routing change - allowed_languages is set to -220 and the MR to -230. All works for me.
Scratch that: this is a duplicate of https://www.drupal.org/project/ai/issues/3499597 📌 Better error handling in the Chatbot Active (which has a more detailed description) so can be closed.
Yeah 2 sounds like a bad idea: Drupal practice with blocks is that they always have separate view permissions on them regardless of whether the thing you are viewing requires a separate permission to view. Doing something non-standard for the AI Assistant sounds like it will just lead to confusion for users.
Just to note, the AI Key is checked as it is saved against the provider settings form for OpenAI so this particular error would be best handled by the providers (as each provider may need a different process to check if the key is usable).
Do all providers return these errors in a normalised way we can check for consistently?
Looks good :)
this is a duplicate of https://www.drupal.org/project/ai/issues/3499361 🐛 CKeditor does not receive text generated with "claude" in ai assistant Active and needs fixing in the AI CKeditor module.
Wrong way round: issue needs fixing HERE not in https://www.drupal.org/project/ai_provider_anthropic/issues/3498151 🐛 Text generated by ckeditor request to claude does not appear Active
I'm going to close this as a duplicate, since https://www.drupal.org/project/ai_provider_anthropic/issues/3498151 🐛 Text generated by ckeditor request to claude does not appear Active exists in the Anthropic provider issue queue and the fix needs to be made there, not here.
I don't think there's anything in this report that isn't covered in https://www.drupal.org/project/ai/issues/3498932 🐛 Links provided by AI assistant are frequently not working Active , so I'll close this as a duplicate.
I've gone a different way in https://git.drupalcode.org/project/ai/-/merge_requests/413 - if we need the sourceEditing plugin for the javascript to work, we should make sure its added to the field that needs it. That way, no-one needs to have a plugin they don't want enabled just because of the way this is coded.
This will probably be reasonably fragile as it relies very much on every entity on a site using a predictable format for creating their routes and menu structure, which Core cannot even manage to do. This covers everything turned on by default by the CMS though.
mrdalesmith → made their first commit to this issue’s fork.
RC-1 has come and gone. Closing ticket.
This looks like it might be an either/or/why not both? situation with https://www.drupal.org/project/ai/issues/3485686 ✨ PreGenerateResponseEvent should allow altering of tags Active which is also waiting for review.
The changes in the MR don't seem to correspond to the description of the ticket, and I'm not sure what they actually add: could you provide a little more explanation of what will be different after this issue is merged, and why?
The AI Assistant needs to be set up with a prompt telling it what to do: we need to know what this is in order to investigate the issue. If you are using the prompts set up by the Drupal CMS set-up recipe, we just need that confirming. Otherwise we need a copy of your AI Assistant's configuration.
Can you confirm whether Javascript of the Drupal Log contained any errors relating to the failure?
The links have been addressed in other issues so I'm marking this as a feature request, since the media field is usable if not configured ideally.
When using OpenAI, the code at line 160 in Drupal\ai_ckeditor\Controller\AiRequest::doRequest() is returning an OpenAI iterator; when using Anthropic it is returning a plain ChartMessage. This means that when the code then tries to iterate through the response, it skips past without triggering any kind of error.
I'm not sure whether this means that Anthropic don't support streamed responses, or whether its as simple as us checking whether the return is iterable and only using a foreach if it is, or if there's been an oversight in the return the Anthropic provider is returning (in white case this will be an issue for that module). I'll need a maintainer to confirm the best approach.
In order to attempt to recreate this issue, we'll need to know with Provider you're using and to have details of the prompts you've set your AI Assistant up with. Is that something you're comfortable providing here, or do we need to look into more private methods of getting the information to the maintainers?
This is again not something we are likely to be able to resolve as the LLM is responding from its own training data, and the response to this is pretty much summed up by @yautja_cetanu's in https://www.drupal.org/project/ai/issues/3498932#comment-15939418 🐛 Links provided by AI assistant are frequently not working Active . I think the best approach would be link the two tickets and close this as a duplicate to prevent confusion between the two.
LLMs generate content by using maths to select the most likely next letter and do not understand the context or content of what they generate: it generated https://www.drupal.org/project/advanced_aggregation → because you asked it to generate links and so it generated a thing that looked like a link.
To get an accurate link to https://www.drupal.org/project/advagg → it would need to be constantly training itself on the live internet, and to possess a level of cognition to understand that when you ask for a link you don't want a thing that looks like a url, you want an actual live pointer that goes to a currently live and relevant web site page. You might be able to tell it only to return links from a specified list you provide, but those too could go out of date pretty quickly.
I think you're asking it to do something it is unsuited to as a tool, but as I say the maintainers may disagree and have a solution.
The LLM you are using is providing links based on its training data: in most cases these will be outdated or completely invented. As far as I'm aware, the best solution to this is to include in the prompt you are using instructions that the LLM should not try to provide links. The maintainers may have a better solution.
Updated MR with additional instances. Ready for review again.
I still get a lot of depecations after applying the changes in the code:
PHP Deprecated: field_group_form_process(): Implicitly marking parameter $form_state as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 426
Deprecated: field_group_form_process(): Implicitly marking parameter $form_state as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 426
PHP Deprecated: field_group_field_group_form_process_build_alter(): Implicitly marking parameter $form_state as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 493
Deprecated: field_group_field_group_form_process_build_alter(): Implicitly marking parameter $form_state as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 493
PHP Deprecated: field_group_fields_nest(): Implicitly marking parameter $vars as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 637
Deprecated: field_group_fields_nest(): Implicitly marking parameter $vars as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 637
PHP Deprecated: field_group_field_layout_fields_nest(): Implicitly marking parameter $vars as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 730
Deprecated: field_group_field_layout_fields_nest(): Implicitly marking parameter $vars as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 730
PHP Deprecated: field_group_group_save(): Implicitly marking parameter $display as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 877
Deprecated: field_group_group_save(): Implicitly marking parameter $display as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/www/modules/contrib/field_group/field_group.module on line 877
Had the issue: used the code change - don't have the issue any more :)
Looks to be fixed in the dev branch already.
mrdalesmith → created an issue.
mrdalesmith → made their first commit to this issue’s fork.
Not sure what the test failures are caused by, but this applies cleanly and resolves the issue for me.
Attached patch should apply cleanly now.
Patch doesn't cleanly apply to the current 2.1.0 release or dev version.
Branch naming scheme has defeated me: can't get a patch version of the MR to apply to 7.0.2 and not entire sure which of the branches relates to the release with the issue. Have to leave it to someone more knowledgable to have a go.
mrdalesmith → created an issue.
mrdalesmith → created an issue.
Had this issue on PHP 8.4 - changes in the MR resolved the issue.
mrdalesmith → created an issue.
There are merge conflicts in this work now so this will need reworking.
Looks good to me
I get the same behaviour I had before only without the validation error, so I'm going to say that's good to go.
mrdalesmith → created an issue.
@arwillame I've tried an alternate approach in the new branch - what this *should* do is use whatever controller exists at that route to build the original template and then add the AI Translate info to it: that way, we don't need to hardcode module names and risk missing one.
It's available at https://git.drupalcode.org/project/ai/-/merge_requests/378. We could do with some people using modules tat already override that translate route to test and see if it works as expected.
mrdalesmith → made their first commit to this issue’s fork.
Seems to work as expected for me :)
I’m not sure it’s worth doing the full remove of token if that theme function isn't part of core - it is something we want to be using. Otherwise we have to come up with our own version of it and it’s just not worth the effort. I say we add Token as a full dependency of the AI module but keep the other changes: you can use tokens without token but you can’t display which ones you can use without a lot of custom code, and doing a check if the module exists just so we can show the help text feels daft.
mrdalesmith → made their first commit to this issue’s fork.
mrdalesmith → created an issue.
We're probably going to need details of your set up to try and recreate this - the prompts used for the assistant and the set up of the VDB provider, and also your SAPI back-end. It would also be useful to have the questions you asked and the responses you expected.
mrdalesmith → created an issue.
Looks good :)
I'm not able to recreate the issue reported here: with JS turned off, I can select a Default Provider where one is unset and available; saving the form fails validation as expected, at which point I can select the model and save the form again. With your changes, I see the user input as expected after every form submit. I did notice there is an issue with the Drupal CMS admin theme, where the sidebar is partially blocking access to the submit button with JS disabled even though it appears as closed, but otherwise I'm not seeing the issue?
Can you possibly explain how you think the form should be working with JS disabled? This may help us to understand why you think it's broken and I think it's working?
I think this issue should be logged against https://www.drupal.org/project/ai_deepchat → , not here?
There are failing tests that need to be addressed, and I don't think you need to comment out code in an example module - it shouldn't be used in any case so it won't break anything if you just add the code.
Suspect this may be related to https://www.drupal.org/project/ai_provider_anthropic/issues/3494529 📌 Handle deprecation of AI External Moderation module Active - can you try using the patched version of the provider from there?
Duplicates https://www.drupal.org/project/ai/issues/3495115 💬 Can't Enable OpenAI Moderation in Anthropic Authentication Setup Active
mrdalesmith → made their first commit to this issue’s fork.
I wonder if we should instead have a method inside $this->aiAssistantRunner to retrieve the session: this could then be used by any code using the assistant API without it having to reroll its own solution?
Something along the lines of:
public function getSession () {
$thread_id = $this->getThreadsKey();
$session = $this->getTempStore()->get($thread_id);
if (empty($session)) {
$session['output_contexts'] = [];
$this->aiAssistantRunner->getTempStore()->set($thread_id, $session);
}
return $session;
}
I agree the composer suggest method is better, but should also point out you already can't install a module if its dependencies aren't there so there's no need to do any additional work on that count.