🇺🇸United States @michaellander

I've got an initial greenfield version of this to put up, that includes parts I cherrypicked from the Rules module. My version does not work through all the BC issues yet, which is the elephant in the room. I do have ideas around how we can sort out many of the known BC issues, but it's the part I am still nervous about. The requirements are not set in stone yet either and we should confirm there's agreement before we go too far into the solution.

michaellander → created an issue.

Let me follow up with @gantal. I know locally he was testing them against 3.0.x but he was running into a number of automated test failures and was trying to locate the issue. Will get you an answer shortly.

That sounds good! 3.0.x can be the new target.

if ($this->moduleHandler->moduleExists('ai_agents')) {

What's the plan with this and is it something I can help with now?

I'm wondering if the DataType up casting/converting should be independent of Contexts...I may be unnecessarily relating them.. I'm going to go back through this and see if that's the case.

I've implemented an improved version of this here:
📌 Experiment with improved Action plugin deriver for FunctionCalls Active

Depending on the future of that task we can decide how to move forward here.

michaellander → created an issue.

I marked 'Needs review' but really looking for feedback before I go any further. I may have not used that status correctly!

michaellander → created an issue.

michaellander → changed the visibility of the branch 3512100-context-upcaster_applies-class to hidden.

michaellander → created an issue.

michaellander → created an issue.

With this branch, the workflow is:

1. When FunctionCall::setContextValue() is called, loop through AiContextConverter plugins and check applies()
2. If found(TRUE), stop looping and call convert()
3. If none apply, pass original value

Where this gets a bit tricky is to what extent applies() should evaluate in regards to returning TRUE/FALSE. Should it just match the proper format? should it be able to successfully convert without doing the conversion?

Let's say we are given 'node:17', we can confirm the first part of the string contains a valid entity type, we can confirm the second part is a real entity. However, if entity type is correct, but the entity doesn't exist, do we return FALSE and let it continue checking for a match? One thing we may want to decide is if the applies call should remain binary or provide more potential states(think \Drupal\Core\Access\AccessResult). We'd create a AiConverterAppliesResult class, with methods such as: applicable, invalidApplicable, notApplicable. This would give us the ability to differentiate converters that definitely don't apply vs ones that may apply but theres an issue(i.e. InvalidApplicable('Node loaded but translation "fr" does not exist')) vs converters that will apply and succeed.

This means the workflow could evolve to:

1. When FunctionCall::setContextValue() is called, loop through AiContextConverter plugins and check applies()
2. If applicable found, convert
3. If invalidApplicable, return these with description on why they were invalid
4. If notApplicable, fail, and decide what to do

I like this approach better because it's up to the implementer to decide how to treat success, partial success and failure. They could still interpret them as true/false, or they can potentially take the natural language description and send that back to a provider and even prompt the user for clarification on how to move forward.

I just want to maybe get some other eyes on it before I continue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

I pushed some fixes for the execute() call and reworked how the action service is getting loaded so that the parent wouldn't be affected.

With this now merged into 1.1, I think we should close this issue and work off separate issues for bugs/features/etc.

michaellander → created an issue.

I believe some of this has made it into the repo already, but there are still some areas to sort out(marked as todos in this patch). We can use this thread here for records and to sort out remaining.

michaellander → created an issue.

Worth noting, we found an issue with eca_config_schema_info_alter() not firing when the eca_config module was enabled. I was able to work around this by using an OOP hook.

See 📌 Config validation for ECA models Active

Might not actually be anything configurable on this one..

@greggles, we are working on a new approach to image type derivatives so that we can support more complex workflows, for example:

Original image is .jpg

• Generated AVIF
• Generated WebP(fallback)
• Original JPG (removed from display)

Original image is .webp

• Generated AVIF
• Original WebP(fallback)

Original image is .avif

• Original AVIF
• Generated WebP(fallback)

This will also allow builders to mix in other standards, like if you have a photography site or maybe product shots and want to use Jpeg XL(with webp fallback) for those displays. We are nearing completion, and have a solution for this, although not the most elegant. Ultimately we will override the ImageStyle entity class and have versions that support core and imageapi_optimize when enabled. Because we are trying to support both core and imageapi_optimize versions, I'm not sure a solution here really save us too much effort. Ultimately a solution might be a better fit for core.

michaellander → created an issue.

michaellander → created an issue. See original summary → .

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue. See original summary → .

michaellander → created an issue. See original summary → .

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue. See original summary → .

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.