xamxam/docs/SIMPLIFICATION.md

Website Structure Simplification

Problem Identified

The initial migration used the Standard PHP Package Skeleton, which is designed for reusable PHP packages/libraries (like Composer packages), not for websites.

This resulted in:

• ❌ Overcomplicated structure (var/, resources/, complex bootstrap)
• ❌ Unused directories (var/cache/, var/logs/, var/tmp/)
• ❌ Package-oriented naming (resources/views/)
• ❌ Unnecessary constants and helper functions

Solution: Simplified for Website

Removed

1. var/ directory - Completely unused, only needed for complex applications with:

   • Custom caching systems
   • Application-level logging
   • Temporary file processing

2. resources/ directory - Package-oriented name, renamed to simple includes/

3. Complex bootstrap - Removed unused constants:

   • VAR_ROOT, CACHE_ROOT, LOGS_ROOT
   • PUBLIC_ROOT, CONFIG_ROOT, RESOURCES_ROOT
   • view() helper function

Simplified Structure

posterg-website/
├── public/              # DocumentRoot (web-accessible) ✅
│   ├── index.php
│   ├── search.php
│   ├── memoire.php
│   ├── admin/
│   └── assets/
│
├── includes/            # Simple template includes ✅
│   ├── header.php
│   └── footer.php
│
├── config/              # Minimal configuration ✅
│   └── bootstrap.php    (simplified)
│
├── database/            # Database files (private)
│   └── test.db
│
├── lib/                 # PHP classes (private)
│   ├── Database.php
│   ├── RateLimit.php
│   └── cache/rate_limit/  (used by RateLimit)
│
├── vendor/              # Composer dependencies (private)
└── tests/               # Tests (private)

Simplified config/bootstrap.php

Before: 66 lines with many unused constants
After: 33 lines with only essentials

<?php
// Define application root
define('APP_ROOT', dirname(__DIR__));

// Database path
define('DATABASE_PATH', APP_ROOT . '/storage/test.db');

// Error reporting (dev vs production)
if (php_sapi_name() === 'cli-server') {
    error_reporting(E_ALL);
    ini_set('display_errors', '1');
} else {
    error_reporting(E_ALL);
    ini_set('display_errors', '0');
}

// Simple helper for templates
function include_template($name) {
    include APP_ROOT . '/includes/' . $name;
}

// Composer autoload
if (file_exists(APP_ROOT . '/vendor/autoload.php')) {
    require_once APP_ROOT . '/vendor/autoload.php';
}

Simplified PHP Files

Before:

require_once __DIR__ . '/../config/bootstrap.php';
require_once LIB_ROOT . '/Database.php';
view('header.php', ['pageTitle' => $title]);

After:

require_once __DIR__ . '/../config/bootstrap.php';
require_once APP_ROOT . '/lib/Database.php';
include APP_ROOT . '/includes/header.php';

Comparison: Package vs Website

Feature	PHP Package	PHP Website (this project)
Purpose	Reusable library	Single website
Structure	Complex (PSR-4, namespaces)	Simple (includes, classes)
Directories	src/, resources/, var/, bin/	public/, includes/, src/
Autoloading	PSR-4 namespaces	Simple require statements
Config	Complex bootstrap with many constants	Minimal bootstrap
Caching	var/cache/ with framework	Simple file-based if needed
Logging	var/logs/ with logger	PHP error_log

Benefits of Simplification

Before (Package-oriented)

• ❌ 66-line bootstrap file
• ❌ 10+ unused constants
• ❌ resources/views/ (confusing name)
• ❌ var/ directory (completely unused)
• ❌ Helper functions for simple includes
• ❌ Over-engineered for a simple website

After (Website-focused)

• ✅ 33-line bootstrap file (50% smaller)
• ✅ 2 essential constants (APP_ROOT, DATABASE_PATH)
• ✅ includes/ (clear, simple name)
• ✅ No unused directories
• ✅ Standard PHP include statements
• ✅ Appropriate for a PHP website

Security (Unchanged)

• ✅ Still uses public/ as DocumentRoot
• ✅ Database still outside web root
• ✅ Config still private
• ✅ All security improvements retained

Testing

All PHP files pass syntax check:

$ php -l config/bootstrap.php    # OK
$ php -l public/index.php        # OK
$ php -l public/search.php       # OK
$ php -l public/memoire.php      # OK
$ php -l public/admin/index.php  # OK

Start dev server:

$ just serve

When You WOULD Need var/

You would need a var/ directory if you were building:

• A framework (Laravel, Symfony)
• A CMS (WordPress, Drupal)
• An application with:
  • Template compilation/caching
  • Session storage
  • File upload processing
  • Application-level logging
  • Queue systems

For your thesis website: Not needed ✅

Conclusion

• ✅ Structure is now appropriate for a PHP website
• ✅ Removed package-oriented complexity
• ✅ Kept all security improvements (public/ directory)
• ✅ Simpler, cleaner, easier to maintain
• ✅ Still follows best practices (just the right ones)

The core improvement (public/ directory for security) remains intact, but now with a structure that fits a website, not a reusable package.