Running Weblogs with Slash

Appendix A. Slash Architecture

With Slash up and running, you will probably want to make things look a little more homey. The key to advanced customization is understanding how Slash fits together. This appendix walks through the basic design and explains how things run. It is intended to help you understand how the individual components work, so you will be prepared to make your own changes.

The Apache Request Cycle

Slash is tied heavily to the Apache request cycle. Further, it is broken into multiple components, each supported by its own libraries. This modularization makes it possible to modify one kind of behavior without having to know how the underlying support structure works. The only pieces of Slash that do not fit this model are the housekeeping daemons, covered in Section 11.2 in Chapter 11.

Apache begins life by reading its configuration file, performing any initializations its modules require (see Figure A-1). Slash uses this stage to initialize several of its own components. For instance, the guest user is created during this stage. Slash also creates all of the menus for a site and stores all of the constant site configuration data (e.g., site name, document root, administrator name, etc.) in a hash. Consequently, any changes to this information require a complete restart of the web server to take effect. Global requirements are stored in /usr/local/slash/httpd/slash.conf, and each site has its own configuration file in the root of its site directory. This ...