🇹🇭Thailand @AlfTheCat

Hi Marcus,

In the explorer image generation is working.

I'm experiencing this with a newly created image field on a taxonomy term. I don't get the settings form as you can see in the screenshot I attached. On pre-existing fields the settings form does render. Image generation on those existing fields is working.

alfthecat → created an issue.

alfthecat → created an issue.

alfthecat → created an issue.

Awesome @itamair, excited to work on this. I'll keep you posted, thanks very much.

Hi @itamair, thanks very much for your attention to this and your guidance. I'm indeed looking into developing and contributing a solution and it's very helpful to know about the @GeofieldProximitySource Drupal Plugin.

My thoughts so far are to look at a javascript based implementation of storing a visitors lat/long in Localstorage and passing that data on to views.

I will study the plugin and it will be great if I can share a working implementation here once I establish one, and maybe get your thoughts on it.

Hi @berdir thanks for clarifying, that's good to know.

Would it be appreciated if I opened a feature request for this? The thing is that suggestions are not available in automated workflows where AI is leveraged for translating entities. It would be useful in those scenarios to have a global setting just like this where referenced entities get translated automatically.

Thanks.

alfthecat → created an issue.

I just found out that the "View orders in own store" permission is not working. Store owners can't view their orders (in a multi-store setup).

alfthecat → created an issue.

For completeness, adding a reference to the discussion in 📌 View Counter:field: Any Entity Type Active , on tracking impressions which would benefit community sites and commerce (market) place type setups that wish to leverage boosting of posts, advertisements, and impression view counts of entities in various views displays across a site.

Thanks! That will be very interesting!

Another UX issue I would like to add, is that with the current implementation, refreshing the page prompts a "confirm form re-submission" dialog to the end user. The problem with that is, is that in doing so the user actually re-submits the original location data. So if the user moves from point A to point B, and refreshes the page in their browser, instead of seeing updated proximity values based on their new location B, they see the old data from point A. This is completely counter-intuitive to the end user because they expect that a page refresh would show the data based on their new location.

Thank you Scott for the kind words and certainly for the brilliant work. It's been my pleasure to do the testing.

Just yesterday I was able to run translations on 10 nodes at a time, each with 7 languages and it worked perfectly. This is really a game changing feature when it comes to translating sites with a lot of content and a lot of languages. The fact that AI can be leveraged to translate content is one thing, but to actually be able to do it in a scalable fashion is a huge challenge in and of itself. Your work here and that of the others involved is a massive contribution to Drupal's future in my opinion.

Thanks very much, that clarifies it. I'll run a test with Deepl but I guess it's a TMGMT core issue, indeed.

I didn't know the TMGMT Extension Suite module existed, I'll check that one out too.

Another interesting option might be to use ECA instead of continuous jobs for automated translations as it would cover the edge case of 🐛 WSOD when inserting content governed by a continuous job for an entity that uses Automators running via cron Active as well, because with ECA it's possible to add an "field is empty" condition, and the "field value has changed" condition is useful as too. ECA models can run on queue so that might be a better approach for continuous translations that require extra logic.

Currently ECA is not yet able to create translations, but ✨ ECA Content: Create translation of an existing entity Active is in the queue and perhaps it can make it into ECA 2.1.

alfthecat → created an issue.

alfthecat → created an issue.

OK very exciting! I'm ready to test when it's ready to test :)

I ran into this problem as well, my server overloaded and produced a WSOD when I attempted to translate Commerce entities. I unchecked all the references in the TMGMT settings UI and that solved the issue.

I tried the patch from #4 but it failed.

Hi Scott, thanks for the pointer, I did implement Deepl and I indeed had the same problem, I read up on the issue you mentioned and tried the patch there, which failed. I checked my settings and unchecked all the entity references so they're not automatically translated. That fixed the issue.

Thanks very much.

