Enterprise Drupal website development in Torrance

Almost every Drupal site needs lists. Latest news, upcoming events, staff by department, products filtered by type, documents by year. Views is the core module that builds these lists through the administrative interface, and a large share of what would be custom code on another platform is configuration here.

A view starts with a base table, usually content, and then adds fields, filters, sorts and relationships. Filters decide which items appear. Sorts decide the order. Relationships join related entities, so a list of events can show the name of the venue stored on a separate venue node. The result can be displayed as a page with its own address, a block placed in a region, an RSS feed, or a data export.

Exposed filters turn a static list into a small search tool. A visitor picks a category, a date range or a keyword, and the view reloads with matching items. With AJAX switched on, the page does not reload at all. For many catalogues and archives, that covers what a client asked for when they said they needed search.

Contextual filters are the less obvious feature. They take a value from the address or from the current page, such as a term ID or the author of the node being viewed, and filter by it. One view can then power the related articles block on every article, each showing different content. Learning contextual filters removes a whole category of custom modules.

Views has a cost. Each view is a query built by a generic engine, and a careless configuration can produce slow SQL: several relationships, a sort on an unindexed field, no pager on a list that can grow without limit. Always set a pager or an item limit. Check the generated query in the preview when performance matters. Caching settings on each display deserve a deliberate choice as well.

Theming is the other friction point. Views wraps output in its own markup, and designers sometimes fight it. The cleanest route is to render content through view modes instead of individual fields. The view then says which items to show, and the teaser or card view mode, themed once, decides how each one looks. The same card appears everywhere the site lists that content type.

There are moments to stop clicking and write code. A list that needs complex scoring, data from an external API, or logic that would require a chain of fragile relationships is often clearer as a small custom block with a query written by hand. Views can also be extended with custom plugins for a single awkward filter while keeping the rest in configuration.

Because views are configuration, they belong in the exported configuration of the site and move between environments like any other change. A list built on a local copy should reach production through a deployment, never through a second round of clicking on the live site.

Taxonomy is the Drupal system for classifying content. A vocabulary is a named list, such as topics, regions or product types, and its terms are the individual values. Content types get reference fields that point to one or more vocabularies. Simple to set up. Hard to keep tidy.

The first decision is how many vocabularies a site needs. One big vocabulary called tags invites chaos, because it mixes subjects, formats and audiences in one list. Separate vocabularies for separate questions work better. What is this about? Who is it for? What kind of item is it? Each answer becomes its own field, and each field can be required or optional according to its purpose.

Free tagging is the next choice. When editors can create new terms while writing, the list grows fast and fills with near duplicates: plurals, typos, the same idea phrased three ways. That is acceptable for an internal archive. For anything that drives navigation or filters on the public site, a controlled list maintained by one person is safer. Editors pick from it and ask when something is missing.

Hierarchy is powerful and easy to overuse. Terms can have parents, which suits a product catalogue or a set of geographic areas. Deep trees, though, confuse editors and complicate queries. Two levels cover most real needs. If a third level appears, check whether it is really a separate vocabulary in disguise.

Terms can carry fields of their own. A topic term can have a description, an image and a short introduction, and Drupal gives every term a page at its own address. Those pages often become landing pages for a subject, listing all related content through Views. When that happens, the term description deserves real writing. An empty term page with a list of links serves nobody.

Merging and renaming terms happens in every mature site. Renaming is easy; references follow the term ID. Merging two terms needs a contributed module or a small script that moves references before deleting the duplicate, plus a redirect from the old term page. Plan for that operation before the first cleanup request arrives.

Multilingual sites add one more layer. Terms can be translated like content, or each language can keep its own vocabulary. Translated terms keep filters consistent across languages, which is usually what people want.

Permissions deserve a line in the plan. Drupal can restrict who may create, edit or delete terms per vocabulary. Give editors the right to use terms widely and the right to change them narrowly.

Finally, look at the vocabularies once a year. Delete terms with no content. Merge the obvious twins. It takes an afternoon and keeps every filter on the site honest.

On a small site, an editor writes a page and presses save. On a larger one, a page passes through several hands before it goes live, and the site has to know where it is. Drupal core handles this with two modules working together: Workflows, which defines states and transitions, and Content Moderation, which applies them to content.

A typical workflow has three states. Draft, in review, published. Transitions connect them, and each transition is a permission. Authors may move content from draft to review. Reviewers may publish it or send it back. An archived state is often added for content that should leave the site without being deleted.

The useful part is forward revisions. A published page can have a new draft sitting on top of it while the live version stays unchanged. Visitors see the old text. Reviewers see the draft on a latest version tab, compare it with the revision diff, and approve when ready. Without this, editors end up copying pages to work on them privately, which breaks links and history.

Different content types can follow different workflows. News might need a single review. Legal notices might need two. A simple blog post might skip review entirely. Keep the number of workflows small, though. Each extra one is another set of states for editors to learn and another set of permissions to audit.

Scheduled publishing is not in core. The Scheduler module is the common choice, adding publish and unpublish dates to content types. It works with Content Moderation through a companion module, so a scheduled item moves to the published state at the right time instead of bypassing the workflow. Scheduling depends on cron. If cron runs rarely, a story set for nine in the morning may appear at ten past.

Notifications close the loop. Core does not email reviewers when something lands in their queue. A contributed module can, or the site can offer a moderated content view that reviewers check each morning. Pick one approach and tell people which it is. A workflow nobody watches is just a slower way to publish.

Media and blocks need thought too. A draft page may reference an image that is already live, or a reusable block that changes on every page at once. Editors should know which parts of a page follow the review and which do not.

Keep the audit trail visible. Every transition creates a revision with the author and a log message. Asking for a short message on each transition turns the revision tab into a readable history of who approved what and why.

Test the workflow with the actual editors before launch. The permission table always looks right until someone tries to publish on a Friday afternoon.