This document documents the architectture of Pulse CMS. It covers functionality by directory.
The pulse codebase started as an old school PHP codebase (PHP 5). The updates have been to the pulsecore directory and is more object oriented with unit tests. The idea there was to add functionality in code that was easier to test and debug.
The configuration, admin area and user areas are described.
This is split into the old config.php in the root and pulsecore/storage/config.json The old config.php is kept around for the older code and should be deprecated at some point. The config.json file is meant for user configurable options. The pulsecore/bootstrap.php is for settings that are not meant to be changed by the user.
The actual config loading is a two step one. The first is to load the defaults and then overwrite with the config.json settings. This allows for adding options in subsequent Pulse CMS releases. This code is in pulsecore/wedge/config.php
This is the admin area. It has some similarities with how the user area is structured.
Its pretty monolithic. The admin pages are routed here and the basic assets and page layout done. This should really be refactored into an admin layout and a standard pulsecore page.
This is used for anything admin page or even tag related for admins. The translation files (plain PHP) are in the lang sub directory
All user added content is stored here. The format (except for media files) is a combination of newline separated text and JSON. Ideally this would be pure JSON.
All tags and plugins are implemented here. Tag PHP is loaded on demand as tags are parsed in the content. Theres not much consistency here. Some plugins are in the global scope. Others load from pulsecore/tags.
This is for new functionality
The Vue.js scripts and any assets that the tags or pages need is placed here. dependencies are either managed from node or as needed.
This is cached management code
This is all the CLI based scripts to create a release, or a set of update files in zip format
This is the api and overview docs
This should be be merged into pulsecore/src/install at some point.
Higher level reuseable logic is abstracted out here. The idea is to have testable chunks of code that do as little as possible for easier reuse.
This is for the page handling code. Most of this is for the admin area.
This is a longer term effort to move the pulsecore source into this directory, so its easier to search without running into the storage or composer dependencies.
The installer, tag parsing and page routing code is here.
Routing is handled in pulsecore/dispatch.php. The idea is to have a list of route objects which are then matched by HTTP method. The route objects do the URL matching via a class method for flexibility.
Its broken up into legacy routing which is routes from the .htaccess file and newer route objects around api, admin and general user routes
This is a new implentation of the tag parsing. The old version used regex to identify tags and extract attributes. This would then be used to include a tag implementation from the inc directory
The new code has a lexer and parser. This allows for embedded tags. This is used for more configurable blog displays. Its pretty ugly code, since PHP does'nt have something like lex/yacc or flex/bison.
This is more for plugin type content eg see the sb login.
This holds the config, cache and log files. Update zips are also moved here before processing. This directory and contents needs to be writable by the web server.
This is to manage the files in /content The blog, page, block files have some text and JSON content. This allows that to be handled properly. Media items have a gallery.txt file which is handled here as well.
Tags are defined here. Some tags from /inc have been rewritten and moved here. The legacy tag interface is a bit kludgy and relies on some global variables for the tag parameters.
This is for the view template files. This includes page and tags. This is different from the layouts which is done in the root template directory.
The PHPUnit tests and test files are defined here. Code coverage is mixed. The idea is for lower level code to be properly tested. Functional tests are a bit lacking since those are hard to define.
This is for all the composer dependencies
This holds all the view helper classes that are loaded on demand in the view
This has the config loading (config.php) and config editing code (config_edit.php). The storage classes are used in a few places but has been superceded by the code in pulsecode/store. It would be fair to say that most of the code here should be refactored.
Theres quite a bit going on in these files:
The page layouts are stored here.