> I Had Codex Write a Summary Of The CI Code Base

You can paste below into a markdown viewer to get a clean read:

https://markdownlivepreview.com/

---

# Camp Idiot Codebase Notes

Camp Idiot is a heavily modified PunBB forum that started around 2002, then spent the next two decades absorbing local behavior, moderation hardening, UI experiments, application-specific features, and whatever else happened to be standing too close to the blast radius. The code has strong shytsmell: global state leaks through the walls, request bootstrapping has side effects with side effects, several generations of helper patterns are stacked on top of each other, and there are often three ways to do the same thing, two of which are wrong but load-bearing.

This repository is not a monument to architectural purity. It is a long-running containment vessel for a hostile anonymous/free-speech forum where bad actors keep showing up with bad ideas and the software has learned to hit back. The job is to keep it usable without accidentally removing some weird-looking anti-abuse behavior that was probably added at 2 AM after production caught fire.

## Runtime Assumptions

- PHP target: 7.4.x. Do not assume PHP 8 compatibility.
- Database: MySQL/MariaDB using both `mysqli` and PDO through `include/dblayer/mysqli.php`.
- Main app root: most root-level `*.php` files are request entry points.
- Legacy UI: PunBB-style PHP templates and procedural scripts.
- Modern UI: Twig-based pages under `modern/`, with page processors in PHP classes.
- Foto Dump: sub-application under `dump/`, using Smarty and its own config files, while also borrowing shared forum helpers.
- Vendored libraries/assets live in-tree: `twig/`, `dump/smarty/`, `svggraph/`, `zzz-*`.

Important: this repo currently contains committed configuration secrets in `config.php`, `dump/thumb.conf`, and related Foto Dump config files. Treat the repository as sensitive. Do not paste config values into issues, logs, docs, or prompts.

## High-Level Layout

- `include/common.php` is the legacy request bootstrap. It loads `include/functions.php`, reads `config.php`, connects to the DB, loads cached config, validates cookies, populates important globals, checks maintenance mode, checks bans for legacy requests, logs the request, updates online users, and extends cookies.
- `include/functions.php` is now mostly an include list for narrower helper files such as bans, flood control, preferences, settings, posts, topics, text parsing, security, logging, and legacy/modern interop.
- `bootStrapper.php` is the modern bootstrap. It defines `MODERN_BOOTSTRAP`, requires `include/common.php`, bulk-loads `include/functions*.php`, runs auto-registration, and creates the Twig environment.
- Root pages such as `viewtopic.php` and `viewforum.php` are UI dispatchers. They define `MODERN_UI_AVAILABLE`, run `bootStrapper.php`, then require either the `old/` page or the `modern/` page.
- `old/` contains legacy implementations for pages that have a dual UI version.
- `modern/` contains Twig templates and modern page processor scripts.
- `classes/` contains modern page infrastructure, parsing classes, helper classes, telemetry DTOs, and form modeling classes.
- `dump/` is Foto Dump. It uses Smarty templates and separate Foto Dump config, DB access helpers, upload/view/browse pages, and blob-backed image/doc storage.
- `tests/` contains browser-style PHP test pages. These are not a conventional PHPUnit suite.

## Request Bootstrapping

Most legacy pages follow this shape:

```php
define('PUN_ROOT', './');
require PUN_ROOT.'include/common.php';
```

That gives the script access to globals such as:

- `$db`
- `$pun_config`
- `$pun_user`
- `$userIsGuest`
- `$userIsAdmin`
- `$userIsMod`
- `$userIsAdminOrMod`
- `$useModernUI`
- `$useSafeMode`
- `$globalRequestId`

Modern-capable root pages follow this shape:

```php
define('MODERN_UI_AVAILABLE', true);
require './bootStrapper.php';
require getOldOrNewUIPageName(__FILE__);
```

The important consequence is that modern pages are not a clean separate application. Modern bootstrapping still runs legacy bootstrapping and shares the same globals, cookies, DB adapter, settings, permissions, and helper functions.

