Vehicle is a modular Drupal project for managing structured vehicle data.

It provides a foundation for sites that need vehicle identity, classification, catalog, specification, or reference data. It can be used as a starting point for vehicle catalogs, dealership websites, listing platforms, comparison tools, fleet systems, garage systems, maintenance workflows, parts compatibility projects, import workflows, and Commerce-related integrations.

Vehicle is intentionally modular. The base module focuses on reusable vehicle identity and classification data. More specialized concerns, such as technical specifications, editorial pages, listings, comparison, imports, garage records, maintenance workflows, and Commerce integrations, belong in optional submodules, integration modules, or site-specific implementations.

Overview

Vehicle is designed to give Drupal sites a clean vehicle data foundation instead of forcing every project to create its own make, model, type, trim, and specification structure from scratch.

The project is built around Drupal's standard entity, field, permission, and Views systems. This makes it useful for site builders who need configurable vehicle data and for developers who need a stable base for custom vehicle-related applications.

This page describes the project's purpose, architecture, and boundaries. Exact functionality depends on the installed release, enabled submodules, and site configuration. For release-specific details, check the README and release notes for the version you are using.

Core purpose

The base Vehicle module is responsible for vehicle identity and classification.

Common vehicle concepts include:

Vehicle Make: A manufacturer, brand, marque, or producer, such as Toyota, BMW, Ford, Yamaha, Volvo, Mercedes-Benz, Trek, Sea Ray, Caterpillar, or John Deere.
Vehicle Model: A model belonging to a vehicle make, such as Toyota Corolla, BMW 3 Series, Ford Ranger, Yamaha MT-07, Volvo FH, or Volkswagen Golf.
Vehicle Type: A broad category, such as car, motorcycle, truck, bus, bicycle, boat, trailer, recreational vehicle, heavy equipment, or another site-defined vehicle category.
Vehicle Body Type: A body or shape classification, such as sedan, SUV, crossover, pickup, hatchback, coupe, van, wagon, cruiser, sport bike, or another site-defined body style.
Vehicle Model Range / Generation: A generation, platform, production range, model family, or market range within a model, such as Toyota Corolla E210, BMW 3 Series G20, or Volkswagen Golf Mk8.
Vehicle Variant / Trim: A trim, grade, edition, style, engine/body combination, or market-specific version within a model range.

Not every site needs all of these concepts. Vehicle is structured so that the base module can stay reusable while more specialized use cases remain separate.

Architecture

Vehicle is an entity-based Drupal project. It is not a Taxonomy backbone, not a marketplace application, and not a single all-in-one vehicle management system.

A typical vehicle identity hierarchy can be represented as:

Vehicle Make
  └── Vehicle Model
        └── Vehicle Model Range / Generation
              └── Vehicle Variant / Trim
                    └── Optional technical specifications
                    └── Optional editorial/profile content
                    └── Optional downstream integrations

The base module should stay focused on identity and classification. Technical specifications, editorial catalog pages, listings, garage records, maintenance records, imports, comparison tools, and Commerce behavior are separate bounded contexts.

Bounded contexts

Vehicle is designed to support different vehicle-related projects without putting every workflow into the base module.

Identity and classification: Makes, models, types, body types, model ranges, and variants.
Technical specifications: Structured facts such as power, torque, dimensions, weight, capacity, fuel or energy information, and similar vehicle data.
Editorial vehicle content: Public vehicle profiles, catalog pages, descriptions, images, and related editorial content.
Selection and discovery: Make/model/range/variant selectors, filters, or discovery interfaces where they are needed.
Comparison: Vehicle comparison tools built on stable identity and specification data.
Listings and postings: Seller, price, mileage, location, availability, contact, moderation, and listing workflows.
Garage and ownership: Saved vehicles, owned vehicles, fleet records, user garages, or ownership context.
Maintenance and service: Service records, repair history, maintenance schedules, inspections, and operational workflows.
Import and synchronization: External data providers, migrations, Feeds-style integrations, scheduled imports, or provider-specific synchronization.
Commerce and compatibility: Product compatibility, fitment, parts relationships, and Drupal Commerce integrations.

This separation keeps the base module maintainable while still allowing the project to support larger vehicle ecosystems over time.

What Vehicle is for

Vehicle can be used as a foundation for:

Vehicle catalog websites
Dealership and showroom websites
Vehicle information portals
Manufacturer, model, and trim reference databases
Fleet-related Drupal applications
Garage or ownership systems that need reusable vehicle references
Maintenance systems that need a stable vehicle identity layer
Comparison tools that need structured vehicle data
Listing or marketplace systems that need clean vehicle references
Parts, compatibility, or fitment projects
Commerce integrations that need vehicle-aware product relationships
Custom Drupal applications that need vehicle make, model, range, variant, or specification data

What the base module is not

The base Vehicle module is not meant to implement every vehicle workflow by itself.

The base module should not be treated as:

A complete classified ads or marketplace system
A seller, contact, negotiation, posting, or moderation workflow
A pricing, inventory, or availability management system
A garage management application
A maintenance scheduling or service history application
A Commerce product, order, cart, or checkout replacement
An import provider or external vehicle database connector
A VIN decoder
A full public search application
A complete vehicle comparison frontend
A full replacement for all historical 7.x branch behavior

Those features can still be valuable. They should be handled by optional submodules, integration modules, other contrib modules, or custom site-specific implementations when their scope is clear.

Features and availability

Vehicle is developed incrementally. Available functionality depends on the installed release and enabled submodules.

