Download the PHP package halestar/laravel-drop-in-cms without Composer

On this page you can find all versions of the php package halestar/laravel-drop-in-cms. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package laravel-drop-in-cms

Laravel Drop-In Content Management System

DiCMS for short

DiCMS is a content management system (CMS) made for programmers and people that need a simple CMS that gets out of the way. The issue with most CMS is that they try to do everything for you. Every CMS out there comes with its own permissions package, or users package or management for assets, etc. As a web app programmer most of the apps we build are internal apps. They come with a wonderful admin panel and maybe a users area or such, but the front side is usually left as an empty space with a promise "to be filled..."

So I built a simple CMS that is extensible with the following goals:

Table of Contents

Features

The reason I built this package is because of my other development app, FormativeLMS, which I'm currently in the process of building. This app is mainly an app that works with authenticated users, with not much happening in the front end. I wanted to create a simple blog that details my struggles and thought processes building this framework and host it in my domain.

However, what I ran into was that it was really hard to put in a front end in a laravel app. The easiest solution was to make a couple of static html pages, but I wanted to build a blog, so that was out. I started looking into blogging software and CMS software and found that all of them ame with baggage. My #1 gripe being that they all had their own users or permissions system. I wanted to use my own and not deal with a 3rd party. I just wanted 5 pages that I could maybe download a design from somewhere and type up some info. A small blog that I could type my thoughts and that's all.

But that was clearly too much. So I started building my own small thing, and it was like re-inventing the wheel. I didn't want to do this, I wanted something that I could "Drop-In" into my project. So I came out with this list of features:

Installation

The installation assumes that you have a Laravel app that you have already built or are designing. Perhaps it has an authenticated section, perhaps not. Perhaps you're just starting a new app and just run the ui/auth component and have a simple admin account, or have a sprawling list of users and guards. It does not matter, the first thing to do is to import the package into your laravel app by executing:

composer require halestar/laravel-drop-in-cms

We next publish the vendor files by doing:

php artisan vendor:publish --tag=dicms

And migrate your tables

php artisan migrate

If you would like to use your own Policies, but want to base it off existing policies, you can export all the DiCMS policies by doing:

php artisan vendor:publish --tag=dicms-policies

The last thing to do before getting started is to configure the routes. Go to your main routes file (in a normal laravel installation this would be the routes/web.php file) and add two entries at the end of the file:

It is important to understand what these two entries mean and how to configure them correctly. The first entry sets up all the admin routes, that is, all the routes to manage the CMS, to run off the /admin url. If you go to https://yoursite.com/admin then you should see the front page of your CMS admin, asking you to create your first new site.

If you, instead, wanted to run them from the url https://yoursite.com/cms you would make the entry:

If you would like to make sure that only authenticated users could reach this admin site you can change this to:

The second entry tells the system where to show the CMS website that you've built. If you don't wrap it around any prefix, then it will show up directly on the root of your website. This is why it is important to put this at the bottom of the routes files, as it will catch all the routes below it. Alternatively, if you would like your app to show the website on https://yoursite.com/front for example, you could set up the entry as:

Once you have these two routes set up, the system is up and running. The first thing you should do is login to the admin section of the CMS and create a new site. There will be instructions below for how to create your first new site.

Building your First Site

You now have your CMS system installed, and you can access the admin section of the CMS. Note that if you try to access anything in the front side of the CMS nothing will come up. That is because we don't have an active site yet! The first step is build one. From the admin menu, hit that "Create New Site" button and enter a name for your site and a title that will show up on the window. Click create and let it take you to your new site.

This CMS is not meant to be creative and allow you to do whatever you want. If that is something that you're looking for, go to word press or write your own static pages. They point of this CMS is to make this structured and logical so that you can push out content fast.

Evey site has attached to it certain components that make up the total site. The componts are:

A site can have multiple of these, but only one set to as the "Default". The Default takes over if a specific one isn't set on the page. The idea is to create a Header, Footer, Menu and link some Css sheets and Js script to make a good site outline, then fill in the content by creating pages.

Once you have all the things set up, make sure you activate the site. This will make your site "live" and you can see the results by heading to the front URL.

