ModelList::getCollapseStatus() unavailable in Build <420

[Asinox]

Hello guys, i got this error trying to create a new model...

Call to undefined method RainLab\Builder\Widgets\ModelList::getCollapseStatus()

October 419

Any idea?

Thank you!

[LukeTowers]

The builder plugin has been updated to work with Build 420+. Update your OctoberCMS instance by enabling config/cms.php edgeUpdates = true and then it will work.

[ghost]

Hi,

This is just a nightmare. I had the same issue #198 on Build 419. I did the update and the build showed 426. The basic error was gone, as it says in the title but appeared to throw a different error from one of the Laravel package.

I noticed that the composer.json file, amongst others, was missing as I had downloaded from Github manually and installed.

In fact there are two packages available: 1) Install-master and 2) octobercms-master.

When I used the octobercms-master in a new dir and did: composer install + update, all worked fine. The entire Laravel package got updated and everything went fine until the end. I could (without db) access the demo page. The vendor dir had all dependencies.

When I used the existing installation with the composer.json from the octobercms-master.zip to have everything updated and obtain all dependencies, where I had manually updated the system core from Build 419 ---> 426, then the disaster began.

The composer install did not go through properly. It stopped giving an error that test/TestCase.php is not a file or folder.

 [RuntimeException]
 Could not scan for classes inside "tests/TestCase.php" which does not appear to be a file nor a folder

Thereafter the entire CMS installation gives an error

FatalErrorException
Declaration of Illuminate\View\Factory::composer($views, $callback) must be compatible with Illuminate\Contracts\View\Factory::composer($views, $callback, $priority = NULL)
in Factory.php (line 14)

Thus, I lost my work or installation and must restart the whole damn thing again because I somehow in the middle of installation did not have the slightest idea that all this is buggy and should make a backup before.

I suggest the team to investigate in the area that there result differences in installation methods one may have used before and concentrate on it such that any update becomes the latest installation how it is intended.

When I was making the update via composer on the existing installation, where I made an update of the Build 419 to 426, it did show Build 426 in admin. Here, when I started to make an update via composer, it began to show in the console making update from 421 to 426. Here is the output after composer install:

Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 38 installs, 11 updates, 0 removals
  - Updating nikic/php-parser (v3.1.1 => v3.1.2): Downloading (100%)
  - Updating psy/psysh (v0.8.12 => v0.8.14): Downloading (100%)
  - Updating mtdowling/cron-expression (v1.2.0 => v1.2.1): Loading from cache
  - Updating laravel/framework (v5.5.17 => v5.5.20): Downloading (100%)
  - Updating doctrine/collections (v1.4.0 => v1.5.0): Loading from cache
  - Updating doctrine/cache (v1.6.2 => v1.7.1): Loading from cache
  - Updating doctrine/annotations (v1.4.0 => v1.5.0): Loading from cache
  - Updating october/rain (v1.0.425 => v1.0.426): Downloading (100%)
  - Updating october/system (v1.0.421 => v1.0.426): Downloading (100%)
  - Updating october/backend (v1.0.421 => v1.0.426): Downloading (100%)
  - Updating october/cms (v1.0.421 => v1.0.426): Downloading (100%)
  - Installing psr/http-message (1.0.1): Loading from cache
  - Installing guzzlehttp/psr7 (1.4.2): Loading from cache
  - Installing guzzlehttp/promises (v1.3.1): Loading from cache
  - Installing guzzlehttp/guzzle (6.3.0): Loading from cache
  - Installing phpseclib/phpseclib (2.0.7): Downloading (100%)
  - Installing firebase/php-jwt (v5.0.0): Downloading (100%)
  - Installing google/apiclient-services (v0.33): Downloading (100%)
  - Installing psr/cache (1.0.1): Downloading (100%)
  - Installing google/auth (v1.1.0): Downloading (100%)
  - Installing google/apiclient (v2.2.1): Downloading (100%)
  - Installing fideloper/proxy (3.3.4): Loading from cache
  - Installing itsgoingd/clockwork (v1.14.5): Downloading (100%)
  - Installing fzaninotto/faker (v1.7.1): Loading from cache
  - Installing sebastian/recursion-context (2.0.0): Downloading (100%)
  - Installing sebastian/exporter (2.0.0): Downloading (100%)
  - Installing sebastian/diff (1.4.3): Loading from cache
  - Installing sebastian/comparator (1.2.4): Loading from cache
  - Installing sebastian/version (2.0.1): Loading from cache
  - Installing sebastian/resource-operations (1.0.0): Loading from cache
  - Installing doctrine/instantiator (1.1.0): Loading from cache
  - Installing phpunit/php-text-template (1.2.1): Loading from cache
  - Installing phpunit/php-timer (1.0.9): Loading from cache
  - Installing phpunit/php-file-iterator (1.4.2): Loading from cache
  - Installing sebastian/code-unit-reverse-lookup (1.0.1): Loading from cache
  - Installing phpunit/php-token-stream (2.0.1): Loading from cache
  - Installing webmozart/assert (1.2.0): Loading from cache
  - Installing phpdocumentor/reflection-common (1.0.1): Loading from cache
  - Installing phpdocumentor/type-resolver (0.4.0): Loading from cache
  - Installing phpdocumentor/reflection-docblock (4.1.1): Loading from cache
  - Installing phpspec/prophecy (v1.7.2): Loading from cache
  - Installing myclabs/deep-copy (1.7.0): Loading from cache
  - Installing sebastian/global-state (1.1.1): Loading from cache
  - Installing sebastian/environment (2.0.0): Downloading (100%)
  - Installing sebastian/object-enumerator (2.0.1): Downloading (100%)
  - Installing phpunit/phpunit-mock-objects (3.4.4): Downloading (100%)
  - Installing phpunit/php-code-coverage (4.0.8): Downloading (100%)
  - Installing phpunit/phpunit (5.7.23): Downloading (100%)
  - Installing phpunit/phpunit-selenium (1.4.1): Downloading (100%)
