OpenSparrow – open-source admin panel builder, zero dependencies, v2.1 just dropped
Hey everyone!
I want to share a project I've been building — OpenSparrow, an open-source visual admin panel framework.
The idea: connect it to a PostgreSQL database, and you get a fully working admin panel — tables, forms, dashboards, calendar, file uploads — configured entirely through a visual /admin interface. No JSON to write by hand.
The stack is minimalist: PHP 8.1+, PostgreSQL, Vanilla JS. No npm. No Composer. No jQuery. No external libraries on either side. Pure code only.
What you get out of the box:
- Visual table builder — create columns, set types, foreign keys, validation rules — all in the UI.
- Full CRUD with inline cell editing, searchable FK columns, and subtables.
- Dashboard builder — stat cards, KPI cards, bar/pie charts, and data lists with live WHERE filters.
- Calendar view + cron-based notifications.
- Audit trail + optional record snapshots (full JSONB history of every change).
- User roles: Admin, Editor, Viewer.
- Security defaults: rate limiting, CSRF, session fingerprinting, HSTS.
LGPL v3 — free for commercial use.
Version 2.1 just released with a major UX overhaul, new modules, and security fixes. More on that in the next post.
Feedback and contributors are very welcome!
Top comments (4)
The fact that there is a packagage.json but no composer.json file for a PHP test library makes me question the code quality.
My first look at the index.php already showed me several questionable decisions.
config.php is filled with global constants. That is considered a bad practice for a long time now.
Setting the session, doing the routing, setting headers in index.php means this is happening in all the public PHP files. This repeating of code is going to cause problems at some point.
Also exposing the php files as endpoints is very old school. This means login.php is going to be hammered. I seen that login.php has brute force protection, but not api.php.
When I opened create.php I saw there is a bootstrap.php file with autoloading. So why is that way of working not used for all public PHP files?
Why have HTML, CSS in files like login.php and create.php while there is a templates directory.
To summarise this feels like a project that is written by someone who wants to write 2000's PHP code and 2015's PHP code.
If you want to continue the project I suggest to look at the best practices of current PHP codebases, and try to find a consistent way of working.
@xwero Thank you for taking the time to review the project and sharing such detailed feedback — it's genuinely appreciated.
You raise some valid points, particularly around the inconsistent use of
bootstrap.phpand the session setup being repeated across multiple files. These are real maintenance concerns and we plan to address them.Some of the other observations reflect deliberate trade-offs: the project intentionally avoids Composer and build steps to stay lightweight and easy to self-host, and the
package.jsonis solely for Cypress E2E tests. The security layer (CSRF, argon2id, CSP nonces, parameterized queries) is more current than the file structure might suggest at first glance.That said, the inconsistency between the modern
src/layer and the older-style entry points is something we're actively working to clean up. Your feedback helps prioritize that.Thanks again — feedback like this makes the project better.
Yes that is one of the problems I addressed. Even if you don't want to use Composer for project dependencies, at least add it for PHPUnit or another test library.
Only having e2e tests makes it harder to debug the project when things go wrong. Having unit and integration tests give earlier warnings.
Fair point, and well taken. You're right that relying solely on E2E tests means slow feedback and makes debugging harder when something breaks deeper in the stack.
The
src/directory already has a number of interfaces and classes that are well-suited for unit testing. Addingcomposer.jsonas a dev-only dependency (PHPUnit, nothing that touches production) is a reasonable next step and we'll add it to the backlog.Thanks for pushing on this — it's a gap worth closing.