Geeklog themes and templates
Geeklog 2.2.2 online theme guide — technical verification ongoing. This guide is a new synthesis informed by topics in the recovered Wiki inventory, including
Caching_Template_LibraryandTheme_Developers_Guide. These pages span different Geeklog releases. Check the target release and the actual bundled theme before reusing configuration keys or code snippets.
Overview
Geeklog uses template files to separate the presentation of a page from its PHP application logic. Themes define the site's layout and styling, while plugins can supply their own template files. The recovered Wiki describes a caching template library, multiple template search locations, variables, blocks and rendering logic.
Working with a theme
- Select a theme that ships with the Geeklog version you deploy.
- Make a working copy in a staging environment. Keep a record of modified files.
- Change one template or stylesheet at a time.
- Check the site in logged-out and administrative views, and on narrow and wide screens.
- Test plugin pages and views, not only the homepage.
- Back up modifications before changing a theme or upgrading.
The legacy Wiki discusses template names such as header.thtml, footer.thtml, blockheader.thtml, blockfooter.thtml and story-body templates. Check that these paths and names exist in your target theme; do not assume an old theme directory structure is still current.
Template variables, blocks and lookup paths
Templates can use variables supplied by the application. The Wiki also documents template blocks and searching multiple template locations, intended to let a site override selected files without replacing every theme template.
Verify precedence rules, default variable availability, caching and supported markup against the installed template engine before relying on these features in a new theme.
Release-specific rendering APIs
The historical Theme Developers Guide mentions COM_createHTMLDocument alongside the older COM_siteHeader / COM_siteFooter approach and references legacy configuration and compatibility scripts. Their exact lifecycle and supported signatures must be checked in the target Geeklog source. This guide intentionally does not reproduce older compatibility JavaScript or deprecated template-engine settings as modern requirements.
Practical theme change workflow
Use this workflow for a specific installed Geeklog release, rather than copying a template from an unrelated Wiki or theme version.
- Record the exact Geeklog version, active theme and enabled plugins. Keep an untouched copy of the original theme files.
- In a separate staging site, identify the template actually rendered by the page you want to change. Inspect the active theme and relevant plugin templates rather than assuming the homepage template controls all output.
- Make one small presentation-only edit, then reload the affected public page, an article, a plugin page and an authorized administration page.
- Verify HTML structure, mobile layout, keyboard focus, readable labels, links, image scaling and language-specific content where used.
- If the result is unexpected, restore the saved file before changing a second template. Compare the original and modified markup to isolate the difference.
- Repeat the same checks after upgrading the underlying theme or the Geeklog release.
What to avoid: editing a production theme without a backup, including secrets in templates, treating a hidden link as an authorization control, and disabling caching or security controls as an undocumented permanent workaround.
Troubleshooting a theme customization
| Symptom | Diagnostic starting point |
|---|---|
| Header or footer appears twice | Identify whether both the theme wrapper and the page/plugin output include a layout; check the actual rendering path |
| Page content overlaps side blocks | Inspect width, grid/flex rules, min-width, overflow and the markup generated by that specific theme |
| CSS changes are not visible | Check the requested stylesheet URL, browser cache and CSS cascade before editing PHP |
| Only plugin pages look different | Compare plugin-specific template locations, styles and loaded assets |
| Page works for administrators only | Verify anonymous page access and server-enforced permissions; presentation cannot grant authorization |
| Template shows raw variables | Confirm variable names and population in the current theme/API before copying old Wiki examples |
Do not infer Geeklog template-engine behavior from visual symptoms alone. If PHP or Core dispatch logic must change, record that as a separate engineering proposal, not a theme-only fix.
Extension points and upgrade safety
A theme can change markup and presentation; this is not the same as changing Geeklog's content model or plugin feature rights. Prefer documented extension points and maintain a clear inventory of modifications. If a new layout requires multiple columns within the main article body, first verify whether the desired structure belongs in the theme's overall page layout, in the article content itself, or in a plugin-rendered page.
For related topics, use the configuration reference for release-scoped theme settings, the plugin API guide when implementing functionality, and the security and permissions guide for server-side authorization.
Quality and security checks
- Test generated HTML and accessibility.
- Escape untrusted dynamic values at the correct output boundary.
- Verify that cached pages do not reveal personalized or administrative content.
- Check plugin templates, responsive layout, and upgrade behavior.
- Confirm theme rendering against the target release's code and shipped themes.
Source provenance: 2024-11-02 recovered Wiki pages Caching_Template_Library and Theme_Developers_Guide. Licensing and technical validation pending.