phpify

.dockerignore

@@ -0,0 +1,9 @@
+old/
+.git
+.gitignore
+node_modules
+vendor
+*.log
+.DS_Store
+.idea
+.vscode

.env

@@ -0,0 +1,5 @@
+# Environment example for Docker compose
+DB_ROOT_PASSWORD=rootpass
+DB_NAME=dopetrope
+DB_USER=dopetrope
+DB_PASSWORD=dopetrope123

.env.example

@@ -0,0 +1,5 @@
+# Environment example for Docker compose
+DB_ROOT_PASSWORD=rootpass
+DB_NAME=dopetrope
+DB_USER=dopetrope
+DB_PASSWORD=dopetrope123

.github/copilot-instructions.md

@@ -1,109 +1,84 @@
-# TWEAK Stake Pool Channel Website
-
-TWEAK SPC is a static HTML5/CSS/JavaScript website for a Cardano blockchain stakepool launchpad. Built on the "Dopetrope" template by HTML5 UP, it uses SASS for CSS compilation and deploys as a static site.
-
-**ALWAYS reference these instructions first and fallback to search or bash commands only when you encounter unexpected information that does not match the info here.**
-
-## Working Effectively
-
-### Bootstrap and Build
-- Install modern SASS globally: `npm install -g sass`
-- NEVER use `npm install` - node-sass dependency has compatibility issues with Node.js 20+
-- Compile SASS: `sass assets/sass/main.scss assets/css/main.css` 
-- SASS compilation takes ~1 second. No timeout needed.
-- SASS compilation produces deprecation warnings - this is normal and expected.
-
-### Run the Website
-- Serve locally: `python3 -m http.server 8000`
-- Server startup takes ~2 seconds. No timeout needed.
-- Access at: `http://localhost:8000`
-- Server runs until manually stopped (Ctrl+C or stop_bash command)
-- **NEVER CANCEL**: Keep server running during testing and validation
-
-### Project Structure
-```
-├── index.html              # Main homepage
-├── start.html              # Getting started page  
-├── channel/index.html      # Channel-specific homepage
-├── assets/
-│   ├── css/main.css       # Compiled CSS (generated)
-│   ├── sass/main.scss     # Source SASS files
-│   └── js/                # JavaScript files
-├── images/                # Static images
-├── .github/workflows/     # CI/CD pipeline (FTP deployment)
-└── package.json           # Node.js metadata (DO NOT USE)
-```
-
-## Validation
-
-### Manual Testing Requirements
-After making changes, ALWAYS validate by:
-1. Recompile SASS if you modified any SASS files: `sass assets/sass/main.scss assets/css/main.css`
-2. Start development server: `python3 -m http.server 8000`
-3. Open browser to `http://localhost:8000`
-4. Test navigation between pages:
-   - Click "Get Started" button → should navigate to start.html
-   - Navigate to `http://localhost:8000/channel/index.html` → should load channel page
-   - All navigation links should work without 404 errors
-5. Verify styling and layout are intact
-6. Check browser console for JavaScript errors
-7. Take screenshot of key pages to document changes
-
-### Build Validation
-- SASS compilation must complete without errors (warnings are acceptable)
-- Generated `assets/css/main.css` file should be updated with recent timestamp
-- All HTML pages should load without 404 errors for CSS/JS resources
-- Website should be fully functional in browser testing
-
-### Known Issues and Workarounds
-- `npm install` fails due to node-sass compatibility - use global sass instead
-- Some external fonts/CDN resources may be blocked - this is expected in testing environments
-- Channel directory uses relative paths that may need adjustment for assets
-
-## CI/CD Information
-- GitHub Actions workflow deploys via FTP to production server
-- Workflow triggers on push to main branch
-- No build step in CI - uses committed CSS files
-- Always commit compiled CSS changes along with SASS changes
-
-## Common Tasks
-
-### Add New Styles
-1. Edit SASS files in `assets/sass/`
-2. Recompile: `sass assets/sass/main.scss assets/css/main.css`
-3. Test changes with local server
-4. Commit both SASS and compiled CSS files
-
-### Add New Pages
-1. Create new HTML file based on existing page structure
-2. Update navigation links in existing pages
-3. Test all navigation paths
-4. Verify CSS/JS asset paths are correct
-
-### Debug Styling Issues
-1. Check browser developer tools console for errors
-2. Verify CSS file is being loaded and is recent
-3. Recompile SASS if changes aren't reflected
-4. Clear browser cache if needed
-
-## Repository Reference
-
-### Key Files (avoid modifying unless necessary)
-- `README.txt` - Original template documentation
-- `package.json` - Contains broken node-sass dependency
-- `.github/workflows/main.yml` - FTP deployment configuration
-- `assets/js/` - jQuery and template JavaScript files
-
-### SASS Color Variables
-```scss
-$color-connect: #d11141;    // Red
-$color-educate: #00b159;    // Green  
-$color-build: #00aedb;      // Blue
-$color-promote: #ffc425;    // Yellow
-$color-teal: #00aba9;       // Teal accent
-```
-
-### Navigation Structure
-- Main sections: POOLS, TEAMS, ABOUT
-- Secondary pages: Start, Mission, FAQ, Whitepaper
-- Channel section has duplicate structure with different content
+# Copilot Project Instructions
+
+Purpose: Give AI coding agents the minimal, project-specific context needed to make correct, maintainable changes quickly.
+
+## 1. High-Level Architecture
+- Origin: Static HTML5 UP "Dopetrope" template progressively converted to structured PHP + Twig.
+- Entry scripts: Legacy page entrypoints remain at project root (`index.php`, `blog.php`, `left-sidebar.php`, etc.). A future front controller is not yet implemented.
+- Templates: Central layout `templates/layouts/base.html.twig` plus `layouts/flexible.html.twig` for dynamic 0/1/2 sidebar pages. Page templates live under `templates/pages/`.
+- Blog system: Markdown-based posts (`blog/<post>/markdown.md`) parsed at request time by `App\Services\BlogContentService` using league/commonmark.
+- Services:
+  - `BlogContentService`: Front matter parsing, Markdown -> HTML, heading ID injection, TOC extraction, reading time, code block normalization.
+  - `TemplateService`: Initializes Twig, registers globals (site meta, navigation, language).
+  - `App\i18n\Language`: Lightweight singleton loading JSON translation files from `includes/i18n/translations/`.
+- A/B Variant: Blog post TOC placement (inline | left | right) controlled in `blog.php` via query param / cookie. Variants drive which sidebar (if any) renders.
+
+## 2. Data & Content Conventions
+- Blog post path pattern: `blog/<post>/markdown.md` (post folder name = URL `?post=<post>`).
+- Front matter: Simple YAML-like block delimited by `---` at top; only flat key:value pairs & bracket arrays `[a, b]`. Parser is custom—avoid advanced YAML features.
+- Supported metadata keys: `title`, `description`, `author`, `published`, `tags`, `seo.keywords` (flat key accepted as `seo: keywords: ...` is NOT parsed—only simple keys). Tags may be comma string or bracket array.
+- TOC: Extracted from rendered HTML headings h2–h6; IDs slugified. Do not introduce a second TOC generator without removing existing logic.
+
+## 3. Templating Patterns
+- Always extend `layouts/base.html.twig` or `layouts/flexible.html.twig` (for sidebar control). Never reintroduce duplicate `<head>` markup.
+- Core overridable blocks: `page_meta`, `page_styles`, `additional_css`, `page_scripts`, `content` (or `main_content` inside flexible layout), `sidebar_left`, `sidebar_right`.
+- Blog post template (`pages/blog-post.html.twig`) uses `main_content` plus conditional sidebar blocks; TOC component reused via `components/blog/_toc.html.twig`.
+- When adding a new sidebar-enabled page: extend `flexible.html.twig`; pass `sidebar_left` / `sidebar_right` vars or override the block(s). Layout computes responsive column widths automatically.
+
+## 4. Variant & Sidebar Logic (Important)
+- `blog.php` sets: `toc_variant`, `toc_html`, `sidebar_left`, `sidebar_right`.
+- Flexible layout only renders a sidebar column if the corresponding variable is non-empty. Ensure controller sets them when introducing new sidebar content.
+- If no TOC (no headings) variant is forcibly `inline` to avoid empty columns.
+
+## 5. Markdown & Security
+- Markdown rendered via league/commonmark with extensions: Core, TableOfContents (placeholder unused directly), HeadingPermalink, Autolink, DisallowedRawHtml.
+- Disallowed tags: `script, iframe, object, form`. Do not relax without review.
+- Additional raw HTML sanitization is minimal—keep disallowed list in sync if enabling richer embeds.
+
+## 6. Code Blocks & Highlighting
+- Post-processing adds `hljs` class to `<code>` inside `<pre>` if missing. Frontend highlight.js (GitHub Dark) initialized in `blog-post.html.twig` script block.
+- When adding languages: include new CDN language module in `page_scripts` block; no backend change required.
+
+## 7. i18n
+- Translation JSON per language under `includes/i18n/translations/<lang>.json`.
+- Access via Twig: `lang.get('site.name')` or global `site.*` (populated from translations). New keys must be added to all language files.
+- Language detection: `?lang=de` overrides session. Keep parameter name `lang` consistent.
+
+## 8. Navigation & Globals
+- Navigation structure hard-coded in `TemplateService::getNavigationStructure()`. Modify there for structural nav changes (ensures every template sees update).
+- Add new global values through `TemplateService::addGlobalVariables()`—avoid scattering repeated arrays across entry scripts.
+
+## 9. Build & Run Workflows
+- Local (PHP built-in) quick run (bypasses Twig cache differences): `php -S localhost:8000` (root directory) then `index.php` paths.
+- Docker stack (preferred):
+  - Start: `docker compose up -d --build`
+  - Rebuild PHP image after dependency changes: `docker compose build php && docker compose up -d`
+- Composer install/update: `php composer.phar install` (lock file present). Require new libs in `composer.json` + run install; keep PHP requirement (>=8.2).
+- Twig cache at `var/cache/twig`; clear manually when altering core layouts.
+
+## 10. Static Analysis / Quality
+- PHPStan included (`vendor/bin/phpstan`). No config file added yet—default level. If adding one, place at project root.
+- Follow `CODING-STANDARDS.md`; do not introduce strict_types yet unless coordinated.
+
+## 11. Adding Features Safely
+- Extend services rather than embedding logic in entry scripts; keep `blog.php` lean (controller-style orchestration only).
+- For new content types (e.g., docs), prefer mirroring blog structure in a new directory and reusing `BlogContentService` or extracting shared parsing.
+- Avoid duplicating TOC or heading logic—refactor into service if expanding.
+
+## 12. Common Pitfalls Recap
+- Missing sidebars: remember to set `sidebar_left` / `sidebar_right` context vars (truthy) or override blocks directly.
+- Double `<head>`: never re-include old header includes; always via base layout.
+- Incorrect TOC after edits: clear Twig cache if template block logic changes.
+- Adding nested front matter data: current parser does NOT support nested YAML—keep it flat.
+
+## 13. Example: Adding a FAQ Page With Right Sidebar
+1. Create `templates/pages/faq.html.twig` extending `layouts/flexible.html.twig`.
+2. In entry script/controller: build sidebar HTML (e.g., quick links) and pass as `sidebar_right`.
+3. Override `main_content` block only—no need to compute grid classes.
+
+## 14. When Unsure
+- Prefer reading existing blog post flow (`blog.php` + `BlogContentService` + `pages/blog-post.html.twig`) before adding similar dynamic features.
+- Keep changes minimal & composable; reuse component partials under `templates/components/`.
+
+---
+Feedback welcome: Clarify TOC/variant logic, Markdown limitations, or sidebar strategy if anything remains ambiguous.

