New Semantics

Deutsch

English

Deutsch

English

Theme

Verzeichnisstruktur ​

New Semantics ist ein Monorepo — PHP-Backend, Nuxt-Frontend, Migrations, CLI-Tools und Docs liegen in einem einzigen Checkout. Dieser Abschnitt erklaert, was in welchem Ordner steckt und wo entwickelt wird.

Top-Level ​

New Semantics/
├── index.php                 # Entry-Point — Routing via .htaccess
├── .htaccess                 # URL-Rewriting (/{view}/{item}/{child}/{value}/{add})
├── config.php                # Versionierte System-Konfig (systemVersion, pw_salt)
├── config.local.php          # DB + Update-Credentials (git-ignored)
├── config.local.example.php  # Template fuer neue Installationen
├── robots.txt
├── sitemap.xml               # Generiert (Scheduled Task)
│
├── _core/                    # Framework-Core (PHP)
├── _public/                  # Plugins / Extensions
├── _theme/                   # Nuxt-Frontend-Themes
├── _migrations/              # SQL-Migrationen
├── _templates/               # Legacy-Smarty-Templates (Transition)
├── _bin/                     # Ad-hoc PHP-Scripts (Imports, Cleanup)
├── console/                  # CLI-Runner fuer Cron-Tasks
├── include/                  # PHP-Hilfsfunktionen (DB, Auth, URL)
├── websocket/                # Node.js-WebSocket-Server (Express + Socket.io)
├── media/                    # User-Uploads (Bilder, PDFs, Videos)
├── docs/                     # Diese VitePress-Dokumentation
│
├── tmp/                      # Runtime-Ordner (siehe "Laufzeit-Ordner" unten)
├── templates_c/
├── var/
├── z_uploads/
└── z_legacy_migration.php

Unterstrich-Prefix

Ordner mit _-Prefix sind interne Buckets (Framework, Plugins, Themes, Migrations). Alles ohne Prefix ist entweder Entry-Point oder Laufzeit-Ordner.

_core/ — Framework-Core ​

_core/
├── libs/                     # Vendored PHP-Libs (ohne Composer)
└── system/
    ├── admin/controller/     # Admin-Controller (Language, Modal, Install)
    ├── api/                  # apiBaseController, apiBaseModel, PageService, RateLimiter
    ├── auth/                 # Session-Handling, 2FA, Fail2Ban
    ├── base/                 # Shared Base-Classes (z. B. Encryption)
    ├── cron/                 # TaskRunner, QueueWorker
    ├── migration/            # MigrationRunner
    └── webhook/              # WebhookDispatcher, WebhookDeliveryWorker

