Straw poll - addon + theme compatibility with v9

Of the 12 add-ons we have in the marketplace which I’ve updated for V9:

  1. = 1 addon (a very simple one)
  2. = 4 addons
  3. = 6 addons
  4. = 1 addon
  5. = 0
  6. = 0
  7. = 0
  8. = 0

Beyond the marketplace, I’ve updated maybe another 6 or 7 private add-ons.
Some are quite simple and just work, whereas others have taken a lot of time, mostly on dashboard and editing cosmetics. I’ve not actually tested any of our custom themes at this point, but I’m not expecting issues.

But the main thing I’ve tackled was updating Community Store, which is effectively V9 compatible now in the master branch. There might be a few remaining details to address (in obscure features), hence why I haven’t put out a release yet, but it’s mostly done. There are some new dashboard components, like how to handle search fields, so I’ve been trying to implement those as well.

For Community Store I really didn’t hit any structural issues, it was 95% cosmetic problems. I have been able to adjust the codebase to simultaneously support V8 and V9.

The main things I encountered were:

  • tabs not working. These are currently not backwards compatible, and I’d urge the core team to work on this. It feels like an oversight that tabs on block editing needed a bit of a hack to get working on both V8 and V9 with the same codebase - I’d be surprised if it couldn’t be addressed before release.

  • bootstrap issues with dashboard pages, mostly to do with pull-left and pull-right now being float-start and float-end respectively. Some bootstrap columns needed adjusting as well. Some dashboard pages looked a complete mess, but didn’t take overly long to fix. It might be worth to add a few very commonly used classes to the dashboard css, so there’s a bit of compatibility with BS3. This might fix quite a lot of broken dashboard pages (or at least clean them up a lot), and having those classes there really wouldn’t harm anything.

  • things like select2 no longer being available and replacements having to be pulled in. I can sort of accept this for outdated libraries, but something like a select multi-picker is a very common user interface element, so I’ve had to update this in multiple add-ons.

I’m really liking V9 (and I rambled about this here), and we’re really looking forward to using it. But I’d be lying if I thought it was going to be a seamless transition in terms of add-ons and themes - without all marketplace developers reviewing and updating their add-ons I’m concerned it’s going to be pretty messy… we’ll not be updating client sites with lots of marketplace add-ons for quite some time because of this concern.

  1. 1 plugin
  2. 3 plugins

When they didn’t work it was mostly due to either:

  • the use of $app->make() with non-named parameters
  • dashboard single pages breaking because the controller was using on_start and now the parent does too

2 plugins required a specific third-party class that was removed from the core so that’s another problem to fix entirely.

For one I just added the class to the packet.

For the other it’s going to require some rewrite

+1 for sorting out tabs, the new way seems to require a lot more code for the same result.

2: 2
4: 2

Simple Gallery worked, some ui style fixes were required.
Grand Gallery/blocks from Block Builder didn’t work at all and fixes were required (that was expected though because they are much more complicated).

I have update all my marketplace packages for c5.9 (they are waiting for release in public/private repos).
I updated them when RC3 was available. If something was fixed/changed in RC4 or later I will just make changes when 9.0 will be released.

I have decided to not support c5.7/c5.8 with latests version of packages and set minimum requirement to 9.0.
Transition from bootstrap3 to bootstrap5 sounded like something that is not 100% backwards compatible (although I still very much appreciate moving to b5).

Grand gallery update example:

  1. File/folder list filtering backward compatibility
had to be replaced with
$list->getQueryObject()->orderBy('name', 'asc');


$list->sortBy('folderItemModified', 'asc');
$list->sortBy('dateModified', 'asc');
  1. Extracting css icon class names.
    In c5.8 css classes can be extracted from variables.less file.
    Obviously in c5.9 there is no such thing, so I copied list from:
    It would be much nicer if that list was actually stored in separate class (or at least just make it public) so I don’t need to manually copy it every time it is updated.

  2. Selectize was removed from core so I had to downloaded it manually and use as external dependency.
    I don’t know if there is core replacement for it, but multi-select plugin (select2, slimselect or similar) is a must-have for me when dealing with stuff like tags.

  3. I had some problems with my custom code of font icon picker but I don’t remember solution. But I guess it was expected to break.

  4. As people mentioned earlier tabs are a mess.
    I had more problems with them than I would expect.
    Still I am not sure what is proper way to tackle them and what direction core is heading (best word would be “confused”)
    In Grand Gallery I changed names in $app->make(‘helper/concrete/ui’)->tabs() helper and added custom css for hiding non-active tab-panes (display none/block).
    In Block Builder/Simple Gallery I decided to just go full b5 style (“tab-content” wrapper and “tab-pane” for actual content).

At this point everything works, but of course there are still some glaring ui styling bugs

  1. Form helper \Concrete\Core\Form\Service\Form ($form->select() etc.)
    is not fully backwards-compatible.
    In c5.8 adding custom class would just add them to the list of existing clasess.
    In c5.9 adding any class to input overrides class list, so for example I had to add manually “form-select” everywhere:
