Straw poll - addon + theme compatibility with v9

For anyone who has updated a v8 site to v9rc, or who has been testing/updating addons for v9rc, this is a quick poll on how compatible addons and themes are out-of-the-box.

To be clear, this thread is not interested in what changes were necessary or what the addon was. All I am asking for at this point is a count of addons/themes and what happened. If an addon or theme matched more than one of the below, count it against whichever was the most severe.

  1. Everything worked, no issues.
  2. Everything worked, but there were cosmetic issues in the front end view or edit dialogues.
  3. The front end worked, maybe with some cosmetic issues, but the edit dialogue was broken in a way that prevented it from being edited.
  4. It didnā€™t work, but didnā€™t stop anything else from working.
  5. It broke one or more individual pages it was used on.
  6. It broke the front end of the site, but the dashboard was still accessible.
  7. It broke so even the dashboard was not accessible.
  8. Something broke the site so badly you couldnā€™t tell which addon or them was responsible or make any more detailed assessment.

Please report as concisely as possible. Total number of addons + themes in each of these categories. It doesnā€™t matter whether you developed them or they were developed by a third party; proprietary, marketplace and elsewhere. You donā€™t need to be a marketplace developer to post a count here.

2 Likes

My own addons I have been updating:

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

Iā€™ve tested 3 addons, theyā€™re big web applications. All 3 were #7:

  1. = 3

They and each one broke the whole site completely, both the frontend and backend. Until I changed all $this->app->make(xxx::class, []) stuff. That allowed the rest of the site to work. But any page with the package crashed due to missing assets. After that functionality was disabled, the pages showed up but obviously without JS functionality and looked ugly as hell with the default Boostrap styling.

So Iā€™m not sure whatā€™s gonna be easier and less messy: rewriting all HTML, CSS and JS from scratch or trying to find it all and replace it. I gave up on v9 for the time being. Itā€™s gonna be an awful f*** around to bring all v8 packages to v9.

  1. = 1
  • All tabbed interfaces in our blocks are broken
  • One dashboard page broken
  • all have format/styling issues.
  • Pagelist custom templates will not render at all.

Its a mystery to me how this is going to work, the official word is V9 is backwards compatible, that may well be true for core, but when people start updating from V8 to V9 and all their themes and add-ons break, they are going to feel rather pi$$ed off.

Come on folks, post your results!
I know there are many more developers and site owners testing v9rc. We need to hear of any good results as well as those with issues. You donā€™t need have to completed updating a site or package. This is only about the immediate consequence of updating to v9 or installing with packages not specifically updated for 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
$list->sortByNodeName();
had to be replaced with
$list->getQueryObject()->orderBy('name', 'asc');

and

$list->sortBy('folderItemModified', 'asc');
with
$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:
    \Concrete\Block\Feature\Controller::getIconClasses()
    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:
from:
<?php echo $form->select($view->field('galleryType'), $galleryTypes, $galleryType, ['class' => 'gallery-type js-gallery-type']); ?>
to:
<?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});
	});
};

with

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.

SNAFU

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 https://github.com/concrete5/concrete5/issues/9746

  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.