All questions

We are a Drupal shop, is there actual Drupal support or just generic PHP?

Asked by Matthias Kraus on

MKMatthias Kraus

We are evaluating personalization vendors for several client projects, all of them Drupal. Before I put Croct on the shortlist, I would like a clear answer on the level of support: is there Drupal-specific documentation and an integration path, or would my team be adapting a generic PHP client and discovering the edge cases ourselves? We have been burned before by vendors whose "PHP support" turned out to be a README and good wishes.

Was this helpful?

2 answers

Croct Bot
AI

Drupal has its own dedicated documentation alongside Laravel and Symfony, all built on top of the PHP SDK, so your team would not be adapting a generic client. The integration model for Drupal is: content is fetched server-side through the SDK and rendered in the theme layer, so the personalized markup is part of the HTML Drupal serves. There is no client-side swap step to bolt on.

A few things that should answer the "edge cases" concern specifically:

  1. The universal quick start applies to PHP projects too: npx croct@latest init scaffolds the setup, and you verify it on the dashboard Integration page, which shows a green "Received traffic in the past 24 hours" badge once requests flow.
  2. The CLI generates slots.stub type stubs for PHP projects, the counterpart of the TypeScript declarations, so slot content shapes are explicit rather than discovered at runtime.
  3. Since your shop runs multiple client projects, the workspace and environment model keeps each client's applications and data separate.

There is a thread on the broader PHP server-side setup that may be useful for your evaluation as well: Using the PHP SDK for server-side personalization in Laravel.

Was this helpful?
BVBram Verhoeven

Chiming in as another Drupal shop that had the same "is this real Drupal support or a generic PHP README" worry before shortlisting. It is a real integration: the Drupal docs sit alongside Laravel and Symfony, all on top of the PHP SDK, and content is fetched server-side and rendered in the theme layer, so there is no client-side swap step to bolt on.

The two details that mattered for our multi-client setup: the workspace and environment model keeps each client's applications and data separate, and the CLI generates a slots.stub so slot content shapes are explicit rather than discovered at runtime. We are a few projects in and have not run into the kind of undocumented edge cases we got burned by elsewhere.

Was this helpful?
Still have questions?