Marketplace warning or separate section for v9

linuxoid · August 19, 2021, 10:46am

v9 is coming sooner or later. I believe there should be a warning saying that v8 packages may not work in v9 out of the box unless clearly stated otherwise to avoid customers paying for a package, realizing it doesn’t work or looks ugly and then demanding a refund thus getting the package for free.

Or a separate section should be made for v9 packages.

JohntheFish · August 19, 2021, 11:26am

+1 on adding a clear warning.

Maybe we could have a big badge over marketplace items that a developer has tagged as v9 compatible ‘v9 Compatible’.

This could also help weed out abandoned items that are not being maintained.

My experience of updating for v9 so far is that simple blocks can look OK and the block edit dialogs need some work to look good because form controls, floats, bootstrap labels and font awesome icons have changed.

More complex edit dialogs, dashboard pages and code that integrates with other core functionality need a lot of work. Not many major changes, but a big accumulation of all the time tracking down many little changes and testing.

linuxoid · August 19, 2021, 11:58am

I’ve just checked a couple of my big applications in v9. Well, they’re totally screwed up and ugly as hell. I don’t know what’s going to be better: trying to adjust every damn div and js or simply making a new version.

From the PRB perspective, if a package is called ab_xyz for v8, can I submit a v9 ready version called ab_xyz_v9? Can handles have numbers BTW?

JohntheFish · August 19, 2021, 12:08pm

