Symfony 1.x on PHP 7.4: Every Error We Hit and How We Fixed It

Moving a Symfony 1.x application from PHP 5.4 to PHP 7.4 is not a clean copy-and-paste job. The framework, its ORM, and several plugins were written before PHP 7 existed, and they make assumptions about language behavior that PHP 7 quietly broke. This article documents every error we encountered during the migration of skylinerenting.eu and the exact fix applied in each case.

Error 1: Apache Internal Redirect Loop

The first error after copying files to the new SiteGround server was an Apache log entry showing the request had exceeded the limit of 10 internal redirects. The site returned a blank page or a generic server error in the browser.

The root cause was the document root configuration. Symfony 1.x expects requests to hit the web/ subdirectory — where index.php and .htaccess live — not the project root. On the old server, this had been configured correctly at the hosting level. On the new server, the document root was pointing one level too high, causing the rewrite rules in .htaccess to loop.

The fix was to set the document root in SiteGround’s site configuration to point directly at the web/ folder inside the project, rather than the project root. Once that was corrected, the redirect loop stopped immediately.

Error 2: Doctrine Autoloader and preg_replace with /e Modifier

PHP 7 removed support for the /e modifier on preg_replace(), which Doctrine 1.x used in several internal files. The errors typically appeared as fatal errors referencing files inside lib/vendor/doctrine/lib/.

Rather than patching Doctrine manually, we replaced the bundled vendor copy with the FriendsOfSymfony1/symfony1 fork, which maintains Symfony 1.x with PHP 7 compatibility patches already applied. This is the actively maintained successor to the original LExpress fork and supports PHP 7.4 through 8.1.

composer require friendsofsymfony1/symfony1 "1.5.*"

After updating the vendor libraries, the Doctrine autoloader errors disappeared.

Error 3: SwiftMailer Not Found

Several pages — property search, tenants, landlords — returned a fatal error referencing a missing SwiftMailer file at a hardcoded path inside the Symfony cache. The error only appeared on pages that triggered Symfony’s mailer factory, not on the homepage.

FATAL ERROR: require_once(): Failed opening required
'.../lib/vendor/symfony/lib/vendor/swiftmailer/lib/swift_required.php'

The quickest fix that did not break anything else was to disable the mailer in apps/frontend/config/factories.yml by setting all environments to use sfNoMailer. The site does not send transactional email from the frontend directly, so disabling the mailer factory had no functional impact.

all:
  mailer:
    class: sfNoMailer
    param:
      delivery_strategy: none

The same change was applied to apps/backend/config/factories.yml. After clearing the Symfony cache, all previously broken pages loaded correctly.

Error 4: sfCombinePlugin Conflict

The site used sfCombinePlugin to merge and minify CSS and JS assets. On PHP 7.4, the plugin produced errors related to its internal cache directory permissions and deprecated function usage. Disabling the plugin entirely from ProjectConfiguration.class.php caused a cascade of 500 errors because other parts of the bootstrap depended on it being loaded.

The correct approach was to leave the plugin loaded but disable its functionality through configuration, rather than removing it from the plugin list. Adding the following to apps/frontend/config/app.yml disabled the plugin behavior without breaking the bootstrap chain:

all:
  sfCombinePlugin:
    enabled: false

With the plugin disabled at the configuration level, CSS and JS assets were served as individual files rather than combined bundles. For a site of this size the performance difference was negligible, and all styles and scripts loaded correctly.

PHP Version Selection

SiteGround supports multiple PHP versions per site, ranging from 7.3 to 8.x. We tested the patched codebase against each available version. PHP 8.x introduced additional breaking changes in Symfony 1.x that would have required deeper framework patches. PHP 7.3 worked but is itself end-of-life. PHP 7.4.33 was the stable choice — the highest version the patched codebase ran on cleanly, and a version still available on SiteGround for existing sites.

Setting the PHP version per-site in SiteGround is done through the Site Tools panel under Devs → PHP Manager.

Summary of Fixes