Join GitHub today
ModelList::getCollapseStatus() unavailable in Build <420 #193
changed the title from
Call to undefined method RainLab\Builder\Widgets\ModelList::getCollapseStatus()
ModelList::getCollapseStatus() unavailable in Build <420
Oct 27, 2017
This was referenced
Oct 27, 2017
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.
Thereafter the entire CMS installation gives an error
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:
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.
@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
The docs (http://octobercms.com/docs/console/commands#console-install-composer) provide instructions on converting a "consumer" instance to a "developer" instance.
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.
THIS IS WRONG!
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
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.
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?
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.
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 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.
@SchneiderDe automatically deactivating people's plugins en mass is even worse then letting some incompatible plugins break some sites. If you've manually specified
Please restate the problem as you see it and your proposed solution.
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.
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. 30a998f
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
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.
@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.