Legacy code and features

Owned by Alex Pagnoni
Last updated: Dec 21, 2015
4 min read

Legacy mode

Innomatic 7 has a strong focus on backwards compatibility and thus lets you reuse code you might have written for Innomatic 6.x. It also still need the Innomatic Legacy 6.x kernel to run applications, so a specific legacy mode has been developed. This legacy mode will be completely removed in Innomatic Platform 8.x.

Legacy mode highlights

  • Runs through the whole Symfony kernel, so Symfony services can be accessed from legacy stack.
  • Disables the default Symfony router, using a chained router handling the legacy response. Innomatic will always fallback to the legacy kernel, looking for a legacy WebApp and controller.
  • Decrease performance since it won't use the HttpCache mechanism.

Using pure legacy stack

If you don't have anything migrated to the new Symfony stack and don't plan to immediately start developing inside the Innomatic Platform, it's usually better performance wise to use pure legacy stack, using innomatic_legacy/ folder as your DocumentRoot.

This way you will only use the legacy stack and Innomatic will have the same behavior as 6.x releases. However, note that you won't be able to use the Symfony stack features at all.

Running Innomatic Legacy code

Innomatic 7 still relies on the Legacy kernel and runs it when needed inside an isolated PHP closure, making it sandboxed. This is available for your use as well making it possible to run some PHP code inside that sandbox through the runCallback() method.

use Innomatic\Core\MVC\Legacy\Kernel;


$legacyKernel = new Kernel();
$result = $legacyKernel->runCallback(
    function () use ($packageDir) {
        $app = new \Innomatic\Application\Application(InnomaticContainer::instance('\Innomatic\Core\InnomaticContainer')->getDataAccess());
        return $app->install($packageDir);
    }
);

Legacy applications

Routing fallback

Any route that is not declared in Innomatic 7 in an included routing.yml and that is not a valid UrlAlias will automatically fallback to Innomatic Legacy.

This allows all your old applications to work as before, out-of-the-box.

Using Innomatic Platform and Symfony features in Innomatic Legacy

If you need to develop a legacy application and access Innomatic Platform or Symfony features you have access to all services registered in the whole framework through the Symofny service container.

$rootContainer = \Innomatic\Core\RootContainer::instance('\Innomatic\Core\RootContainer');

$container = $rootContainer->getServiceContainer();
$logger = $container->get('logger');

Running legacy scripts

Legacy scripts can be executed from the Symfony CLI, by using the innomatic:legacy:script command, specifying the script name without the path as argument.

The command will need to be executed from Innomatic Platform 7 root, and the the desired script must exist in the innomatic_legacy/innomatic/core/scripts folder. Here's a usage example:

php innomatic/console --env=prod innomatic:legacy:script maintenance.php

Here we made sure to specify --env=prod, this is needed for all legacy scripts that clear cache, otherwise they will will clear dev environment cache instead of prod for Symfony stack.

If you want to access the script's help please be aware that you will need to use the --legacy-help option, since --help is already reserved for the CLI help.

Composer integration

In Innomatic 6.5.0 we introduced an integration with Composer, a leading dependency manager for PHP that is similar to the Innomatic Legacy native dependencies support but more powerful and popular.

You can check inside the code if a valid Composer autoloader is available through the \Innomatic\Core\RootContainer->hasComposer() method. In that case, any package installed in the vendor directory using Composer is available to Innomatic Legacy through the Composer autoloader.

Including a legacy application via Composer

Since Innomatic 6.5.0 legacy applications can be referenced and deployed through Composer.

To convert an existing legacy application to a Composer package a valid composer.json file must be provided in the legacy application base directory, explicitly setting "innomatic-legacy-application" as package type and adding "innomatic/innomatic-legacy-installer" as a require.

{
    "name": "innomatic-libs/ckeditorlib",
    "description": "ckeditor library",
    "homepage": "http://www.innomatic.io",
    "license": "GPL-2.0",
    "type": "innomatic-legacy-application",
    "authors": [
        {
            "name": "Innomatic Team",
            "homepage": "http://www.innomatic.io"
        }
    ],
    "require": {
        "innomatic/innomatic-legacy-installer": "^1.0",
        "innomatic/innomatic-legacy": ">=6.4 <8.0"
    }
}

Legacy applications can be referenced both by new Innomatic Platform based applications and legacy applications that have been updated with a composer.json file.

Referencing external packages via Composer inside a legacy application

Once a legacy application has been updated to support Composer as described in the previous paragraph, you can use the application composer.json file to reference external packages as you would do in any other Composer package by just adding your dependencies to the "require" section.

See the next paragraph to learn about installing Innomatic applications at run time and still obtaining Composer dependencies support.

Installing legacy applications with Composer dependencies at runtime

While you would normally edit the root project composer.json file to define your dependencies, you can also deploy new applications at run time as in the old Innomatic 6.x way so you don't have to change the root composer.json file. This also applies to legacy applications updated with a composer.json file. You can think of them as plugins that are installed by an administrator after the platform has been installed.

Since Composer doesn't still natively support recursive dependencies, we have added this sort of support in Innomatic using the Wikimedia Composer merge plugin so that new applications with a composer.json file can be added at run time without changing the root composer.json file.

To avoid timeouts we recommend installing applications with Composer dependencies using the applications.php CLI script in place of the applications web control panel.