Package Developers: Upgrading Your Packages for Version 8

This tutorial is over a year old and may not apply to your version of Concrete CMS.
May 20, 2016

Concrete CMS version 8 adds a lot of user-facing improvements, but also refactors a number of classes under the hood. Your package could be affected. In general, we're really trying to make this version fully backward compatible, but it's not always possible. With that in mind, here are some fixes to common issues that may strike your add-ons and themes as you install them on concrete v8.

Important Note: This is a work in progress. If you have employed a particular method to make a package compatible with version 8 while retaining backward compatibility, please edit this tutorial with your ideas.

Avoid Type-Hinting Package in your Methods

The Concrete\Core\Package\Package class was a massive beast. In version 8 it is being split into many other files. Consequently, you should no longer type-hint your installation methods against Concrete\Core\Package\Package because you might be working with an alternate object. Consider this code, which works in version 7:

public function installStore()
{
    $pkg = Package::getByHandle('community_store');
    Installer::installSinglePages($pkg);
}

And in the Installer class

public static function installSinglePages(\Concrete\Core\Package\Package $pkg)

Unfortunately, Package::getByHandle() now returns an entity object (Concrete\Core\Entity\Package) instead of the service object found at Concrete\Core\Package\Package.). So the type hint will fail.

Solution

Simply remove the type hint. Obviously, stricter code could type-hint with the entity object instead, but then that renders your code unusable in 5.7.x. The easiest and most compatible code simply removes the type hint, resulting in this:

public static function installSinglePages($pkg)

Creating thumbnails types programmatically

In 5.7, you would use the Concrete\Core\File\Image\Thumbnail\Type\Type class to create thumbnails. In 5.8, this has been replaced by the Concrete\Core\Entity\File\Image\Thumbnail\Type\Type class.

These are some of the errors you may get: Undefined method Concrete\Core\File\Image\Thumbnail\Type\Type::setName() Undefined method Concrete\Core\File\Image\Thumbnail\Type\Type::setHandle() Undefined method Concrete\Core\File\Image\Thumbnail\Type\Type::setWidth()

Solution

Simply replace the old class with the new one in your code. Have a look at the "Keeping backward compatibility in your code" section on this page if you need your code to work in both version.

Keeping backward compatibility in your code

Concrete 5.8 is a backward compatible. However, in some cases you'll need make some updates in your code. In those cases, to ensure backware compatibility, you can add the following function to your package:

if (!function_exists('compat_is_version_8')) {
    function compat_is_version_8() {
        return interface_exists('\Concrete\Core\Export\ExportableInterface');
    }
}

Then you can use that function in your if statements:

if ( compat_is_version_8() ) {
    //code for version 8
}
else {
    //code for version 7
}

More Coming Soon

This tutorial is unfinished. I am posting it now, but I'd love to have community additions to it as more backward compatibility tweaks are made to your code bases.

Recent Tutorials
Customize locale icons
Oct 29, 2024
By myq.

How to customize locale (language region) flags

Concrete CMS Caching Guide
Oct 16, 2024

An overview of types of caching in Concrete and considerations when using them.

Redirect all requests to HTTPS
Oct 9, 2024
By myq.

How to follow best practices for a secure web

Upgrade Concrete versions 9.3.1 and 9.3.2
Sep 10, 2024
By myq.

How to get past a bug in versions 9.3.1 and 9.3.2 that prevents upgrading the Concrete core through the Dashboard

How to use Composer with Marketplace extensions
Aug 22, 2024

Composer can be used to manage third-party extensions from the marketplace

Controlling Google Tag Manager Tags Based on Concrete CMS Edit Toolbar Visibility
Aug 13, 2024

This document provides a step-by-step guide on how to control the firing of Google Tag Manager (GTM) tags based on the visibility of the Concrete CMS edit toolbar. It explains how to create a custom JavaScript variable in GTM to detect whether the edit toolbar is present on a page and how to set up a trigger that ensures GTM tags only fire when the toolbar is not visible. This setup is particularly useful for developers and marketers who want to ensure that tracking and analytics tags are not activated during content editing sessions, thereby preserving the accuracy of data collected.

Improvements?

Let us know by posting here.