Elgg 3.0.3 released

A new version of Elgg 3.0 is now available in the download section.

This release contains some small bug fixes and a lot of code documentation improvements. We use Scrutinizer to analyse our code base and based upon the results we improved the code documentation. We went from +/- 1800 issues to less than 50. The remaining issues are a bit more complex and have separate tickets to be solved.

Release notes


  • Jerôme Bakker (55)
  • Jeroen Dalsem (21)
  • Rohit Gupta (1)
  • therecluse26 (1)


  • db: improved preloader queries for performance (6ec44b7a)
  • entity: only update private settings if value changes (ee955db4)

Bug Fixes

  • ajax: reponseFactory prepares reponse (ff965eab)
  • cache:
  • core:
    • use correct typehint namespace (aaeacf36)
    • remove unused action hook listener in BootService (01ff862c)
    • report correct duration for non sequential timers (1831589f)
  • db: make sure all queries are tracked and logged (8e6da0c6)
  • email: don't set duplicate content-type header (#12625) (5625412c)
  • gatekeeper: allow access to content of banned users (c7c36082)
  • messages: added missing translation string (5c612c1a)
  • metadata:
    • removed usage of canEditMetadata is MetadataTable::delete (35c39119)
    • removed usage of canEditMetadata (42495a6b)
  • notifications: prevent php warning when no collections selected (6efd8f7b)
  • output: always return string in formatter (b92a6dbd)
  • pages: don't show access fields if no edit rights (33eff4b2)
  • plugins:
    • only reindex plugin priorities with new disabled plugins (9652c77e)
    • plugin details tabs work again (f3c9bb3f)
  • request: upload post max size is now correct validated (#12610) (5b118806)
  • river: restored ignoring access when bulk deleting river items (761dc191)
  • search: no longer set deprecated search_type tags on tag links (#12611) (a639fbba)
  • session:
    • cookie configuration not read from settings file (d43d282c)
    • session close moved to the latest possible moment (16c06fc2)
  • system_log:
    • filtering in logbrowser could result in no results (bdf6ec54)
    • system_log_get_log accepts single array argument (#12607) (9641b008)
  • web_services: fetch correct api user (f857b1ef)
  • widgets: return all widgets in case of duplicate order (e2899cb4)
  • Hello, I'm with elgg 3.0.2, to upgrade to 3.0.3, is it possible to just send those to the server, replacing? Do you need to do something else?

  • Hello, I'm with elgg 3.0.2, to upgrade to 3.0.3, is it possible to just send those to the server, replacing? Do you need to do something else?

    You could probaby overrule the files, but if files are (re)moved this will not take full effect.

    Have a look at http://learn.elgg.org/en/stable/admin/upgrading.html#b-manual-upgrade-legacy-approach

  • Yes, I would just replace the existing ones. I'm afraid of losing everything!

  • There shouldn't be any risk of losing data when replacing the files in the Elgg install folder with the files of a newer Elgg version. If you haven't modified any core files yourself, the only files that contain site-specific data are elgg-config/settings.php and maybe .htaccess (if you made any changes in this file). Additionally, the mod folder might contain 3rd party plugins you've added.

    A newer Elgg version might not only contain modified files and new files but there could also be some files no longer included in the new version. When overwriting the install folder with the new Elgg version you would replace the modified files and also add any new files. But the files no longer included in the new version would remain on your server (as they would not be touched by overwriting). Such obsolete files could (not necessarily do in any case) cause issues if not removed.

    Now you wouldn't have to search for any of the files that might need to be removed. My approach is as follows: I prepare a separate folder with the new Elgg version outside of the public_html folder (aka document root folder) on the server (you could also do this locally on your computer and upload once ready) where I not only add the Elgg core files of the new Elgg version but also add the folders of the 3rd party plugins used on the site in the mod directory. Then I check if there are any changes in elgg-config/settings.php and .htaccess I would have to merge. If not, I can just add these two files currently used on my site also to the separate folder.

    When you work with such a separate folder containing everything that is later to be placed into the target folder of your Elgg installation you can prepare the upgrade without any time pressure. And once you are ready the actual upgrade goes faster.

    When I'm ready I do a backup of current install folder (to be on the safe side in case anything unexpected happens) AND also backups of database and data directory (as the data that really makes the site are either in database or data directory).

    Once I have backups of everything the upgrade can start. It might be best to enable the maintenance mode now (keeping other users out reduces the risk of database changes at just the wrong time) and then also disable the caching options in the advanced site settings. Now you can simple delete the content of the install folder to be sure that no obsolute files remain. Then you can MOVE the content of the folder containing the new Elgg version and everything else into the Elgg install folder (moving goes much faster than copying). Once the install folder contains all files and folders of the new Elgg version plus the 3rd party plugins again you can run the upgrade scripts (either clicking on the Upgrade button in the admin dashboard or running site.url/upgrade.php in the browser - the latter methods might not work on Elgg 3 anymore if accessing this url is protected by the Elgg site setting). Once the upgrade script has finished (best to check in the admin area also if any async upgrades need to be run) you can enable the caching options again and then disable the maintenance mode. All in all the actual upgrade only takes a few minutes this way (time to prepare the separate folder with the new version not included), so downtime is minimal and you don't need to put yourself under any pressure to finish fast. And with backups of everything at hand you could restore the site as it was before the upgrade in case anything bad happens.