.github/instructions/review-blog-post.instructions.md

@@ -0,0 +1,68 @@
+---
+applyTo: '**/blog/**/*.md'
+---
+# Review & Writing Instructions for Blog Posts
+
+## Goal
+
+Help the author produce **clear, educational, and engaging programming articles** that are technically accurate, accessible, and enjoyable to read.
+
+---
+
+## Review Dimensions
+
+1. **Clarity & Structure**
+
+   * Is the article logically structured (intro → explanation → examples → conclusion)?
+   * Are complex ideas broken down into digestible parts?
+   * Does the writing avoid unnecessary jargon?
+
+2. **Educational Value**
+
+   * Does the article teach a clear concept or skill?
+   * Are examples runnable, correct, and easy to follow?
+   * Are definitions or technical terms explained when first introduced?
+   * Are trade-offs, best practices, or pitfalls covered?
+
+3. **Engagement**
+
+   * Does the writing use analogies, visuals, or storytelling to make it memorable?
+   * Are there “hooks” (questions, surprising facts, small anecdotes) that pull the reader in?
+   * Is the tone friendly and motivating, not dry or overly academic?
+
+4. **Technical Accuracy**
+
+   * Are code snippets correct, idiomatic, and aligned with current best practices?
+   * Are explanations technically precise without misleading simplifications?
+   * Are references (docs, standards, papers) accurate and up to date?
+
+5. **Readability**
+
+   * Is the text concise (no fluff, no redundancy)?
+   * Is the formatting consistent (headings, lists, code blocks)?
+   * Is the language active and direct (avoid long-winded sentences)?
+
+---
+
+## Assistant Tasks
+
+When reviewing or helping draft content:
+
+* Suggest **improvements** (clarity, flow, depth, examples).
+* Highlight **missing perspectives** (pitfalls, trade-offs, alternatives).
+* Propose **more engaging phrasing** (hooks, analogies, rewording).
+* Verify **code correctness** and suggest more idiomatic solutions if needed.
+* Ensure the **reader takeaway** is obvious at the end of the post.
+
+---
+
+## Style Preferences
+
+* Use modern programming idioms and conventions.
+* Favor concise, information-dense paragraphs.
+* Prefer active voice over passive voice.
+* Encourage curiosity and exploration rather than giving only “final answers.”
+
+---
+
+👉 The assistant should act as a **critical co-author**: point out weaknesses, propose improvements, and strengthen the article until it’s both technically sound and enjoyable to read.

