thx,
I reviewed carefully while questioning whether the tests test the right thing. While mostly this seems right, in particular for chat, I'm not sure in some cases - please check my review comments.
this is fixed via https://github.com/drunomics/nuxt-component-preview/releases/tag/v1.0.0-... - more specifically https://github.com/drunomics/nuxt-component-preview/pull/65
It defaults to the block context, so it's enough to add @contentMediaType: text/html
all implemented, including some test-coverage.
only Textarea is not specifically implemented, since that's not supported by canvas any more. it's detected based upon a string pattern, what we support setting. thus, this works similar as it would with SDCs.
tested successfully :-) use nuxt-component-preview beta3 or later to use it! See README for usage details.
That works, but fails with canvas due to errors during url-rewriting. we need to add this as well.
There are more types we should add support for, see https://project.pages.drupalcode.org/canvas/sdc-components/props/
- Textarea
- dates
- arrays
implemented and added a PR here: https://github.com/drunomics/nuxt-component-preview/pull/64
create MR with the help of AI. works good and code is fine - merged.
while many types can be already covered with typescript, for some types there is special input-handling support in canvas. here an aI generated list:
Schema Definition: image
Special Handling: ✅ Media Library integration
Details: Uses media_library_widget, maps to entity_reference → Media entity with Image source. Extracts src, alt, width, height from media. Has ImageAdapter for transformation.
────────────────────────────────────────
Schema Definition: video
Special Handling: ✅ Media Library integration
Details: Uses media_library_widget, maps to entity_reference → Media entity with VideoFile source. Extracts src from file URI.
────────────────────────────────────────
Schema Definition: stream-wrapper-image-uri
Special Handling: ✅ Media Library integration
Details: When Media Library is installed, overrides to use media_library_widget instead of plain file upload. Has ImageUriAdapter.
────────────────────────────────────────
Schema Definition: image-uri
Special Handling: ⚠️ Adapter only
Details: ImageUriAdapter transforms stream-wrapper URI to public URL. No special widget.
────────────────────────────────────────
Schema Definition: date-range
Special Handling: ✅ DateRange field
Details: When datetime_range module is installed, maps to daterange field type with daterange_default widget.
────────────────────────────────────────
Schema Definition: heading-element
Special Handling: ❌ None
Details: Standard list_string enum handling
────────────────────────────────────────
Schema Definition: column-width
Special Handling: ❌ None
Details: Standard list_integer enum handling
────────────────────────────────────────
Schema Definition: background-color
Special Handling: ❌ None
Details: Standard list_string enum handling
────────────────────────────────────────
Schema Definition: stream-wrapper-uri
Special Handling: ❌ None
Details: Standard uri field handling
────────────────────────────────────────
Schema Definition: heading
Special Handling: ❌ None
Details: Standard object with nested fields
────────────────────────────────────────
Schema Definition: text
Special Handling: ❌ None
Details: Standard object with string field
────────────────────────────────────────
Schema Definition: shoe-icon
Special Handling: ❌ None
Details: Standard object with enum fields
────────────────────────────────────────
Schema Definition: config-entity-id
Special Handling: ❌ None
Details: Standard string with pattern validation
Summary of special integrations:
We want to support those properly which have special input-handling, so it is easy to benefit from that.
atm Drupal canvas does not support picking aspect-ratios or image-styles - Related: #3562276: Support selection of image styles or aspect ratio →
However, selecting images is supported via the noted json-schema-type.
We need to extend nuxt-component-preview to allow adding this metadata easily, together with a suiting example.
Then later on, we can look into focal-point support by passing-through the focal-point, so the frontend can apply it, and/or providing a desired aspect-ratio, minimum and/or minimum dimensions in the image metadata.
it would be great if you could select the display-mode for an image, i.e. the media display mode. that way suiting image effects and aspect ratios could be pre-configured. or provide similar means to allow for a selection of image-styles.
Responsive images are supported already, so re-titling.
minor, but please spell drunomics all lower-case! Thanks :-)
Tested successfully. Also the categor of existing components survived, I suppose thanks to the canvas update hook. All good - merged!
Implemented the necessary change. Moved storing category into plugin settings, so we can return the right default folder.
it seems the fails are related to https://www.drupal.org/node/3557215 →
I've found no usage of the client-side data. Fortunately the ajax callbacks are correctly reading information out of FAPI elements, else this would have been a security issue.
Reviewed the MR, all good -it fixes the incorrect documentation of the hook.
Gitlab CI is not happy but this seems all unrelated to the MR. That should be fixed separately.
> Would that resolve the paragraphs fields?
Not sure about that, specifically treating the non-translatable fields seems safer?
Attached is a re-roll of the patch against 2.0.0
I also ran into this or a similar issue, with autosave_form. In this case the token results in an invalid-argument-exception error!
I updated the branch, and added a kernel test to cover the cases. Note: I've used AI to help me with that.
Also attaching a patch file for usage with composer-patches.
Thank you for taking the time to document this, this is very helpful!
I also read through it and found everything sound and logical, I only took note of two small typos - as commented at the MR.
The MR has some phpstan fails which are unrelated. opened 🐛 Deprecations cause phpstan errors Active for that.
Then there is a phpunit test checking cache headers which needs to be updated. Done so. Note: I used AI to help with this.
added a quick MR to address the phpstan issues. Note: I created this with the help of AI.
So instead of using an uncacheable response, it shoudl have correct cache-metadata. added this.
attaching a copy of the change for composer-patches usage.
Currently missing this feature as well. It seems like this has been a frequent request / missing part, so I'd say this is major for recipes.
I agree that changing the log-level makes sense to better communicate the severity.
However, I added a small remark to the comment, could we improve that?
improving issue title and type then.
ok, thanks. Update the issue summary + I'm trying to bring some more structure to it.
So yes, this is me trying to think about all edge cases and be extra cautious in Canvas since it depends on a super complex tree of dependencies. I've been bitten too many times by the content, config, migration and recipe systems not performing the validation one would reasonably expect 😨
I see, that makes completely sense, thanks for the explanation!
As commented on the MR I'm not sure throwing an exception is a good idea though. Maybe we can prevent the potential issue otherwise?
As I understand the problematic entity-is-not-YET existing case can mostly incur with default content imports. If so, it sounds like something we could address there by making sure we invalidate caches of all imported entities after default content import. Or can we think of other cases also that could cause that friction?
> Are there known limitations regarding page-level caching, views caching, BigPipe, etc. that still affect this even when disabled?
There might be, I just opened a very much related issue: 📌 Ensure render-cached items work correctly Active . We'll check and if needed fix.
> Or is this effectively a different module/approach in v3, and recreating the simple v2 behavior is not possible?
As I understand, you tried to use the module correctly and it should have worked. We'll look into the caching issue + try to reproduce all works good. I guess it would make sense to add a functional test which configures some example views to show and proof it being working correctly.
Comparing https://github.com/HelgeSverre/mistral and https://github.com/partITech/php-mistral
php-mistral:
- php-mistral is well supported, includes tool calling, but also more sophisticated le-platform APIs like OCR
- not very popular, but well maintained
- code-base is solid, MIT licensed, comes with test-coverage
- not very popular, but has frequent releases, issues are answered! https://github.com/partITech/php-mistral/issues/78
- solid docs website: https://php-mistral.partitech.com - also covers using the same lib with other providers. in total quite some docs!
HelgeSverre/mistral
- no frequent releases. new 2.0.0 tagged in october, no release since then. Before the latest 1.x release was in 2024!
- no activity for the last two months at all
- not very popular also, even less it seems. it has 6 issues in total created, vs 27 in php-mistral
- documentation is in markdown format in docs directory. Covers important topics also, but not as solid / nicely prepared as done by php-mistral
Then, I've used claude code to help me comparing the libraries, here the result:
Mistral API Client Comparison
| Aspect | HelgeSverre/mistral | partITech/php-mistral |
| --- | --- | --- |
| Package Name | helgesverre/mistral | partitech/php-mistral |
| Version | v2.0.0 (Oct 2025) | v0.1+ (Dec 2025 - actively maintained) |
| GitHub Stars | 49 ⭐ | 25 ⭐ |
| Last Updated | Oct 21, 2025 | Dec 3, 2025 (more recent) |
| License | MIT | MIT |
Dependencies & Compatibility
| Aspect | HelgeSverre/mistral | partITech/php-mistral |
| --- | --- | --- |
| PHP Version | ^8.2 ⚠️ | \>=8.2 ⚠️ |
| Framework | Laravel-specific 🔴 | Framework-agnostic ✅ |
| Core Dependencies | • saloonphp/laravel-plugin• spatie/laravel-data• spatie/laravel-package-tools | • PSR-18 HTTP client (any)• PSR-7 (nyholm/psr7)• Symfony/mime ^6.3 |
| HTTP Client | Saloon (Laravel) | Any PSR-18 client (Guzzle, Symfony, cURL) ✅ |
| Your Project Compatibility | ❌ INCOMPATIBLE(Requires Laravel, you use Drupal) | ✅ COMPATIBLE(Framework-agnostic, works with Symfony) |
| PHP Version Issue | Your project: \>=8.1Package needs: ^8.2 | Your project: \>=8.1Package needs: \>=8.2 |
Features
| Feature | HelgeSverre/mistral | partITech/php-mistral |
| --- | --- | --- |
| Chat Completions | ✅ Streaming & non-streaming | ✅ Streaming & non-streaming |
| Tool/Function Calling | ✅ Standard tool calling | ✅ Advanced MCP support 🌟 |
| MCP (Model Context Protocol) | ❌ | ✅ Full MCP integration 🌟 |
| Tool Recursion Safety | ❌ | ✅ setMcpMaxRecursion() |
| Embeddings | ✅ Dense only | ✅ Dense + Sparse (Splade) |
| Reranking | ❌ | ✅ |
| Guided JSON | ❌ | ✅ |
| Audio/Transcription | ✅ | ✅ (via supported backends) |
| OCR | ✅ | ✅ (via supported backends) |
| Fine-tuning | ✅ | ✅ |
| Files API | ✅ | ✅ |
| Batch Jobs | ✅ | ✅ |
| Agents | ✅ | ✅ |
| Conversations | ✅ | ✅ |
| Moderation | ✅ | ✅ |
| Multi-backend Support | Mistral only | Mistral, OpenAI, HF TGI, vLLM, Ollama, llama.cpp, xAI ✅ |
| Hugging Face Datasets | ❌ | ✅ Full dataset management |
| Document Generation | ❌ | ✅ |
Code Quality & Testing
| Aspect | HelgeSverre/mistral | partITech/php-mistral |
| --- | --- | --- |
| Testing Framework | Pest PHP | PHPUnit |
| Test Structure | • ArchTest• 15 Resource tests• Connector tests | • Functional tests• Unit tests• Client-specific tests |
| Test Coverage | ✅ Good (15+ test files) | ✅ Good (Functional + Unit) |
| Static Analysis | ✅ PHPStan + Larastan | ✅ PHPStan |
| Code Style | ✅ Laravel Pint | Not specified |
| Examples | ✅ 10 detailed examples with docs | ✅ Multiple examples by client type |
| Documentation | ✅ Excellent (744-line README, comprehensive API reference) | ✅ Good (links to external docs site) |
| Typed DTOs | ✅ Full DTO support with \*Dto() methods | Partial |
Tool Calling Support (Critical for Your Needs)
| Feature | HelgeSverre/mistral | partITech/php-mistral |
| --- | --- | --- |
| Basic Tool Calling | ✅ Yes | ✅ Yes |
| Tool Definition | Standard JSON schema | Standard JSON schema + MCP |
| Tool Response Handling | Manual processing | Manual + MCP auto-execution |
| MCP Protocol | ❌ Not supported | ✅ Full MCP support |
| External Tool Servers | ❌ | ✅ Docker/exec MCP runners |
| Recursion Protection | ❌ | ✅ setMcpMaxRecursion() |
| Tool Call Examples | ✅ Detailed in examples/05-function-calling | ✅ Via MCP integration |
Architecture
| Aspect | HelgeSverre/mistral | partITech/php-mistral |
| --- | --- | --- |
| Design Pattern | Resource-based API wrapper | Multi-client abstraction |
| Service Provider | Laravel only | None (framework-agnostic) |
| HTTP Abstraction | Saloon PHP | PSR-18 (any client) |
| Extensibility | Laravel ecosystem | PSR standards |
---
Recommendation for Your Drupal Project
🏆 Winner: partITech/php-mistral
Reasons:
1. ✅ Framework Compatibility: Works with Drupal (you have Symfony components already)
2. ✅ PSR-18 Support: Can use Symfony HttpClient or Guzzle (both common in Drupal)
3. ✅ MCP Support: Advanced tool calling with Model Context Protocol - superior for complex tool interactions
4. ✅ Multi-backend: Works with multiple AI providers, not just Mistral
5. ✅ More Features: Reranking, sparse embeddings, guided JSON, HF datasets
Concerns:
* Both require PHP 8.2, your project specifies \>=8.1 (minor upgrade needed)
* Less GitHub stars (but more recently maintained)
* Slightly less polished documentation than HelgeSverre's
Why NOT HelgeSverre/mistral:
* ❌ Laravel-specific dependencies - Won't work in Drupal without Laravel
* ❌ Requires Laravel service container and packages
* ❌ Not suitable for framework-agnostic use
Action Items:
1. Upgrade project PHP requirement to ^8.2 in composer.json
2. Install partitech/php-mistral
3. Choose HTTP client (recommend Symfony HttpClient since you already use Symfony components)
4. Leverage MCP support for advanced tool calling needs
\-----------------------------
The laravel dependencies rule out HelgeSverre/mistral. But also otherwise, partITech/php-mistral is the winner. Even it turns out becoming un-maintained, it seems to be a solid to base we could continue with. I'd propose to go with php-mistral!
fails are unrelated. opened 📌 Make 1.0.x gitlab-ci pipeline green Active
Other proposed solutions from ✨ Build custom client for Mistral or switch to HelgeSverre lib Active
* Build our own Guzzle Client for Mistral that can forward errors to an exception.
* (or) try this out: https://github.com/HelgeSverre/mistral
let's pause this until we decided https://www.drupal.org/project/ai_provider_mistral/issues/3495572#commen... 📌 Research new Mistral client Active - if we switch the client we don't need to do this any more. 1.0.x I'd keep rather stable as is + focus on moving on with 1.1x
Created a first MR. Not all plugin-instances are converted yet, just a a couple for now. We should complete this when the approach is good.
Note: AI disclosure, I created the MR with the help of AI.
For usage with composer-patches I'm attaching a copy the MR.
Note: With mistral this was even more severe. But that's another issue: 🐛 Drupal 11.3 compatibility: Active .
Adding an MR for the issue I ran into. There might be more, but this is what I found.
Attaching a copy of the MR for composer-patches usage.
submitted MR. attaching a copy of it for usage with composer-patches.
let's fix this in 1.0.x, 1.1.x is unreleased and can be used for new developments like changing the API package.
Problem is not specific to Request::get(), but that generally various deprecation warnings are already enough to break it. That's a pre-existing issue with errors/warnings/notices in general, however in particular a problem with un-important things like deprecation warnings.
I'd propose to ignore deprecation warnings for now and to take a closer look at a better API-library first before investing more time into this.
running into this again now that 11.3 is out. See 🐛 Toolbal module and AssertionError: Bubbling failed Active for more background.
I see it fixed when the item pre-processing is not used any more. Not sure whether it's needed in 11.3 still, everything seems to work fine without the pre-processing.
I tracked it down to responsive_preview module making use of \Drupal\Core\Theme\ThemePreprocess::preprocessItemList(). The preprocessing of the item-list triggers the warning, what causes the rendering process to be aborted.
I'm not sure about details here, but it seems to be that the warning is a false positive since 'attributes' of item-list is a valid key for passing the theme variable.
I'd say this is major bug since item-lists are not un-common. I tried to improve the bug report as well.
I'm running into an issue with the same error.
Worse, it results in broken pages with broken CSS due to broken HTML with placeholders like in head:
<head-placeholder token="...">
<css-placeholder token="...">
<js-placeholder token="...">
<js-bottom-placeholder token="...">
yeah, I think this modules and the code are only valuable when sharing enough context. That might be lots of work. So maybe, instead it would be better to emphasize / encourage sharing a complete site setup? I'd assume there is even more to learn for AI in a whole site-build besides "only" custom code. It also needs to see and learn how projects are configured and stuff gets used!
Maybe we could have a drush command similar to the "export site-recipe" command from drupal cms, that includes custom code and shares the whole thing as working site, for AI and others to learn from.
we got the PR merged! also meanwhile we refactored and improved codespaces, so they are now fully replacing gitpod.
see https://github.com/drunomics/lupus-decoupled-project/commit/787fdc3037a4...
I refactored the codespaces setup, what makes this work. it's all shown when using devcontainers locally, codespaces show it once you create "view build output" in the appearing tooltip or open "view creation log". that's just how things work at codespaces.
Additionally I managed to show some default output in the opening terminal what gives some usage instructions.
see https://github.com/drunomics/lupus-decoupled-project/commit/787fdc3037a4...
I worked over this, it should work good now! Please open issues if you run into troubles.
meanwhile we got lots of recipes created for this, see www.drupal.org/project/lupus_decoupled_recipe_dev
This has been tested more, got a new standard profile recipe + is now all used in lupus_decoupled_project. So time to call this fixed!
the recipe is working fine. I'm also adding a test case and test setup, so need to make this green first. But the recipe is ready for review.
Since all those recipes got published, I think we can call this done! :-)
Given the huge amount of config that gets duplicated, I'm not convinced this the right approach for us. It seems to create a too much maintenance burden.
I think we need to find a better way, which re-uses more of what is there. Relies on CMS recipes and tunes things on top, i.e. we could add a config action to create CE-variants of views page and use that.
Anyway, meanwhile CMS 2.x is almost out and this is what we need to focus on now. Thus, I think we need to re-check things for CMS 2.x and go with what's best for that.
Merged! It also runs tests with 1.x-dev now, so we shoudl catch issues like this earlier in the future.
all good, test fails are caused by https://www.drupal.org/project/canvas_extjs/issues/3563480#comment-16385550 📌 Incompatibility with latest canvas 1.x-dev version Active and unrelated.
this is the reason: https://www.drupal.org/node/3556891 →
re-added some ajax updates and made sure they go smooth.