semantic-delivery — ein Inhalt, elf Distributoren.

Datenbank- und Seiten-Felder

Tabellen

Page-Felder

Der Plattform-Selector zeigt nur Plattformen, für die in der aktuellen Site Credentials hinterlegt sind. Redakteur:innen können so kein Ziel auswählen, das fehlschlagen würde.

Unterstützte Plattformen

Social Media (Short-Form)

Blog-Plattformen (Long-Form)

Blog-Distributoren setzen automatisch ein Canonical zurück auf die TYPO3-Originalseite. Hinweis: Medium gibt keine neuen API-Tokens mehr aus; der MediumDistributor wurde entfernt.

Proxy-Dienste

Setup

1. Distribution in den Site Settings aktivieren

semanticDelivery:
  channels:
    socialMedia:
      enabled: true
  distribution:
    enabled: true
    defaultDistributor: 'bluesky'

2. Plattform-Credentials konfigurieren

Credentials liegen pro Site in config/sites/<name>/config.yaml. Sensible Tokens nutzen die %secret()%-Syntax (siehe moselwal/secret-resolver), öffentliche Identifier landen direkt im YAML.

Nur Plattformen mit gefülltem Primär-Credential erscheinen im Backend-Editor. Plattformen ohne Credential sind ausgeblendet — fehlerhafte Auswahl ist somit ausgeschlossen.

3. Datenbankschema aktualisieren

vendor/bin/typo3 database:updateschema

4. Plattformen pro Seite auswählen

Im TYPO3-Backend hat jede Seite einen Tab Semantic Delivery:

1. Enable Distribution aktivieren
2. Zielplattformen auswählen (nur konfigurierte sind sichtbar)
3. Speichern und publizieren

Das Distributionssystem respektiert diese Auswahl — Seiten gehen nur an die markierten Plattformen.

CLI, Backend-Modul und Erweiterung

CLI-Befehle

# Neue Podcast-Episoden erkennen
vendor/bin/typo3 semantic-delivery:detect-episodes --dry-run
vendor/bin/typo3 semantic-delivery:detect-episodes
vendor/bin/typo3 semantic-delivery:detect-episodes --auto-publish

# Pending-Jobs verarbeiten
vendor/bin/typo3 semantic-delivery:process-jobs

Empfohlener Cron

*/15 * * * * cd /app && vendor/bin/typo3 semantic-delivery:detect-episodes
*/5  * * * * cd /app && vendor/bin/typo3 semantic-delivery:process-jobs

Backend-Modul

Verfügbar unter Content → Semantic Delivery (Admin-Zugriff):

• Preview — transformierter Inhalt pro Plattform vor Publikation
• Queue — Verwaltung wartender Distribution-Jobs
• Log — abgeschlossene und fehlgeschlagene Distributionen mit externen URLs

Eigenen Distributor ergänzen

1. Klasse anlegen, die DistributorInterface in Classes/Infrastructure/Distribution/ implementiert
2. Optional einen TransformerInterface in Classes/Infrastructure/Transformer/
3. Credential-Mapping in DistributionPlatformItemsProcFunc::CREDENTIAL_KEYS ergänzen
4. Site-Setting in settings.definitions.yaml und settings.yaml hinzufügen

Sobald Credentials hinterlegt sind, taucht die Plattform automatisch im Page-Editor auf. OAuth-Tokens werden über den OAuthTokenService verwaltet und at-rest mit AES-256-CBC unter dem TYPO3 Encryption Key verschlüsselt.

Schema.org-Resolver-Logik

Der SchemaTypeResolverService entscheidet pro Seite, ob ein Dokument der Article- oder WebPage-Familie ausgegeben wird. ArticleSchemaGenerator (Priority 50) und WebPageSchemaGenerator (Priority 45) delegieren beide ihr canHandle() an den Resolver, sodass nie beide Familien gleichzeitig erscheinen.

Auflösungs-Reihenfolge

1. Manueller Override über pages.tx_semanticdelivery_schema_type. Werte aus Article- oder WebPage-Familie werden direkt übernommen. Andere Werte (z. B. Product, FAQPage) lassen den Resolver null liefern, damit der zuständige Generator die Seite übernimmt.
2. Slug-Heuristik — nur sprachstabile Index-/Section-Patterns.
3. Hero-Content-Block-Hinweis — der erste passende CType gewinnt.
4. Keywords-Heuristik auf Basis von pages.keywords.
5. Default: Article bei Standardseiten (doktype 1 oder 2 mit Inhalten), sonst WebPage.

Sprachspezifische Patterns wie /kontakt, /ueber-uns, /about, /contact, /team, /profil werden bewusst nicht automatisch erkannt — hier setzen Sie den Override im Backend.

Slug-Heuristik

Hero-CType-Mapping

Keywords-Heuristik

Backend-Override-Dropdown

Das Page-Property-Dropdown ist via --div---Separatoren gruppiert; jede Option trägt einen Tooltip für das Backend.

• Auto (Erkennung über Slug, Hero-CB, Keywords)
• Article-Familie:Article, BlogPosting, NewsArticle, TechArticle, ScholarlyArticle, Report, SocialMediaPosting
• WebPage-Familie:WebPage, AboutPage, ContactPage, CollectionPage, ItemPage, ProfilePage, QAPage
• Other:FAQPage, Product, HowTo, Organization, LocalBusiness