Securing Your CMS

The key to securing your CMS is two-fold, through routes and through Policy Objects.

Securing Through Routes

In a way, this has been done when you installed the project. Simply by wrapping the admin routes in an auth section, or applying a permissions middleware will secure all the CMS admin routes. You can go further by creating a custom middleware that will check permissions or users before giving access to the admin routes. This, essentially, gives you a coarse protection.

For most projects this will be enough. However, you can make the protections more fine-grained by the use of Policies.

Securing Through Policies

Securing through Policies is the most fine-grained approach to permissions that you can have. Essentially every model that the CMS uses has a Policy class attached to it that defines what permissions a user has when manipulating this model. All the models in DiCMS have Policies and all policies can be overridden in the config file. The list of models and policies are found in the config/dicms.php config file in the $policies array. It will usually look like this:

The left side of the array is the model, such as a Site, or a Page, the right hand side is the Policy that is attached to it. The default policy is extremely permissive, allowing users to do everything. However, you can change this by creating your own policy and overriding it.

For example, lets look at the \halestar\LaravelDropInCms\Models\Site model.This model is the representation of a Site. We see that it has the class \halestar\LaravelDropInCms\Policies\SitePolicy attached. Looking at this class the definition is quite simple:

You can immediately see that all functions in this Policy (and indeed, all policies) return true, meaning that permission is granted. So creating site will always be allowed by everyone. But what if you wanted to change this? What if you wanted the creation of sites to only be available to users with a specific permission? Well, we can extend the SitePolicy class and change it into:

Then we alter the policy's config:

Alternatively, we can add an env variable to our .env file:

Now, only the correct users can create sites.

You can publish all the Policies in the system and then tweak them to your heart's content by executing:

php artisan vendor:publish --tag=dicms-policies

Backing up your CMS

There are 3 ways to back up your CMS. Backing up means, as of version 0.4.0 a string or file representation of your database structure that can then be given to a restore method.

Programmatically

The Site can be backed up programmatically by obtaining an instance of the halestar\LaravelDropInCms\Models\SystemBackup object by instantiating it, such as:

You can then use that data to restore it by passing it to the halestar\LaravelDropInCms\Models\SystemBackup as a static function such as:

Your site's database is now restored.

Over the Web

You can back up and restore your website over the web by going to the CMS Admin site of your DiCMS install and selecting the Backups menu options. From there you'll get a page that will allow you to download a backup (aptly named backup.json), or select a file that you exported previously and restore the site.

Through Artisan

You can back up and restore the site through artisan commands. Use

You can add the optional --file=file_out.json option to save the backup to a file. To restore the Site:

This will load the data from the file_out.json file and restore your Site

Scheduled Backups

Since this project is primary aimed at developers who want to showcase a project, it was made to be easy to survive database wipes.

For example, lets say you have a demo in your app that you host for people to play with. You don't give them access to the CMS (through Policies), and you want to wipe and re-seed the database every night. You can do this in the scheduler calling this function every night:

Plugin System

DiCms has a plugin system!

Why you may ask? Because I wanted to add a blogging mechanism, but it would have complicated the development of this system. I wanted to keep it simple in what it did. The only solution then, was to make it extensible. As such, plugging support is built in by default and the first plugging, DiCmsBlogger was created to both add a blogging component to DiCms and to explain how to create plugins.

If you're interested in creating plugins, head over to DiCmsBlogger GitHub page and a description on how to build plugins will be included there.

Roadmap to 1.0

At the time of writing this, this package is not what I consider "released". My plan is officially release as a v1.0 once all the features are built. This space here is meant to detail what features and upgrades I consider essential to release a v1.0

These requirements are subject (and in fact, most likely) to change and I will cross them out (probably) as I build things.

The following features need to be implemented in order to release v1.0:

Other things may be added to this list, or taken away.


All versions of laravel-drop-in-cms with dependencies

PHP Build Version
Package Version
Requires php Version ^8.2
laravel/framework Version ^11.0.0
livewire/livewire Version ^v3.5.4
intervention/image Version ^v3.7
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package halestar/laravel-drop-in-cms contains the following files

Loading the files please wait ....