<?php echo $form->select($view->field('galleryType'), $galleryTypes, $galleryType, ['class' => 'gallery-type js-gallery-type']); ?>
<?php echo $form->select($view->field('galleryType'), $galleryTypes, $galleryType, ['class' => 'gallery-type js-gallery-type form-select']); ?>

If I don’t add any class, “form-select” will be added automatically and input will by styled properly.
This behaviour caused most eyesore styling bugs in my addons, because I often add custom classes to inputs.

  1. Manually activating file selector using js.
    concreteFileSelector() function has been removed, which is a surprise for me because concretePageSelector() still works.
    Anyway i just replaced:
var activateFileSelectors = function(parentContainer) {
	var fileSelectors = parentContainer.find('.js-file-selector');
	fileSelectors.each(function(i, item) {
		var inputName = $(item).attr('data-input-name');
		var fID = parseInt($(item).attr('data-file-id'));
		$(item).concreteFileSelector({'inputName': inputName, 'filters': [], 'fID': fID});


var activateFileSelectors = function(uniqueID, position) {
	Concrete.Vue.activateContext('cms', function (Vue, config) {
		new Vue({
			el: 'div[data-concrete-file-input="js-file-selector-'+uniqueID+'-'+position+'"]',
			components: config.components
  1. Random thoughts about b3=>b5 backward compatibility

a) I would probably add some backward compatibility for input groups (I used them quite a lot).
b) Deprecated stuff like wells are “take it or leave it” for me, I would just style them by myself.
c) Bootstrap3 checkboxes look fine (though I think they don’t look exactly the same as proper botstrap5 checkboxes) .
d) B3=>B5 transition upped css breakpoints on level up, so that’s not something that can be fixed, but I think impact is quite minimal.
e) I had some “btn-default” classes which I had to replace with “btn-secondary” (another backward compatibility candidate).
f) You can add backward compatibility for pull-right/pull-left
g) Bunch of icons were missing, I had to replace them with proper ‘Font Awesome 5 Free’ classes.
h) Grand Gallery is private repo, but you can see what I have changed in commit history of free addons:

Keep in mind I don’t plan to make latest versions of addons compatible with c5.8/c5.7.

And for statistic funsies, this is the time I devoted to updating them to c5.9:
Grand gallery: 16 hours
Block builder: 20 hours
Simple gallery: 1,5 hour

Created a package with Queueable jobs for v8, tried to test it in v9 and… jobs are no longer used in v9. Now it’s tasks instead. WTF?! As always no Documentation on tasks whatsoever.

I thought I recalled @andrew saying jobs would remain in v9 for a while WITH tasks ?!

  1. = 0
  2. = 1 addon
  3. = 0
  4. = 1 addon
  5. = 0
  6. = 0
  7. = 0
  8. = 0

To handle tabs, what I did was do a check for anything under v9, to work out if a prefix to the class is needed:

and then add the prefix on each tab-pane:

Most of our interfaces were broken due to the transition to Vue. We reworked those to Vue and got all but one fixed/working without much of the main functionality breaking. There is still one add-on we cannot fix due to the Concrete Core piece still not being converted and working for v9. I created an issue for this, but it was closed and it has yet to be done.

We also have a job in a plugin and are waiting on documentation on updating it to a task.

Jobs will remain, along with tasks – we don’t want to break backward compatibility just because. Tasks are definitely better in a variety of ways, but Jobs should continue to work. We will get documentation on tasks soon.

@andrew , this is what I get in v9:

Could not check compatibility between Concrete\Package\AbRegisterGroup\Job\AddUsers::start(ZendQueue\Queue $q) and Concrete\Core\Job\QueueableJob::start(Concrete\Core\Job\JobQueue $q), because class ZendQueue\Queue is not available

Well, ZendQueue in not in v9. +1 for the fact that v9 is NOT backward compatible with v8.

How many more libraries would I have to load myself to make v8 packages run on v9? Why can’t they simply leave the v8 stuff there in their latest version for backward compatibility?

I rapidly lose interest in v9 with so many compatibility problems piling up. I expect new versions of the core should make life easier for developers, not make it a nightmare. v9 for package upgrades is not a spanner in the wheel, it’s a huge piece of rail thrown in.


We need to remember that the purpose of a release candidate and beta test is to find such issues as we are identifying here.

If the v9 core is subsequently improved prior to official release to prevent such issues from occurring, both by resolving incompatibility and by protecting sites from un-fixed incompatibility, then the beta test has achieved its purpose.

