PRESS2PIXEL
Produktdocs

Dokumentation

press2pixel macht aus einer brauchbaren Website kampagnenfähige Social-Media-Assets. Diese Seite dokumentiert die echte App hinter der Landingpage: Crawler, Markenextraktion, KI-Gruppierung, Template-Rendering, Export, Persistenz und Deployment.

Demo buchen App öffnen
Start

Quick Start

Starte die App, füge eine Website-URL ein und lass den Server einen wiederverwendbaren Kunden-Workspace bauen. Der erste Crawl legt Datenbankzeilen, Corporate-Identity-Kontext, Kampagnen und Live-Previews an.

  • Installiere Abhängigkeiten mit npm install und starte den Express-Server mit npm start.
  • Öffne http://localhost:3000 oder den konfigurierten Reverse-Proxy-Host.
  • Füge eine Domain ein. press2pixel löst Weiterleitungen auf, extrahiert Markensignale, crawlt Inhalte, gruppiert Kampagnen und speichert das Ergebnis.
  • Nach einem Refresh bleiben Kunde, Template-Auswahl, Captions und Design-Einstellungen über SQLite und localStorage erhalten.
npm install
npm start
# http://localhost:3000 öffnen
Die App läuft unter app.press2pixel.fun. Die Landingpage wird getrennt unter press2pixel.fun ausgeliefert; deshalb werden alle Landing-Assets nach landing/dist kopiert.
Ergebnis

Was die App baut

Das Produkt ist ein Bulk-Generator für Social-Media-Assets. Es verwandelt Beiträge, Seiten, Produkte, Events, Listings und andere strukturierte Inhalte in gebrandete Bildsets und passende Captions.

  • Kampagnenfähige PNG-Grafiken in praktischen Social-Media-Formaten.
  • Lazy generierte KI-Captions für Twitter/X, Instagram und LinkedIn, gespeichert pro Content-Zeile.
  • ZIP-Exporte und Vollbild-Signage-Playlists.
  • Universelle Templates plus kundengebundene Signature-Templates, die nur bei passenden Hosts erscheinen.
Die aktuelle App enthält 101 aktive Templates: 36 universelle Styles und 65 kundengebundene Brand-Signatures.
Crawler

Website-Ingestion-Pipeline

Crawling läuft serverseitig, damit der Browser rein präsentational bleibt und keine CORS-Probleme bekommt. Der Crawler versucht zuerst strukturierte Quellen und ergänzt sie danach über Sitemap-basierte Seitenauswertung.

  • resolveCanonical folgt http/https-Weiterleitungen und normalisiert den Kunden-Host.
  • extractCI sammelt Logo, Markenfarbe, Fonts, Sprache, Hero-Bild, Social Handles und Kontakt-Signale.
  • WordPress REST und Shopify JSON werden gelesen, wenn sie verfügbar sind.
  • sitemap.xml, robots-Sitemap-Einträge, llms.txt, JSON-LD, Open Graph und gerendertes SPA-HTML schließen Lücken.
  • Medienkandidaten werden bewertet, damit Hero-, Cover- und seitennahe Bilder besser ranken als Icons, Thumbnails und generische Logos.
POST /api/crawl/:customerUrl
  -> resolveCanonical()
  -> extractCI()
  -> wpScrape() / shopifyScrape()
  -> discoverUrls()
  -> extractFromPage()
  -> groupItems()
  -> persist
JavaScript-lastige Seiten können mit Playwright gerendert werden, wenn statisches HTML wie eine leere Hydration-Shell aussieht.
Backend

API-Oberfläche

Das Frontend spricht mit einer kompakten Express-API. Kunden-, Content-, Kampagnen-, Sync-, Auth-, Caption-, Provider-Status- und Config-Routen kommen alle aus der Node-App.

  • POST /api/crawl/:customerUrl startet die komplette Sync-Pipeline.
  • GET /api/customers, /api/content/:customerUrl und /api/campaigns/:customerUrl hydratisieren den Workspace.
  • POST /api/captions/generate schreibt generierte Caption-JSONs zurück nach content.captions.
  • GET /api/events streamt Sync-Updates per Server-Sent Events.
  • Auth-Routen sind verfügbar, sobald AUTH_ENABLED true ist.
GET  /api/customers
POST /api/crawl/:customerUrl
GET  /api/content/:customerUrl
GET  /api/campaigns/:customerUrl
POST /api/captions/generate
GET  /api/events
Daten

Content-Modell und Storage

Jeder gefundene Inhalt wird normalisiert, bevor er in die UI geht. Ein stabiler id_unique-Schlüssel dedupliziert Inhalte über Syncs hinweg; raw_json hält genug Quelldetails für Medienreparatur und Diagnose.

  • customers speichert URL, Anzeigename, Corporate-Identity-JSON, Preset-JSON, Owner und letzten Sync-Zeitpunkt.
  • content speichert title, excerpt, imageUrl, date, type, source_url, raw_json, campaign_id und captions.
  • campaigns speichert KI- oder Heuristik-Gruppen pro Kunde.
  • crawl_cache hält gecachte Seiten mit sechs Stunden TTL.
  • sync_log dokumentiert Start/Ende, Status, Item-Zahlen und Fehler.
content {
  id_unique,
  customer_url,
  type,
  title,
  excerpt,
  imageUrl,
  source_url,
  campaign_id,
  captions
}
KI

KI-Routing, Gruppierung und Captions

