Gibbon Core: the PHP school platform behind a module system

What the Core repository actually contains

The README is explicit about the division of labour. The Core repository represents the bulk of Gibbon, including all of its primary functionality, and the core can be extended through the use of modules and themes, which are provided separately. That sentence is the architecture in one line: a school runs the core, then adds what it needs from the extension ecosystem, and the project points at the Extend page on its website for more on that. The audience is stated in the same paragraph, a flexible open source school management platform designed to make life better for teachers, students, parents and schools. The homepage is gibbonedu.org and the full documentation lives on a separate domain at docs.gibbonedu.org. The default branch is v31.0.00, a version-named branch rather than master, which is worth noticing when you clone, and the project is licensed under the GNU General Public License v3.0.

A PHP application with a SQL schema and an installer

The repository layout is what a traditional PHP application looks like, and it tells you how the thing is put together. At the top level there is gibbon.php as the front controller, index.php, login.php, logout.php, and a long list of process endpoints named for the action they handle, such as preferencesProcess.php, notificationsActionProcess.php, passwordResetProcess.php and publicRegistrationProcess.php, each with an accompanying index_..._ajax.php where the interface is asynchronous. There are also export.php, report.php and indexExport.php for data output, and index_fastFinder_ajax.php for the quick search. A gibbon.sql file and a gibbon_demo.sql file sit alongside an installer/ directory, which tells you the schema ships as SQL and there is a guided installer rather than a migration-only deployment. The modules/ directory is the extension point, the lib/ directory holds shared code, and the i18n directory holds translations. There is also a cli/ directory and a composer.json with a composer.lock, so dependencies are pinned, and phpstan.neon for static analysis.

The Docker setup exists so contributors do not configure PHP by hand

The Docker development setup is the most useful thing in the repository for anyone evaluating the project, because it removes the environment work rather than describing it. The README states the intent plainly: contributors can run Gibbon without manually installing and configuring PHP, Apache and MySQL on their machine. The prerequisite is Docker Desktop. From the project root, one script does the work.

./up.sh

The script checks that a .env file exists and creates it if not, checks that Docker Desktop is installed and running, and builds and starts the Gibbon development server container. The application is then available on port 8080 on localhost.

./up.sh down

That second command stops the development environment and removes volumes, which is the one a contributor should remember, because removing the volumes is what resets the database to a clean state after schema experiments. The third shows the live container logs.

./up.sh logs

So the whole local loop is three subcommands of one shell script, and the only configuration file you touch is the .env the script creates for you. For a project whose real installation is a manual procedure, this is the difference between a ten-minute evaluation and a weekend one.

Production installation is a documented procedure, not a script

The contrast with the Docker path is deliberate and worth stating. For a real installation the README does not give commands at all; it sends you to the documentation page titled Getting Started: Installing Gibbon, and for support it points at ask.gibbonedu.org as well as the documentation site. That is the honest shape of the project. A school deployment involves setting up a web server, a database, a PHP configuration and the installer, and the details of that belong in a document that can be updated without a code release, so the README links rather than duplicates. It also means that if you are evaluating Gibbon as a platform rather than as a codebase, the installation guide is the document to read, not the repository. The same pattern applies to the other entry points: the Extend page for modules and themes, and the docs domain for the developer workflow.

prerelease is a branch, and the project says it can lose data

There is a clear warning about the development version. The README says that if you want to run the latest version of Gibbon, prerelease, you can get the source from the GitHub repository, and then says plainly that it is not stable and you may lose data, adding that this is not for the faint of heart. For installation it points you at the specific instructions for prerelease Code rather than the standard installer. That framing matters for anyone running this in a school, because the difference between a tagged release and the tip of the development branch is the difference between a versioned upgrade path and a moving target, and the project is clear that the latter carries a data risk. The release history supports treating the tags as the safe choice, with v30.0.01 published on 2026-02-06, v30.0.00 on 2025-11-20 and v29.0.00 on 2025-05-20, while the default branch is the later v31.0.00.

Modules and themes are where a school's actual configuration lives

Because the core holds only the primary functionality, the module set becomes the deciding factor for a school. The extension points named in the top level listing are visible: the modules/ directory, the installer/ directory, and the fact that the repository carries a .gitmodules file, so some of the extension content is tracked as submodules rather than vendored. The i18n directory and the translation process belong to the same story. The README explains that Gibbon is available in many different languages through the online tool POEditor, which lets volunteer translators collaborate and track their translation progress, and asks contributors to email [email protected] to help. For an evaluation, the useful question is not whether the platform is flexible but which modules your school will need and whether they exist, because the core by itself is deliberately not the whole product.

A community process and a GPL-3.0 licence

The governance signals are in the README too. The project welcomes community contribution and aims to ensure Gibbon is an open and friendly environment, and it links a Contributor Guide for both code and non-code contributions, a Code of Conduct, and a Developer Workflow document. That workflow document notes that there will generally be a development branch with the latest code, per the Development Road Map, which is the mechanism behind the prerelease warning described earlier. Support has its own channel at ask.gibbonedu.org, separate from the code contribution process, and the licence is the GNU General Public License v3.0, obtainable from the LICENSE file in the repository. For a school that modifies and redistributes the platform, or for a hosting provider, that licence choice is the first legal question to answer, and it is the same reason the project is distributed as open source in the first place.

Editorial conclusion

Gibbon Core fits a school that wants an open source system of record for students, staff and parents, and that has someone able to run a PHP and MySQL stack in production and to own the module configuration. It does not fit a team that expects a hosted, hands-off product, since the install path is a documented manual procedure, and the prerelease branch is described by the project as unstable with a risk of losing data. Before you commit, read the installation instructions at docs.gibbonedu.org, decide whether you run the release tags or the development branch, and check what the module and theme ecosystem you need actually exists, because the core deliberately contains only the primary functionality.

Frequently asked questions

Official sources

1. GibbonEdu/core on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases