Question 262539 in Ubuntu Question posted in
The official Ubuntu documentation can be found here.

Ubuntu – How to solve error 503 when copying project to another server? TYPO3 11.5

I am migrating a site on typo3 v11.5 to another server.

  1. I replicated the environment (Ubuntu v22.04 – apache v2.4.41 – php v7.4.3 – MySQL v8.0)
  2. I copied the folder with all the files.
  3. I imported the database.
  4. I updated credentials in LocalConfiguration.php
  5. I updated the "base" path in sites.

However, it generated error 503, it is not possible to access the backend either, same error. I tried the following:

  1. I deleted the typo3temp temporary files.
  2. I truncated all the cache tables.

But the error persists.

I don’t know if I need any other adjustment steps, I appreciate the information.

Postscript:
Is there a better way to migrate? The other option I think is to do a clean installation and insert the contents into each table.

Tags:

2

Answers


  1. 0

    The first step would be to check if the new Server fullfills all
    requirements regarding the server environment. As you mentioned
    apache2, that means needed availabel/enabled apache modules for
    example. On the other hand, TYPO3 core expectes at least a couple
    of php extensions which are required to be available in all contexts,
    cli for commands and the webcontext for the rest.

    To verify and check you can view them up in the (System Requirements)[https://docs.typo3.org/m/typo3/tutorial-getting-started/main/en-us/SystemRequirements/Index.html] Documentation. You can always switch to the correct TYPO3 core version. Beside the "main" link above, here is the one for
    the mentioned TYPO3 v11.5.x version: https://docs.typo3.org/m/typo3/tutorial-getting-started/11.5/en-us/SystemRequirements/Index.html

    If the server requirements are met, other points could be:

    • do you have the correct .htaccess in place – validate by using the default shipped one with the core if you have a changed one: https://github.com/TYPO3/typo3/blob/11.5/typo3/sysext/install/Resources/Private/FolderStructureTemplateFiles/root-htaccess
    • If you are using the legacy (non-composer) installation mode, you may recheck the symlinks or recreate them as they may have been either created wrong and are broken now or missing or something is off. See the installation guide for non-composer mode or gettypo3.org etc.
    • Ensure you have cleared the opcache.
    • Lookup in the system apache/php error logs (php-fpm etc) if there are errors before TYPO3 can handle them
    • Try to login into the dedicated intall tool (creating the magic file and using /typo3/install.php etc.
    • Try to enable the debug mode / context and enable backend debugging (LocalConfiguration.php/AdditionalConfiguration.php etc) and review ajax calls if there is somewhere a error page / stacktrace then instead of the 503 page.
    • Check the MySQL settings. Eventually there are defaults not matching yet the requirements. You did not sate if the pror system had the excat settings and version – recheck them. MySQL settings can be a culprit (charset/collation, strict mode, default datetime field values, explicit timestamp defaults etc – eventually from custom/3rd party extensions)

    503 Normally points to a urgend error, php error, some nearly fatal error or configuration issues.

    You may try to invoke the cli command to see if you get a stack trace there ( typo in db credentials and so on).

    If you can access the backend but not the frontend, enable the FE debugging mode.

    Your described a not complete, but from basic reading it’s a normal way to go. Done that a lot of times to move installations from one server to another.

    Sadly, it could be alot of things going wrong here – so you need to check that yourself. I hope I could give you at least some points at hand to check and narrow down the issue.

    Login or Signup to reply.
  2. 0

    I made a short list of the most reasons I found when something is failing after an update or move to another server:

    1. use the new .htaccess resided in EXT:install/Resources/Private/FolderStructureTemplateFiles.
    2. adjust $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] if required.
    3. adjust $GLOBALS['TYPO3_CONF_VARS']['BE']['cookieDomain'] if required.
    4. If you update to TYPO3 v12 and you use custom extensions (which have to be updated): search in all files inside each extension (usually ext_tables.php, ext_localconf.php and all files in Configuration/TCA/, including Configuration/TCA/Overrides/ ) and replace defined('TYPO3_MODE') || die(); by defined('TYPO3') || die(); The constant TYPO3_MODE is not defined anymore, therefore all those scripts are doing what they are told to do: they die(). This change can be done for TYPO3 v11 already but is not yet required there.
    5. Old public extension should be updated, usually an installation of an old public extension shouldn’t be possible and raise a warning, but I’m not sure if this 100% always the case, it depends on each extension. It’s also possible to disable all ‘local’ extensions first, make the update and enable them again step by step.

    Some problems might also arise if an installation is just copied into DDEV-environment, there the trustedHostsPattern and cookieDomain are usually always different than in common live environment.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search