No description
Legacy-API-Kunden mit Keys beider Altportale — vor allem connektar — senden jede Meldung an presseecho.de UND businessportal24.de. Weil die Firma ihr Portal vom User und die Meldung es von der Firma erbte, landeten beide Kopien im selben Portal, die zweite mit Slug-Suffix "-2". Verifiziert wurde das über die Token-Hashes gegen die Legacy-Datenbanken. Das Portal wird jetzt in fester Reihenfolge aufgelöst: expliziter portal-Parameter, sonst die aufgerufene Domain, sonst das Portal des Firmenprofils, zuletzt Portal::Both — genau der Default, den beide Spalten ohnehin tragen. Die Auflösung ist damit nicht-nullbar; vorher konnte sie null liefern, was als SQL-Fehler und damit als 500er beim Alt-Client gelandet wäre. Ein Update über die v1-API verschiebt eine bestehende Meldung ausschließlich über den expliziten Parameter, nie über die aufgerufene Domain. press-releases:fix-api-portal-duplicates repariert die Altdaten: Es findet Paare (gleicher User, Titel, Sprache und Portal, beide per API eingereicht, kurz nacheinander) und verschiebt die zweite Kopie samt ihrer exklusiven Firma ins jeweils andere Portal, mit neu vergebenem Slug. Web-Doppel-Submits ohne Status-Log source=api und Legacy-Sync-Daten mit gesetzter legacy_id werden geschont. Auf Live ausgeführt und verifiziert. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .agents/skills | ||
| .codex | ||
| .devcontainer | ||
| .github/workflows | ||
| _docs | ||
| app | ||
| bootstrap | ||
| config | ||
| database | ||
| dev | ||
| docs | ||
| lang | ||
| public | ||
| resources | ||
| routes | ||
| storage/debugbar | ||
| tests | ||
| .cursorrules | ||
| .editorconfig | ||
| .env.example | ||
| .gitattributes | ||
| .gitignore | ||
| .mcp.json | ||
| AGENTS.md | ||
| artisan | ||
| boost.json | ||
| CLAUDE.md | ||
| composer.json | ||
| composer.lock | ||
| docker-compose.yml | ||
| package-lock.json | ||
| package.json | ||
| phpstan-baseline.neon | ||
| phpstan.neon | ||
| phpunit.xml | ||
| pint.json | ||
| Readme.md | ||
| setup-new-asset-urls.sh | ||
| tailwind.portal.config.js | ||
| tailwind.web.config.js | ||
| vite | ||
| vite.config.js | ||
| vite.portal.config.js | ||
| vite.shared.js | ||
| vite.web.config.js | ||
Multi-Domain Laravel-Anwendung
Übersicht
Diese Laravel-Anwendung unterstützt verschiedene Domains mit unterschiedlichen Styles:
- Haupt-Website: https://pressekonto.test (lokal) / https://pressekonto.de (live) – Haupt-Portal Admin-Page
- APP_PRESSEECHO: https://presseecho.test
- APP_BUSINESSPORTAL: https://businessportal24.test
Installation
- Repository klonen
- Abhängigkeiten installieren:
composer install npm install - Umgebungsvariablen konfigurieren (siehe
.env.exampleundDOMAINS-CONFIG.md) - Laravel-Anwendung initialisieren:
php artisan key:generate php artisan migrate - Assets kompilieren:
npm run build npm run build:admin npm run build:web
Domain-Konfiguration
Die Domains werden über die .env-Datei konfiguriert. Für detaillierte Anweisungen siehe DOMAINS-CONFIG.md.
Lokaler Entwicklungsserver
php artisan serve
Asset-Kompilierung
Diese Anwendung verwendet Vite mit verschiedenen Konfigurationen:
- Hauptkompilierung:
npm run devodernpm run build - Admin-Assets:
npm run build:admin - Web-Assets:
npm run build:web
Domain-Simulation
Während der Entwicklung können Domains simuliert werden, ohne die Hosts-Datei zu bearbeiten:
- In der
.env-Datei:DEV_SIMULATE_DOMAIN=true - Gewünschte Domain angeben:
DEV_SIMULATED_DOMAIN=landing1.local
Favicons
Um Platzhalter-Favicons für alle konfigurierten Domains zu generieren:
php artisan domains:generate-favicons