a.dmitriiev → made their first commit to this issue’s fork.
I have fixed phpcs errors and also made the configuration property names more abstract for compatibility with version 2.x where not only paragraphs are supported, but also other entity types.
Hi @adel-by, thank you! This is a nice feature. For MR to be merge quickly, could you please address at least phpcs issues from here https://git.drupalcode.org/issue/frontend_editing-3554641/-/jobs/7054276 ?
If you also have time it would be nice to fix style lint problems for the file that you have added, see https://git.drupalcode.org/issue/frontend_editing-3554641/-/jobs/7054278 and for the JS that you have added https://git.drupalcode.org/issue/frontend_editing-3554641/-/jobs/7054279
Search API provides aggregated fields. You can use it to actually put data from different datasources into 1 field. Or you can also use "Rendered HTML Output" field that also works like aggregated field for all datasources across the index.
@dcam, thank you for rebasing the code. Regarding LinkWidget: the changes are described in the issue description with screenshots of Before and After
I recommend you to try the module out, for example here https://www.1xinternet.de/en/try-drupal or locally
Frontend editing is not a substitution for any of the modules like Layout Builder, Canvas, Gutenberg, etc.
Layout Builder, Canvas, Gutenberg are trying to solve the problem of a page look, building layouts, constructing the page from blocks/components, etc. Some of the like Canvas and Gutenberg are also improving the editor experience.
Frontend editing module is not for building pages nor layouts, this is a small lightweight module that just allows editors to quickly change the part of the page without going deep into forms/layouts or going away from the page. If your page consists of blocks (content blocks) or paragraphs or you have media items or nodes from entity reference fields, this module allows you to edit those references directly on the same page where you are, without going to a separate edit (in version 2.x also "add") forms and do content management directly there. In comparison with Gutenberg and Canvas, Frontend editing still uses usual admin UI and Drupal core Form API for working with entities, while Canvas is itself a React App and uses JSON:API instead and Gutenberg has its own way to handle its blocks/components. If your editors find it hard to learn new ways of working with content, Frontend Editing is a good solution, to still keep some "usual" things and maybe adopt the new technologies at your own pace.
In combination with https://www.drupal.org/project/all_entity_preview module, Frontend Editing also allows to have a nice preview of your changes in real time and it is possible to preview them without actually saving entities.
To sum it up, if you need to make a decision what to use to create pages, you need to consider technologies like paragraphs, canvas, layout builder, gutenberg, etc. But when it comes to edit content without navigating to any admin UI, here Frontend Editing comes into play. It is confirmed that it works with any entity reference (paragraphs, nodes, media, taxonomy terms even menu links), layout builder. Regarding compatibility with Canvas - I would say it is still possible, at DrupalCon Barcelona 2024 there were examples of integrating Frontend Editing with headless solution, but first Canvas needs to be stable.
Merged to both 1.x and 2.x. Thank you for detailed feedback and debugging!
I found that those console errors also exist for 2.x version of the module, so I changed the version in the issue and created MR for it.
But I have also created MR for 1.x here https://git.drupalcode.org/project/frontend_editing/-/merge_requests/131... . Please review, I hope it helps and no "hacks" will be needed.
Similar issue was already reported here https://www.drupal.org/project/ai/issues/3546744#comment-16280973 🐛 RagTool uses chunks results only but in results set the id for full entity is used Needs review . The problem was "Highlighting" processor and the follow-up issue was fixed here 🐛 Highlight Search API processor is incompatible with chunked results (RagTool) Active .
@jbuttler @dotist please check the "Processors" tab and make sure that you do not have "Highlighting" processor enabled, as it is useless with Vector database search.
Nice to hear that. There is now a lot of information on how to reproduce. I will try to install Drupal 10 and check this out also with Gin 4.1
There is an issue with packagist namespace ✨ Change namespace for Field Widget Actions module Active still. In MR I have used the current namespace with duplicated module machine name. The pipeline is green. Field Widget Actions is in require-dev section, so that all tests for automators and phpstan is satisfied.
The MR was reviewed and tested. Everything works as expected.
The new project was created https://www.drupal.org/project/field_widget_actions →
I have tried to reproduce the issue. It seems Drupal 11.2 and Gin 5 doesn't have this issue with Frontend Editing 1.8.15 and block field module.
Can you give more details? Maybe some logs are there in "Recent log messages"? Or an error in "Console log" of your browser? This information can help to understand the problem better.
I made a change, that no ajax is triggered with "Bind with the form mode" option enabled when the paragraph is loaded in standalone form, but the original behavior is preserved, when paragraph is loaded in parent form.
Please review.
I can confirm, that the option "Bind with the form mode" checkbox causes the problem. If it is disabled, then there is no problem. The problem originates from the logic that is behind Paragraph View mode module. It tries to reload the SUBform when this checkbox is checked. But in case of frontend editing, the paragraphs form is not a subform, that is why the actions are gone, as subform (a normal inline paragraph widget) doesn't need the actions.
This of course can't be fixed in paragraph view mode module, as it can't have context where the paragraph form is opened. I think the only way would be to modify the widget values inside the frontend editing form and disable this "Bind with the form mode" option.
@junaidpv thank you for the patch. I made a MR from it and it turned out that there are more lines that are not needed anymore. So I made more clean up. Please review.
a.dmitriiev → made their first commit to this issue’s fork.
Thank you everyone, this is merged. Releasing a new version with the fix
Are you using Paragraphs View Mode → module? There is already this issue 🐛 Conflict with Paragraphs View mode Active , maybe it is related.
The change makes sense in POV of the change that all input settings are moved from provider object to ChatInput instead.
I can confirm that gpt4 in any name doesn't appear anymore. All others are there like gpt5, 4o, etc.
It seems that still one gpt4 model is still in the list:
It was decided to have the plugin in custom_field project. Closing as won't fix.
For testing:
1. Install this module
2. Install ai_automators module.
3. Install field_widget_actions module (AI submodule)
4. Create a custom field
5. Create an automator for this field. Set the worker to "Field widget actions"
6. On manage form display of the entity bundle where the field was created go to settings of the field widget for the custom field. There will be a setting for "Field widget actions". Choose the plugin "Automator Custom field" and then select your automator in the action settings.
7. When you are on the edit form of the entity there will be a button near the custom field. When clicking this button the automator is triggered and the custom field properties are populated
a.dmitriiev → made their first commit to this issue’s fork.
a.dmitriiev → made their first commit to this issue’s fork.
a.dmitriiev → changed the visibility of the branch 3550681-add-field-include to hidden.
I just found out, that this recipe doesn't require the node module to be installed. For the field storage to exist for all content types, the dependency is needed to Node module itself. Maybe then this functionality should be added to this recipe https://www.drupal.org/project/ai_recipe_llm_optimized_content → instead, and it will extend LLM Support recipe to keep the latter untouched and be a base for all future recipes.
I am moving this feature to another project.
Created an issue for "Include in llms.txt" functionality here ✨ Add field "Include in llms.txt" for all content types Needs work
The recipe project was created https://www.drupal.org/project/ai_recipe_llm_optimized_content →
Thank you @b_sharpe! This is definitely the better and elegant approach! I have tested it and it works.
For testing, make sure that the changes from related issues are applied to AI Core module.
This issue 📌 Make setup field widget action config action support bundle wildcards RTBC is also needed to implement this recipe feature.
Related issue ✨ Field widget action for automator on custom field Needs review is needed to setup the field widget action on a custom field that uses Automator.
Found this issue, while trying to add Custom Field (module version 4.0.0-rc2) #3550437: Custom field automator compatibility with version 4.0 → and provided MR with a fix
a.dmitriiev → made their first commit to this issue’s fork.
a.dmitriiev → made their first commit to this issue’s fork.
Hi @gxleano, thank you for working on this issue.
Please check my comments, also the pipeline for phpstan and phpcs are failing, as well as tests. Please adjust the tests if needed for the new logic.
As AI Core RC1 was released with the config action to configure Field Widget Actions, now the "Generate Alt Text" button will appear automatically on image field of media type "Image".
I found this page https://community.openai.com/t/image-url-is-only-supported-by-certain-mo... , some people also randomly have this problem.
For my tests I used gpt-4o and it was not returning such an error. By the way gpt-4o is the default one that is set by ai_provider_openai module when you setup the provider.
Some more references for the changes:
- constraints support was introduced in Drupal 10.3 see change record https://www.drupal.org/node/3428254 →
- FullyValidatable constraint introduced in Drupal 10.3 see change record https://www.drupal.org/node/3404425 →
I have changed the config dependency to enforced dependency. I have also checked the update path from 1.1.0 to 1.2.0 and the enforced dependency is also added with update hooks.