Skip to content

Latest commit

 

History

History
133 lines (91 loc) · 6.83 KB

FAQ.md

File metadata and controls

133 lines (91 loc) · 6.83 KB
Raw

FAQ

Publisher backend modules are not visible?

Please check if you have set the environment variables on your server for the stage system via htaccess:

SetEnv IN2PUBLISH_CONTEXT Local

or AdditionalConfiguration.php:

putenv('IN2PUBLISH_CONTEXT=Local');

See https://github.com/in2code-de/in2publish_core/blob/feature/v12/Documentation/Admins/Installation/1_Preparation.md#typo3-requirements for details

How to delete caches of a page in production?

Manually clearing a page cache should not be necessary, because the Content Publisher clears all related caches after publishing.

If you publish a page, frontend-caches of the same page on production will be cleaned. Special case: For sysfolders, e.g. with news-records, you want to clean the cache of another page than the sysfolder that was published. In this case you can use clearCacheCmd in Page TSConfig on the stage (!) system:

# Put this page TSConfig on a news sysfolder. Any publish of this sysfolder will clean FE-cache of PID 12 and 23
TCEMAIN.clearCacheCmd = 12,23

# Clean all caches if a page was published
TCEMAIN.clearCacheCmd = all

#  Will clear all pages cache
TCEMAIN.clearCacheCmd = pages

See https://docs.typo3.org/typo3cms/TSconfigReference/PageTsconfig/TCEmain/Index.html#clearcachecmd for the original documentation

If you need to manually clear the caches:

The Content Publisher Enterprise Version includes the Remote Cache Control (short: RCC) feature. This allows you to clear page and system caches of the Foreign instance. It is easy and configurable as the clear cache controls in you normal TYPO3 Backend.

Scheduler: Can't call commandController from the cli or cronjob but it works in the scheduler module?

You have to add the environment variable for all CLI calls of commandControllers Example call with environment variable (for the stage system):

IN2PUBLISH_CONTEXT=Local ./vendor/bin/typo3 in2publish_core:status:version

Where can i get the Foreign Key Fingerprint

The Foreign Key Fingerprint is, as the name states, a hash of the public ssh key from the foreign system's ssh server. You can get the hash with following command on your foreign server (example command!): ssh-keygen -E md5 -lf /etc/ssh/ssh_host_rsa_key.pub

Hint:

You can omit the colons of the hash.

How do i enable SSH Daemon on my Mac?

Enable login for all users (not recommended) or just the user you configured in sshConnection.username

Newer versions of OS X: Got to "System Preferences" -> "Sharing" -> enable "Remote Login"

Older versions of OS X: Go to "System Preferences" -> "Internet & Networking" -> "Sharing" -> enable "Remote Login"

How can i publish content from Live to Stage?

You can't (kind of).

If you want to transfer user generated content from Live to Stage you can use the TableCommandController (available in the Scheduler for example) or write your own scripts. But be aware that the table:import command overwrites one table with another. It does not keep relations (it does not even resolve them) and it does not merge data. It is just a simple task that copies a whole table.

How do i handle user generated content?

CAUTION: in2publish_core does not handle user generated content. If record UIDs match any data will be overwritten!

The TYPO3 core does not provide a frontend user image upload or any other plugin that enables frontend users to create, update or remove data, therefore any implementation is a 3rd party extension. Please note that we can not provide generic ("out-of-the-box") support for any 3rd party extension. If you have problems with a specific 3rd party extension you can contact [email protected] to ask for a consulting/support quote.

First of all: Ensure all tables that are affected by user generated content are included in excludeRelatedTables. Some tables like sys_file, sys_file_reference and sys_file_metadata, however, must not be included in excludeRelatedTables or publishing content with images will not work. Since these tables are also affected by frontend user interaction on live (if there is an image upload or a forum or something like that [3rd party!]) there will be uid conflicts. This means that a file uploaded by an editor and another file uploaded by a user will get the same uid. When the file is published the file from local will be published and the one uploaded by the user will be deleted. Be aware that unhandled conflicts might lead to data disclosure!

You can solve this by setting the AUTO_INCREMENT value of the affected tables to a high value.

You have to set the auto_increment of the tables sys_file, sys_file_reference and sys_file_metadata to a high value on foreign (and only on foreign!). The distance between the local and foreign auto_increment denominates the number of entries, which can be created on the local system. In case you set the auto_increment too low (e.g. 1000) you will run into conflicts very soon, if you set it too high (e.g. 2147483547) you will soon run out of possible UIDs on foreign (on 32-bit systems). There is still one thing you must know: Conflicting UIDs will still lead to the problem of sys_file records getting overwritten. You should ensure there are no conflicts before starting.

File publishing and publisher tests for file transmission fail

The publisher tests sometimes fail with the following error: TATAPI: The file has not been transferred cat: /app/var/transient/a969b9534c36f7db8c8bed8f1eabd1bb84f46033: No such file or directory

On slow file systems (e.g. Mac OS X) the file transfer sometimes takes too long, resulting in errors in the tests or file publishing process. You can try to set the following configuration in your LocalConfiguration.yaml:

adapter.local.fileTransmissionTimeout: 1

This timeout (in seconds) may resolve the problems, but leads to very slow publishing. It should therefore only be used on development systems.

Steps if there are problems with the publication of data

  1. Content Publisher Selftest Call up the "Tests" tab in the "Publisher Tools" backend module. Problems are displayed in either red or orange and should be fixed.
  2. Install extension TYPO3 Database doctor (https://extensions.typo3.org/extension/dbdoctor) Install the TYPO3 Database doctor extension on both systems (Local & Foreign) and clean up the inconsistencies in the databases. The use of the extension is at your own risk, it is best to make a data backup beforehand.
  3. Activate Advanced Debug Information You can activate the option addFormEngineDescription in your configuration YAML. This setting will show a description above each field when you edit an item in TYPO3 backend.
  4. Check TCA If you are familiar with TCA, you can use the tab "Inspect TCA" in the "Publisher Tools" backend module to check if every relation you have in your data is correctly resolved.