In order of priority

  1. A site should not be able to update from v8 to v9 if it has incompatible packages installed. This is the backstop. It stops us from seeing a rush of broken sites, addon support issues and marketplace refunds after v9 is released. Achieving such is the objective of

  2. The v9 core update needs better compatibility (or at least survivability) with existing addon/theme packages. What we are seeing in this thread are reports from active developers who have put time into testing their code with v9rc4. There are 100x as many addon/theme packages in the marketplace that have not been actively tested on v9rc4 and many of these are not actively supported. Results posted in this thread suggest they will nearly all have some incompatibility and a fair proportion will break a v9 site. On my scale of 1…8 at the top of this thread, the core needs to unilaterally move issues away from 8 and towards 1. Achieving perfect compatibility universally will not be possible, That is why we need the backstop (1).

  3. We addon/theme developers need to make changes. Such changes are hampered by lack of documentation. @frz has documentation on the way. Most who have posted above are actively working on updating packages for v9. Others are either waiting or will not be updating. Addon and theme updates take time. Hence the need for (2) and (1).

With the above in mind, v9rc4 has fallen a long way short of readiness for release. We need at least a v9rc5 to demonstrate (1) and (2) before an official release version should be contemplated. If @frz can get the v9 developer documentation out with v9rc5, that will both encourage developers and make the whole process less fraught.

I couldn’t agree more with your points here John, as well as the ones in that github thread.

I understand the desire to try to get V9 ‘out there’, being seen and used asap, but if these backwards compatibility issues aren’t mostly resolved it’s going to be a real mess.

By resolved, that might be either V9 being modified to support some more backwards compatibility (e.g. tabs) or add-on developers updating their add-ons - it can’t all be on the core, but it has to be one or the other.

Ultimately I think there should be a significant delay before V9 is offered as an upgrade via the dashboard as a one-click operation. Someone could still manually update their site if they wanted to, but my concern is the type of user who just updates anytime there’s a new version available.

I’m very fearful that we’ll have clients email through to say their website is broken or looks very strange, to find that they’ve triggered the V9 update themselves, before we’ve had a chance to run through an upgrade test run. We’ll then either have to restore their sites from backups, or scramble to fix what we can on a live site.

There needs to be some sort of critical mass of add-ons that are V9 ready before opening that up, or something that is actually flagged in the marketplace and/or add-ons themselves.

Stability is hugely important here, and much more important than the ability to upgrade.

There is generally an expectation that major version upgrades of any software have caveats regarding backwards compatibility - so it wouldn’t be seen as a negative that upgrading to V9 from V8 requires an extra series of checks before saying it’s ok to do so. And if those checks come back to say ‘don’t do it, some add-ons will break’, that’s a good thing.

A well functioning V8 site is 100 times better than a broken V9 site.

Whilst on a technical level V9 is mostly compatible with V8 add-ons, the reality is that it’s just not fully backwards compatible. There’s no shame or defeat in this, people do understand the reality of software. But what can’t happen is the situation where V9 is promoted as ‘completely backwards compatible’, and then sites end up broken after upgrading.

I can’t remember, has there been a mass email out to all marketplace developers that ‘V9 is coming, we need you to update your add-ons’? Perhaps there needs to be another one?

Have the most installed, say, 30 add-ons from the marketplace been tested to work correctly on V9?

+1 for that as a test. A set of test sites with the most popular (free and paid) addons & themes needs to be maintained and tested against every core upgrade. It would also be a good test of @frz’s new containerized quick spin-up hosting package, so serving multiple purposes.

(I expect some of the free addons/themes with most downloads would be buggy even on v8.5.6)

It doesn’t take an experienced developer to do such a test. Developer experience is only needed to analyze when the test fails.

One add-on:
1 = 0
2 = 1 (tabs issue)
3 = 0
4 = 0
5 = 0
6 = 0
7 = 0
8 = 0

Woohoo! I have an addon that worked for v9 with no issues at all! My Safe HTML template.

(my numbers above edited)

1 Like

@enlil I heard the exact same thing and I remember asking him about it myself.

9.0.1, jobs are still a thing, with a notice that they will one day not work any more… Talk about almost cold turkey :smiley:

Jobs won’t work directly. The job itself and parameters passed into the job are strongly typed by class names. The class names from pre v9 do not exist in v9. v9 has changed the definitions to another set of strongly typed class names unique to v9.

Thus an un-modified v8 job will fail with php parameter type errors when installed on a v9 site or when a v8 site is upgraded to v9. And a v9 job will fail with php parameter type errors when installed on v8.

I discussed this with @Lemonbrain on a PRB review and we came up with a solution involving conditional declaration of the class as an extension of a pair of v8 and v9 intermediary classes. A similar approach should be feasible for handling some of the other more tricky v8/v9 differences , especially where strongly typed method declarations have changed.

At its most basic, it boils down to

if(version <v9){
    class MyClass extends v8_intermediarry_class
} else {
    class MyClass extends v9_intermediarry_class

The initial test could also check for class existence rather than core version.

The intermediaries can either be copies with differences in v8/v9 classes, or can simply look after the parameter class differences and then call back into a common class for the real code.