Handles can have numbers. I did such porting addons between v5.6 and v5.7 where the marketplace was split. ( example Magic Tabs - concrete5 (v5.7), Magic Tabs (c5.6) - concrete5 (v5.6).

If you are creating a new v9 version of an addon, please hold off submitting it to the PRB for now. The PRB is not currently testing against v9.

When you do submit a ‘new’ v9 update, post a diff with the submission and a summary of changes made. We will need to know what is new functionality and what is a v9 compatibility change. Manpower permitting, we will try and fast track ‘new’ v9 addons that only have compatibility changes from v8 code.

Personally I am trying to make addons adaptive so they work with v8 and v9. In a worst case, this has involved conditionally registering namespaces in a package controller dependant on core version.

More worrying is the number of sites that will update from v8 to v9 without thoroughly checking addon compatibility first, then either discover that dialogs etc are seriously glitched or brick their site. We get a rush of ‘failed update’ forum posts on every major update and I can foresee this being a record breaker.

If we had a tag for addons/themes confirming v9 compatibility, the core upgrade procedure could check that flag and refuse to update unless all were compatible.

JohntheFish · August 19, 2021, 1:27pm

I have proposed a v9 compatibility mechanism as a github issue

github.com/concrete5/concrete5

v9 - Proposal to ensure addons are compatible with v9 before updating a site or installing addon

opened 01:26PM - 19 Aug 21 UTC

JohntheFish

My experience of running v8 addons on v9rc sites so far has been mixed. Simpl…e blocks can look OK on the page, but the block edit dialogs usually need some work to look good because form controls, floats, bootstrap labels and font awesome icons have all changed. More complex edit dialogs, dashboard pages and code that integrates with other core functionality need a lot of work. Not many major changes, but a big accumulation of all the time tracking down many little changes and testing. Many sites owners will update from v8 to v9 without thoroughly checking addon compatibility first, then either discover that dialogs etc are seriously glitched or brick their site. We get a rush of ‘failed update’ forum posts on every major core update and I can foresee v9 being a record breaker. Many v9 fresh install site owners will also try and install addons/themes that have not been updated for addon compatibility and consequently glitch or brick their site. My proposed solution is to have a flag in package controllers confirming maximum version compatibility. If not set, it will default to the previous major core version. Package install and the core upgrade procedure can then check that flag and refuse to update unless all packages are already flagged v9 compatible. for example ``` // core base class abstract class Package implements LocalizablePackageInterface{ public function getMaxAppVersion(){ if(isset($this->maxAppVersion)){ return $this->maxAppVersion; } else { // sets a default of v8.latest that prevents any un-confirmed v8 package being installed on v9 // max handles special case of v7 addons already in use on v8 sites return max( 8, extract_major_version_from($this->appVersionRequired )); } } } // An updated package class Controller extends Package { protected $appVersionRequired = '8.5.2'; // This package has been updated by the developer and confirmed as v9 compatible, but will not be compatible with v10. protected $maxAppVersion = '9'; //.... } // A package that has not been updated class Controller extends Package { protected $appVersionRequired = '8.5.2'; // This package has not been updated. It defaults to only being compatible with v8 //.... } // A package built for v9 class Controller extends Package { protected $appVersionRequired = '9.0.0'; // This package has been built for v9. It is automatically compatible with all v9, but will not be compatible with v10. //.... } ``` This flag can also be used in the marketplace to provide a big 'v9 Compatible' rosette on updated packages. The mechanism is automatically capable of handling further major version updates. A beneficial side effect of this flag will be to weed out addons that are not actively maintained in the marketplace.

All are welcome to add their 2c

enlil · August 19, 2021, 4:24pm

We surely need to start “versioning” the addons in the marketplace. Users NEED to be able to know what they are purchasing will work with the version they are running on! @JohntheFish your idea, with the core updates you proposed, looks great!

linuxoid · August 20, 2021, 1:24am

Although versioning is good, who knows when it will be implemented. But I think the warning must be put in the MP now regardless.

JohntheFish · October 1, 2021, 8:05am

For anyone following this, there have been some developments on GitHub.

JohntheFish · October 13, 2021, 12:23pm

To gauge the risk, I have started a straw poll on v9 compatibility.

For anyone wanting to provide technical details or concerns on GitHub, the issue is at

github.com/concrete5/concrete5

v9 - Proposal to ensure addons are compatible with v9 before updating a site or installing addon

opened 01:26PM - 19 Aug 21 UTC

JohntheFish

Type:Enhancement Status:Proposal Product Areas:Upgrading

My experience of running v8 addons on v9rc sites so far has been mixed. Simpl…e blocks can look OK on the page, but the block edit dialogs usually need some work to look good because form controls, floats, bootstrap labels and font awesome icons have all changed. More complex edit dialogs, dashboard pages and code that integrates with other core functionality need a lot of work. Not many major changes, but a big accumulation of all the time tracking down many little changes and testing. Many sites owners will update from v8 to v9 without thoroughly checking addon compatibility first, then either discover that dialogs etc are seriously glitched or brick their site. We get a rush of ‘failed update’ forum posts on every major core update and I can foresee v9 being a record breaker. Many v9 fresh install site owners will also try and install addons/themes that have not been updated for addon compatibility and consequently glitch or brick their site. My proposed solution is to have a flag in package controllers confirming maximum version compatibility. If not set, it will default to the previous major core version. Package install and the core upgrade procedure in v9 can then check that flag and refuse to update unless all packages are already flagged v9 compatible. for example ``` // core base class abstract class Package implements LocalizablePackageInterface{ public function getMaxAppVersion(){ if(isset($this->maxAppVersion)){ return $this->maxAppVersion; } else { // sets a default of v8.latest that prevents any un-confirmed v8 package being installed on v9 // max handles special case of v7 addons already in use on v8 sites return max( 8, extract_major_version_from($this->appVersionRequired )); } } } // An updated package class Controller extends Package { protected $appVersionRequired = '8.5.2'; // This package has been updated by the developer and confirmed as v9 compatible, but will not be compatible with v10. protected $maxAppVersion = '9'; //.... } // A package that has not been updated class Controller extends Package { protected $appVersionRequired = '8.5.2'; // This package has not been updated. It defaults to only being compatible with v8 //.... } // A package built for v9 class Controller extends Package { protected $appVersionRequired = '9.0.0'; // This package has been built for v9. It is automatically compatible with all v9, but will not be compatible with v10. //.... } ``` This flag can also be used in the marketplace to provide a big 'v9 Compatible' rosette on updated packages. The mechanism is automatically capable of handling further major version updates. A beneficial side effect of this flag will be to weed out addons that are not actively maintained in the marketplace.