Elgg

Last reviewed Sep 13, 2026 · 792 words

Elgg installs in 20 minutes and then hands you a blank social network with an activity stream, groups, friend lists and a plugin system, and expects you to build the rest. That is the whole review in one sentence. If you want a working community intranet by Friday, HumHub ships one. If you want to build your own Facebook-Groups-shaped application in PHP and own every screen of it, Elgg is the most mature framework left for that job, with a codebase dating to 2004 and 1,676 GitHub stars that undersell how many universities and NGOs still run it.

What "framework" means in practice

The stock install with the bundled plugins enabled gives you user profiles, an activity river, groups with discussions, a blog, file uploads, bookmarks, messaging and the friend graph. It looks like a 2015 social site because the default theme is one. Every organisation I have seen run Elgg for real had a developer who wrote at least three custom plugins: a theme, a registration or LDAP hook to match their identity system, and something domain-specific like a course catalogue or a member directory. Budget for that. Elgg's plugin API (entities, relationships, annotations, views, event hooks) is genuinely well designed, which is why people who have worked with it stay, but it is an API, and the documentation at learn.elgg.org reads like one.

The stack is plain PHP, and that cuts both ways

Requirements are a modern PHP with the usual extensions, MySQL or MariaDB, and a web server. Installation is a Composer project (composer create-project elgg/starter-project) and a browser wizard, plus a cron entry for the scheduled jobs; skip the cron and notifications and the activity river's cleanup silently stop. There is no official Docker image, so the community Compose files you will find are one person's opinion of PHP-FPM plus Nginx plus MariaDB. The 512 MB RAM floor in the catalogue is honest for a small site; a site with a few hundred daily active members wants 2 GB and opcache tuned. The upside of plain PHP is that Elgg runs on the same cheap hosting as WordPress and a sysadmin who has never seen it can still read the logs.

Who actually runs Elgg in 2026

Three groups. Universities and research networks that built a member site on it a decade ago and keep upgrading, because migrating ten years of user content is worse than maintaining PHP. Small membership organisations whose one developer prefers to own the code rather than a SaaS bill. And agencies that ship white-label community sites and want a base they can change without asking upstream. What you will not find is a large hobbyist community sharing plugins: the community is small, the third-party plugin directory is thin, and a plugin last touched in 2019 probably needs porting. That is the "niche community" con in the catalogue, and it is the one that matters.

Upgrades are the ongoing tax

Elgg has done several major-version rewrites of its internals, and each one broke third-party plugins. Core upgrades themselves are scripted and reliable; it is your custom plugins that need touching, and if you inherited the site from a developer who left, that is the moment you find out how much undocumented code is holding it up. Read the upgrade notes before every major, run it on a copy first, and keep the site pinned to a supported PHP version rather than chasing the newest.

Where the bigger projects win

For an internal social intranet with no developer on staff, HumHub gives you spaces, a modern UI and a marketplace of maintained modules out of the box, and it is the safer pick for most readers of this page. For a public discussion community, Discourse is the standard. For federated social, Friendica or Mastodon speak ActivityPub, which Elgg does not without a plugin. The broader social category lists the rest. Elgg's remaining niche is specifically the case where the social features are scaffolding for an application you are writing yourself.

What I'd do

If I had a PHP developer and a clear spec for a members-only application with profiles, groups and an activity feed, I would build it on Elgg, keep every customisation in one versioned plugin, and treat upgrades as a quarterly sprint. If I did not have that developer, I would not install Elgg at all; I would deploy HumHub, accept its opinions, and spend the saved months on the community itself. Elgg rewards people who want to write code and quietly punishes those who hoped they would not have to.