## Legacy vs Modern UI

UI routing is handled mainly by `include/functionsPhpHelpers.php` and `include/functionsLegacyModernInterop.php`.

`getOldOrNewUIPageName(__FILE__)` derives target filenames by convention:

- `viewtopic.php` can dispatch to `old/oldViewTopic.php`
- `viewtopic.php` can dispatch to `modern/modernViewTopic.php`
- `viewforum.php` can dispatch to `old/oldViewForum.php`
- `viewforum.php` can dispatch to `modern/modernViewForum.php`

The choice depends on:

- the current user's `useModernUI` preference
- page availability via `MODERN_UI_AVAILABLE`
- settings such as `{oldPageName}PageDisabled` and `{modernPageName}PageDisabled`

Modern page scripts generally define a `Modern...PageProcessor`, get a singleton processor with `getModernPageProcessor(__FILE__)`, and call `processPageRequestPipeline()`.

The modern pipeline in `classes/ModernPageProcessor.php` roughly does:

1. initialize `ModernPageContext`
2. page load hook
3. validate/populate ID
4. authorization
5. GET/POST validation
6. GET/POST processing
7. response headers
8. render Twig template
9. unload/end hooks

`ModernPageContext` copies a lot of data out of globals and config into an object, but the values still originate from the same legacy bootstrap and database.

## Database Access

The main DB adapter is `DBLayer` in `include/dblayer/mysqli.php`.

There are two main query styles:

- Old style: `$db->query('SELECT ... '.$db->prefix.'table ...')`, then `$db->fetch_assoc()`, `$db->result()`, etc.
- Safer newer style: `$db->querySafe($sql, $values)` and `$db->execSafe($sql, $values)`.

The safer methods use PDO prepared statements and support the `@dbp_` prefix placeholder:

```php
$db->querySafe("SELECT * FROM @dbp_users WHERE id = ?", array($id));
```

Prefer `querySafe`/`execSafe` for new work unless the surrounding code has a strong reason to stay in the old pattern. Some older code still builds SQL with concatenation; do not copy that pattern into new feature work.

One gotcha: `DBLayer::getPdoDB()` currently hard-codes the local database name in its connection string and relies on globals for credentials. This is part of the existing coupling and should be treated carefully before environment work.

## Authentication, Cookies, and Preferences

Cookie/user initialization lives mainly in `include/functionsCookie.php`.

`check_cookie()`:

- touches IP info
- defaults to guest user `id = 1`
- deserializes the PunBB cookie
- validates the cookie against user password hash and `cookie_seed`
- updates online/last-visit state
- creates or touches user preferences
- assigns `PreferenceKey`
- adds IP fields to `$pun_user`

Preferences are central to the app. They control UI selection, safe mode, Foto Dump page size, timezone behavior, and other user-specific behavior. Guests also rely on preference keys, which are used by trust, ban, and anti-abuse logic.

## Anti-Abuse, Moderation, and Security

This application has many layers of anti-abuse behavior. Assume any odd-looking logic may have production history behind it.

Notable areas:

- Bans: `include/functionsBan.php`
- Flood control: `include/functionsFloodControl.php`
- Censoring/text filtering: `include/functionsCensor.php`, `include/functionsText.php`, `include/functionsPostContent.php`
- IP/fingerprint/trust handling: `include/functionsIP.php`, `include/functionsFingerprint.php`, `include/functionsTier.php`
- Moderation workflows: `moderate.php`, `moderatePhone.php`, `deleteban.php`, `admin_bans.php`, `admin_cage.php`, `admin_censoring.php`
- Audit/logging: `include/functionsAudit.php`, `include/functionsLogging.php`

Ban logic can match on username, IP, password hash, preference key, email, and IP organization. There are bypass rules for registered users and guest trust tiers. `legacyCheckBans()` is called during legacy bootstrap when the modern UI page is disabled.

