Skip to content

Aurora 1.2 is out!

What's new →
Docs menu

Reference

Routing

How an address finds its page, and where the website's own routes fit in.

How an address finds its page

  1. The app's own routes, in routes/web.php, load first and always win.
  2. Aurora's page routes come after: / (the homepage), sitemap.xml, robots.txt, signed preview/{page} links, then a catch-all for every other address. The catch-all leaves alone addresses starting with admin, livewire, filament, oauth, mcp, api, storage and up.
  3. An address that isn't a page goes to the stored redirects, then answers 404.

Files (/files/{id}) and forms (/forms/{form}) have routes of their own. Set aurora.routes to false to turn the page routes off and route pages yourself with Aurora\Http\Controllers\PageController.

Routes of your own

Put the website's own routes in routes/web.php. Aurora\Http\Middleware\UseSiteLocale runs on every web route: an address starting with a language's prefix sets that language (app()->getLocale() and ContentLocale::current()). So a route in more than one language is defined under each prefix, next to the default one:

routes/web.php PHP
use App\Http\Controllers\ShowEvents;

Route::get('/events', ShowEvents::class)->name('events');
Route::get('/no/events', ShowEvents::class)->name('events.nb');   // /no is Norwegian's prefix

ContentLocale::prefix($code) gives a language's prefix (empty for the default language), and Menus::localized(['/events']) makes menu links to /events go to the language being shown.

The sitemap

Sitemap::add() adds the website's own addresses to sitemap.xml, each a URL or an array:

app/Providers/AppServiceProvider.php PHP
use Aurora\Support\Sitemap;

Sitemap::add(fn (): iterable => Event::query()->live()->get()->map(fn (Event $event): array => [
    'url' => route('events.show', $event),
    'updated_at' => $event->updated_at,
    'priority' => 0.6,
]));

The site's layout around your own routes

A route of the website's own gets the site's head, header, menus and footer from one of its layouts, the same as a page. Wrap the view's content in <x-aurora::layout>, and it stands where a page's blocks would:

resources/views/events/index.blade.php Blade
<x-aurora::layout :title="__('Events')" description="What's on this spring.">
    <section class="mx-auto max-w-5xl px-6 py-16">
        <h1>{{ __('Events') }}</h1>
        @foreach ($events as $event)
            <x-event-card :event="$event" />
        @endforeach
    </section>
</x-aurora::layout>
AttributeWhat it does
titleThe page's title, in the browser tab and for search engines. Required
descriptionThe meta description
layoutThe handle of the layout to use, such as landing; the default layout otherwise
:settingsThe layout's own fields, as a page would have them ($settings in its view)
noindexKeeps search engines away

The layout gets a stand-in page with that title and description and the request's address: in each language, the same address under that language's prefix, so the layout's language switcher works. current_page() inside answers the stand-in, as on a page. It's only drawn, never saved.

From a controller, Layouts::wrap() returns the same HTML:

app/Http/Controllers/ShowEvents.php PHP
use Aurora\Support\Layouts;

return response(Layouts::wrap(
    view('events.list', ['events' => $events]),   // anything Htmlable
    title: __('Events'),
    description: 'What\'s on this spring.',
    layout: 'landing',
));