KI läuft über lokales Ollama oder Command-Line-Provider statt über Browser-Direktaufrufe. Jede Aufgabe hat eine eigene Provider-Kette, Modell-Einstellungen, Fallbacks und Herkunftsangaben.

  • Kampagnen-Gruppierung läuft local-first über Ollama, mit deterministischem Taxonomie-Fallback.
  • Caption-Generierung nutzt eine Server-Route, speichert Provider-/Modell-Metadaten und verwendet gespeicherte Captions beim Export erneut.
  • Template- und Vision-Generierung kann je nach Task-Kette Gemini, Claude, Codex, MLX oder Ollama nutzen.
  • Rate-Limit-Status und Token-Verbrauch werden erfasst, damit vorübergehend blockierte Provider übersprungen werden.
CAPTION_PROVIDERS=claude,gemini
GROUPING_PROVIDERS=ollama,gemini,claude
OLLAMA_URL=http://localhost:11434
OLLAMA_MODEL=gemma4:26b
Captions werden in der Sprache des Quellinhalts generiert, soweit das Modell sie erkennen kann.
Renderer

Templates und Designkontrollen

Templates sind JSON-Dateien, die vom Frontend gerendert werden. Die App trennt Template-Markup von App-Logik und nutzt einen strikten Root-Token-Vertrag, damit jedes Design dieselben Controls respektiert.

  • Neue Templates liegen unter assets/json/templates und werden über index.json aktiviert.
  • Template-Variablen decken Titel, Auszug, Bild, Markenfarben, Typografie, Spacing, Schatten, Flächen und Ratio-Verhalten ab.
  • Schriftgrößen nutzen em-Einheiten, damit getrennte Headline- und Body-Slider zuverlässig skalieren.
  • Image Fit und Position sind über object-fit und object-position gebunden.
  • Brand-Templates nutzen customerHosts und erscheinen nur bei passender Kundendomain.
font-size:100%;--p2p-headline-mul:{{headlineScale}};--p2p-text-mul:{{textScale}}
Der gemeinsame template-base.css-Vertrag hält neue Templates konsistent, lässt aber ausdrucksstarke Brand-Signatures zu.
Persistenz

Datenbank, Backups und Sync

Die App nutzt eine kleine Datenbank-Fassade. SQLite ist Standard; MariaDB/MySQL kann über DB_DRIVER gewählt werden, ohne den restlichen Code zu ändern.

  • scripts/db/index.js stellt run, all, get und migrate für alle Module bereit.
  • Migrationen sind idempotent und erzeugen beim Booten das Schema des aktiven Drivers.
  • npm run db:backup exportiert JSONL-Tabellensnapshots und kann sie später importieren.
  • npm run db:sync kopiert Daten zwischen SQLite und MariaDB/MySQL.
  • node-cron führt stündliche Hintergrund-Syncs aus und überspringt kürzlich synchronisierte Kunden.
DB_DRIVER=sqlite
# oder
DB_DRIVER=mariadb
DB_HOST=127.0.0.1
DB_NAME=press2pixel
Ops

Deployment mit Docker oder Reverse Proxy

Die App kann direkt mit Node oder über Docker Compose laufen. Ein Produktionsproxy sollte jede App-Anfrage an Node weiterleiten, weil der Server API-Routen und View-Komposition besitzt.

  • docker compose up -d startet App und Ollama-Sidecar.
  • BYO-Ollama-Setups können OLLAMA_URL auf Host oder Container zeigen lassen.
  • Nginx- und Apache-Beispiele proxien alle App-Routen an http://127.0.0.1:3000.
  • Das Produktionsimage enthält bewusst kein Playwright/Chromium und keine Cloud-CLIs, außer ein Custom Image ergänzt sie.
  • Die öffentliche Landingpage ist ein statischer Build und hängt nicht vom App-Server ab.
docker compose up -d
docker compose exec ollama ollama pull gemma4:26b
Security

Auth, Datenschutz und Sicherheitsnotizen

Authentifizierung ist vorhanden, in den aktuellen App-Docs aber optional. Sobald die App öffentlich erreichbar ist, sollten Auth, HTTPS, Rate Limits und Crawl-Grenzen zusammen aktiviert werden.

  • AUTH_ENABLED=true aktiviert Login-Gate und sessiongeschützte API-Routen.
  • Passwörter nutzen scrypt, Sessions liegen als undurchsichtige HttpOnly-Cookie-Tokens vor.
  • OAuth-Buttons erscheinen nur, wenn Provider Client IDs und Secrets konfiguriert sind.
  • Offene Registrierung sollte vor breiter Veröffentlichung durch Freigabe oder Invite-Codes ersetzt werden.
  • Public Deploy sollte HTTPS erzwingen und Crawl-, KI-, Login- und Register-Routen limitieren.
AUTH_ENABLED=true
ADMIN_EMAIL=info@example.com
ADMIN_PASSWORD=change-me
Roadmap

Quality Gates und Roadmap

Die App hat bereits einen strikten Template-Audit und einen praktischen Open-Source-Backlog. Die nächste Qualitätsarbeit betrifft vor allem Public-Deploy-Härtung, Tests, Modularisierung und Brand-Polish.

  • npm test führt den Template-Audit aus und validiert aktive Template-JSONs, Renderer-Tokens, Image Controls, Conditionals und Customer-Host-Coverage.
  • Wichtige Deploy-Arbeit umfasst Auth-Defaults, Rate Limiting, HTTPS-Erzwingung, sichere Header und Cleanup alter Scripts.
  • Produkt-Roadmap: Desktop-Paket, Template-Editing, Per-Item-Image-Picking, Stock-Foto-Integration und stärkere Visual-Audits über mehr Ratios.
  • UI-Roadmap: bessere Empty States, Toasts, Shortcuts, Bulk-Kunden-Workflows und Mobile-Verifikation.
npm run test:unit
npm run test:audit
npm test
Die Landingpage-Dokumentation fasst die App-Docs bewusst zusammen, ersetzt sie aber nicht; die Markdown-Dateien im Repo bleiben die Implementierungsquelle.