Text Registration

Chapters of this Documentation

The workflow

Assign a pixel from the pool to the page.
Assign authors to the page.
Prepare—the text is extracted from the rendered frontend page and stored as a draft.
Review—optional: adjust the title, correct the extract.
Submit—the report goes to VG Wort.

Between 3 and 5 nothing is transmitted. After 5 nothing can be changed.

The text registration list with five texts side by side: one reported to VG Wort, one prepared over four pages and ready to send, one below the minimum length and without an author, one whose page did not deliver its counting pixel, and one whose second author is not yet verified.

What a text needs before it can be reported

A pixel from the pool. A code typed into the field has no private code and cannot be reported—see Pixel Pool.
At least one author, with a card number verified against VG Wort.
1,800 characters, counted with spaces over the whole text. For a bundled text, over all parts together.
API credentials for the site.
A page that actually delivers its pixel. This is checked, not assumed—see How It Works.

When to report

A text can be sent at any time. The API does not wait for the pixel to reach the minimum access count, and VG Wort says so plainly: "Werden die Zählmarken der VG WORT verwendet, kann eine Meldung zum jeweiligen Text umgehend erfolgen."

The reason to wait is a different one:

Eine Meldung ist aber auch in diesem Fall erst sinnvoll, wenn sich der Text des gemeldeten Artikels nicht mehr wesentlich ändert, da die VG WORT den gemeldeten Text mit dem Text, der sich tatsächlich im Internet befindet, vergleicht.

So: report a text once it has stopped changing. A documentation page that is still growing is the case to wait on, because the report cannot be corrected afterwards and will be compared against a page that has moved on.

Waiting has a limit, though. Reports have to reach VG Wort by the Meldeschlusstermin of the distribution you want them in—1 June up to and including 2026, 31 March from 2027. The registration view names the next date and how far away it is, and says it more loudly inside the last eight weeks.

The module naming the next VG Wort reporting deadline and how many days are left, with the reminder that a text is reported once it has stopped changing.

Text extraction

The text is taken from the rendered frontend page, not assembled from database fields. What the reader sees is what gets reported.

Content is picked in this order:

 /  markers, if present
the <main> element
<body>, as a fallback

Marking what belongs to the text

Two partials ship with the extension. Wrap the main content:

<f:render partial="VgwortInclude" contentAs="content">
    <article>… your main content …</article>
</f:render>

and exclude what is not prose—code blocks, image galleries, teasers to other articles:

<f:render partial="VgwortExclude" contentAs="content">
    <div class="code-block"><pre><code>…</code></pre></div>
</f:render>

Register the path in your site package:

# FLUIDTEMPLATE
lib.contentElement.partialRootPaths.5 = EXT:vgwort_pro/Resources/Private/Extraction/Partials

# PAGEVIEW
page.10.paths.5 = EXT:vgwort_pro/Resources/Private/Extraction/

This is worth doing before you report, not after. Everything inside the markers counts towards the 1,800 characters and is what VG Wort compares against the live page. A teaser block that changes weekly makes the reported text drift from the page on its own.

How the markers stay out of your HTML

The markers are always rendered, and a middleware strips them from every frontend response. The extraction service appends a short-lived HMAC token (?vgwort-markers=<token>), signed with the site’s encryptionKey, to keep them visible for the duration of its own request. Backend users can use the same bypass while previewing, and the literal ?vgwort-markers=1 still works outside production contexts for local debugging. Responses carrying markers are sent with Cache-Control: private, no-store, so no CDN keeps them.

Authors

Authors are records (tx_vgwort_author) with a name, a VG Wort card number, a verification status, and an inactive flag.

Verify before you report. An unverified card number is refused at submission, one text at a time, and the verification call is a single click in the module.

Each assignment of an author to a page is either Author (Urheber) or Translator (Übersetzer); set it in the review step. Authors who have retired are marked inactive: they stay for the record and disappear from selection lists.

Author records with their VG Wort card numbers, two verified against VG Wort and one still unverified.

Length and the minimum access count

Two lengths decide how a text is treated, and the review view names which one applies:

Characters
under 1,800	cannot be reported at all
1,800 to 9,999	reportable once the pixel reaches the full minimum access count
10,000 and above	reportable once the pixel reaches half the minimum access count

The longer text has the lower bar. How many accesses that is in a given year is VG Wort’s number, changes yearly, and is not part of this extension.

A text that crosses the 10,000 line in either direction after it was reported needs a different pixel. This extension does not do that swap for you.

Poetry. VG Wort still exempts poems from the 1,800-character minimum for the 2026 distribution, which settles texts counted in 2025; the exemption ends with counting year 2026. This extension does not implement it—a poem under 1,800 characters is treated as too short here and has to be reported through the VG Wort portal.

Both numbers come from METIS für Urheber, document version 5.1, checked 17 September 2026, and live in Classes/Domain/ReportingThresholds.php with that reference.