Many users of the Concrete5.6.x.x CMS have been forced to abandon their website CMS 5.6 files because of hosting companies that have decided to no longer support the PHP version that is required to successfully run Concrete5.6.x.x
I have just finished updating Concrete5.6.4.0 to run on PHP 8.4 and I can tell you it is very lightweight and blisteringly fast running on this version of PHP.
If any member is worried about the possibility of having to rebuild their website because of the hosting company declaring no support for older PHP versions, there is now an alternative solution available.
Your packages will need updating to be compatible with PHP 8 but that should be relatively straight forward depending on the complexity of your packages.
This is VERY interesting, do you have a git repo with the changes you made that a person could look at?
I’d be very interested to see as well.
When I have finished the current round of fault finding I intend to put this codebase on a live server with just a minimal and basic theme so that interested parties can take a look.
I will post the url of the live site here when it is ready for viewing.
I have loaded the current codebase onto a live server, you can view the site at https://deepsea.uk/
Looking back over the work we have just done converting an old Concrete5 5.6.2.1 codebase to run cleanly under PHP 8, these were the main hurdles:
-
Database/ADODB compatibility — the old ADODB version required several changes before Concrete5’s database layer would initialise reliably under PHP 8, including ensuring the required ADODB files and functions were loaded in the correct order.
This was achieved by first performing a sequential update of the core from 5.6.2.1 to 5.6.4.0 (GitHub version), this ensured we had a database with all the necessary tables to run our PHP 8 compatible core. -
Removed PHP functions — legacy code depended on functions removed from PHP 8, including
get_magic_quotes_gpc()andeach(), particularly within older third-party libraries such as ADODB. -
Static vs non-static method calls — PHP 8 is much stricter about calling instance methods statically. We encountered this throughout the core and packages, including
Config,Loader, package handling, attribute classes and third-party packages. -
Legacy class loading and aliases — some Concrete5 classes were no longer being loaded/aliased as the old code expected.
UserListwas a good example:Concrete5_Model_UserListexisted, but the expectedUserListclass was not available. -
Undefined variables — PHP 8 exposed numerous places where old code assumed variables already existed, such as
$fr,$error,$alt,$task,$uID,$blockStyle,$bFilenameand various controller/view variables. -
Undefined array keys — old PHP code routinely accessed
$_REQUEST,$_GET,$_POSTand other arrays without checking whether the key existed. We replaced many of these withisset(),!empty()or PHP’s??operator. -
Undefined object properties — legacy objects sometimes contained only partially populated data. Examples included
CollectionVersion::$cvID,CollectionVersion::$cvDatePublicand attribute-related properties. -
count()on non-countable values — PHP 8 no longer tolerates some of the loose uses ofcount()that older PHP versions accepted. Several lists and attribute-related objects needed checking before being counted. -
Old constructors and object initialisation assumptions — some classes relied on older PHP behaviour concerning constructors, properties and object setup. These had to be checked carefully rather than simply modernising everything wholesale.
-
Permission-system compatibility — the Dashboard permissions dialogs exposed several problems, particularly around groups, group sets, access entities and missing request parameters.
-
User management/search compatibility — Search Users required fixes to its controller, request handling, user list loading, search columns, bulk operations, group filtering and user attributes.
-
Attribute-system problems — user, collection and select attributes exposed several PHP 8 incompatibilities, including static calls, missing/default values, option lists and attribute controller handling.
-
Block controller compatibility — Auto-Nav, Search, Form, Mini Survey and other blocks contained assumptions that generated PHP 8 warnings or errors.
-
Block editing interface problems — the Dashboard/page editing UI needed fixes to block headers, footers, filenames, styles and edit controls before blocks behaved normally again.
-
Sitemap/dashboard overlays — the Sitemap UI depended on request variables, callbacks, IDs and display modes that were not always initialized.
-
Page/version handling — partially populated
CollectionVersionobjects caused warnings during permissions checks and search indexing, particularly aroundcvIDandcvDatePublic. -
Search indexing — the full search-index job uncovered problems that ordinary page browsing didn’t reveal. Running the indexing job was particularly useful for finding deeper page/version compatibility issues.
-
Search block behaviour — after making the Search block PHP 8 compatible, we discovered that multiple Search blocks on the same page were all processing the same
queryrequest. We corrected the controller so a block configured to Post to Another Page Elsewhere only submits the search, while the Search block on/search-resultsprocesses and displays it. -
Uninitialised search results —
$resultscould remain undefined when a search returned nothing, so it now starts as an empty array. -
Direct property access — in several places we replaced fragile direct access to internal properties with the appropriate methods, such as using
getCollectionPath()rather than relying on$page->cPath. -
Mail system compatibility — Concrete5’s old mail code required work around address generation and message encoding. We also tested PHP
mail()and SMTP separately because the WAMP development environment cannot simply behave like the live mail server. -
Quoted-printable email corruption — the contact form initially delivered visible
=0A,=0D,=3Detc. rather than properly decoded text. We traced and corrected the legacy mail handling. -
SMTP configuration — local SMTP testing involved the correct server, port, TLS and authentication settings, eventually resulting in successful test mail delivery.
-
Overrides hiding core fixes — old files in
/models,/blocks,/single_pagesand other override locations could silently take precedence over our corrected Concrete5 core. We found several obsolete overrides and removed them where they were no longer required. -
Whitespace/output-before-headers problems — one override produced output from line 1, resulting in
Cannot modify header informationwarnings. Removing the obsolete override resolved it. -
Legacy package installation/uninstallation — Package methods and loader behaviour needed PHP 8 corrections before packages could be inspected, installed and uninstalled reliably.
-
PHP 8 error reporting itself — many of these defects had existed unnoticed for years because older PHP versions were much more forgiving. PHP 8’s stricter handling of undefined data, invalid method calls and type assumptions effectively exposed the accumulated technical debt.
-
Testing beyond simply loading the website — getting the homepage to display was only the beginning. We systematically exercised the Dashboard, users, permissions, attributes, blocks, editing, sitemap, packages, jobs, search indexing, forms and email facilities.
-
Separating genuine PHP 8 problems from site-specific legacy problems — some faults were PHP compatibility issues, while others came from old overrides, obsolete packages or historical customisations. Distinguishing between them prevented us from unnecessarily modifying the Concrete5 core.
-
Preserving Concrete5 5.6 behaviour — probably the biggest overall challenge was that we weren’t trying to rewrite Concrete5 as a modern application. We wanted to make the existing application PHP 8 compatible without changing how the site works, which meant making small, targeted compatibility fixes rather than wholesale redevelopment.
The significant achievement is that we didn’t merely get an old Concrete5 installation to start under PHP 8. We progressively exercised the functionality that a real site actually depends upon and fixed problems as they appeared. That is a much stronger test of compatibility.
I’m interested, too.
I am still ironing out a few wrinkles but will update this post when I am satisfied that the core is stable, the Dashboard and the System & Settings page are playing nicely, I just have to test the core blocks for PHP 8 compatibility and then do a final PHP version 8 compatibility pass.
Thank you all for your interest.
That’s great news 
Let us know if there’s anything we can do to help you with testing!
Thanks for the offer but I am quite capable of breaking the code myself ha ha.
Just modernised the Google Map block to use the Leaflet map system that accepts both postal codes and Lat Long coordinates.
That was a biggy but well worth doing as the displayed map is excellent.
I will put one up on the test site shortly after I have had a lay down in a darkened room!
Outstanding, and the Leaftlet.js map block is pretty darn cool too.
Thanks @jero I have just this moment updated the leaflet map to properly display a balloon marker.
Take another look.
I have created a new page in which I have added one each of the core blocks.
The only one that is not included is the Flash Content block and although it is not selectable from the Add Block page it is still included in the core blocks in case any client is still using the Flash block.
The new page can be viewed at: Concrete5 Legacy Revival :: Block Test
Just updated the System & Settings page with an image option section.
I have attached a screenshot of the options available for the manipulation of uploaded images to the file manager, including auto rotation of images based on the image exif data, auto compression of images including WebP images, auto resizing of images to the set values.
we also handle WebP images uploaded to the file manager including the creation of thumbnail images for the file manager view.
The test legacy site is now sporting a brand new responsive theme.
The phpinfo link has been removed from the public view.
Upgrading an Existing Concrete5 5.6.4.0 Site to the PHP 8 Compatible Codebase.
Send me ZIP archives of the existing site files together with a copy of the database, I will perform the conversion and PHP 8 compatibility work for you.
Alternatively, place the zip archive and the exported database file in the root of your site and send me the links to those files for me to download.
davidmeerkat@gmail.com
Deepsea.uk is currently being used as a live demonstration environment for upgrading legacy client websites to PHP 8, as well as for testing the new add-ons and extensions we are developing for inclusion with the new PHP 8 platform.
During this period, the normal Deepsea.uk website will be unavailable. It will return once the demonstration, testing and development work has been completed.
Having upgraded several legacy sites to our new PHP8 codebase, we are mostly patching packages and themes now, usually we find nothing too difficult in those.
Occasionally we find the odd wrinkle in our PHP8 codebase but getting less and less now.
One thing we have found that speeds up the process is to ensure the existing legacy site is running on 5.6.4.0 and there are no core overrides in place, overrides will often throw a php error because they were created using the old codebase.
If any member would like us to upgrade a legacy site free-of-charge, get in touch, we have limited availability, so first come, first served.
davidmeerkat@gmail.com
Did I mention 5.6.4.0 is lightweight?
I have two sites running on the same server with PHP 8.4.25
https://deepsea.co.uk is a Version 9 site.
https://deepsea.uk is a 5.6.4.0 site.
I have just downloaded zip archives of both site files and a database export from each site.
The deepsea.co.uk Version 9 site has a combined size (zip archive and database file) of 347MB.
The deepsea.uk Version 5.6.4.0 site has a combined size of 75.5MB
So yes, 5.6.4.0 running on PHP 8 is not only lightweight but extremely fast.