Forem: giuliopanda

EAV: a fascinating, but often dangerous pattern

giuliopanda — Tue, 10 Mar 2026 16:29:53 +0000

The Entity-Attribute-Value (EAV) model is a solution that initially looks very clever.
It allows developers to add new fields without changing the database structure.
For this reason it has often been used in CMSs, e-commerce platforms, and systems that support dynamic fields.

The idea is simple: instead of storing data in tables with fixed columns such as name, surname, or age,
data is saved as generic rows composed of entity, attribute, and value.
This makes the database very flexible, but that flexibility comes with a cost.

Why it is still used today

EAV is still widely used because it allows systems to support custom fields,
add extensions without modifying the database schema,
and keep a structure that appears stable over time.
For these reasons it still appears in many modern projects, including those written in PHP.

The problem is that what looks convenient at the beginning can become complicated as the project grows.

Main problems

The first issue is query complexity.
In a traditional relational database, reading data is simple and direct.
With EAV, even basic operations often require multiple joins,
data transformations, and logic that is harder to optimize.

The second issue is performance.
EAV tables tend to grow very quickly,
indexes become less effective,
and the database has to work harder to perform fast searches.

There is also a data integrity problem.
In a traditional relational model, the database itself can enforce types, constraints, and consistency.
With EAV, many of these guarantees move into the application code,
which can make the system more fragile.

Finally, EAV makes the database harder to understand.
In a relational system the structure is visible directly in the tables.
In an EAV system the real structure is hidden inside the data itself
and often has to be reconstructed by reading queries and application logic.

Why it made sense in the past

Historically, EAV also became popular because modifying database tables used to be risky.
Operations such as ALTER TABLE could lock large tables or require long downtime.
To avoid these problems, many systems preferred to use a generic structure.

Today, however, modern relational databases handle schema changes much better.
In many cases adding a column is much simpler and safer than it used to be.

Conclusion

The real advantage of EAV is flexibility,
but that flexibility often comes at the cost of slower queries,
more complex code,
less clarity,
and weaker data management.

For many modern systems, modifying the database structure directly can be a better choice:
clearer, faster, and easier to maintain over time.

Inside MilkAdmin I decided to experiment with this idea by building an admin form system
that, instead of using EAV, modifies the structure of the original database tables directly.

giuliopanda / milk-admin

Open-source PHP admin panel and dashboard built with Bootstrap 5 — relational CRUD generator, authentication, REST API, CLI, modular architecture, MySQL & SQLite.

Milk Admin

Milk Admin is a PHP framework for building backoffice and internal management tools — without framework lock-in, SaaS dependencies, or vendor tie-ins.

Project Status: Beta The core architecture is stable. Actively developed toward a 1.0 release in mid-2026.

Official links: Website · Documentation · Live Demo

The Form Builder That Generates Code

Most form builders store their configuration in the database and generate forms at runtime. Milk Admin is different.

The Projects module lets you design modules visually — tables, forms, field types, relations — and generates real PHP modules that you own completely.

How it works:

The builder generates PHP modules extended by JSON configuration files
The JSON layer handles the builder's configuration updates
The PHP code is always the final authority — modify, extend, or rewrite freely
Both layers coexist: you can start with the builder and continue with code

This means you can prototype rapidly…

View on GitHub

An Independent backoffice for WordPress?

giuliopanda — Sun, 15 Feb 2026 21:51:15 +0000

It All Started with Metadata

Milk Admin natively relies on two separate databases — one for internal configuration, the other for managing external data. This architecture made it a natural candidate for integration with external systems, such as a WordPress database.

Once connected, I was able to start managing a WordPress site's tables directly from my panel. From there, an immediate need emerged: handling metadata relationships natively. I looked at how the most well-known and mature systems similar to mine handled this, and I found that there usually isn't a native system for it. So I wrote hasMeta, a method that handles native metadata relationships.

How it looks in a model definition

$rule->table('#__users')
    ->id()
        ->hasMeta('nickname', UserMetaModel::class, 'user_id')
        ->hasMeta('city', UserMetaModel::class, 'user_id')
    ->string('name', 100)->required();

