Problem/Motivation
AI module is moving into Drupal CMS and recipes will be a new standard on how you apply configurations. This causes a big dilemma - what if the system is getting installed or what if you are applying a recipe and there is no provider installed.
With recipes that are not applied during site installation one could add validation that default providers is setup, otherwise it will not be applied. This means that you could add a specific provider recipe before the configuration recipe.
It should also be mentioned that we have developed most of the submodules in the AI Core so that if you set them up and use the default provider option they have graceful fallback, meaning that they don't do anything or break anything before you setup a default provider. This means that a recipe could install them even without a provider setup. They just don't start working until the default provider for the operation type is set. It should also be said that this is not always true for third party AI modules
For the site installation though we want as many options open as possible, that it can either happen during the installation or after the installation.
With DXPR we have for instance already added a solution that gives you the opportunity to choose between OpenAI and Anthropic during installation and where it will uninstall all of the AI module and its dependencies if you do not choose one.
For Drupal CMS however the following issue exists, but as written there, it should be used sparsly and AI is not a necessity for Drupal CMS, so this is not an option:
https://www.drupal.org/project/drupal_cms/issues/3482992
✨
The installer should collect input for recipes that need it
Active
There are also three types of providers (with some gray area in between):
1. Simple SaaS that just requires you to register, add a credit card and copy an API Key (OpenAI, Groq, Fireworks AI, Anthropic, Mistral, Google Gemini etc.)
2. Enterprise servers or serverless architectures that requires more steps and sometimes even sysadmin knowledge to setup (Azure, AWS Bedrock, Google Vertex etc.)
3. Self-hosted solutions that requires quite complex setups to run in production and needs sysadmin knowledge to setup (Ollama, Jan.ai, llama.cpp etc.)
For anything that should be facing towards beginners of Drupal or AI only the #1 type of providers make sense to setup.
But the second problem is that the setup of these are using a very typical Drupal structure where you have to know where to look to set them up and even then you might not understand that you have to create a Key entity before you set it up etc.
Therefore my suggestion is to create a simple Wizard form that works if it sees that certain provider modules are available on the system and enables them and sets them up in one form and even have description on the providers and where you can register and find API keys and how costs are managed. We could also add a checkbox that they have to confirm there that they do understand that it will incur costs.
This wizard form can be linked to from setup dashboard similar to what Drupal CMS will offer and make it possible for the users to setup the AI capabilities easily after installation.
One option is that the above becomes a contrib module as well.
Proposed resolution
- Create a provider setup Wizard form where you can simply choose your provider from a dropdown.
- The providers available are handpicked ones that are simple to setup, both outside and inside of Drupal.
- After choosing it, there will be a description of the platform and a form with an API key and a checkbox that they understand that it will incur costs and perhaps a link to the pricelist of the provider.
- On form submit there will be a validation that the actual API key is working.
- On validated submit there will be a message that its setup and it will be forwarded back to the referer.
- The form needs no menu linking, just routing.
- There will be a config where you can pick from the providers available and where you can choose another forwarding url.
Remaining tasks
User interface changes
API changes
Data model changes