.gitignore

@@ -8,3 +8,13 @@
 images/ada.jpeg
 images/ada - Copy.jpeg
 images/ada01.jpeg
+
+# PHP / Composer
+vendor/
+var/
+docker/
+composer.phar
+*.cache
+*.log
+/.phpunit.result.cache
+/.php-cs-fixer.cache

CODING-STANDARDS.md

@@ -0,0 +1,64 @@
+# Coding Standards
+
+These lightweight standards guide ongoing PHP changes.
+
+## Target Runtime
+
+- PHP 8.2+
+- Nginx (reverse proxy) -> PHP-FPM upstream
+- UTF-8 everywhere
+
+## File & Directory
+
+- Use lowercase with hyphens for standalone scripts if added (e.g., `contact-form.php`).
+- Reusable logic should move toward `includes/` first; later can evolve into `src/` + autoload (Composer) if complexity grows.
+
+## PHP Style
+
+- Follow PSR-12 formatting style subset: 4 spaces indent, Unix line endings, `<?php` (no short tags), one class/function per file when introduced.
+- Strict types may be introduced later (`declare(strict_types=1);`) once a front controller is added.
+- Use meaningful variable names; avoid single letters (except for small loop indices).
+
+## Security & Escaping
+
+- Escape all untrusted output in HTML context with `htmlspecialchars($var, ENT_QUOTES, 'UTF-8')`.
+- Never trust `$_GET`, `$_POST`, `$_COOKIE`; sanitize/validate before use.
+- If forms are added: implement CSRF token (hidden input + session token comparison).
+- Avoid eval / dynamic includes.
+
+## Includes / Layout
+
+- Each page sets `$pageTitle` and `$bodyClass` before including `includes/header.php`.
+- Do not embed `<html>` or `<body>` again outside header/footer includes.
+
+## Arrays & Data
+
+- Prefer short array syntax: `[ 'key' => 'value' ]`.
+- When generating repeated sections (portfolio/blog), isolate the data structure at the top of the file or in a dedicated include for clarity.
+
+## Comments
+
+- Keep comments minimal and purposeful (why > what). The template HTML is self-descriptive; avoid duplicating markup intent.
+
+## Future Evolution Hooks
+
+- When introducing routing: one front controller file in project root or `public/`.
+- Add Composer when first external dependency is required (e.g., router, Twig).
+- Introduce `strict_types` after ensuring existing dynamic behavior is stable.
+
+## Git / Deployment
+
+- (Future) Ignore `old/` folder in deployments if no longer needed.
+- FTP deployment: only transfer `.php`, `assets/`, and required docs. Exclude local editor/project files.
+
+## Licensing / Attribution
+
+- Preserve original `LICENSE.txt` and attribution comments while template remains recognizable.
+
+## Performance
+
+- Defer premature optimization. Only add caching once dynamic content or heavier queries appear.
+
+## Accessibility
+
+- When modifying markup, retain semantic headings order and ensure `alt` attributes remain on images.