PRESS2PIXEL
Produktdocs

Dokumentation

press2pixel macht aus einer Website kampagnenfähige Social-Media-Assets. Diese Seite dokumentiert nur die App: Crawler, Markenextraktion, KI-Gruppierung, Template-Rendering und -Editor, Planer, Imports und Exports, Social-Integrationen, API, Persistenz, Auth und Deployment.

Demo buchen App öffnen
Start

Schnellstart

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
Nutze die gehostete App unter app.press2pixel.fun oder starte dieselbe Node/Electron-App lokal in der Entwicklung.
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, Import-/Export-Werkzeuge und Vollbild-Signage-Playlists.
  • Universelle Templates plus kundengebundene Signature-Templates, die nur bei passenden Hosts erscheinen.
  • Ein Template-Editor für JSON-Templates, Live-Vorschau und gespeicherte Custom Designs.
  • Ein Projekt-Planer, der kommende Background-Syncs und laufende Refreshes zeigt.
Die Template-Auswahl ist dynamisch: universelle Styles, kundengebundene Signatures und Custom Templates werden aus der aktiven App-Registry geladen, nicht aus einer festen öffentlichen Zahl.
Crawler

Website-Datenerfassung

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.
  • Gerenderte DOM-Bilder, srcset-Kandidaten, Lazy Images, Inline-Backgrounds und berechnete CSS-Background-Images werden vor dem Scoring extrahiert.
  • Medienkandidaten werden bewertet, damit Hero-, Cover- und seitennahe Bilder besser ranken als Icons, Thumbnails und generische Logos.
POST /api/crawl/:urlId
  -> 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. URL-Workspaces, Content, Kampagnen, Sync-Status, Auth, Captions, Provider-Status, Templates, Logs und Config-Routen kommen alle aus der Node-App.

  • POST /api/crawl/:urlId startet die komplette Sync-Pipeline für einen gespeicherten URL-Workspace.
  • GET /api/urls, /api/content/:urlId und /api/campaigns/:urlId 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.
  • GET /api/sync-schedule versorgt Task Manager und Projekt-Planer-Kalender.
  • Auth-, OAuth-, Settings-, Provider-, Custom-Template-, Social-Import-, Token-, Log- und System-Stats-Routen versorgen die App-Shell.
GET    /api/urls
POST   /api/urls
POST   /api/crawl/:urlId
GET    /api/content/:urlId
GET    /api/campaigns/:urlId
POST   /api/captions/generate
POST   /api/social/import
GET    /api/sync-schedule
GET    /api/events
Daten

Inhaltsmodell und Speicher

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.

  • urls speichert kanonische URL, Anzeigename, Corporate-Identity-JSON, Design-Preset-JSON, Spracheinstellungen, per-URL Crawl-Limit 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 URL-Workspace.
  • crawl_cache hält gecachte Seiten mit sechs Stunden TTL.
  • sync_log dokumentiert Start/Ende, Status, Item-Zahlen und Fehler.
  • Custom Templates, OAuth-Tokens, Kontakte, Socials, Logs und Provider-Metadaten liegen in eigenen Tabellen.
content {
  id_unique,
  url_id,
  type,
  title,
  excerpt,
  imageUrl,
  image_alts,
  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.
  • Der In-App-Template-Editor kann Custom-JSON-Templates mit Live-Vorschau und Validierung erstellen und aktualisieren.
  • 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.
  • Element-Toggles und Text-Overrides erlauben Anpassungen pro Post oder Template, ohne den ganzen Workspace zu ändern.
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 Hintergrund-Syncs aus und überspringt URL-Workspaces, die kürzlich synchronisiert wurden.
  • Production-Sync-Jobs schreiben direkt nach MariaDB/MySQL, wenn DB_DRIVER auf die Production-Datenbank zeigt.
DB_DRIVER=sqlite
# oder
DB_DRIVER=mariadb
DB_HOST=127.0.0.1
DB_NAME=press2pixel
Betrieb

Bereitstellung 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.
  • Electron-Packaging kann dieselbe Express-App lokal für Desktop-Nutzung starten.
docker compose up -d
docker compose exec ollama ollama pull gemma4:26b
Sicherheit

Auth, Datenschutz und Sicherheitsnotizen

Die App enthält Session-Authentifizierung, optionale OAuth-Provider, owner-gebundenen URL-Zugriff und Admin-Bootstrap. Öffentliche Deployments sollten Auth mit HTTPS, Rate Limits, sicheren Headern und klaren Crawl-Grenzen kombinieren.

  • 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.
  • Social Imports können aktuelle Posts verbundener Provider in dasselbe Content-Modell holen wie gecrawlte Website-Inhalte.
  • 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

Qualitätskontrollen und Roadmap

Die App enthält automatisierte Tests, Template-Audits, Sync-Logs, Provider-Status, Token-Tracking und einen Task Manager für Laufzeitdiagnose.

  • npm test führt den Template-Audit aus und validiert aktive Template-JSONs, Renderer-Tokens, Image Controls, Conditionals und Customer-Host-Coverage.
  • Laufzeitdiagnose zeigt Sync-Fortschritt, aktuelle Logs, Provider-Status, Token-Nutzung, geplante Refreshes und Host-Ressourcen.
  • Template-Audits validieren aktive JSON-Dateien, erforderliche Renderer-Tokens, Image Controls, Conditionals und Host-Einschränkungen.
  • Unit-Tests decken Auth-Logik, Datenbankmigration, Template-Validierung, Renderer-Interpolation, Token-Tracking und Provider-Konfiguration ab.
npm run test:unit
npm run test:audit
npm test
Für Implementierungsdetails hält die App eigene Dokumente zu API-Verhalten, KI-Routing, Datenbanktreibern, Docker-Deployment, Auth und Templates bereit.