Cockpit as a composer dependency?

Support
1

Maybe I’m misunderstanding the intended implementation of Cockpit, but I will provide some background first.

I tend to develop web applications in MVC frameworks such as Laravel, Symfony, etc. Often these are basic e-commerce or brochure sites, and for any CMS functionality I build a custom CMS in the admin area.

This works fine up until a point, where the client needs more advanced CMS functionality, in which case it becomes tedious to build more and more bespoke CMS modules.

So then you have the choice of using a CMS-first framework, such as OctoberCMS, Craft or even WordPress. However these are not ideal as you have to build your application around the CMS, instead of the other way round. That’s where the idea of Cockpit appealed to me.

However I’m a bit confused as to how it should be implemented in an MVC framework. Almost all frameworks use Composer to install dependencies, and Cockpit doesn’t seem to come as a Composer dependency - or at least not that I know of.

So the ideal scenario would be for Cockpit to be installed via Composer in to the application vendor folder, and the database / media to exist in the application’s structure itself. This way Cockpit can be safely and easily updated whenever a new release is out and does not need to exist in Git.

Or is this not how Cockpit is meant to be used? Can somebody shed some light on this please?

2

It would be a good idea to have it available via Composer, however Cockpit should be installed in its own environment, on its own domain / subdomain.

1 Like
3

Hi ChristianE, thanks for your reply.

Is there any reason why Cockpit should be installed in its own environment? Is there anywhere that explains this process?

The installation instructions simply tell us to download the zip file in to a subdirectory of the website: https://getcockpit.com/documentation/getting-started/installation

I can get Cockpit working fine by doing this, but I don’t really like the idea of having Cockpit in my public folder, when really it should be outside of public and if it were to be a Composer package it could just be in the vendor folder.

Still a bit confused!:confused:

4

@gstar, the intent of cockpit is to be more than a simple dependency/library for other projects, but instead a full headless CMS, where you login and manage contents that will be consumed via the Rest API.

The current way of installing is quite straightforward, you still have some flexibility in terms of setup, for example, you can just have it in a different docroot and access it using nginx reverse proxy.

1 Like