Module7

Module7 is our solution for embedding structured content — such as points of interest, events, and gastronomy listings — directly into existing websites.

It acts as a display and aggregation layer: Module7 does not manage content of its own. Instead, it queries the Venus Social Knowledge Graph, transforms the results, and delivers them as a fully rendered, interactive web application — using server-side rendering (SSR) with client-side hydration.

Module7 is designed so that its styles do not affect the host page, and the host page's styles do not affect Module7's output. In the vast majority of cases, embedding Module7 on an existing website will not cause any CSS conflicts in either direction.

What's new in Module7

Module7 is a ground-up rewrite of the previous generation (Module6) and introduces several fundamental changes:

	Module6	Module7
Integration	iFrame or PHP CMS adapter	CMS adapter, JS embed, or iFrame
CMS coupling	PHP classes deployed inside the CMS	Adapter optional; core runs independently
Rendering	Server-side via PHP, minimal interactivity	SSR (Node.js) + full client-side hydration
SEO	Partial (iFrame) or adapter-dependent	Full SEO support via SSR (not available via iFrame)
Deep linking	Limited or adapter-dependent	First-class, URL-driven (not available via iFrame)

How Module6 integration worked

With Module6, embedding content into a PHP-based CMS meant deploying our We2p WebModulesCore directly into the CMS installation, instantiating them through a CMS-specific adapter, and injecting the rendered HTML into the CMS page lifecycle. Alternatively, content could be embedded via a plain iFrame. Both approaches required CMS-specific setup and tied the integration tightly to the PHP environment.

What changes in Module7

Module7's core runs as a standalone service completely independent of the host CMS. All rendering happens there. The CMS only needs to know where to point certain requests, which is handled at the web server layer via a reverse proxy.

For TYPO3, we provide a native adapter, a direct upgrade of the existing Module6 adapter. Existing content elements carry over without being re-created, and the adapter adds CMS-native functionality on top of the standard embed (e.g. content element configuration, editorial workflows). Migrating from Module6 to Module7 on TYPO3 is therefore an upgrade, not a re-integration.

For other CMS platforms, there are three options:

• Write a custom CMS extension that integrates the <m7-view> element into your CMS's content management workflow — this gives the same CMS-native editing experience as the TYPO3 adapter.
• Use the JS embed directly — include the Module7 loader via a <script> tag and place <m7-view> elements in your page templates or HTML blocks. No custom extension required. Note that the JS embed does not support SEO, as content is rendered in the browser.
• Use an iFrame — the simplest possible integration. Suitable when web server access is restricted or a full embed is not feasible. SEO and deep-link support are not available in this mode.

Only the TYPO3 adapter and custom server-side adapters deliver Module7 content as part of the initial HTML response, enabling proper SEO indexing.

Integration Key

To use Module7, you need an Integration Key issued by us. Without a valid key, Module7 will not load or display any content.

The key carries everything needed to operate your Module7 instance:

• Module configuration — which views are available, layout, theming, language settings, and data filters
• Domain allowlist — the key is bound to one or more specific domains. Requests from unlisted domains will be rejected. This prevents unauthorized use of your key on third-party websites.

The key is passed directly to the <m7-view> element (or configured in the TYPO3 adapter backend):

<m7-view
    view="listing"
    token="your-integration-key">
</m7-view>

info

Contact us to request an Integration Key for your project. We will configure it according to your requirements and provide it along with your Module7 setup.

Security

Module7 renders HTML received from an external server into the host page's DOM. All HTML produced by Module7 — including content sourced from the Social Knowledge Graph — is strictly sanitized on the server before it reaches the browser. We treat every output field as a potential injection vector and apply conservative sanitization rules throughout.

That said, no sanitization is unconditionally complete. Bugs, edge cases, or unforeseen combinations of content can, in rare circumstances, introduce XSS vulnerabilities. For pages that handle sensitive data — particularly where personal data is involved — we strongly recommend enforcing a Content Security Policy (CSP).

A CSP limits which scripts, styles, and resources the browser is permitted to load and execute, providing a reliable second line of defense even if sanitization is bypassed.

TYPO3 adapter: automatic CSP support

If CSP is enabled in your TYPO3 installation, the Module7 TYPO3 adapter automatically contributes the required CSP directives for Module7 assets. No manual configuration of CSP headers for Module7 is needed on TYPO3.

Required CSP directives for custom integrations

If you are using the JS embed or a custom server-side adapter, you must configure the following directives in your host page's CSP headers. The exact origins depend on whether you use a reverse proxy:

Reverse proxy vs. direct origin

The recommended setup proxies all /module7/* requests through the host domain (see JS Embed Guide). In that case, scripts, styles, and assets are served from your own domain and are covered by 'self'. Only the connect-src and media-related directives need explicit origins.

If you load loader.js directly from https://mo7.vns.services without a proxy, replace 'self' with https://mo7.vns.services in the script-src, style-src, and font-src directives below.

Directive	Required value	Notes
script-src	'self'	Covers loader.js and the embed bundle when served via reverse proxy
style-src	'self' 'unsafe-inline'	'unsafe-inline' is needed for dynamic CSS custom properties applied by the embed
connect-src	'self' https://mo7.vns.services	The embed POSTs to the Module7 server for every SSR render. Gateway calls happen server-side only — the browser never calls the gateway directly
img-src	'self' data: blob: https:	Entity images come from various CDN origins; map tiles use blob: and data:
font-src	'self' https: data:	Fonts may be served from the Module7 server or configured CDN origins
worker-src	'self' blob:	Required for map views — MapLibre GL uses Web Workers loaded as blob URLs
frame-src	https://www.youtube-nocookie.com https://player.vimeo.com https://open.spotify.com https://www.dailymotion.com	Only required if your Module7 views embed media content. Omit if not used

Notes on unsafe-inline and unsafe-eval:

• script-src 'unsafe-inline' is not required — the embed uses only external script tags, no inline scripts
• script-src 'unsafe-eval' is not required — Module7 uses no eval() or dynamic code evaluation
• style-src 'unsafe-inline' is needed because the embed applies CSS custom properties (theme colours, layout variables) via element.style.setProperty() at runtime

CSP nonces are not supported. Module7 does not generate or inject nonces into its rendered output.

How to get started

Choose the integration path that fits your setup:

Option	Best for	Guide
TYPO3 Adapter	TYPO3 v13–v14; upgrading from Module6	TYPO3 Adapter
JS Embed	Any CMS with web server access; no SEO needed	JS Embed Guide · WordPress Example
iFrame	Restricted environments, quick integrations	iFrame Embed