in2publish for TYPO3: Content Publishing Between Staging and Live

Why in2publish defines the content workflow in enterprise TYPO3 projects

In professional TYPO3 installations, editors do not work directly on the live system. They maintain content on a staging environment, coordinate changes internally and publish only after approval. But how does the data get from staging to live? Without in2publish, this means: create a database dump on staging, import it on live, synchronize files via FTP. A process that is error-prone, takes 30 to 60 minutes and where one wrong click can overwrite the entire live database.

in2publish by in2code eliminates this process. Editors click “Publish” in the TYPO3 backend, and the extension synchronizes exactly the changed records and files to the live system. No FTP credentials, no database dumps, no downtime. The industry standard for content staging in TYPO3.

Typical use cases

Editorial approval workflow. A corporation operates its corporate website on TYPO3 with 12 editors across 3 departments. Each department maintains its section on staging. Team leads review changes and approve them. The editor clicks “Publish” and only their approved pages go live. Other areas of the website remain untouched. in2publish shows a diff view: which fields changed, which images are new, which records will be overwritten.

Multi-language publishing. A company maintains its website in 5 languages. The German editorial team publishes finished texts while the English translation is still in progress. in2publish enables selective publishing per language: German content goes live, English stays on staging until the translation is complete.

Campaign launches with defined dates. The marketing team prepares a product launch page that should go live on October 15 at 8:00 AM. All content - texts, images, videos, landing pages - is prepared and tested on staging. On launch day, the responsible editor publishes everything in a single step. If problems arise, in2publish can reverse the changes. For time-critical launches, this is a decisive advantage over manual deployment processes where a rollback takes 30 minutes or more.

Technical architecture

in2publish operates at the database and file system level. The extension compares the state of the staging database with the live database and transfers differences.

The architecture consists of four core components:

• Record comparison: in2publish compares every record (uid, table, fields) between staging and live. Changed, new and deleted records are identified and displayed in a tree structure. Relations (e.g. page has content elements, content element has images) are resolved so that publishing a page automatically includes all dependent records.
• FAL synchronization: images and documents from the File Abstraction Layer are transferred to the live system via SSH/SFTP. in2publish compares file sizes and hashes to transfer only changed files.
• Transport layer: communication between staging and live occurs via SSH. in2publish connects to the live server via public key authentication and executes CLI commands there. Alternatively, the enterprise version supports HTTP-based communication through an API.
• Configuration: a YAML configuration defines which tables are published (whitelist) and which are excluded (e.g. sys_log, be_sessions, cache tables). The default configuration covers all content-relevant tables.

Dependencies: TYPO3 Core, SSH access between staging and live servers, PHP SSH2 extension or ssh2 binaries on the server. The network architecture requires that the staging server can establish an outgoing SSH connection to the live server. In corporate networks with restrictive firewall rules, a dedicated SSH port must be opened.

Common problems and solutions

Publishing aborts with “SSH Connection Failed”. The most common cause: the staging server’s SSH key is not deposited on the live server, or the SSH configuration in in2publish points to the wrong host/port. Solution: manually test the SSH connection (ssh -i /path/to/key user@live-server), then verify the credentials in the in2publish configuration. With managed hosting environments, the hoster often needs to enable SSH access between instances.

Records on live are not updated. The table is not included in the whitelist of the in2publish configuration. This frequently happens with custom tables from proprietary extensions. Solution: add the table to the configuration and define the relations (which field references which other table). Without correct relation configuration, in2publish cannot resolve dependencies.

FAL files missing after publishing on live. The FAL storage on the live system has a different path than on staging, or permissions on the live server do not allow writing to the upload folder. Solution: ensure the FAL storage base path is identical on both systems and the SSH user has write permissions in fileadmin.

Migration and version compatibility

in2publish is actively maintained by in2code and available for TYPO3 v11 and v12 LTS as a Composer package. The enterprise version offers additional features (HTTP transport, extended logging, multi-environment support) and is commercially licensed.

For TYPO3 v13, in2code is working on a compatible version. The extension uses stable TYPO3 APIs (DataHandler, FAL), so porting typically occurs shortly after the LTS release.

During a TYPO3 upgrade, the in2publish configuration must be reviewed: new system tables, changed TCA definitions and new content element types require whitelist adjustments. Gosign recommends a test publish with a single page after every core upgrade to validate the configuration before full editorial operations resume. The test should include a page with all relevant content types: text elements, images, file downloads and at least one relation (e.g. news record with categories). Only this way are all synchronization paths covered.