Skip to content

Page Handling (CMS)

At it's core, this project is a CMS (Content Management System) that allows users to generate their own pages and populate them with customizable sections.

In the pages that follow, we'll explore how pages are constructed and the parts that make up a pages. We'll cover the anatomy of a page, the request lifecycle, and then go into each component of a page in detail:

  • Page and PageTypes,
  • Section and SectionTypes
  • PageParameters.

Anatomy of a Page

While this project supports traditional Symfony routes, it is primarily designed to handle pages in a CMS-like manner. The primary components used to render a page in the database are shown below:

Page Parameters

A single page that is created in the administration panel and registered to a URL address.

A page can have many sections. Sections are the building blocks of a page and can be of different types, such as text content, breadcrumbs, or other custom components. These section instances store their own JSON configuration in the database.

A pool of information that can be accessed called PageParameters. It can be read, mutated, and used by both the page and all sections on the page. This allows for dynamic content that can be reused across different sections without needing to reload from the database multiple times.

For instance, if you need staff member details in 3 different sections, it would be beneficial to do this in PageParameters and access it in all sections instead of calling the database 3 separate times.

Request Lifecycle

This project follows the standard Symfony request lifecycle with minor changes to accomodate the CMS nature of the project. The request lifecycle is as follows:

  1. The user requests a page from the server via the URL bar.
  2. The request is routed by the Symfony router to the appropriate controller. If the controller matched is a PageType controller:
    • The PageType controller will then match the URL to pages in the database. If a page is found:
    • The controller will engage the PageBuilder service to begin building the page from the database.
    • The PageBuilder service will then use PageParameters to render the page and all SectionTypes assigned to the page within the site administration panel as a single HTML response.

Request Lifecycle

How Page URLs Are Generated

When adding a page in the administration panel, the URL that the page will be registered for is constructed from the following components:

  1. PageType: Each page type has a path prefix. For example, the Blog PageType has a path prefix of /blog. All URLs that start with /blog will be renderde by the Blog PageType controller.
  2. Page Slug: If the blog page has a slug of my-first-post, the full URL will be /blog/my-first-post.
  3. Page Parent: If the page is a child of another page, the parent's slug will be prepended to the URL. For example, if the parent page has a slug of technology, the full URL will be /blog/technology/my-first-post.