Core Laravel Package

Product Decisions This Supports

• CMS/platform selection: Informs whether to adopt Drupal as the content platform for products requiring structured content, editorial workflows, revisions, roles/permissions, multilingual content, taxonomy, accessibility, and governed publishing.
• Build vs. buy: Supports buying platform fundamentals from Drupal core and building only differentiated modules, integrations, and editorial experiences. It is generally not a reason to build CMS fundamentals in-house.
• Decoupled/headless architecture: Supports evaluating Drupal as a content service behind a Laravel or other application, integrated through JSON:API/REST or contributed GraphQL. In this pattern, drupal/core runs in a separate Drupal service, not inside the Laravel codebase.
• Dependency and upgrade governance: Supports decisions to pin drupal/core/drupal/core-recommended via Composer, track Drupal security advisories, and budget for major-version upgrades and module compatibility.
• Roadmap constraints: Makes explicit the platform commitments: Drupal release cadence, PHP version requirements, contributed-module ecosystem, hosting, and editorial training.
• Use cases: Enterprise content sites, public-sector and higher-education portals, multilingual publishing, regulated content workflows, and decoupled content hubs.
• Not a fit for: Simple Laravel admin CRUD, lightweight blogs, products needing a small embeddable library, or teams unwilling to own Drupal operations and GPL compliance.

When to Consider This Package

Consider drupal/core when:

• The product is a Drupal site, distribution, or module and is managed through Composer.
• The roadmap genuinely needs Drupal’s content modeling, editorial workflow, multilingual, and permissions capabilities.
• The team has or will fund Drupal expertise and can follow Drupal’s security and upgrade cadence.
• The organization accepts GPL-2.0 obligations and has completed legal review for distribution or embedding scenarios.
• Drupal will be deployed as a separate content platform integrated with Laravel via APIs, rather than installed as a Laravel dependency.
• You need to pin and audit Drupal core directly; in practice, evaluate drupal/core-recommended and the canonical Drupal.org release/security metadata, not GitHub stars alone.

Look elsewhere when:

• You are building a Laravel application and want CMS/admin features inside that application; evaluate Laravel-native admin/CMS options or a SaaS/headless CMS.
• The product cannot accept GPL-2.0 copyleft implications or proprietary redistribution constraints.
• The team lacks Drupal experience and the content needs are simple enough for a lighter CMS or managed platform.
• You need a small PHP library, not a full CMS runtime.
• You cannot commit to security patching, major-version upgrades, and contributed-module compatibility management.
• Adoption is being driven by the package’s GitHub stars or score; drupal/core is a subtree split, so those signals are not representative of the canonical project.

How to Pitch It (Stakeholders)

Executive summary: drupal/core is not a utility package to drop into a Laravel app; it is Drupal’s core CMS runtime. Choosing it means choosing Drupal as a platform. The upside is a mature editorial and content platform with strong multilingual, accessibility, permissions, and structured-content capabilities, backed by Drupal’s security process. The cost is specialized talent, upgrade ownership, hosting/operations, and GPL-2.0 compliance review.

Engineering summary: Treat Drupal as a separate Composer-managed service. Pin core/recommended versions, monitor Drupal security advisories, plan major upgrades, and integrate with Laravel through JSON:API/REST or GraphQL rather than vendoring drupal/core into the Laravel application. The low GitHub star count and score reflect the subtree-split mirror, not Drupal core’s actual adoption; validate against Drupal.org release notes and security advisories.

Recommendation: Proceed only if the content strategy and editorial requirements justify Drupal’s platform overhead. If the goal is to add content management to a Laravel product with minimal operational burden, evaluate Laravel-native or SaaS/headless CMS alternatives first. If Drupal is selected, adopt it deliberately as a platform dependency with clear ownership for security updates, upgrades, and legal compliance.