Der Core bietet die Baukloetze — Plugins erweitern ihn, modifizieren ihn aber nie direkt.

  • API-Routing: _core/system/api/apiBaseController.php ist der Einstiegspunkt fuer /api/*
  • Plugin-Registrierung: alle Plugins extenden install_controller aus _core/system/admin/controller/
  • Sessions: IP-gebunden, in der DB gespiegelt (Recovery nach GC)

Siehe Plugins › Plugin-Anatomie fuer das Zusammenspiel mit Core-Klassen.

_public/ — Plugin-Verzeichnis ​

_public/
├── extensions/
│   └── core/
│       └── backend/          # Backend-Plugins (insgesamt 42)
│           ├── demoAPI/      # Haupt-API-Hub (Auth, Pages, Settings, User, Webhook, ...)
│           ├── pagebuilder/  # Visual Page Builder
│           ├── shop/         # Shop + Widgets + Checkout (eigene api/)
│           ├── elearning/    # CME-Fortbildung (eigene api/)
│           ├── menueditor/   # Visual Menu Editor (eigene api/)
│           ├── ai/           # Multi-Provider AI-Plugin (eigene api/)
│           ├── abtesting/
│           ├── shopware6/    # Headless SW6 Integration (eigene api/)
│           ├── elasticsearch/
│           ├── emailmarketing/
│           ├── redirects/
│           ├── updatemanager/
│           ├── taskmanager/
│           └── ... (30 weitere)
└── src/                      # Shared Assets (CSS/LESS inkl. css/frontend/menu.less, Fonts, Bilder, JS)

Jedes Plugin ist in sich geschlossen:

{plugin-name}/
├── bootstrap.php             # Registrierung (Content, Buttons, API, Webhooks)
├── layout/                   # Vue-Admin-Komponenten (index.vue, index_detail.vue)
├── script/                   # PHP-Action-Scripts
├── api/                      # (optional) eigene API-Models
├── widgets/                  # (optional) Pagebuilder-Widgets
└── migrations/               # (optional) plugin-eigene SQL-Migrationen

Details in Plugins › Plugin-Anatomie.

API-Routing: demoAPI + Plugin-eigene APIs ​

Ein Haupt-Hub buendelt viele Endpoints, aber Plugins mit umfangreicher API bringen ein eigenes api/-Verzeichnis mit und registrieren ihre Modelle in der eigenen bootstrap.php.

demoAPI (Haupt-Hub):

demoAPI/
└── api/
    ├── auth/model.php                # class auth
    ├── pages/model.php               # class pages
    ├── settings/model.php            # class settings
    ├── menu/model.php                # class menu
    ├── user/orders/model.php         # class user_orders
    ├── shop/cart/model.php           # class shop_cart
    ├── checkout/model.php            # class checkout
    ├── webhook/...
    └── backend/
        ├── auth/model.php            # class backend_auth
        ├── page/model.php            # class backend_page
        └── pagebuilder/model.php     # class backend_pagebuilder

Plugins mit eigener API (11 Stueck, zusaetzlich zum Hub):

elearning/api/elearning/my-courses/model.php   # class elearning_my_courses
shop/api/shop/...
menueditor/api/...
ai/api/backend/ai/model.php                    # class backend_ai
shopware6/api/...
elasticsearch/api/...
emailmarketing/api/...
abtesting/api/...
design/api/...
taskmanager/api/...
updatemanager/api/...

Klassen-Naming

Pfad-Segmente (inkl. Dashes) werden zu Unterstrichen — user/orders → class user_orders, elearning/my-courses → class elearning_my_courses. Siehe Plugins › API-Endpunkte.

_theme/ — Nuxt-Frontend ​

_theme/
├── vue-base/                 # Default-Theme (Nuxt 4)
├── base/                     # Shared Komponenten-Bausteine
├── projekt01/                # Projekt-spezifische Overrides (Beispiel)
├── custom/                   # Kunden-Anpassungen
└── backend/                  # Backend-spezifisches Asset-Bundle

Aktives Theme wird via NUXT_PUBLIC_THEME (in .env) gewaehlt — siehe Themes › Nuxt-Aliases.

vue-base/ ​

_theme/vue-base/
├── app/
│   ├── app.vue
│   ├── components/
│   │   ├── admin/            # NsModal, NsForm, NsTable, NsSelect, MediaManager, ...
│   │   └── pagebuilder/      # PagebuilderWidget/Row/Column (Frontend-Rendering)
│   ├── composables/          # useSeoHead, useSchemaOrg, useUserCenter, ...
│   ├── layouts/              # admin.vue, admin-login.vue, default.vue
│   ├── middleware/
│   ├── pages/                # File-based Routing (admin/[...slug].vue, [...slug].vue)
│   ├── plugins/              # admin-css, cookieconsent, ab-tracking, gsap-animations
│   ├── stores/               # Pinia (admin.ts, layout.ts, sw6Store.ts, ...)
│   ├── utils/
│   └── widgets/
├── public/
│   ├── backend/
│   │   ├── css/style.less           # Admin Light-Theme
│   │   └── css/style-darkmode.less  # Admin Dark-Theme
│   ├── css/
│   └── fonts/
├── server/
├── nuxt.config.ts
└── package.json

Wichtig:

  • Einzige Admin-Route: app/pages/admin/[...slug].vue — keine index.vue. Alle Plugin-Layouts werden via import.meta.glob dynamisch geladen
  • Komponenten-Konvention: Admin-Komponenten tragen das Ns-Prefix (NsModal, NsForm, …)

_migrations/ — Datenbank-Schema ​

_migrations/
├── core/                     # 001_baseline.sql, 002_add_sessions.sql, ...
├── plugins/                  # Plugin-Migrationen, die mit dem Core ausgeliefert werden
│   ├── shop/
│   ├── ai/
│   └── ...
└── changelogs/               # Version-Changelogs (Markdown, per Release)

Plugin-eigene Migrationen koennen zusaetzlich unter _public/extensions/core/backend/{plugin}/migrations/ liegen — der MigrationRunner scannt beide Quellen. Details in Plugins › Migrations.

include/ — PHP-Hilfsfunktionen ​

Legacy-Funktions-Bibliothek, die vor dem OOP-Refactor zentral war. Weiterhin produktiv im Einsatz:

include/
├── connect.php               # DB-Connection
├── mysql.php                 # query, fetch_assoc, fetch_all, num_rows,
│                             # insert_id, real_escape_string
├── rights.php                # ACL-Checks
├── translation_engine.php    # Multi-Language-Helpers
├── get_url.php               # URL-Builder
└── ...

insert_id statt last_insert_id

Das Projekt nutzt die Funktion insert_id() aus include/mysql.php — niemals last_insert_id() (existiert nicht).

console/ — CLI-Runner ​

console/
└── bin                       # Dispatcher — Subcommands siehe --help

Wichtige Commands:

bash
php console/bin scheduled-tasks --time-limit=540
php console/bin process-queue   --time-limit=55
php console/bin process-webhooks --time-limit=25
php console/bin list-tasks

Empfohlener Cronjob-Setup:

cron
*/10 * * * *  php /pfad/console/bin scheduled-tasks --time-limit=540
*   *   * * * php /pfad/console/bin process-queue   --time-limit=55
*   *   * * * php /pfad/console/bin process-webhooks --time-limit=25
*   *   * * * sleep 30 && php /pfad/console/bin process-webhooks --time-limit=25   # zweiter Lauf nach 30s (halbe Minute Taktung)

docs/ — Diese Dokumentation ​

docs/
├── .vitepress/
│   ├── config.ts             # Site-Meta, Nav, Sidebar
│   └── theme/
│       ├── index.ts
│       └── custom.css        # Brand-Farben (Electric Indigo #4F46E5)
├── api-reference/            # Scalar-Embed
├── getting-started/
├── plugins/
├── widgets/
├── themes/
├── public/
│   └── openapi.json          # Generierte OpenAPI-Spec
├── scripts/
│   └── build-openapi.sh      # Wrapper fuer swagger-php
├── index.md                  # Startseite
├── package.json
└── README.md

Build:

bash
cd docs
npm install
npm run dev              # http://localhost:5173
npm run build            # Output: docs/.vitepress/dist/
npm run build:openapi    # Regeneriert docs/public/openapi.json

Laufzeit-Ordner (nicht versioniert) ​

OrdnerInhalt
media/User-Uploads (Bilder, PDFs, Videos)
tmp/Temporaere Dateien (z. B. Deployment-Dumps)
templates_c/Smarty-Kompilate
var/Runtime-State (AI-Jobs, Queues, Locks)
z_uploads/Legacy-Upload-Ordner

Diese Verzeichnisse muessen auf dem Server beschreibbar sein, sind aber nicht Bestandteil des Git-Checkouts.

Siehe auch ​