FAQs

This is the primary advantage of Drupal's Unified AI Framework. Because the system uses an abstraction layer, you are not hard-coded to one vendor. If a provider becomes too expensive or changes their terms, you can switch to a different provider (e.g., from OpenAI to Anthropic or Google Gemini) by simply changing a configuration setting, without rewriting a single line of code.

No. Drupal approaches AI Agents as "force multipliers," not replacements. An agent can handle the majority of the rote work, like tagging 5,000 historical articles or checking for broken links. But a human administrator is still required to define the strategy, approve sensitive changes, and monitor the AI Audit Logs for quality control.

Traditional search (Solr) matches keywords (e.g., searching "automobile" matches the word "automobile"). AI Search (RAG) matches meaning (e.g., searching "automobile" will also find "car," "vehicle," and "sedan"). RAG also allows the AI to "read" the search results and summarize a direct answer for the user, rather than just showing a list of links.

Absolutely not. While Drupal CMS will package these features into an easy "out-of-the-box" experience, the underlying technology, the ai module, CKEditor Assistant, and RAG Search, is available and stable today. You can start building now and migrate to Drupal CMS recipes later when they stabilize.

The Drupal module itself is free and open-source. However, most powerful AI models (like GPT-4 or Claude 3.5) require a paid API subscription from the provider, usually charged by usage (tokens). If you choose to run open-source models (like Llama 3) on your own hardware, there are no API costs, but you will incur server hosting costs.

No, not by default. The drupal/ai module is designed with security in mind. It sends only the specific prompts you authorize to the LLM provider. Furthermore, because Drupal is vendor-agnostic, you can choose to connect to "Zero-Retention" enterprise endpoints (like Azure OpenAI) or even run Local LLMs (via Ollama) on your own server, ensuring no data ever leaves your infrastructure.

Yes, absolutely. Drupal relies on cached data (for configuration, route definitions, and class discovery). If a patch modifies PHP code or configuration, the changes will not take effect until the old cached versions are deleted, typically using the 'drush cr' command.

Yes. If you used git apply Drupal to apply the patch, you can usually reverse it using the same command with the -R (reverse) option:

git apply -R my-changes.patch

This is a quick way to undo changes if you find a problem or if the patch was misapplied.

The simplest way to fix conflicts with 'git apply' Drupal is to first run it with the reject option: 'git apply --reject my-changes.patch'. This will leave '.rej' (reject) files showing exactly where the patch failed. You must then manually review the original file and the '.rej' content, manually edit the file to incorporate the change, and then remove the '.rej' file.

• Git apply (used for 'git diff' patches): This command simply applies the file changes described in a patch file to your working directory. 
• Git am (used for 'git format-patch' patches): It applies patches that contain commit metadata (author, date, message) and automatically creates a new commit in your repository for each patch it successfully applies.