Elgg is a long-running social engine with a community repository of 1000+ plugins

What it is: an engine for sites whose content belongs to users

Elgg describes itself as an open source rapid development framework for socially aware web applications, and the project site frames it as building blocks for businesses, schools, universities and associations to run their own social networks.

The wording matters. Elgg is not a general purpose MVC framework you could use for anything, and it is not a social network product you configure and deploy. It assumes your application has users, content owned by users, relationships between them, and permissions on that content. Every headline feature follows from that assumption.

Groups are supported out of the box. The access control system is described as allowing granular content access policies as well as private networks and intranets, which is the feature that distinguishes it from a blog engine with user accounts. Notifications let an application subscribe users to on-site and email notifications and integrate with other party services. The entity system exists so applications can prototype new types of content and user interactions without a migration for each one.

The project started in 2004, founded by Ben Werdmuller and Dave Tosh, and is now governed by the Elgg Foundation, a nonprofit set up to protect and promote the project as an organisation independent of any single commercial or individual interest.

Events and view overrides are the two extension points plugins use

Two mechanisms carry most plugin work, and they are named first in the feature list.

The event system is described as flexible, allowing plugins to extend and modify most aspects of application functionality and behaviour. Events at the request level, the plugin level and the view level are how a plugin adds a menu item, changes what a page renders, or reacts to an entity being created without editing core files.

The view system is separately overridable, so plugins can collaborate on the presentation layer and themes can be built out from plugins. That combination is why a theme in Elgg is not a separate template directory but a set of view overrides competing with other plugins, and it is also why two badly behaved plugins conflict.

Static assets are cacheable in a way that bypasses the engine, so themes and plugins can serve images, stylesheets, fonts and scripts directly. That is a performance decision with a consequence: the asset is served outside the PHP layer, so anything dynamic about it has to move elsewhere.

Authentication is pluggable too. The README describes auth modules as the mechanism allowing applications to implement custom authentication protocols, rather than the framework assuming one scheme.

The stack underneath, and why it reads as older than it is

The under the hood list is short and specific.

Elgg is a modular object oriented framework driven by DI services. Symfony's HTTP Foundation handles requests and responses, and Symfony Mailer handles outgoing email. Database access goes through DBAL, with Phinx handling database migrations. Image manipulation is Imagine, XSS filtering is htmLawed, and error handling goes through Monolog.

Two entries are dated in a way that matters. It says Symfony2 HTTP Foundation, and it describes a cacheable system of static assets plus a Gruntfile.js at the repository root with bower_components/ and yarn.lock alongside package-lock.json. So the build tooling has a Grunt era layer and an npm era layer coexisting, and the PHP dependency set is anchored to a Symfony generation from well before the current one.

The client side is described as modular JavaScript with ECMAScript modules and a client-side API powered by asynchronous ES modules and a built-in Ajax service. That part is current in intent even where the surrounding tooling is not.

The PHP requirement itself is not stated in the README, so check the composer.json in the branch you plan to use rather than assuming a version floor from the description.

Installation and upgrades are documented elsewhere, not in the README

The README is explicit that it does not contain the steps. For installation it points to http://learn.elgg.org/en/stable/intro/install.html, and for upgrades to http://learn.elgg.org/en/stable/admin/upgrading.html.

So there are no commands in this repository's README to copy, and an article that printed some would be inventing them. What the repository layout does show is the shape of the process: install.php and an install/ directory at the root for the web installer, index.php and autoloader.php as the front controller and bootstrap, upgrade.php for the upgrade path, and elgg-cli as a command line entry point.

elgg-config/ holds configuration, engine/ the core, views/ the presentation layer, mod/ the modules that implement the social features, languages/ the translation catalogues, and docs/ the documentation sources, since the same docs site is built from this repository with a .readthedocs.yml at the root.

Composer is described as the package manager of choice for both core and plugins, and the repository ships composer.json and composer.lock. The JavaScript side uses npm with package.json and package-lock.json plus yarn.lock, driven by Grunt tasks, and phpunit.xml.dist configures the test suites, with a GitHub Actions workflow running the PHPUnit suites per branch.

The documentation is versioned, and the badges in the README point at the 7.1 branch rather than at the default branch, so read the version of the docs that matches the version you are running.

Security features are listed, and SECURITY.md is where the detail lives

The feature list makes specific security claims: built-in anti CSRF validation, strict XSS filters, HMAC signatures, and current cryptographic approaches to password hashing. The README maps those to htmLawed for filtering and to the Symfony components for the HTTP layer.

There is a SECURITY.md at the repository root, which is where a project that makes those claims usually records a disclosure process. The README does not summarise its contents, so treat the file as the authoritative statement about how to report a problem rather than assuming it follows the same path as a normal bug.

The plugin ecosystem is the practical weak point in that model. A framework with 1000+ community plugins inherits every outdated dependency and every abandoned plugin in the set, and the README's framing of that repository as a feature is accurate in the same breath as it being a maintenance surface.

RPC web services are listed as a feature for complex integrations with external applications and mobile clients, which adds an authenticated API surface to a system whose main surface is server rendered pages.

The licence statement and the package.json statement are not the same

The README says Elgg is released under the GNU General Public License version 2 and the Massachusetts Institute of Technology MIT-X11 licence, and that the applicable terms are in LICENSE.txt in the root of the package you downloaded. Copyright is given as 2008-2026 with a pointer to COPYRIGHT.txt.

package.json in the same repository records license as GPL-2.0-only.

Those two statements do not say the same thing. GPL-2.0-only is a single licence with no option to treat parts of the work as MIT-X11, while the README describes a dual arrangement. The repository metadata also classifies the licence as a custom one that GitHub cannot categorise.

For your own use this is a documentation question. For redistribution it is not, because the difference between a dual licence and a single one determines whether a downstream party can take the MIT-X11 side. Read LICENSE.txt in the archive you actually have, and COPYRIGHT.txt for the attributions, rather than relying on either summary.

Elgg is also a registered trademark situation worth noting generally, since a name that identifies a social engine does not travel with a fork. The README does not spell out trademark terms, so check before you rename.

Where Elgg is the wrong tool

The first wrong case is a project with no social dimension. A booking system, a reporting tool or an internal dashboard does not need an entity model built around user owned content, and adopting one to get there means fighting the framework rather than using it.

The second is a team that wants a modern PHP foundation. Elgg brings its own conventions on top of Symfony's HTTP components rather than being a Symfony application, so a team with Symfony experience will find familiar parts and unfamiliar structure at the same time.

The third is a dependency on a plugin you have not evaluated. The 1000+ plugin count is an asset when you need one of them and a liability when you inherit five that no one has touched in a decade. There is no version compatibility guarantee stated for plugins in the README, so a core upgrade is where you find out.

The fourth is host PHP version drift. This is a framework whose README describes Symfony2 components and whose tooling includes a Gruntfile and bower_components, and the site it runs on moves whether or not the framework does.

Editorial conclusion

Adopt Elgg when you are building a social application and want groups, an access control system, notifications, file handling and an entity model already designed for user owned content, and when you can live with a PHP framework that has chosen to keep its own shape rather than track current Symfony conventions. Do not adopt it for a project that needs a modern typed PHP stack or a plugin you cannot find. Verify first the licence file in the package you download, because the README describes a GPL version 2 plus MIT-X11 release while package.json records GPL-2.0-only, and the two statements are not the same promise.

Frequently asked questions

Official sources

1. Elgg/Elgg on GitHub
2. Issues
3. Project website
4. README
5. Releases