Hi Scott, great work, the 🐛 Translating more than one source mixes up translations Active issue is resolved on my side with the latest patch. The continuous job is still triggered however, so after manual translation is finished, a new job is still created for each translation.

Yeah, I figured it might be out of the scope of the module. Just wanted to report it because I do think this will be something users are going to run into when working with automators. I was thinking maybe the check for translatable content could happen on cron, instead of on submit. But like I wrote before, edge case :)

alfthecat → created an issue.

alfthecat → created an issue.

alfthecat → created an issue.

Hi Scott, I've tested again and I'm still getting the same result. When requesting a manual translation for a content type that is also covered by a continuous job (the continuous job being created after the node was created), I get a duplicate job that remains in the "processing" stage.

Just to make sure I have the right code, I'm using the "plain diff" link at the top of this issue to generate a patch (https://git.drupalcode.org/project/ai_tmgmt/-/merge_requests/2.diff).

I noticed is that I don't have the "AI TMGMT translate queue worker" available. I use the ultimate cron module. I can run the Translation Management Core module cron but I don't have an option of running the other one. I'm using the latest dev version of the module.

Hope this helps, thanks for the quick updates, I'm ready to test further.

Hi Scott, been very busy the past few days but will test tomorrow morning. Been on top of my list, so looking forward to it :)

Hi @bluegeek,

The example I'm thinking of, and the kind of site I'm referring to, is like one of those food delivery platforms (it can apply to any kind of directory and marketplace). Let's say each restaurant has a page and they add their menu items as commerce products. Both the restaurant nodes and the commerce products leverage view modes. The restaurant nodes would have a viewmode for "full view" and "ad". The products would have a "full view" and "catalog" viewmode, the latter styled for display in a typical catalog grid.

To restaurant owners, it would be useful to see how often their dishes were shown to users on the site, which would be the "catalog" view mode. Also, restaurant owners might want to boost their page at a fee, so then it would be necessary to report how often their restaurant node's "ad" viewmode was served to users of the site.

Adding a psuedo-field to the entity, maybe one for each viewmode, would be an easy way to add a segmented "counter" to entities and views for site builders. Maybe there's a better approach, but I think this kind of reporting would be very valuable for this kind of platform.

I currently display a footnote under the user's visitor count stating it doesn't include product views or views in recommender views distributed across the site and am not able to provide a "boosting" feature because there would be no way of reporting the results.

alfthecat → created an issue.

Hi @bluegeek, thanks for clarifying that.

One additional thought I had based on this conversation, is that in some cases (like my marketplace), it would be very valuable if we could track impressions by viewmode or a view.

If we could then build reporting views and display statistics by view mode, it would open up the possibility of offering the boosting of posts, user profiles, and other forms of content promotion to the site's users. If the site sells ad space, this would be vital.

Just a thought, not sure if a psuedo field would be the way to go but I imagine adding it to a view mode to initiate tracking might be handy and intuitive for site builers.

Hi Marcus, thanks for the fix. This is a great setting to have.

Hi Marcus,

I've updated to the latest dev but now it's not longer fetching any data. Not getting any errors in the log, it just stopped working.

Hi guys, I just ran into an issue where if the automator runs via cron, this issue still persists.

Working perfectly so far! Cheers :)

Hi Marcus, awesome, thanks very much for the fix. I'm testing it now.

Hi, I had a chance to revisit this and the issue was related to a since resolved bug in Drupal. Marking this as fixed, thank you very much for the great module.

If we could leverage views it would already be great because the https://www.drupal.org/project/viewfield → module could then allow it to be added to any view mode of any entity.

Hi Marcus,

The field is on taxonomy terms, of the type: Text (formatted, long, with summary).
Attached is the field config and the automator config.

Nothing special is configured regarding input formats, it defaults to "basic HTML". After manual save the text is properly formatted.

Thanks!

alfthecat → created an issue.

Hi Marcus,

Thanks for the quick work, I'm on the latest dev and I'm still experiencing the issue.

