I'm sad to see Drupal keeps doubling down on a destructive focus on neo-marxist "wokeism".
It's anti-thetical to the notion of merit and innovation and it will not end well.
Perhaps just like the OP, I was a Rules orphan for many years, skipping D8 entirely because of the absence of a compatible release. Then I found ECA and I've never looked back.
I've accomplished some extremely advanced scenarios using ECA and thanks to the BPMN IO modeler it's a delight to work with it. These readability these models introduce is fantastic.
The previous comment covers all the bases, I'd like to add that with ECA, it's easy to integrate AI in many or any nook and cranny of your site using the brilliant ai_eca and ai_automator modules. The sky is really the limit.
On top of all that, the patient, pleasant, and professional support from Jurgen and the team is amazing and that's extremely important to consider if you're working on important projects.
I'll always love Rules for the many years of my life that I've spent with it. I haven't kept up with it and am happy it's moving forward. However I'm marrying ECA to death do us part.
Thanks very much, I didn't pay enough attention to the terminal output. Turned out that my codebase was still running on ECA 1.x. After upgrading, I got it to work beautifully.
One glitch: even though I use JSON formatted data, the RAW option didn't work. But when I set serialization to JSON, it does. Using Raw, I get:
error] Passing in the "body" request option as an array to send a request is not supported. Please use the "form_params" request option to send a application/x-www-form-urlencoded request, or the "multipart" request option to send a multipart/form-data request.
Very happy it's working now, this is very powerful.
Hi @jurgenhaas, thank you.
In the meantime, I found the ECA Helper module → . I can't get it to work yet but it seems to/should be able to send JSON payloads to an endpoint. I'm not sure if it requires something similar regarding the data preparation, but I don't think so if I'm reading the config field descriptions correctly. I've opened a support request in the queue under: 💬 Keep getting 400 Bad Request` - "No entity content received." Active .
alfthecat → created an issue.
alfthecat → created an issue.
@priti197 thanks, closing this issue as a duplicate of 🐛 Call to undefined method Drupal\views\Form\ViewsForm::getEntity() Active .
Hi @scott_euser sounds very good to me!
Hi Marcus, yes this is resolved :)
I'm running into this problem as well, not just with new users.
I set up the default settings to "Subscribe users to their entity follow-up notification emails by default" and I set the "Default state for the notification selection box" to "All comments". Also updated the user profile settings of a number of test users to always subscribe.
Regardless, on the comment form, the comment notify checkbox still appears and is not checked by default, and there is also no default option pre-selected when doing so manually.
This is a major issue for me because users will definitely forget to hit the checkbox, it is counter-intuitive that the account level setting is ignored, and it's much cleaner to only have a setting in the user account form and not have the comment notify option when posting comments. I'll need to phase out comment notify in favor of a much more complex solution in order to get the desired UX.
Turns out this is a Drupal Core issue; marking this issue as a duplicate accordingly.
🐛 LogicException: The database connection is not serializable. Needs review
Having the same issue on 10.3.9, on image fields in my case.
I tried the patch from #39 but it doesn't apply:
sudo -u www-data patch -p1 < core_2987548-39_serialize.patch
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.Hi guys, thanks for the great work.
I ran into 3 issues after applying the patch (running Drupal 10.3.9):
1 - the new setting for "Default state for the notification selection box" is confusing because the help text: "Choose the default subscription mode if both subscriptions modes are enabled." implies that I should select 1 option yet there are checkboxes allowing me to select all or none of the states. I think that if the admin is prompted for a default state, there should be a required radio select widget that allows only one option.
2 - After I save the settings form I get a WSOD with error:
The website encountered an unexpected error. Try again later.
InvalidArgumentException: The configuration property enable_default.watcher.1 doesn't exist. in Drupal\Core\Config\Schema\ArrayElement->get() (line 95 of core/lib/Drupal/Core/Config/Schema/ArrayElement.php). 3 - On the user account edit form, the text: "Check this box to receive email notifications for comments on your content (e.g. an article authored by you). You cannot disable notifications for individual threads." is confusing to end users because in my case they don't have the option to author articles. I think that in the help text it shouldn't be assumed site users are familiar with the article content type, and a more ambiguous text is perhaps better. I.e.: "Check this box to receive email notifications for comments on content you authored. You cannot disable notifications for individual threads."
Thanks and hope this helps.
I encountered the same issue, fresh install on Drupal 10.3.9, in my case simply clearing the caches fixed the issue (this far).
Hi everyone, both the patch from #56 and the latest merge diff fail against 2.xdev on Drupal 10.3.9
Patch from #56:
sudo -u www-data patch -p1 < 3311063-56.patch
patching file composer.json
patching file modules/video_embed_media/src/Form/VideoEmbedFieldForm.php
patching file modules/video_embed_media/src/Plugin/media/Source/VideoEmbedField.php
Hunk #1 FAILED at 5.
Hunk #2 succeeded at 18 (offset -5 lines).
Hunk #3 succeeded at 47 (offset -37 lines).
Hunk #4 succeeded at 105 (offset -37 lines).
Hunk #5 succeeded at 144 (offset -37 lines).
Hunk #6 FAILED at 191.
2 out of 6 hunks FAILED -- saving rejects to file modules/video_embed_media/src/Plugin/media/Source/VideoEmbedField.php.rej
patching file modules/video_embed_media/src/Plugin/media/Source/VideoEmbedFieldInterface.php
patching file modules/video_embed_media/video_embed_media.module
patching file modules/video_embed_wysiwyg/.gitignore
patching file modules/video_embed_wysiwyg/config/schema/video_embed_wysiwyg.schema.yml
patching file modules/video_embed_wysiwyg/css/video_embed.admin.css
patching file modules/video_embed_wysiwyg/icons/film.svg
patching file modules/video_embed_wysiwyg/icons/play-circle.svg
patching file modules/video_embed_wysiwyg/icons/video.svg
patching file modules/video_embed_wysiwyg/js/build/README.txt
patching file modules/video_embed_wysiwyg/js/build/videoEmbed.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/index.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/insertvideoembedcommand.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/videoembed.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/videoembedediting.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/videoembedui.js
patching file modules/video_embed_wysiwyg/package.json
patching file modules/video_embed_wysiwyg/plugin/README.md
patching file modules/video_embed_wysiwyg/src/Form/VideoEmbedDialog.php
Hunk #1 FAILED at 48.
Hunk #2 succeeded at 85 (offset 3 lines).
1 out of 2 hunks FAILED -- saving rejects to file modules/video_embed_wysiwyg/src/Form/VideoEmbedDialog.php.rej
patching file modules/video_embed_wysiwyg/src/Plugin/CKEditor4To5Upgrade/VideoEmbed.php
patching file modules/video_embed_wysiwyg/src/Plugin/CKEditor5Plugin/VideoEmbedWysiwyg.php
patching file modules/video_embed_wysiwyg/src/Plugin/CKEditorPlugin/VideoEmbedWysiwyg.php
Hunk #1 succeeded at 14 with fuzz 1 (offset 3 lines).
patching file modules/video_embed_wysiwyg/src/Plugin/Filter/VideoEmbedWysiwyg.php
patching file modules/video_embed_wysiwyg/video_embed_wysiwyg.ckeditor5.yml
patching file modules/video_embed_wysiwyg/video_embed_wysiwyg.info.yml
patching file modules/video_embed_wysiwyg/video_embed_wysiwyg.libraries.yml
patching file modules/video_embed_wysiwyg/video_embed_wysiwyg.module
Hunk #1 succeeded at 13 (offset -2 lines).
Hunk #2 succeeded at 27 (offset -2 lines).
Hunk #3 FAILED at 50.
1 out of 3 hunks FAILED -- saving rejects to file modules/video_embed_wysiwyg/video_embed_wysiwyg.module.rej
patching file modules/video_embed_wysiwyg/webpack.config.js
patching file modules/video_embed_wysiwyg/yarn.lockLatest merge request plain diff:
sudo -u www-da ta patch -p1 < 6.diff
The next patch would create the file .gitlab-ci.yml,
which already exists! Assume -R? [n] n
Apply anyway? [n] y
patching file .gitlab-ci.yml
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file .gitlab-ci.yml.rej
patching file composer.json
patching file modules/video_embed_media/modules/vem_migrate_oembed/tests/src/Fun ctional/oEmbedUpdateTest.php
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file modules/video_embed_media/mod ules/vem_migrate_oembed/tests/src/Functional/oEmbedUpdateTest.php.rej
patching file modules/video_embed_media/src/Form/VideoEmbedFieldForm.php
patching file modules/video_embed_media/src/Plugin/media/Source/VideoEmbedField. php
Hunk #1 FAILED at 5.
Hunk #2 succeeded at 18 (offset -5 lines).
Hunk #3 succeeded at 47 (offset -37 lines).
Hunk #4 succeeded at 105 (offset -37 lines).
Hunk #5 succeeded at 144 (offset -37 lines).
Hunk #6 FAILED at 191.
2 out of 6 hunks FAILED -- saving rejects to file modules/video_embed_media/src/ Plugin/media/Source/VideoEmbedField.php.rej
patching file modules/video_embed_media/src/Plugin/media/Source/VideoEmbedFieldI nterface.php
patching file modules/video_embed_media/video_embed_media.module
patching file modules/video_embed_wysiwyg/.gitignore
patching file modules/video_embed_wysiwyg/config/schema/video_embed_wysiwyg.sche ma.yml
patching file modules/video_embed_wysiwyg/css/video_embed.admin.css
patching file modules/video_embed_wysiwyg/icons/film.svg
patching file modules/video_embed_wysiwyg/icons/play-circle.svg
patching file modules/video_embed_wysiwyg/icons/video.svg
patching file modules/video_embed_wysiwyg/js/build/README.txt
patching file modules/video_embed_wysiwyg/js/build/videoEmbed.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/in dex.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/in sertvideoembedcommand.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/vi deoembed.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/vi deoembedediting.js
patching file modules/video_embed_wysiwyg/js/ckeditor5_plugins/videoEmbed/src/vi deoembedui.js
patching file modules/video_embed_wysiwyg/package.json
patching file modules/video_embed_wysiwyg/plugin/README.md
patching file modules/video_embed_wysiwyg/src/Form/VideoEmbedDialog.php
Hunk #1 FAILED at 48.
Hunk #2 succeeded at 85 (offset 3 lines).
1 out of 2 hunks FAILED -- saving rejects to file modules/video_embed_wysiwyg/sr c/Form/VideoEmbedDialog.php.rej
patching file modules/video_embed_wysiwyg/src/Plugin/CKEditor4To5Upgrade/VideoEm bed.php
patching file modules/video_embed_wysiwyg/src/Plugin/CKEditor5Plugin/VideoEmbedW ysiwyg.php
patching file modules/video_embed_wysiwyg/src/Plugin/CKEditorPlugin/VideoEmbedWy siwyg.php
Hunk #1 succeeded at 14 with fuzz 1 (offset 3 lines).
patching file modules/video_embed_wysiwyg/src/Plugin/Filter/VideoEmbedWysiwyg.ph p
patching file modules/video_embed_wysiwyg/tests/src/Functional/TextFormatConfigu rationTest.php
Hunk #4 FAILED at 55.
Hunk #5 FAILED at 69.
2 out of 5 hunks FAILED -- saving rejects to file modules/video_embed_wysiwyg/te sts/src/Functional/TextFormatConfigurationTest.php.rej
patching file modules/video_embed_wysiwyg/tests/src/FunctionalJavascript/EmbedDi alogTest.php
Hunk #3 FAILED at 43.
1 out of 6 hunks FAILED -- saving rejects to file modules/video_embed_wysiwyg/te sts/src/FunctionalJavascript/EmbedDialogTest.php.rej
patching file modules/video_embed_wysiwyg/tests/src/Kernel/FilterTest.php
patching file modules/video_embed_wysiwyg/video_embed_wysiwyg.ckeditor5.yml
patching file modules/video_embed_wysiwyg/video_embed_wysiwyg.info.yml
patching file modules/video_embed_wysiwyg/video_embed_wysiwyg.libraries.yml
patching file modules/video_embed_wysiwyg/video_embed_wysiwyg.module
Hunk #1 succeeded at 13 (offset -2 lines).
Hunk #2 FAILED at 29.
1 out of 2 hunks FAILED -- saving rejects to file modules/video_embed_wysiwyg/vi deo_embed_wysiwyg.module.rej
patching file modules/video_embed_wysiwyg/webpack.config.js
patching file modules/video_embed_wysiwyg/yarn.lock
patching file src/Plugin/Field/FieldType/VideoEmbedField.php
patching file tests/src/Functional/FieldConfigurationTest.php
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file tests/src/Functional/FieldCon figurationTest.php.rej
patching file video_embed_field.info.ymlThe latest MR fixed the issue on my end: I could not set the aggration settings to "Count Distinct" which was breaking aggregation in my view all together. After the patch, it all worked.
Thanks everyone for the great work on this so far.
Maybe it 'just works'
Maybe it actually does....! I ran a test and now one-by-one the translations are stored as the job is running. If I disrupt the process, all the finished translations are still there. A massive win for large translation sets.Seems perfect!
One last thing to consider is to either automatically purge the job items that are left behind if the main job is stuck, or to restart them somehow. Currently, to delete stuck jobs and items requires either 2 custom VBO views to do in bulk, or, site admins have to go into every individual job item, click "abort", wait for a page reload, and then hit "delete".
alfthecat → created an issue.
Awesome, thanks! I'll test this tomorrow and report back.
alfthecat → created an issue.
Ah! That did it.
Thanks very much. All systems are go again! Very happy with this.
Hi Marcus,
I just watched the video in full, and double checked the API key setting and that was the cause. Updating to the latest dev had cleared out that setting, apparently, so I had to re-configure it and now it works again. Thanks very much.
Also it was useful to see you enabled the automator on the address field. I don't have that in my setup, I tried it but that was when the module itself wasn't working correctly and I never revisited that setup. I'm relying now on manual address input. I will play with this to see if I can make my workflow easier for admins. Very much appreciate the recording :)
Hi Marcus, thanks for your attention. Maybe it's somehow related to 🐛 Configuration import no longer possible due to missing ai_automator_address extension Active , in my case all I have to do tho break functionality is to run composer update. I have nothing in the log still. I think we have to see if this persists after the above mentioned issue resolves.
Hi Marcus,
Thanks, I figured that would be it, but in my case that directory was empty.
I ran drush cex, changed the config file name, and flushed caches.
When I try to import, I get a new error:
vendor/bin/drush cim
+------------+---------------------------------------------+-----------+
| Collection | Config | Operation |
+------------+---------------------------------------------+-----------+
| | google_places_settings | Create |
| | ai_automator_address.google_places_settings | Delete |
+------------+---------------------------------------------+-----------+
┌ Import the listed configuration changes? ────────────────────┐
│ Yes │
└──────────────────────────────────────────────────────────────┘
In ConfigImportCommands.php line 291:
The import failed due to the following reasons:
The config name google_places_settings is invalid.
Configuration <em class="placeholder">google_places_settings</em> depends on the <em class="placeholder">google_
places_settings</em> extension that will not be installed after import.Appreciate your thoughts on this. I also tried removing the multi-field, uninstalling the module, installing it again, re-creating the field, and strangely enough I get the same error when trying to import config files and on top of it the module stops working.... It has me scratching my head a bit, I can't figure out what is wrong :)
In my case, I have a need for this functionality on a fairly large location based website that has multiple views that sort results based on proximity. The issue is that there are usability issues with the current options available for proximity sorting from the geofield module, specifically detailed here: ✨ Suggestions to solve UX issues with Proximity Form Field location based views Active .
A more general issue is that for proximity sorting to work, a user needs to grant location access.
It would be perfect to have an option to sort views based on proximity gleaned from the smart_ip module. I would also like to wire that into the UX solution to the geofield module that I'm working on, so that the geofield module can have a fallback option to IP address based proximity calculation, like the ip_geoloc → module used to offer.
Hi,
If I may jump in, this is definitely a feature I'd really like to have. Main reason is to be able to evaluate and trigger ECA logic based on visitor tokens.
Not sure if this is the kind of info @heddn is looking for, I'm happy to elaborate if needed. Thanks :)
Hi Marcus,
I'm having no luck with this still, it's getting problematic that I can't import config updates anymore.
Could you perhaps clarify:
rename the configuration file ai_automator_address.google_places_settings.yml to google_places.settings.yml
I'm looking for this file but its not in my codebase anywhere.
I've tried drush config:delete "ai_automator_address.google_places_settings" and that gets my imports up and running again but also breaks the functionality of the module.
alfthecat → created an issue.
Brilliant, thanks to you both for fixing this double jeopardy issue. It's working great now.
Hi @mfb, I'm very happy to report the patch fixes the issue on my end. Thank you very much for the rapid solution.
marcus_johansson → credited alfthecat → .
Hi @biguzis,
Thanks for the patch. I applied it, but now when I set an image field to use the Pixabay automator, the site immediately crashes and new image fields can no longer be added or have their config page accessed.
Here is the error message printed in the browser:
The website encountered an unexpected error. Try again later.
Error: Cannot use object of type Drupal\Core\Form\FormState as array in Drupal\ai_automator_pixabay\Plugin\AiAutomatorType\PixabayImage->extraFormFields() (line 130 of modules/contrib/ai_automator_pixabay/src/Plugin/AiAutomatorType/PixaBayImage.php).
Drupal\ai_automators\FormAlter\AiAutomatorFieldConfig->alterForm() (Line: 16)
ai_automators_form_field_config_edit_form_alter() (Line: 552)
Drupal\Core\Extension\ModuleHandler->alter() (Line: 834)
Drupal\Core\Form\FormBuilder->prepareForm() (Line: 285)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm() (Line: 62)
Drupal\field_ui\Controller\FieldConfigAddController->fieldConfigAddConfigureForm()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)I'm noticing a mix of ai_aitomators and ai_automator in the stacktrace.
Hope this helps :)
@longwave thanks, I opened 🐛 Drupal core update + update to symfony/http-foundation causes certain views blocks to cause a "client error" and breaks page display. Active .
alfthecat → created an issue.
With appreciation for the work on this, I've just tested this by upgrading to Drupal 10.3.x-dev from November 21st but the problem still persists.
To re-iterate, my case does not involve a space in a URL, it is triggered by views block displays that use a contextual filter on URL (raw value/content id, etc).
The display doesn't contain a page display. Removing all views blocks from the page returns the page again.
I'm unable to update to the latest security release due to this issue.
After the update one particular views node display is no longer rendering and seems to be the cause of the client error. It uses a contextual filter "content id from URL" which in turn uses a relationship. There is no page display in the view.
There are no spaces in the URL of the node.
I have this issue after upgrading to 10.3.9, I don't see any spaces in my views URLs on the main views admin page.
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.