phpseclib/phpseclib suggests installing ext-libsodium (SSH2/SFTP can make use of some algorithms provided
phpseclib/phpseclib suggests installing ext-gmp (Install the GMP (GNU Multiple Precision) extension in ord
google/apiclient suggests installing cache/filesystem-adapter (For caching certs and tokens (using Google_
sebastian/global-state suggests installing ext-uopz (*)
phpunit/phpunit-mock-objects suggests installing ext-soap (*)
phpunit/php-code-coverage suggests installing ext-xdebug (^2.5.1)
phpunit/phpunit suggests installing phpunit/php-invoker (~1.1)
phpunit/phpunit suggests installing ext-xdebug (*)
Writing lock file
Generating autoload files

  [RuntimeException]
  Could not scan for classes inside "tests/TestCase.php" which does not appear to be a file nor a folder

There is something here which is causing this error.

Because I began with the same error, as the title suggest, and have taken a different course to eradicate it based on the solution suggested, I landed up in a total different area of this problem.

Hence, I find it appropriate to put this message as an addition to this issue. If this is not relevant, please shift it to a different issue, or let me know to do so to open a new one.

Pl. feel free to ask me on this issue if required.

PS: I used it on windows 7 (64bits), php 7.1 and sqlite.

[LukeTowers]

@SchneiderDe it sounds like you tried to install the update using a different method than you originally did to install October. Basically, there are two "versions" of October if you will. The "consumer" version is installed by the installer and does not include server.php, composer.json, or any tests. The "developer" version is installed by composer with composer create-project october/october myproject and includes composer.json and the tests folder.

The docs (http://octobercms.com/docs/console/commands#console-install-composer) provide instructions on converting a "consumer" instance to a "developer" instance.

[ghost]

Hello Mr. Towers,

First of all, my sincere thanks to you for your lightening answer. Not a single developer has reacted so fast within minutes.

You are partly correct. Initially I did install the consumer version. While developing a new Plugin, I landed in changing it to the developer version.

Here, you are missing the issue I have raised in above. Let me once again limelight it.

A.

1. The Build got update from the web interface from 419 ---> 426. It displayed correct.

2. With composer, it made the update from 421 ---> 426, as shown in the output.

THIS IS WRONG!

B. Now I also found the problem area. As mentioned earlier, I did not have the backup and got into restoring the installation manually. I had the db, themes and Plugins.

I used the developer version 426 and did the composer update. All got installed. I could access demo theme. Then I pushed in that installation the changes in app.php, database.php, etc. Copied the theme, Plugin dir. Earlier WITHOUT the Plugin dir-data in it, there was no error. After that it threw the same error. Thus, the Plugins were not compatible in the developer version. The error mentioned above comes from that.

After trying under 50:50 to exclude and proceed, I found ultimately following Plugins with the dir names are NOT compatible with the 426 build + Laravel 5.20:

bytepoets ---> BYTEPOETS.BasicAuth garretfick ---> GarretFick.Trustedproxies qub ---> Qub.Clockwork

I will have to reinstall everything again. Thats bad. I cannot reconstruct it based on the themes and Plugins I already have downloaded or are available. Thus, I suggest now:

a. To have checks in the developer updating process if all Plugins are compatible. This did not evidently happen in my case.

b. Reconstruct CMS function. The force update is not enough. If there is a function to reconstruct everything based on files, as if the entire db is reconstructed then it would be good.

In such cases, any error as the title of this post shows, or I had in the middle of repair, update, etc. could be ironed up.

Now I shall proceed for a fresh installation after tasting and playing a bit more the existing corrupted installation. Glad that I used this one to find out which Plugins are troublesome before deleting the installation.

Finally, thanking you again Mr. Towers.

PS: I hope not to make a mistake here, if such a feature already exists. If yes, excuse me please.

Edit: What I suggested above could be well achieved with Database migration...

[ghost]

Hello Mr. Towers, Sorry, I made a mistake again. Because I had 'disableCoreUpdates' => false, in cms.php, the composer downloaded it again. So in fact this was an intended behaviour. I was wrong in mentioning it. Well, as a new comer, this happens. Pardon me...

[LukeTowers]

@SchneiderDe what would you suggest for telling the developer to check plugin's compatibility before updating?

[ghost]

Hello Mr. Towers,

Thanks for taking your time to read my messages.

My problem is that I know OctoberCMS very little. Even a tiny thing I suggest above WAS WRONG, as you see from above.

I do not even know if something like this already exists. But I now wonder why did the update go through successfully from Build 419 to 426, when these above mentioned Plugins were causing a crash. Logically, there is no such compatibility check.

Composer has things like "require" that has version number included. It follows ~1.0, 1., 1.0., >1.0, etc. So, if such a feature does not exists, then it would be helpful to have a version number check before having an update go through successfully.

The developers must be compelled to mention in the Plugin file and declare the build it is compatible with. They must give a max. number for the compatibility, for e.g. >419.

Consequently, a Plugin for October CMS >419 shall never get updated in the consumer or developer version under Build 426 until and unless the developer makes a small change of updating the compatibility version number.

If the Plugin under >419 exists already, then it should automatically deactivate it. This will prevent a crash. Further, if a Plugin is deactivated, all function calls should be sidetracked not to cause a crash.

Do you suggest that I open an new feature request on this?

[LukeTowers]

Having the developers declare their own compatibility wouldn't work quite as well as you might think. October's release cycle is continuous, so it would very quickly become arduous to be constantly updating the compatibility each plugin maintains with core.

That said, there normally shouldn't be any breaking changes in October, but unfortunately with the upgrade to Laravel 5.5 we just can't avoid them in this release cycle. We've done the best we can to prepare people for the change with http://octobercms.com/support/article/rn-9 and layers inbetween Laravel and October plugins, but some plugins are too reliant on Laravel 5.1's implementation of things. If you upgrade through the web interface (with disableCoreUpdates = false), you should have seen a warning message requiring extra confirmation that this update will likely cause issues with incompatible plugins.

[ghost]

Hello Mr. Towers,

During the update process it did warned me, as you rightly pointed out, the risk upon update.

Had I seen the date of updates, when developers updated their Plugins, I would have refrained to suggest above. So you are right again.

At some point, the incompatibility of some Plugins, that are introduced now in the developers version shall be transferred to a stable version. Thereafter, the same problem I have had shall get repeated in all consumer versions. So that does not solve the problem related to the title of this Issue, or the one I have raised here. It remains.

At least one could make a bandage available to administrators before they get hurt. How about:

If ($build equal to or greater than "426" && $laravel_version equal to or greater than "5.5" ) { set value $deavtivated_plugin; }

If the update process deactivates the Plugins automatically, the site does not become immediately inaccessible. At least that site and other Plugin remains functional.

Then one could manually check that Plugin and activate it on a temporary installation. This would keep things going, for a while at least.

[LukeTowers]

@SchneiderDe automatically deactivating people's plugins en mass is even worse then letting some incompatible plugins break some sites. If you've manually specified disableCoreUpdates = true and you update plugins without updating the core, then you're responsible for ensuring that the new versions of the plugins will work with the old version of the core.

Please restate the problem as you see it and your proposed solution.

[ghost]

Hello Mr. Towers,

The title of this Issue mentioned by @Asinox describes the error and states in the content very accurately. I had the same problem. No need to restate it.

I believe this error occurred due to incompatible Plugins after an update. Again, you are right that admins are responsible for ensuring that the new versions of the Plugins will work with the old version of the core. It would be secure to make an update on a different temporary installation.

Apart from an advice of additional responsibility by admins on the Issue, may be there is no other solution. If an update process should not be made sensitive to version compatibility, then I see no other possibility, except God, who may help us here.

[sinfuljosh]

Since I am stuck on php 5.6 for the env I am working on I am stuck in this same boat.

I was able to manually set the tag of October to 419, however from the code I have gone over. I do not see a method to do the same with their plugin:install command. I was able to track the changes between the 419 version and current and did not see much.

And I changed three lines and was able to resolve that problem while running on the non php7 build.

I basically manually reverted this change. https://github.com/rainlab/builder-plugin/commit/30a998f9f10f7d252d96438d5bab7f2b092101a3

Or if you are not comfortable with manually changing the file. Here are the two files prior to version 420.

USE ONLY IF YOU ARE STILL USING OCTOBER BUILD 419 OR EARLIER

https://raw.githubusercontent.com/rainlab/builder-plugin/8906ef1ce51accf94c550c100185fc7d2263c592/widgets/modellist/partials/_items.htm

https://raw.githubusercontent.com/rainlab/builder-plugin/8906ef1ce51accf94c550c100185fc7d2263c592/widgets/modellist/partials/_model-list.htm

Also, and I think this is a bigger issue, many plugins that are on the marketplace lack any form of version control. If the plugins had a version control and a requirements setup like most composer packages then being able to support more than just the latest build would be a non issue. (Keeping in mind that more often than not, corporate environments generally dont run the most current. and on top of that, Linux OS's like Red Hat have provided back patching and generally kept to older repo's due to security issues with newer ones)

Possible method to ensure backwards compatibility.

Yii2 is running into something similar with plugins as php7.2 becomes more common and has restricted certain class names (Object is now forbidden).

Im not familiar with the October framework that forced the need to change the operator, but If it was only a change in the class name and for the plugin its interchangable with getCollapseStatus and getGroupStatus then perhaps write code on the plugin side that checks if one of the classes exists first and if so , then route it through that class. Or fall back to the other class.

It would be one additional hop but if you are handing off the same data to both classes and getting back the same results. its just a small routing issue that could be easily added.

[LukeTowers]

@sinfuljosh it was changed because the naming was changed in October core and the old methods deprecated. The deprecated messages clutter the message log, so since this is a developer tool for building new plugins, and developers should be working on the latest versions, we made the decision to update the code to use the new code instead of the deprecated code for this plugin. If you want, submit a PR to revert that change and we can have a discussion about the merits of either decision.

[bennothommo]

Closing as it has been over a month since any activity on this occurred and we are trying to figure out what issues are still relevant. If this is still something that you would like to see through to fruition please respond and we can get the ball rolling.