Skip directly to page content
b13 GmbH

Hauptstätter Str. 59
70178 Stuttgart
Germany
+49 (0) 711 460 589 70 [email protected]
Black icon featuring a stylized letter "A" with sparkles, set against a light blue and green abstract background.

Documentation

TYPO3 Extension “VG Wort Pro”
Version 0.10.0 (2026-09-19)

Install

composer require b13/vgwort-pro

This pulls in b13/vgwort, which holds the pixel field and renders it in the frontend. typo3/cms-dashboard is optional: with it you get the VG Wort Status widget, without it the widget is simply not registered and nothing else changes.

Run the database schema update afterwards—the extension adds four tables and several columns on pages:

vendor/bin/typo3 extension:setup

Include the site set

In your site package’s config.yaml:

dependencies:
  - b13/vgwort-pro

The Pro set includes the free one, so you do not list both.

Without this the extension does nothing visible. The site set is what shows the VG Wort fields in page properties and what delivers the pixel in the frontend.

Credentials

The API is off until you turn it on, per site, in config/sites/<identifier>/settings.yaml:

settings:
  vgwort:
    api:
      enabled: true
      username: '%env(VGWORT_USERNAME)%'
      password: '%env(VGWORT_PASSWORD)%'
      testMode: true

These are your T.O.M. portal credentials. Keep them out of version control by reading them from the environment, as above—in DDEV via .ddev/.env, in production via the server environment or a .env file.

Every setting, including what to do when several sites use different VG Wort accounts, is in Configuration.

Not every account can use the API. A publisher account (Verlag) has webservice access by default. A personal account (Urheber) has to request Optionale Zusatzfunktionen in the T.O.M. portal first. Without it, credentials are correct and every call still fails.

Smoke test

Open Web > VG Wort, pick a page inside the site, and look at the pool statistics. If the module names the site and shows a pool of zero, the set is included and the module sees the site.

Production Checklist

Walk this before you report the first text. Every line here is something that looks fine until money is missing.

  • testMode is false. Reports sent in test mode never reach the real account. Nothing in the backend distinguishes a test report from a real one afterwards.
  • A page actually delivers its pixel. View the source of a published page and find the pixel. A site package that defines page = PAGE in a sys_template replaces the page object after the site set added the pixel to it, and the pixel is gone on a page that otherwise looks perfectly normal. See How It Works.
  • The pixel is not behind a consent banner, or you have decided knowingly that it is. A pixel that renders after someone clicks "accept" counts a fraction of the accesses. See Privacy and Consent.
  • Pixels come from the pool, not from the field. Text registration needs the private code, and a pixel typed into the field by hand has none. Import the CSV or order through the API—see Pixel Pool.
  • Authors are verified. An unverified card number is refused by VG Wort at submission, one text at a time.
  • Permissions are granted to the editors who will do this work, or they will be able to prepare texts and not send them. See Backend Module.
  • The reporting deadline is in your calendar. Texts have to reach VG Wort by the Meldeschlusstermin; missing it costs a full year of payout for every text that was ready. The module shows the next date, but only to whoever opens it.

Upgrading from an existing setup

If the site already tracks with VG Wort through custom code or another extension:

  1. Install b13/vgwort-pro.
  2. Move the existing pixel codes into the tx_vgwort_pixel field on the page records.
  3. Switch frontend rendering to the site set and remove the old output, so the pixel is not delivered twice. Not to the free extension’s Fluid partial—see Configuration for why that one stops working the moment a text spans more than one page.
  4. Upload the CSV from VG Wort. Pages whose pixel matches an imported code are upgraded in place and gain the private code they need for reporting.
  5. Run the sync to read back what is already reported—see Syncing Registrations.