Cockpit implementation in PHP application

#1

I’m aware that headless CMSs such as Cockpit are designed to be used over a variety of platforms (not just websites), but let me explain my specific scenario.

I currently develop websites primarily in monolithic frameworks such as WordPress. I now wish to replace this with Cockpit. At present, the websites that I want to develop are just simple brochure websites - so their content will most likely never be consumed on other platforms.

I want to know what is the best way I should implement Cockpit in my websites? For the front end I will use a custom built PHP framework, or maybe Laravel in some cases. So I guess I could use something like Guzzle for the API calls.

My idea is to place Cockpit in a subfolder of the website structure, and so my clients can access the CMS by going to /cms.

Is there anything wrong with this approach? Is there a better way to do it?

#2

Hi!

this is totally possible. Just add cockpit in a subfolder and the only thing you have to do is to

include 'cockpitfolder/bootstrap.php'

anywhere in your code to get full access to the cockpit api.

e.g. to get all posts of the posts collection:

$posts = cockpit('collections')->find('posts', [
   'filter' => ['published' => true],
   'limit' => 10
]);
1 Like
#3

Excellent. So am I right in assuming I would need to include the Cockpit subfolder in my Git repository?

#4

One more question. What is the best way to create “pages” for a website? So let’s say I want to build a 5 page website (home, about, services, service details, contact). I want my client to go in the CMS, click the page and be able to edit the content. Each page has the following fields:

  • Title (SEO)
  • Description (SEO)
  • Heading
  • Sub heading
  • Banner image
  • Content

However some pages will also contain some specific fields, e.g. on the Contact page there will be a field to enter Google Maps embed code.

Now I think the closest thing to achieve this in Cockpit is “Singletons”. The only issue with this is that I would have to create the fields repeatedly for each page. Is there a way to have a singleton which extends a “base” singleton, which contains all of the above fields?

#5

Anyone able to advise on my last 2 posts?

#6

You can have a page content composed by the fields you described:

  • Title - textfield (can be used to generate also the page slug)
  • Description - textarea (limited to 155 chars), you may use it in your FE also for og and twitter card description
  • Banner - asset (don’t use image field but asset instead, you can take a look on the imagestyles addon to have images automatically resized for your fe)
  • Content - my suggestion is to use the LayoutComponents module and use the core components or build your own, it results in a better user experience and you can handle them better in the fe. That will also help with the specific aspects of each page like the google map embed code.
#7

Hey, thanks for your reply.

So just to clarify, do I create “pages” as a collection or singleton?

And secondly how do I include a LayoutComponent? I have managed to create one but I cannot work out how to include it as a field.

EDIT: I think I’ve figured this out. Thanks for your help!

#8

Contents that may have many entries (e.g. pages, taxomies, etc…) should be on Collections, Singletons are for a different purpose (you can use it for storing settings, blocks of data, etc…).

To use core components you only need to create a field of type Layout in your collection.
If you want to build your own components you need https://github.com/agentejo/LayoutComponents addon (and then go to settings / layout components)

#9

@gstar If you build a PHP app, maybe Monoplane is interesting for you. I solved a lot of edge cases already and it is based on the same structure, like you suggested. I use it with one collection named “pages” and one singleton named “config” and a handful of custom controllers for different collections, forms etc.