Then there are a number of other small conventions I inherited from WordPress: the dynamic table prefix (#__) and a functions.php file for more advanced customizations.

A Small Personal Win

Every now and then I try to promote my work — I'm terrible at it, but I try. When I showed the metadata functionality to a client of mine, his reaction was enthusiastic. He asked me for a demo… that had nothing to do with metadata. He wanted to verify whether my admin panel could handle WordPress authentication.

A different request than expected, but an exciting one, so I got to work.

The WordPress Plugin

I developed a plugin that hooks into WordPress's authenticate filter, with priority 30, to intervene after the standard checks:

add_filter('authenticate', [$this, 'authenticate'], 30, 3);

The method receives three parameters: $user (the result of previous checks), $username, and $password. If conditions require it, the plugin makes a POST call to my admin panel's endpoint via wp_remote_post:

$args = [
    'headers' => ['Content-Type' => 'application/json'],
    'timeout' => (int)$options['request_timeout'],
    'body'    => wp_json_encode([
        'username' => $username,
        'password' => $password,
    ]),
];

$response = wp_remote_post($endpoint, $args);

The Authentication Endpoint

On the Milk Admin side, I created a dedicated module that exposes a public endpoint for credential verification:

#[ApiEndpoint('public-auth/check-credentials', 'POST')]

Reachable with a simple call:

POST /public_html/api.php?page=public-auth/check-credentials
Content-Type: application/json

{
  "username": "user@example.com",
  "password": "password"
}

For this demo the table only contains username and password, but nothing prevents extending the response with additional data such as roles, permissions, or profile information.

Key design choices

The plugin is designed not to interfere with administrators and not to block the native flow when username or password are empty: in those cases, WordPress handles everything as usual.

Final Thoughts

What started as an experiment with metadata turned into a concrete demonstration of interoperability. My admin panel doesn't replace WordPress — it works alongside it: it makes it easy to create a management panel that extends WordPress data, but I discovered it can also integrate well via API.

Github project

MilkAdmin 0.9.0 - Toward a First Stable Version

giuliopanda — Mon, 26 Jan 2026 10:38:42 +0000

MilkAdmin is a lightweight PHP admin panel, designed to remain understandable even after a long time. With version 0.9.0, it officially enters beta phase: it's not yet a 1.0, but it's the point where this system now has a clear, coherent shape and, most importantly, will be used in a real project.

Why MilkAdmin Exists

MilkAdmin is a personal project, born from a very practical need.

I don't usually work on backends based on popular frameworks: I work on various PHP products developed for specific needs. However, I wasn't able to develop even simple backends.

I tried studying a backoffice like Filament, but after abandoning it for a while, when I tried to pick it up again I realized how difficult it was to re-orient myself. I would have had to start practically from scratch.

Hence the idea: create a system that remains understandable even after months of inactivity, a project that, once reopened, allows you to immediately understand what you had done and why.

At first it was just an idea, I didn't think I would ever complete it, also because it was objectively more work than studying Filament. So at the beginning I tentatively made small experiments on creating a framework, from there I started trying to understand how in my opinion a system should behave. Then over time it became a hobby, and eventually something much more mature than I expected.

The Philosophy: Simplicity and Control

The main goal of MilkAdmin is to remain understandable even after a long time.

The idea is that, when opening a module, it should be easy to understand how it's structured, what data it manages, how they are validated, how they are connected to other data, and how they are used in the backend - even if you don't remember how the framework works. However, I wanted the creation of a basic CRUD to be very concise, so I reformulated where concepts should be written.

namespace Local\Modules\Recipe;
use App\Abstracts\AbstractModel;

class RecipeModel extends AbstractModel
{
    protected function configure($rule): void
    {
        $rule->table('#__recipes')
            ->id()
            ->title('name')->index()
            ->text('ingredients')->formType('textarea')
            ->select('difficulty', ['Easy', 'Medium', 'Hard']);
    }
}

Then I reflected on what the use case might be: In real business contexts, data often already exists, coming from Excel, SharePoint, or legacy flows, and cannot always be reorganized according to ideal schemas. MilkAdmin deliberately stays close to PHP, without excessive abstractions, leaving full control over queries, relationships, and flows.

Let's Be Realistic: I Don't Expect MilkAdmin to Be Adopted by Other Projects

An Admin Panel that doesn't use Laravel or Symfony doesn't attract the community's attention, and I'm perfectly aware of that.

I'm an "old-school" programmer: I prefer clear code over abstract code, even if it's less "elegant" by certain standards. Sometimes files are long, I still use static classes, and if the code is readable and works, that's fine by me.

What I care about, instead, is open source: sharing your own work and studies to create a dialogue that doesn't necessarily need to involve large numbers, but that can be useful even to just a few people.

At this point, if the project intrigues you, head over to GitHub, and if you'd like to leave a star - it would make me very happy.

GitHub Repository

These reflections come from the development of MilkAdmin, a PHP admin panel system I actively maintain. Code, demos, and documentation are available at milkadmin.org. MIT licensed.

When CRUD Tables Are No Longer Enough

giuliopanda — Fri, 09 Jan 2026 21:43:50 +0000

Anyone who has built an admin panel in PHP knows how this story usually ends. At the beginning, everything is simple: a table, a form, a couple of filters. Then real requirements arrive — relationships between data, more complex flows, partial updates — and the classic “table + form” CRUD starts to crack.

It’s not CRUD’s fault. The problem is that admin interfaces are not just CRUD.
A real admin needs to see data in different contexts, navigate relationships without losing state, and edit related entities quickly.

These reflections led me to explore different approaches, until I decided to build a system from scratch, outside of the most popular frameworks. This is where I ended up.

A Different Way to Think About the Problem
Instead of thinking “I need to build a page”, I started thinking “I need to describe a view of this data”.
This led me to builders: PHP objects that describe what to display and how. Not frontend components, not magic widgets — just PHP structures that generate HTML, handle queries, and return either HTML or JSON responses.
The code stays PHP. The flow stays request → processing → response.

A Concrete Example: Posts
Let’s start with the simplest case: a module to manage posts with a title and content.

The Model defines the data structure

class PostsModel extends AbstractModel
{
    protected function configure($rule): void
    {
        $rule->table('#__posts')
            ->id()
            ->string('title')->index()
            ->text('content')->formType('editor');
    }

    #[Validate('title')]
    public function validateTitle($current_record_obj): string {
        $value = $current_record_obj->title;
        if (strlen($value) < 5) {
            return 'Title must be at least 5 characters long';
        }
        return '';
    }
}

The model is the source of truth. It declares the table, the fields, how they should appear in forms, and where validation belongs — in the model, where it actually makes sense.

The Controller uses builders to generate views

class PostsController extends AbstractController
{ 
    #[RequestAction('home')]
    public function postsList() {
        $tableBuilder = TableBuilder::create($this->model, 'idTablePosts')
            ->field('content')->truncate(50)
            ->field('title')->link('?page=posts&action=edit&id=%id%')
            ->setDefaultActions();

        $response = array_merge($this->getCommonData(), $tableBuilder->getResponse());
        Response::render(MILK_DIR . '/Theme/SharedViews/list_page.php', $response);
    }

    #[RequestAction('edit')]
    public function postEdit() {
        $response = $this->getCommonData();
        $response['form'] = FormBuilder::create($this->model, $this->page)->getForm();
        Response::render(MILK_DIR . '/Theme/SharedViews/edit_page.php', $response);
    }
}

TableBuilder already knows how to handle search, pagination, and sorting. FormBuilder knows which fields to show and how to validate them. You describe what you want — the builders generate the rest.

Views are plain PHP templates — no templating engines, no special syntax. If you need to change something, you open the file and edit the HTML directly.

Where Things Get Complicated: Relationships

Simple CRUD works everywhere. Problems start when entities are related.

Recipes
 └─ Comments

When relationships become interactive, the usual options are either: splitting everything into multiple pages (losing fluidity), or relying on heavy frameworks that manage state for you (losing transparency and control).

Tools like Laravel Nova or Filament are powerful and work well in structured teams. But when flows become very specific, it can be hard to understand what is really happening between backend and frontend.

I wanted a different approach: keep everything in PHP, use fetch to avoid page reloads, but without hiding what’s going on.

Recipes: CRUD with Relationships, Fully in Fetch

This is the full example: recipes with comments, two interface levels, no page reloads.

Recipe model

class RecipeModel extends AbstractModel
{
   protected function configure($rule): void
   {
        $rule->table('#__recipes')
            ->id()
            ->hasMany('comments', RecipeCommentsModel::class, 'recipe_id')
            ->image('image')
            ->title('name')->index()
            ->text('ingredients')->formType('textarea')
            ->select('difficulty', ['Easy', 'Medium', 'Hard']);
   }
}

In just a few lines, it defines the table, the one-to-many relationship, and the field types. The builders automatically know how to handle uploads, selects, and text areas.

Comments model

class RecipeCommentsModel extends AbstractModel
{
    protected function configure($rule): void
    {
        $rule->table('#__recipe_comments')
            ->id()
            ->int('recipe_id')->formType('hidden')
            ->text('comment');
    }
}

Everything else — lists, offcanvas forms, modals, automatic refresh — is built using the same builders and the same mental model.

Why This Approach
This is not another framework. It’s a way of thinking about admin panels.
Builders reduce boilerplate, but the code remains readable PHP. If a builder doesn’t do what you need, you can always drop down to plain PHP.
JSON as a contract between backend and frontend is easy to debug. No hidden state, no complex lifecycles. PHP sends instructions, the browser executes them.
Most importantly, relationships are handled with the same tools as basic CRUD. There’s no separate system to learn just for relations.

Who This Is For
If you work with Laravel and you’re happy with it, this is probably not for you.

But if you find yourself in one of these situations:

You maintain existing PHP projects that can’t be migrated
You work on internal tools, CRMs, or management systems
You need to understand the code quickly, even months later
You don’t want to chase complex ecosystems
You want PHP that looks and feels like PHP
Then it might be worth rethinking how we build admin interfaces.

Admin panels are not public websites. They are work tools. And the best tools are those that do their job well, remain understandable over time, and don’t force you to rewrite everything when requirements change.

These reflections come from the development of MilkAdmin, a PHP admin panel system I actively maintain. Code, demos, and documentation are available at milkadmin.org. MIT licensed.

https://github.com/giuliopanda/milk-admin

Is it time to introduce milkadmin?

giuliopanda — Tue, 25 Nov 2025 15:11:38 +0000

I've been working for some time on a simple, lightweight core admin for PHP. It's a basic administrative environment: login, user & permission management, install and updates. I'm finally ready to talk about it.

It's an open-source project I called MilkAdmin.

Installation is "the old way", like WordPress: copy it to the server and you're up and running. You get a minimal environment with access to two databases: one for internal configuration (works well with SQLite) and a second one for your application data.

Development

I'll keep this short and give a few practical examples.

A page in seconds

To create a new page (with a menu entry) you just define a module:

class CupOfMilk extends AbstractModule { protected function configure($rule): void { $rule->page('cup') ->menu('A cup of milk', '', 'bi bi-cup-hot-fill') ->access('registered'); } }

Build Calendar Example
The configure method enforces a clear and consistent structure for module rules.

Attributes to keep code readable

I make heavy use of PHP attributes to identify actions and methods:

#[RequestAction('home')] public function helloWorld() { Response::render('<h1>Hello World</h1>', []); }

The models

Models follow a classic approach but use a compact, expressive syntax:

class MyModel extends AbstractModel { protected function configure($rule): void { $rule->table('#__posts') ->id() ->title()->index() ->text('content')->formType('editor') ->created_at()->hideFromEdit() ->datetime('updated_at')->hideFromEdit()->saveValue(date('Y-m-d H:i:s')); } }

Built-in builders

Even though the core is minimalist, I built a set of builders for tables, forms, lists and other UI elements. In the latest version I added a CalendarBuilder:

$calendar = CalendarBuilder::create($this->model, $calendar_id) ->mapFields([ 'id' => 'id', 'title' => 'title', 'start_datetime' => 'start_datetime', 'end_datetime' => 'end_datetime', 'class' => function($event, $event_raw) { return $event_raw->event_class; } ]) ->setMonthYear($month, $year) ->setHeaderTitle('Events Calendar') ->setHeaderIcon('bi-calendar-event') ->onAppointmentClick('?page='.$this->page.'&action=edit&id=%id%') ->onEmptyDateClick('?page='.$this->page.'&action=edit&date=%date%') ->setHeaderColor('primary');

Other features

Very few dependencies.
No external JavaScript libraries. The project includes a small internal system for AJAX responses and theme element handling.
Example: to show a modal from a server response you can return JSON like this:
Response::json([ 'status' => 'success', 'modal' => [ 'action' => 'show', 'title' => 'Hello World', 'body' => 'Hello World', ] ]);

There's also an integrated permission system and attention to security. For now, I do not recommend using MilkAdmin in production projects without a security review.

The ideal user

I know there are mature, powerful solutions for admin panels. But if you work with WordPress or other PHP platforms, you may not have the time or desire to learn large frameworks, nor to download thousands of files to create a simple table.

MilkAdmin aims to be a lightweight support system, easy to integrate with other systems, and that lets you fall back to plain PHP when needed.

Work in progress

MilkAdmin is not the destination, it's a base for building your ideas. My long-term goal is to develop an advanced reporting system; what's yours?

For a quick experiment, try MilkAdmin on a small personal project: a book list, a link catalog, or a private calendar.

Links

View the repository on GitHub: https://github.com/giuliopanda/milk-admin Visit the project site: https://www.milkadmin.org/

Tip: the Star button is at the top-right corner of the GitHub repository page. If you like the project, please click the star there.

Call to action

If you find MilkAdmin interesting, please give it a try and star the repo. Stars are the first sign of success for an open-source project.

Want help formatting this?

I can also:

adapt this as a Medium or blog post;
prepare a LinkedIn announcement;
turn it into a README or a more technical write-up.

Would you like me to prepare the LinkedIn version as well?

Reinventing the Wheel: A Reflection on Software Development and Open Source

giuliopanda — Mon, 10 Nov 2025 14:17:09 +0000

Reinventing the Wheel: A Reflection on Software Development and Open Source

I'm working on an open-source project called Milk Admin: a PHP admin core designed to quickly build supporting administrative backends. The project isn't ready yet, but if you feel like taking a look, I'd be happy.
But that's not what I wanted to talk about.
A couple of months ago, I posted an article about it on an Italian forum. I was very surprised by the comments, and I decided to write this piece to reflect on how the open-source software landscape has changed.

The Time Before Certainties

When I started developing for the web, the world was split in two: those who used CMSs, and those who wrote everything from scratch. As strange as it may sound today, building from scratch was still a respected approach'also because it showed you knew how to program. The code was often questionable, sure, but there was tolerance: the important thing was that it worked.

A few years later, using Joomla, I developed an open-source component that found some success. I never knew exactly how many people downloaded or used it, but over time I received thanks, donations, and collaboration proposals.

The Rise of Standards (and the Shift in Mindset)

Then something changed in the PHP world. With WordPress in particular, a different model emerged: open source as a showcase for premium versions. A perfectly legitimate business strategy, but one that profoundly reshaped community dynamics. In my small personal experience, I had a terrible time developing WordPress plugins'I found its community truly unpleasant and surprisingly ignorant.

Even Richard Stallman had raised concerns about the open-source development model. But the world changes, and we have to adapt.

With the rise of frameworks like Laravel and Symfony came a new mantra: don't reinvent the wheel. Sensible in theory. But it evolved into something more rigid: the idea that there are 'right' and 'wrong' ways to do things, and that innovation means learning to use existing tools better'not creating new ones.

Companies embraced this approach enthusiastically: standards mean interchangeability, replaceable resources, fast onboarding. Economically, it makes sense. Culturally, something may have been lost.

The Trial by Fire

When I introduced the project I mentioned at the start, the reaction I received was almost hostile. It struck me, because in the end it's free code'you can like it or ignore it, but criticizing it feels like an attitude I struggle to understand.

And the objections weren't even about how it actually worked. Basically, they criticized the fact that more sophisticated tools like Filament already exist. Others complained that it didn't follow modern programming standards. Few seemed to have actually tried the code. The judgment was pre-emptive, based on abstract principles rather than concrete issues.

Why Keep Reinventing

I thought about abandoning the project. But then I stopped to reflect on what drives me to program. It's not just solving problems'that's my job. It's understanding how things work. It's exploring. It's learning by re-programming the obvious.

Just last week I was explaining why namespaces are supposed to follow folder structure. Logically, organizing them by concept would make more sense. But it's a standard, so it's not up for discussion. Except'sometimes we should question whether better ways of doing things might exist. Reflecting on that every now and then isn't a bad thing.

If everyone stopped building CMSs because 'there's WordPress,' if no one created new frameworks because 'there's Laravel,' how many opportunities would be lost?
If no one had ever reinvented the wheel, our cars today would still be rolling on stone wheels.

What to Choose for Creating a PHP Admin Panel?

giuliopanda — Mon, 18 Aug 2025 16:34:26 +0000

I'm sharing my hands-on tests of installing and making initial modifications to various admin panels.

Companies often need to develop internal administrative systems: dashboards, CRUD panels, reports, notifications, and other management tools. The reasons vary. Even though the initial goal is often to "build something quickly" without reinventing the wheel, the work requires skills, time, and solid architecture.

The Dilemma: What to Use to Build It?

I tested several open-source products to evaluate the possible options available on the market. In this article, I share my direct experience of installing and modifying some of the most popular open-source products.

Laravel-based Solutions

These are the descriptions and considerations found online:

Filament
Excellent if you're already using Laravel. Filament is a modern admin panel that allows you to create CRUD interfaces, tables, charts, and dashboards with just a few lines of code. It's built around the TALL stack (Tailwind, Alpine, Laravel, Livewire).
Backpack for Laravel
A simpler alternative to Filament, based on Bootstrap. Also great for developers with limited experience in Laravel.
MoonShine
A lightweight and quick-to-configure admin panel. Promises a working CRUD setup in less than 5 minutes. Ideal for getting started quickly.

My experience: I only tested Filament among these. It has extensive documentation. However, navigating Laravel installations for someone who doesn't know it requires some time to get oriented (it took me half an hour to install it, but obviously those who know it do everything in 5 minutes). I encountered some silly problems, but perhaps the documentation, although extensive, wasn't that clear. First you create the Laravel project, then you add Filament - it's obvious, but in haste I had gotten the order wrong. Additionally, the guide assumed you needed to use artisan serve. With regular Apache, the login appeared but wouldn't let you in, and I initially thought the error was related to file permissions. In the end, it took me three-quarters of an hour to access it. To create a "hello world" page, after consulting the documentation I had to ask an AI for help, and thanks to this I succeeded in half an hour, but honestly I don't feel like I understood the structure and how to modify it (and I had even taken a brief Laravel course some time ago). I had to modify 5 different files. The impression is that if you're not a Laravel expert, you risk not being able to separate the code correctly, creating a structure that's difficult to maintain over time. After an hour and a half I have an installation still without user management.

Specialized Frameworks

4. UserFrosting

A framework built specifically for user management, with roles, permissions, modules, and ready-to-use dashboards.

My experience: The shell installation is well done, but with some small naivety: on the first attempt I set a password that was too short and the system crashed. On the second attempt, everything went well. In 8 minutes I had the server ready and managed to log in. Very nice, although the tables are strangely slow to load. It has everything necessary: users, activities, roles, permissions, and groups. The code is clear, but the documentation a bit less so I had to consult Claude to understand how to create a page. However, after finishing the work I understood quite well how to intervene in the code. Unfortunately, it seems somewhat outdated now. It uses Bootstrap v3.4.1. Total test time: 45 minutes.

5. UserSpice

A lightweight solution for basic login, roles, and simple CRUD operations.

My experience: You download the package and install it by opening it from the browser. I admit it's the system I prefer: clean and clear interface, 5 minutes and I'm in. In just 15 minutes I created a new widget by myself. The structure is very well done. After just 20 minutes, in addition to the widget I also created a "hello world" page. Very complete and mature. It doesn't seem to use PSR, but I must say you don't miss it. Well updated, very complete with 57 initial tables. Particular is that on GitHub there's no code present, only documentation and a hotfix folder.

6. Bonfire (CodeIgniter 4)

A starter kit for CodeIgniter 4, complete with everything necessary to start an administrative app: login, user management, roles, dashboard, logs, settings.

My experience: I had to repeat the installation 3 times: the first time I skipped a command (but the documentation misled me), the second time I had a problem with localhost ports (I think a spark bug). The third time it finally went well and I was able to access the administration. I was happy to have persisted because it's the administrative system I liked most. Essential: User, settings, and tools. What you need to start developing. The user tab is complete: in addition to basic data, we find permissions, access logs, and the ability to change the password. Underneath there's CodeIgniter which is a very solid framework. The settings are particularly well crafted!

7. Milk Admin

An admin panel designed for creating your own administrative applications.

My experience: This entire test was done to see the various online products and compare them with the project I'm developing. Milk Admin is a solution aimed more at development like Bonfire or Filament, but which uses an approach close to UserSpice. It installs in 5 minutes from browser and not from shell and doesn't require particular knowledge to start modifying it. It's modular and user and permission management is limited to the essentials to make it as easy possible. It allows you to manage CRUD, APIs, cron jobs, and the product installation update flow.

Conclusion

If you're already an expert in a framework, it obviously makes sense to use the tools of that framework, but otherwise the learning curve of Laravel or CodeIgniter can be too steep, especially if you don't plan to have continuous development in that area. In this case, solutions like UserSpice or MilkAdmin can be more immediate and practical.