netslim-blog

netslim-blog est une application blog construite au-dessus de netslim-core.

Le dépôt fournit :

• le domaine métier Post ;
• un module applicatif Site qui intègre les briques transverses du core ;
• les templates, assets et points d’entrée HTTP du projet ;
• la configuration applicative (config/modules.php).

Dépendance vers netslim-core

Le projet consomme netig/netslim-core depuis le dépôt Git en HTTPS.

{
  "repositories": [
    {
      "type": "vcs",
      "url": "https://git.netig.net/netig/netslim-core.git"
    }
  ],
  "require": {
    "netig/netslim-core": "^0.3@dev"
  }
}

Démonstration des modules du core

L’application active et démontre les modules suivants :

• Identity pour l’authentification et l’autorisation fine ;
• Settings pour les réglages persistants du site ;
• AuditLog pour tracer les actions d’administration ;
• Notifications pour l’envoi et l’historique d’emails transactionnels ;
• Taxonomy pour la classification des contenus ;
• Media pour la médiathèque ;
• Post pour le domaine blog local.

Les pages d’administration transverses se trouvent sous :

• /admin
• /admin/settings
• /admin/audit-log
• /admin/notifications

Démarrage rapide

Local (PHP intégré + assets compilés localement)

composer install
composer frontend:install
composer frontend:build
cp .env.example .env
composer provision
composer start

Docker

cp .env.example .env
docker compose up -d --build
docker compose run --rm provision

Composition active

Le manifeste applicatif est défini dans config/modules.php.

Il active :

• KernelModule
• IdentityModule
• SettingsModule
• AuditLogModule
• NotificationsModule
• TaxonomyModule
• MediaModule
• SiteModule
• PostModule

Documentation

• docs/APPLICATION.md présente l’application livrée ;
• docs/ARCHITECTURE.md décrit la frontière entre le blog et netslim-core ;
• docs/DEVELOPMENT.md sert de guide quotidien ;
• docs/FRONTEND.md couvre Twig, SCSS et JavaScript ;
• docs/DEPLOYMENT.md couvre Docker et les répertoires persistants ;
• netslim-core/docs/PUBLIC_API.md reste la référence sur les points d’intégration stables du package partagé.

Les tests et scripts CLI initialisent explicitement les runtime paths du blog, de sorte que le core résolve toujours le manifest de modules et les répertoires persistants contre ce projet et non contre vendor/.