Flood control is data-driven from `vwFloodControlRules`. Rules cover actions such as creating posts, editing posts, creating users, reporting posts/photos, and Foto Dump activity. Remediation can include block, ban, cage, censor, and captcha-style flows.

## Foto Dump

Foto Dump lives under `dump/` and is a bolted-on sub-app, not a cleanly separated service.

Key points:

- Uses Smarty templates under `dump/*.tpl` and `dump/smarty/`.
- Uses Foto Dump config files such as `dump/thumb.conf`.
- Uses its own limited DB connection in some paths.
- Can create a full main forum DB connection via `setUpMainDbConnection()` in `dump/fotoFunctions.php`.
- Calls forum APIs/helpers for user ID, admin status, bans, trust level, preferences, settings, and flood control.
- Stores or serves images/docs through blob URLs configured in Foto Dump config.

Some Foto Dump pages require only selected shared helper files rather than full `include/common.php`.  In practice, Foto Dump and the forum are coupled through config, cookies/preference keys, shared DB tables, shared helper code, and API calls.

## Tests

The `tests/` directory contains PHP pages such as:

- `testFloodControl.php`
- `testPagination.php`
- `testBan.php`
- `testTrustScore.php`
- `testModern.php`
- `testText.php`

These are not normal automated tests. Most require the application bootstrap, a database, and manual enabling of `$emitMessages = true` to display results. They are still useful as executable documentation for behavior, especially around flood control, parsing, trust, pagination, and bans.

Before changing sensitive behavior, inspect whether a matching test page exists. If practical, add a focused case there or create a small test page following the same local pattern.

## Development Guidance

- Read the local code path before changing it. Similar features may exist in legacy, modern, Foto Dump, and API forms.
- Prefer small changes with narrow blast radius.
- Preserve globals unless you are deliberately isolating a small helper. Many pages depend on them implicitly.
- Prefer `querySafe`/`execSafe` with placeholders for new database work.
- Keep PHP 7.4 compatibility. Avoid PHP 8-only syntax and behavior.
- Do not assume modern UI is active. A feature may need legacy, modern, or both.
- Do not assume guests are simple anonymous users. Guest preference keys, trust tiers, IP info, cookies, safe mode, and flood rules all matter.
- Be careful with ban/flood/censor/moderation code. These are security and abuse-control surfaces.
- Avoid broad refactors during feature work. Mild refactors are safest when they are local, behavior-preserving, and covered by existing behavior checks.
- Do not move vendored libraries or generated assets unless the task explicitly requires it.
- Treat config files as secret-bearing files.

## Useful Starting Points

For page behavior:

- `index.php`
- `viewtopic.php`
- `viewforum.php`
- `post.php`
- `edit.php`
- `delete.php`
- `header.php`
- `footer.php`

For shared behavior:

- `include/common.php`
- `bootStrapper.php`
- `include/functions.php`
- `include/functionsPhpHelpers.php`
- `include/functionsLegacyModernInterop.php`
- `classes/ModernPageProcessor.php`
- `classes/ModernPageContext.php`

For abuse controls:

- `include/functionsBan.php`
- `include/functionsFloodControl.php`
- `include/functionsSecurity.php`
- `include/functionsCookie.php`
- `include/functionsPreference.php`
- `include/functionsAudit.php`

For Foto Dump:

- `dump/fotoFunctions.php`
- `dump/view.php`
- `dump/thumb.conf`
- `dump/*.tpl`

## Current Mental Model

This is best understood as one shared PHP process model with three presentation/application layers:

1. legacy PunBB pages
2. modern Twig pages layered on top of the legacy bootstrap
3. Foto Dump, which looks separate but still shares authentication, configuration, database, helper code, and API behavior

The safest way to add features is to identify the exact entry point, trace its bootstrap path, locate the relevant helper family, and make the smallest behavior-preserving change that fits the existing page's UI generation style.