alfthecat → created an issue.

Hi Scott,
I've applied the patch from !MR2 again but I'm still getting duplicate jobs.

I've tested as follows:

1 - I requested 5 translations for a single node. I checked the AI logger log, and it looked good, no duplicates.

2 - I then checked the Sources page, and it showed there were completed translations for the node, but also inactive jobs for each language. So for each language there are 2 jobs.

3 - I ran TMGMT cron, and the sources page showed me that now the first language had its second job marked as "in progress". That progress is stuck, it doesn't complete.

I attached a screenshot of the final result.

Thanks for the hard work on this, it will be amazing when this is working.

Hi Marcus, I was on the latest dev of both, but today's dev of the ai module no longer triggers the error. Thanks!

alfthecat → created an issue.

alfthecat → created an issue.

Hi Marcus, I'm using LLM simple.

alfthecat → created an issue.

Yes that's it, it seems like the translation doesn't happen or gets stuck somehow. I checked the AI log and it doesn't show any prompts being sent.

@shasha821110 you should use the non-deprecated one. So just the "AI Automators" module.

Hi, the continuous jobs are triggered on cron, which is when they will move to the "in progress" state. I think auto-accept jobs needs to be turned on for that to work.

Hi Marcus,

I'm finding a lot of errors in my watchdog log:

A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): entity type: node, bundle: g_post, field name: ai_automator_status

Also, lots of errors referring to fields:
Field [..]i_automator_status exists but is missing a corresponding field definition and may be misconfigured.

It turns out that even though there are automator fields on an entity, the AI automator status that is re-created by adding a temporary automator-enabled field as suggested in #18, gets deleted again when I delete that temporary field, unless I re-save another pre-existing automator-enabled field.

I figured this might be useful to know, maybe the update script needs to re-save the existing fields or something...

Hi Marcus, one more issue I'm running into when I try to import a configuration file (unrelated to ai modules):

Configuration ai_automator_address.google_places_settings depends on the ai_automator_address extension that will not be installed after import.

Any thoughts on what this can be and how I can fix this?

Thanks as always.

alfthecat → created an issue.

alfthecat → created an issue.

Great, done! ✨ Fallback to ai_translate configuration Active

alfthecat → created an issue.

Great, happy to be that trigger. Thanks again for the great work.

Hi @scott_euser, very excited about all the work you've been doing. Looking forward to all of the good stuff this module will have to offer :)

One question, the ai_translate module has a pretty neat interface for specifying prompts per language. Would that be something ai_tmgmt could leverage? Some specific instructions per language would be very useful to have, apart from the field-level instructions from this issue.

Hi all, great to see this module moved into the ai ecosystem and excited about all the work being done.

I tried to patch the module again with the plain diff from MR !2 and getting a partial failure:

sudo -u www-data patch -p1 < 2.diff
patching file .cspell-project-words.txt
Hunk #1 FAILED at 8.
1 out of 1 hunk FAILED -- saving rejects to file .cspell-project-words.txt.rej
patching file src/Plugin/QueueWorker/AiTranslatorWorker.php
patching file src/Plugin/tmgmt/Translator/AiTranslator.php

This is causing a major issue for me, as selection rules on all my asset injectors are no longer functional.

I can't uninstall the module because I can't disable the selection rules provided by this module.

I get a WSOD if I try:

The website encountered an unexpected error. Try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity_field:node" plugin does not exist.

Any tips on how I can get rid of the module?

OK, I figured that one out, somehow the google_places settings were reset so it no longer had a key provided.

Phew :)

I restored all my automators, I'm now noticing that google_places no longer fetches any data.

Is there something I can do to fix that?

Awesome, thanks very much. It turned out I needed to do this on the updated site, after I created an automator enabled field on all the entity types the import worked. That will save me a lot of time.

It also cleared up the errors on the status page.