The project is designed to support capabilities such as:

Fieldable vehicle reference entities
Vehicle make and model management
Vehicle type and body type classification
Model range or generation management
Variant, trim, grade, or edition management
Contextual administration pages for related vehicle data
Granular permissions for vehicle data management
Drupal core Views integration through standard entity integration
Field UI compatibility for site builders
Structured technical specifications where provided by the installed modules
Editorial vehicle profile or catalog content where provided by the installed modules
Views-based catalog pages or blocks where provided by configuration or submodules
Integration points for import, comparison, listing, garage, maintenance, compatibility, or Commerce workflows where implemented separately

This section describes the project direction. It is not a guarantee that every capability is included in every release or provided by the base module alone.

Technical specifications

Technical specifications are separate from vehicle identity. This keeps the base module useful for many kinds of sites while still allowing structured specification data where it is needed.

Specification data may include typed values such as fuel or energy type, engine label, displacement, power, torque, drivetrain, transmission, acceleration, top speed, consumption, battery capacity, electric range, dimensions, weight, seating capacity, door count, cargo volume, or fuel capacity.

Provider-specific imports, large external datasets, comparison interfaces, and highly specialized specification databases should remain separate concerns unless they are explicitly implemented and documented by a specific release or submodule.

Vehicle content and catalog pages

Vehicle identity entities are primarily reference data. Public-facing catalog pages are better handled through a content layer that references vehicle entities instead of forcing every identity entity to become a public content page.

Where available, a Vehicle content layer can allow site builders to create vehicle profile or catalog pages that combine structured vehicle references, editorial text, images, and selected specification data.

This approach supports practical vehicle catalogs without turning the base module into a marketplace, review platform, comparison frontend, or search application.

Views and site building

Vehicle is intended to work with Drupal's normal site-building tools. Vehicle entities and related content can be exposed through Drupal Views where supported by the installed release and enabled modules.

Views-based pages and blocks are preferred for basic catalog output. Advanced selectors, AJAX make/model workflows, marketplace search, public comparison interfaces, and custom frontend applications should be implemented separately only when their scope is clear.

Submodules and integrations

The Vehicle project can grow through optional submodules and integration modules instead of expanding the base module into a large all-in-one application.

Possible module areas include:

Vehicle Specs: Structured technical specifications.
Vehicle Content: Editorial vehicle profile or catalog content.
Vehicle Selector: Optional make/model/range/variant selection interfaces.
Vehicle Compare: Optional comparison tools based on stable specification data.
Vehicle Listing or Posting: Optional listing, classified, marketplace, seller, and pricing workflows.
Vehicle Garage: Optional saved, owned, fleet, or garage vehicle records.
Vehicle Maintenance: Optional maintenance, service, repair, and inspection workflows.
Vehicle Import: Optional import, migration, provider, or synchronization integrations.
Vehicle Commerce: Optional Drupal Commerce integrations.
Vehicle Fitment or Compatibility: Optional product, part, or compatibility relationships.

Listing a module area here does not mean that it is included in the base module or available in every release. It documents the architectural direction and keeps future work separated into appropriate bounded contexts.

Installation

Install the project as a normal Drupal contrib module:

composer require drupal/vehicle

Enable the base module using Drush:

drush en vehicle

Optional submodules, if provided by the installed release, can be enabled separately according to the needs of the site.

Configuration

After enabling the module, vehicle administration pages are available from the Drupal administrative interface, typically under the Structure section.

Depending on the installed release and enabled submodules, administrators may be able to manage vehicle makes, models, types, body types, model ranges, variants, specifications, vehicle profile content, or other related data.

Vehicle is designed to work with Drupal's standard entity, field, permission, and Views systems rather than a custom all-in-one administration application.

Requirements

Supported Drupal versions are defined by the release branch and module metadata.
The base Vehicle identity layer is intended to avoid required third-party libraries.
The base Vehicle identity layer is intended to avoid required contrib dependencies.
Optional submodules may depend on additional Drupal core modules depending on the functionality they provide.
Optional integration modules may depend on contrib modules only when that integration specifically requires them.

Release status

The modern direction of Vehicle is a modular, entity-based vehicle foundation for Drupal.

Development releases, alpha releases, beta releases, release candidates, and stable releases may differ in completeness, stability, and supported scope. Review the release notes before using a specific version on a production site.

The goal of the 1.0.x line is to establish a stable vehicle catalog foundation, not to implement every possible vehicle-related workflow in the base module.

Historical note

Earlier versions of the Vehicle project had a different architecture and scope. Historical 7.x-era functionality may have referenced concepts such as Y/M/M selectors, selector blocks, external data providers, Feeds integrations, Pathauto/Token behavior, or default listing-oriented views.

The modern Vehicle direction is a cleaner and more modular architecture. Legacy behavior should not be assumed to exist in the current branch unless it is explicitly implemented and documented for the installed release.

Feature requests

Feature requests are welcome, but they should clearly describe the intended bounded context.

When proposing new functionality, please clarify whether the feature belongs in:

the base Vehicle module,
an optional Vehicle submodule,
a future integration module,
another contrib ecosystem module, or
a site-specific custom implementation.

This helps keep the base module maintainable while still allowing the project to support broader vehicle-related use cases over time.

Support

Please use the Vehicle issue queue to report bugs, request features, or discuss architecture decisions.

When reporting issues, include the Vehicle release version, enabled submodules, Drupal core version, and a clear description of the expected and actual behavior.

Vehicle