Werte außerhalb der Article-/WebPage-Familien geben die Seite an den jeweils zuständigen Generator (FAQ, Product, Organization …) ab. Der Resolver liefert ebenfalls null, wenn die Seite FAQ-, Service-, Product-, Podcast- oder PackagesGrid-CTypes enthält oder unterhalb von /leistungen, /impressum, /datenschutz, /karriere oder /podcasts liegt.

Plattform-Setup-Guides

Schritt-für-Schritt-Einstieg pro Plattform. Sensible Tokens werden über %secret()% aufgelöst, öffentliche Identifier (Handle, Page-ID, Account-ID) stehen direkt in der YAML.

Bluesky

Auth: App Password. Token läuft nicht ab und kann jederzeit in den App-Passwords-Einstellungen widerrufen werden.

1. Auf bsky.app einloggen.
2. Settings → Privacy and Security → App Passwords öffnen.
3. Add App Password, Namen vergeben (z. B. „TYPO3 Distribution“).
4. Generiertes Passwort kopieren und unter semanticDelivery.social.bluesky.appPassword via %secret(BLUESKY_APP_PASSWORD)% referenzieren. Handle (z. B. yourhandle.bsky.social) direkt in YAML.

LinkedIn

Auth: OAuth 2.0 Access Token. Modi: w_member_social (privat) oder w_organization_social (Company Page). Tokens laufen nach 60 Tagen ab; Refresh manuell oder per OAuthTokenService.

1. Auf linkedin.com/developers/apps über Create app eine App anlegen, Company Page verknüpfen, Logo hochladen.
2. Im Reiter Products das Produkt Share on LinkedIn aktivieren.
3. Im Reiter Auth Client ID, Client Secret und Redirect URL hinterlegen.
4. Authorization-Code über www.linkedin.com/oauth/v2/authorization mit Scope openid profile w_member_social einholen.
5. Code per POST auf www.linkedin.com/oauth/v2/accessToken gegen Access- und Refresh-Token tauschen.
6. Person-ID per GET api.linkedin.com/v2/userinfo ermitteln (Feld sub).
7. Token, personId und optional organizationId in semanticDelivery.social.linkedin eintragen. Wenn beide gesetzt sind, hat organizationId Vorrang.

Detail-Doku im README.

X / Twitter

Auth: OAuth 2.0 Bearer Token. Scopes: tweet.read, tweet.write, users.read. Für tweet.write ist mindestens Basic-Access erforderlich.

1. Auf developer.x.com/en/portal ein Project und darin eine App anlegen.
2. Unter User authentication settings OAuth 2.0 aktivieren.
3. App-Permissions auf Read and write setzen.
4. Unter Keys and tokens einen Bearer Token erzeugen.
5. Token in semanticDelivery.social.twitter.bearerToken via %secret(TWITTER_BEARER_TOKEN)% hinterlegen.

Facebook

Auth: Long-Lived Page Access Token. Scopes: pages_manage_posts, pages_read_engagement.

1. Auf developers.facebook.com über Create App eine Business-App anlegen und das Produkt Facebook Login hinzufügen.
2. Im Graph API Explorer die App auswählen, Generate Access Token klicken und pages_manage_posts erteilen.
3. Im Dropdown User or Page die Ziel-Page wählen — das angezeigte Token ist nun ein Page-Token.
4. Token gegen Long-Lived-Token tauschen: GET graph.facebook.com/v21.0/oauth/access_token?grant_type=fb_exchange_token&client_id=APP_ID&client_secret=APP_SECRET&fb_exchange_token=SHORT_LIVED_TOKEN.
5. Page-ID via GET graph.facebook.com/v21.0/me/accounts auslesen.
6. accessToken und pageId unter semanticDelivery.social.facebook setzen.

Instagram

Auth: Instagram Graph API über Facebook-Page-Token. Scopes: instagram_basic, instagram_content_publish. Voraussetzung: Facebook-Page mit verknüpftem Instagram-Business- oder Creator-Konto. Reine Text-Posts werden von der Graph API nicht unterstützt.

1. Account-ID ermitteln: GET graph.facebook.com/v21.0/FACEBOOK_PAGE_ID?fields=instagram_business_account&access_token=PAGE_ACCESS_TOKEN.
2. instagram_business_account.id aus der Antwort als accountId übernehmen.
3. Page-Token (identisch zu Facebook) als accessToken in semanticDelivery.social.instagram eintragen.

Dev.to

Auth: API-Key, kein OAuth. Token läuft nicht ab. Posts werden als Markdown publiziert, kanonische URL zeigt zurück auf die TYPO3-Seite.

1. Auf dev.to einloggen.
2. Settings → Extensions öffnen.
3. Unter DEV Community API Keys einen neuen Key erzeugen und kopieren.
4. Key unter semanticDelivery.blogging.devto.apiKey via %secret(DEVTO_API_KEY)% hinterlegen.

Setzen wir ein bei …

Dieses Paket trägt die Multi-Channel-Distribution in AI-Ready CMS und AI-Ready Commerce. In der betreuten Variante läuft es als Teil von AI-Ready CMS as a Service.