Documentation

The direct way, and the one without a file.

1. Web > VG Wort > Pool Management
2. Select a page inside the target site—the module reads the site from it and uses that site’s credentials.
3. Enter how many pixels you want (1 to 1,000 per request) and order.

The pixels arrive from /pixel/v1.0/order and land in the pool in one step, ready to assign. Repeat to replenish; the pool is additive and nothing is ever removed automatically.

Needs api.enabled, credentials, and the order_pixels permission.

The way that works without API access.

1. Download the pixel codes as CSV in the METIS portal.
2. Web > VG Wort > Pool Management, select a page inside the site, upload the file.

Expected format—semicolon separated, one header line, both codes 32 hex characters:

If pages already carry pixels that were typed into the field, import the CSV afterwards. The import recognises the public codes, adds the matching private codes, and marks those pool entries as assigned to exactly those pages. From that point the pages can be reported like any other.

This is the migration path—no re-assignment, no touching the pages.

Importing the same CSV into several sites is safe. Per site, the import decides:

• a pixel assigned to a page on another site is skipped,
• a pixel matching a page on this site is imported as assigned,
• everything else is imported as available.

So the same file can be uploaded everywhere, and no two sites end up claiming the same pixel.

When VG Wort rejects a report in their manual review—most often because the minimum length is not reached once non-eligible parts are excluded—they deactivate the counting pixel. It is permanently retired and must never be used again.

The API does not tell you this. Rejections go out by e-mail to the owner of the reporting account and nowhere else, so this step is deliberately manual:

1. Web > VG Wort > Pool Management > Deactivate Counting Pixel
2. Enter the public code from the e-mail and search.
3. Check the page it names, then confirm.

On confirmation the extension marks the pool entry as deactivated—kept for the record, never handed out again, not counted as available—removes the pixel from the page, and clears that page’s registration data. Then, by default, it assigns the next free pixel so the page starts the workflow again. Uncheck that and the page is flagged rejected with the reason stored instead.

Needs the deactivate_pixels permission.

Not every rejection retires a pixel. If the pixel was not deactivated, the message can be corrected or deleted in the T.O.M. portal and sent again with the same pixel. Nothing needs to happen in TYPO3.