Drupal development for content with structure and responsibility.
Build a Drupal site around the information you manage and the people accountable for it. WebXd scopes content architecture, publishing workflows, themes, custom functionality, and migrations so your public website and your editorial system work together.
Define the resource before designing its page.
A policy library might contain guidance, forms, and reference documents owned by different departments. If every resource is a freeform page, a change to an owner or topic can become a search through unrelated text. A Drupal content model gives those details a defined place.
For example, a policy resource can have a title, summary, topic, responsible department, document, and review date. A department reference connects the resource to its owner. A controlled topic list supports filtering without asking editors to invent a new label each time.
We work through real samples before settling the fields. That exposes questions a page sketch can hide: can a document have several owners, does a retired policy stay available, and what happens when a resource has no file? The model and its display should handle those cases deliberately.
| Information | Drupal structure | Why define it? |
|---|---|---|
| Policy title and summary | Resource fields | A consistent card and detail page |
| Responsible department | Reference to a department | Ownership without retyping a profile |
| Topic | Controlled taxonomy | Predictable library filters |
| Document and review date | Media reference and date field | A file and an editorial review cue |
The same model can support a resource detail page and a filtered listing. We scope the listing behavior, empty states, and editing form alongside the fields. A review date is useful information; sending reminders or archiving content requires a separately defined workflow.
Give each publishing transition a responsible person.
The person who knows a policy best may not be the person authorized to release it. Drupal can keep a published revision available while a newer draft goes through review. We translate your approval rules into states, transitions, and permissions, then test them with ordinary editor accounts.
- Author revises the resource and saves a draft.
- Reviewer checks the wording, attachment, and ownership.
- Publisher releases the approved revision.
- Visitor sees the published resource, without access to the draft.
| Task | Author | Reviewer | Publisher |
|---|---|---|---|
| Edit an assigned draft | Allowed | Allowed | Allowed |
| Return it for changes | — | Allowed | Allowed |
| Publish an approved revision | — | — | Allowed |
A workflow diagram is only part of this decision. Preview links, unpublished media, and API access also need the correct visibility rules. We check what an anonymous visitor and each editorial role can actually reach, including attempts to view or change content outside their responsibilities.
For multilingual content, review also needs a language owner. Drupal moderates translations separately, so approval in one language should not be treated as approval of every translation. The scope should say who updates translated content when the source changes.
Name the kind of change your site needs.
An existing Drupal site needs an inventory before a development estimate. Core version, contributed modules, custom code, hosting requirements, and content relationships all affect the work. We use that evidence to distinguish a feature extension from a version upgrade or a migration to a newly structured site.
Extend a supported site
A new resource type, directory, or editorial workflow may fit the current platform. We review the existing configuration and module choices, then define the smallest coherent change. The proposal identifies the affected editing forms, public pages, and permissions.
Upgrade the platform
A version upgrade depends on the compatibility of the site and its dependencies. We identify module replacements and custom code changes before treating the upgrade as routine. The review environment should exercise the important publishing and visitor tasks on the target version.
Migrate into modern Drupal
Drupal 7 no longer has community support. Moving from it to modern Drupal requires a migration plan that accounts for content, files, references, and replacement functionality. We separate what can be mapped from what needs rebuilding, with the target version confirmed against the project requirements.
A trial migration should reconcile more than totals. We inspect representative records, missing attachments, topic assignments, department references, and changed URLs. Your team also needs a plan for edits made during the transition, the final import, release approval, and recovery if a launch check fails.
Decide how Drupal will deliver the experience.
Drupal can provide the website through a theme or supply content to a separate frontend. That choice changes how preview, routing, caching, and deployment work. We compare the actual requirements and the systems your team can maintain before choosing the architecture.
A Drupal theme
A theme keeps the public presentation within the Drupal application. We define responsive templates and components around the content model, with editorial preview and accessible interactions considered in the build. This can be a practical starting point for a content-focused website.
A separate frontend
A separate frontend may suit a shared content source or a specific application experience. Drupal can expose content through JSON:API, but the project must also define frontend hosting, preview, access rules, and cache updates. The extra system needs an owner as well as a reason.
Custom modules belong where a requirement exceeds configuration or a suitable contributed module. We record the behavior they own and the dependencies they introduce. Connections to other systems are scoped with clear data ownership, failure behavior, and access requirements rather than hidden inside a theme.
Keep the decisions with the working site.
A Drupal delivery should leave a usable record of the platform. The agreed packet can include field definitions, workflow permissions, theme and module source, configuration exports, migration mappings, and acceptance results. Your proposal names which artifacts are included and who reviews them.
Configuration changes move through a review environment before production. Content imports follow their own plan so deployment does not overwrite editorial work. We check the key resource journeys, publishing roles, responsive layouts, and agreed integration behavior, then document unresolved issues before requesting release approval.
- A content model with field meanings and reference rules
- A permission matrix checked with editorial accounts
- A dependency inventory and configuration deployment instructions
- Migration reconciliation and redirect records, where included
- Editing guidance, access handover, and an agreed maintenance owner
Ongoing updates need a defined arrangement after the build. Confirm responsibility for core and module updates, backups, recovery, and future changes in the agreement. Training and continued support can be scoped around the people who will operate the platform and the work they expect to do.
Resolve the questions that change the proposal.
When is Drupal a useful choice?
Drupal is worth considering when structured information, relationships, and editorial control are central to the site. The decision also depends on your maintenance capacity and existing systems. We compare those requirements with simpler publishing options before recommending a platform; a large page count alone does not settle the choice.
Can you work with our current Drupal site?
The starting point is a technical and content review, with access agreed for the assessment. A repository, module inventory, environment details, and representative content help establish what can be extended. Unsupported dependencies or undocumented custom code may change the proposal before development begins.
How are budget and timing determined?
The estimate follows the content model, templates, workflows, custom functionality, and migration requirements. Availability of source data and reviewers also affects the schedule. We define the deliverables and review points in the proposal, including any feasibility work needed before a reliable build estimate.
Can department editors have different responsibilities?
Yes, the publishing rules can be designed around different editorial roles. Restricting access to particular departments or content groups may need additional configuration or modules. We confirm the exact boundary, including previews and files, and test it rather than assuming a role name supplies that restriction.
What if we want to leave Drupal?
A move to another CMS is a different decision from Drupal development. The useful starting evidence is similar: content types, relationships, files, URLs, and publishing requirements. If WordPress is the intended destination, our migrations to WordPress service addresses that change of platform.