Hi Marcus, what do you mean by automator type? I created a new field on the old database, and I created an automator chain type.

Still I get the same errors when I export a single automator and try to import it. I'm not sure what the status field is about. I'm going manual now by cleaning up the exported prompts and setting the field config manually. At least I can restore my prompts and know which fields to address :)

I'm still on the dev release, since the alpha is behind I didn't know it was a good idea to switch to alpha, I decided to just not update the ai module until there is a new alpha release :)

And totally understand the breaking changes, it's all in flux at the bleeding edge.

Hi Marcus, quick question, when I try to import a single configuration file though the UI, it fails validation and it lists a long list of reasons, all variations of:

Configuration core.entity_view_display.node.g_post.default depends on the field.field.node.g_post.ai_automator_status configuration that will not exist after import.

This also hints at the problem reported in the status report about the automator status field.

Any tips on how to get around this?

OK great. Skeleton modules are great for the upcoming Haloween.

Yes correct, I did not install the automators module, nor did I uninstall the automator module. I just ran updatedb after updating the ai module a few days ago. That turned out to cause issues that blocked me from running updated again, which I tried to do in order to update ECA from 1.x to 2.x, which I attempted again this morning, which is when I discovered the problem and tried to solve it with the commands described.

I'm just checking if I didn't structurally break something, I see in my modules page a disabled AI Automator (Deprecated) (Deprecated) and the AI Automators module, as per the screenshot. Is that indicative of a bigger problem?

Hi Marcus,

I could not update the database due to errors caused by the automator update, so I used the MySQL commands I listed above to get around that. I did not uninstall the automator module, myself, it happened as part of the module update I suppose. It's not exactly clear to me how it happened.

I do have a backup that I'm restoring now, thanks for the guidance on the configuration restore method, I'll try that route.

I don't know by heart which of the countless fields used automators so having those config files will save my day (and night!) :)

I just found out that, perhaps because of those MYSQL commands, all of my automators are deleted. Automator is disabled everywhere and the data is gone.

I ran into this issue after a fresh upgrade to ECA 2.x and the patch fixed the issue for me.

Thanks very much, I have a bunch of flag related models that were all affected.

Patch worked for me, thanks very much.

Hi Jurgen,

I got through the update this morning. In my case, I had to:

1 - remove the ai_interpolator_eca module from composer
2 - truncate all cache tables
3 - apply a patch to the openai module 🐛 Return type declaration error for Drupal\openai_eca\Plugin\Action\OpenAIActionBase::create RTBC
4 - apply a patch to the prompt module 📌 Get ready for ECA 2.0 Needs review
5 - fix issues caused by 📌 Rename data name to ai_automators Active that were preventing drush updatedb from running (I documented the fixes there)

After all that, the update ran great and it looks like all my models are in good shape and I've reached my coffee limit far before noon.

Thanks for your guidance, it certainly helped.

Hi Marcus,

I encountered a number of issues as a result of this update (some still remain), for others I'm able to provide solutions here for anyone running into this. The main problem was that I could not run database updates anymore. Drush returned:
[notice] Module ai_automator has an entry in the system.schema key/value storage, but is not installed. More information about this error.

I then ran the following MySQL command that resolved the issue with running updated.

DELETE FROM key_value WHERE collection = 'system.schema' AND name = 'ai_automator';

SELECT * FROM key_value WHERE name = 'ai_automator';

SELECT * FROM config WHERE name LIKE '%ai_automator%';

This helped to resolve the issue, but in the site's status report there are a number of errors listed:

Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
AI Log Type

The AI Log Type entity type needs to be installed.

Product

The commerce_product.ai_automator_status field needs to be uninstalled.

Content

The node.ai_automator_status field needs to be uninstalled.

Taxonomy term

The taxonomy_term.ai_automator_status field needs to be uninstalled.

I'm not sure how to address those errors, whether or not I can delete those fields.

Thanks as always!

