Compatibility of agentejo/cockpit and cockpithq/cockpit and docker support

Cockpit v2
1

Hi,

I am wondering about our possibilities to migrate from an old 0.11.0 version running in the previously provided docker image (agentejo/cockpit).
Now I know this version is about 3 years old and we are considering whether or not we can manage to find the resources to upgrade to v2.

However I can neither find any information on a migration guide nor does there seem to be an official docker image anymore. I found some 3 months old post here of @raffaelj working on a migration script, but not sure what the status is on this …

Am I overseeing anything? Are the version at all compatible or what are our options?

Thanks!
Tom

2

from an old 0.11.0 version

This is very outdated with security issues…

You should update at least to 0.12.2. Better update to the latest next branch and run composer update. Alternatively I have a fork, that should be compatible with PHP 8.1 (only tested with MongoLite).

running in the previously provided docker image (agentejo/cockpit)

Never trust a public docker image. Build and update it yourself regularly.

I found some 3 months old post here of @raffaelj working on a migration script, but not sure what the status is on this …

I’m debating myself, if I want to update to v2. I’m not happy about the new direction:

That’s why I didn’t spend any more time on the migrate script. It worked for a huge part, but converting field definitions was only partially implemented. I wanted to do some cleanup before publishing it as alpha release. Maybe I should publish it anyways as unfinished prototype…

3

Hi @raffaelj,

thanks for your continued activity and community support! Sorry for getting back on this only after such a long period. I am not working for the company that is using cockpit anymore and only support them in my free time, when I can.

Upgrading to 0.12.2 does not seem to cause any issues, however the official cockpit docker image is massively outdated and comes with a lot of security issues.

I was trying to get a container running with your fork, however I get some deprecation notifications, that seem to break the code. I can see it finds my singletons, collections and forms, when I am on the dashboard, but whenever I click any of them I just get a blank page.

The error seems to be resulting from a deprecation warning, which makes its way into a the URL of an API call. So I get a 401 for query to: http://localhost/collections/entries/%3Cbr%20/%3E%3Cb%3EDeprecated%3C/b%3E:%20%20basename():%20Passing%20null%20to%20parameter%20#2%20($suffix)%20of%20type%20string%20is%20deprecated%20in%20%3Cb%3E/var/www/html/lib/LimeExtra/Helper/Filesystem.php%3C/b%3E%20on%20line%20%3Cb%3E295%3C/b%3E%3Cbr%20/%3E/config/tags/field-object.tag?nc=1697195112

I am running this in the php:8.1-apache base image. Are you not seeing this issue in your running version? I am not a PHP dev by any means, the line in questions seems to be:
lib/LimeExtra/Helper/Filesystem.php #295

I will sign up for codeberg and see if I can make a PR :wink:

4

Otherwise it seems to be working just fine also with SQLLite!

5

I think, I did the most tests only for PHP 8.0. And I switched versions with existing data of a few local test instances. So I might have missed a few things, that could break while editing…

I’ll have another look soon… (before PHP 8.0 EOL)

Thanks for the fix on Codeberg.

6

@tommueller Finally I was able to reproduce your issue. It turns out, that I don’t use custom tags in the #config folder in my test instances. Most other file system tasks use the leage flysystem library.

I reverted your change in my fork and replaced it with a correct one:

-    public function getBasename(?string $suffix = null): string {
+    public function getBasename(string $suffix = ''): string {

See also: PHP: SplFileInfo::getBasename - Manual
And: PHP: basename - Manual

This issue also appears in v2: https://github.com/Cockpit-HQ/Cockpit/blob/develop/lib/Lime/Helper/Filesystem.php#L290