Bespoke layouts
Faithful design implementation with editable content fields.
← All technologies
MODX · BIG FISH
Web development with MODX
Bring bespoke layouts together with a task-focused editor. Services, cities, technologies and case studies have their own fields, while listings follow published content.
BIG FISH / MODX
01Resource + TVs
02Template and chunks
03Resource query
04Page and listing
Design × technology × your workflow
PRODUCT CAPABILITIES
Technology becomes
a working product.
Scalable sections
Cities, technologies and services with consistent presentation and automatic listings.
Task-focused editing
Fields, repeatable blocks and clear guidance for the content team.
INTERACTIVE EXAMPLE
Try the workflow.
See the outcome.
A service is stored as a resource with dedicated fields. Change its data or publication status: the listing card and detail page follow the same model.
Educational example with fictional data. Actions stay in your browser. This models the workflow; it is not a connected CMS, server or database.
MODX
MODXWorkflow result
The example is ready to explore.
WORKFLOW ARCHITECTURE
Every step has
a responsibility.
01
Resource + TVs
02
Template and chunks
03
Resource query
04
Page and listing
| Layer | Outcome |
|---|---|
| Interface | Input, limits, loading and errors are clear. Keyboard operation is available. |
| Data | Values have an owner, format and freshness rules. |
| Release | Critical journeys, backups and recovery have been checked. |
BIG FISH · MODX
A distinctive website. A clear CMS.
MODX website development lets us shape the interface around brand identity and content structure. We design distinctive service pages, portfolios and catalogues, then connect their visual elements to clearly named editing fields.
For a corporate MODX website, we separate everyday editorial changes from the structure that holds the design together. Field labels, hints and repeatable elements let your team maintain the site without editing HTML.
PRACTICAL GUIDE
Building a product
with MODX.
Architecture, constraints and testable workflows. The exact configuration follows the project requirements.
MODX / 01
Resources and site tree
Arrange pages in a clear hierarchy of sections, subsections and entries. Decide which entities deserve a resource and which are repeated blocks within a page. URIs and parent sections influence navigation and automatic listings. Check moves together with the address, breadcrumbs and redirects from the previous URL.
Acceptance check
Moving a resource retains a clear route.
MODX / 02
Additional fields
Template Variables suit covers, introductions, captions, categories and other distinct values. Repeated blocks can use a supported extra such as MIGX when installed. Bind fields to the appropriate templates. Give editors clear labels, sensible defaults and an explanation of what happens when a field is left empty.
Acceptance check
A missing cover behaves predictably.
MODX / 03
Templates, chunks and snippets
A template defines the page, a chunk contains reusable markup and a snippet runs server-side logic. Separate queries from presentation so a card redesign does not change business rules. Test every consuming section before updating shared elements. Pilot work benefits from separate elements with an explicit scope and rollback path.
Acceptance check
A pilot change does not affect the shared template.
Resource: service
TV: service_intro
TV: service_cover
TV: service_category
Listing: published children of a selected sectionMODX / 04
Parsing and embedded code
Native MODX tags and an additional template engine may operate together. Establish the processing order first. JSON, CSS and JavaScript contain braces that must not be indiscriminately passed through another template pass. Keep scripts and styles in files, and validate structured data after complete HTTP rendering rather than only in a console.
Acceptance check
The HTTP response contains no template markers.
MODX / 05
Automatic listings
Build listings around explicit criteria: parent, publication, visibility and language. A new page appears without manually copying a card. Use bounded queries and pagination for larger sections. Give search its own parameter name; MODX routing parameters must not double as user filters. Test drafts and scheduled publication dates.
Acceptance check
A draft does not appear in the listing.
MODX / 06
Language versions
Localisation may use separate contexts or a translation extra, depending on the project. Define translated and shared fields explicitly. A cover may be inherited while text and SEO remain independent. Language switching should reach the corresponding entry. Test missing translations, canonical links and local anchors when a base tag is present.
Acceptance check
An English anchor stays on the English page.
MODX / 07
Caching and editor access
Page caches, snippet results and extra-specific caches may have different lifetimes. Define what is invalidated by publishing or data changes. A section editor does not need access to every PHP snippet on the site. Check manager restrictions and public routes, including direct attachment links and unpublished entries.
Acceptance check
Editors cannot access server-side code.
MODX / 08
Release without content loss
Before changing a template, preserve resources, TVs, translations and files. Check not only a successful server response but also sections, forms, links and valid markup. Rerunning an installer must not overwrite editorial changes. Rollback should restore the previous presentation while retaining new data for subsequent work.
Acceptance check
Rerunning installation preserves editorial changes.
FAQ
Before we start
Is this a ready-made product?
No. The example illustrates a proposed workflow for MODX. We design the production system around your requirements, data and integrations.
Can we retain our current systems?
We first review their interfaces, data ownership and constraints. The result may be an integration, a phased migration or a focused replacement of one component.
What do we receive at handover?
The agreed deliverables include design assets, source code, environment requirements and operational instructions. Scope, ownership and support are recorded in the contract.
Let’s design your product
Tell us about your workflow, audience and existing systems. We will define the interface, technical boundaries and delivery stages.