
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.
-
testModeisfalse. 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 = PAGEin asys_templatereplaces 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:
- Install
b13/vgwort-pro. - Move the existing pixel codes into the
tx_vgwort_pixelfield on the page records. - 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.
- 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.
- Run the sync to read back what is already reported—see Syncing Registrations.
Installation