Hi Marcus, awesome thank you. I didn't know moderation was enabled by default although it now makes sense because there is the moderation provider option in the general ai settings. So I was trying to solve a problem I didn't have by using the external moderation module :).

Thanks for the insight and I think adding that validation is a good idea.

Hi Marcus, yes it could be the content moderation module that's causing the watchdog errors. I just didn't see them before but I will check the setup for that one.

With regards to the settings form, the provider is set to OpenAI, empty tags field, and OpenAI - text-moderation-latest is the model selected.

alfthecat → created an issue.

Hi Marcus, great, thanks. I'm attempting another upgrade of ECA tomorrow early in the morning.

Is it safe for me to update to the latest dev of the ai module, though? ;)

Hi Jurgen, thanks for this, I will try this method and report back.

Actually I was too fast, when I try to install ai_eca, the warning is "The AI Automator (Deprecated) module is deprecated. (more information)"

I suppose the ai_eca module lists it as a dependency. I assuming it can't be installed without causing a conflict.

Is there a way to get ECA 1.x back in play as a worker for automators?

Thanks very much, I modified settings.php and it resolved the issue.

Thanks, I'll use the alpha version of AI with the beta of google_places. Life on the bleeding edge :)

alfthecat → created an issue.

alfthecat → created an issue.

Hi Marcus, no problem, and thanks for the guidance and the new release. I just updated and it works great again :)

Hi Marcus,

This turned out to be caused by a field that suffers from the Drupal core bug: 🐛 Not able to add to List field with 0 as the first machine name. Needs work .

I spent a few hours migrating the field data to a new field, and updating all the views that used it. I got a bit further after the offending field was deleted.

I'm not just getting the following errors and an incomplete result with a number of automators not returning data:
Error invoking model response: cURL error 28: Operation timed out after 30002 milliseconds with 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://api.openai.com/v1/chat/completions

and
A general error happened why trying to interpolate, message Error invoking model response: cURL error 28: Operation timed out after 30002 milliseconds with 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://api.openai.com/v1/chat/completions

The taxonomy entity has a lot of automator enabled fields, including two image field. Is that the issue? The execution method is set to "direct". Is the cron/batch method necessitated in this case?

Hi Marcus,

Sure, the Google places composer.lock info reads:

{
            "name": "drupal/google_places",
            "version": "1.0.0-beta1",
            "source": {
                "type": "git",
                "url": "https://git.drupalcode.org/project/google_places.git",
                "reference": "1.0.0-beta1"
            },

Hi Marcus,

Thanks for the quick reply. The automaton I ran (I didn't try other entities that have multiple automators) was the google_places automator.

I did run updatedb and cr.

Composer.lock holds this information related to the branch I was on (and now restored to again):

 {
            "name": "drupal/ai",
            "version": "dev-1.0.x",
            "source": {
                "type": "git",
                "url": "https://git.drupalcode.org/project/ai.git",
                "reference": "8be49dd66b7ee604f826e0fb3b1fea16bb8f17ba"
            }

Hope this helps, let me know if there's anything more I can provide.

alfthecat → created an issue.

alfthecat → created an issue.

alfthecat → created an issue.

I think this needs to have the "needs review" status

I applied the patch from MR 5 but in my case it didn't solve the problem. The conditions appear in my CSS injector UI and they are pre-selected with the first field in the list.

It excludes the plugins created by this module from any form other than the context UI.

is not what's happening in my case.

I'm on the 2.x branch, could that be the issue?

alfthecat → created an issue.

Just adding another case example, I got this error again after I deleted a field that was configured to use custom field permissions (field_permissions module) and then tried to alter permissions for an unrelated flag. Once more #11 fixed the issue.

Hi Jurgen, thanks very much for clarifying that. I was certainly confused about that part. That also explains why evaluation a condition on [node:author] works in my model, but setting the field value didn't. The field "uid" isn't shown in the token browser, which threw me off track.