Configuration

What to set after installing, and what already works without you.

Routing

One setting decides how much of the request PageBlocks handles:

pageblocks_routing	What happens
Disabled (off)	The component does not touch routing. MODX resolves every URL itself.
Route Only (routes)	Your routes are matched; anything unmatched falls through to MODX.
Full API (full)	PageBlocks owns the request.

full is the default. off used to be, and it gave a clean install a dead manager: the moderation menu entry and the dashboard widget call /mgr/pb/*, and with routing off there are no such routes.

The rest of the settings have working defaults; see System settings for the full list.

Server

• Apache — rename ht.access to .htaccess
• Nginx — set up the rewrite rules, since nginx does not read .htaccess

Without this, every address except the front page is a 404: the web server looks for a directory that is not there instead of handing the URL to index.php.

Pages already work

The app layer ships two routes for ordinary MODX resources, in core/App/routes/web.php:

<?php

use Boshnik\PageBlocks\Facades\Route;

Route::get('/{context}/{alias?}', 'ResourceController@context')->where('context', '[a-z]{2}');
Route::fallback('ResourceController@index');

The first is the multilingual case: a two-letter prefix is treated as a language and the rest as the alias — which is why an address like /en/about works as soon as a second language exists, without adding a route. See Languages.

The second opens any other resource. It is a fallback, not a /{alias?} pattern, and deliberately so: MODX resources nest to any depth while ResourceController works out the resource from the whole URI anyway, so a pattern would impose an artificial nesting limit — with routing = full, /catalog/phones would answer 404.

ResourceController finds the resource, picks its template and renders the page. Nothing else is required to serve a normal site.

These live in the site layer, so they are yours

core/App/routes/ belongs to the site, not to the component — an upgrade will not overwrite it. Override either route, or delete them and take the request over entirely.

Route files are read in alphabetical order

Everything in core/App/routes/ is picked up by a glob, sorted by filename. Files whose name starts with _ are skipped — that is how a routes file is parked without deleting it.

Order decides which of two overlapping patterns wins, so name a file for a specific section — product.php, catalog.php — and it is matched before whatever sorts later. web.php is not part of that race: its catch-all is Route::fallback(), which is tried only after every registered pattern has missed, whatever the filename order.