Hi folks,
i run the version 8.5.9 with php 7. Everything works fine. Now my provider is going to switch off all php version lower than 8. When I switch to php 8 my screen becomes white (empty body tag). When i switch back to 7.0 everything works fine again. What have I to do to solve this issue.
Thanks a lot in advance
Mathias
You will need to update to concrete v9. Do this in 2 steps, upgrade to v8.5.latest, which should be fairly safe.
Then upgrade to v9.latest, which may uncover addon and theme compatibility issues you will need to resolve.
Make backups before each step. Ideally do a thorough cleanup before each starting (old versions, temp files, cache,empty the trash ). Disable all caches. Put doctrine entities into development mode.
If the above is just not feasible, move to another host which provides extended support for php7.
Concrete Version 8.5.9 is not compatible with PHP 8: System Requirements for Concrete CMS
Youâll want to upgrade to 9.0.2+ or examine the PHP logs to see what changes youâll need to make to get your site running on PHP 8+
Thank You so much. Thatâs what I expected. 
My Concrete CMS site is very complex and built in trial & error mode (at least with the friendly help by the people in this forumâŚ), because I am not a programmer. My theme became pretty complex. It has page-type-dependent queries from remote databases, some IP ranges get access to grouped e-PDFs, users have access to special issues of our magazin, etc. A full crash would be a disaster.
Iâll try the updates. If necessary, I can restore all the data. Otherwise I have to pay the extra charge to the provider.
Thanks againâŚ
Check in the site root for your PHP error log and youâll see the exact errors there that will need fixing for PHP8
Hi Matthias
We had quite a lot of sites like yours. Most sites were created as 5.7 with bespoke themes, many pages and sometimes many plugins. A few were easy to upgrade, others extremly difficult. It was OK to upgrade to the core 8 versions but trying to upgrade to 9 failed in many ways and broke programming/code. Once we mastered the v9 upgrades, you still had to deal with PHP 8. All addons had to be checked for php errors. Fixing them was an alptraum, it took so much time. By the time providers switched to PHP 8 many sites broke, the original addons in the marketplace were not available anymore. Most of the upgrade budget was eaten by our developer.
We were able to upgrade four sites, all others failed. Eventually we had to move all these sites to a provider supporting PHP 7.4. That also took time. After all I have to say, it is all about making a decent pay for this work we do. Charging a flat rate for moving the sites didnât cover all expenses.
I suggest to move your site to a provider supporting 7.4 (LTS) before you start the tedious process to upgrade. It will save you a lot of problems.
Good luck
Stefan
Thanks a lot. My provider takes an extra charge (about 8 $ per month) to run php 7*. But it is not the money. I am a little angry about that. First, youâre encouraged to use all these systems and programs, and then they keep getting âmodernizedââoften completely unnecessarilyâwhich almost always causes technical problems.
I even still have a Concrete5.6 website running. Itâs a nice website that has been working for many years and is regularly expanded. I canât migrate it to a newer version because the necessary packages no longer exist.
And so, youâre left with no choice but to look for compromises and create temporary workarounds. This makes Concrete5 completely unsuitable for client websites.
Now I have to explain to my clients why the websites I built for them suddenly cost more each monthâjust to run on an old (!) PHP version. And when they ask me why we donât just update to Concrete5.9 , I have to tell them that itâs not possible. Or rather, that it could lead to massive difficulties, up to a complete crash.
For new projects, I will no longer use Concrete5.
We use âkrystal.ioâ, have done for over ten years and have the option of setting PHP from 5.4 to 8.4+. Cost from ÂŁ70.00 a year for 1 website, 10GB storage, unlimited bandwidth and mailboxes, daily backups and free SSL certificates. There are few more options. Maybe that will help?
Good idea, but I see just a blanc screen.
You need to FTP in to check your PHP error log, this is in your hosting space, not the CMS
This is largely true for almost every modern framework (and technology), not just Concrete CMS. As technology evolves, vulnerabilities in older versions of software are discovered or become easier to exploit and it takes time, effort, and money to continually patch old versions to be secure. Youâd be hard pressed to find any support for older versions of Windows without an expensive support contract, an older smart phone, or any piece of tech more than about 10 years old (like legacy concrete5).
There are ways of running older software more securely, usually by putting them behind a WAF and reverse proxy, but that also takes some resources to set up and run.
And if you are willing to accept the risks of putting old software directly on the net, you can just get a cheap instance from any cloud provider and load it up with outdated versions of PHP.
To address this problem, much tech is now sold as a service with a monthly or yearly subscription that pays for ongoing security fixes and improvements. Concrete even has this option: Web Hosting :: Concrete CMS Marketplace
Any software that would make these big version jumps without the need to adjust code should be viewed suspiciously.
Because it means that there is some seriously old code in that software that avoids modern technology and âkeepsâ old security issues going.
PHP has evolved much, added a lot of features and performance, making much of the old preconceptions meaningless.
That modernization has a price which comes with a change of code and methodology but it is really inevitable.
I always assume that a website has a âmaximum ageâ of around 5 years.
Most of us have had this issue.
As mentioned above, you can run a VPS for a few bucks per month and equip it with any old PHP version and run it yourself if you absoluteley need it. But I would rather not.
The probability of this âsolutionâ biting you back is very high.
As others have just said, this has little to do with concrete cms
Thatâs all true. But in my eyes, this hysteria about security is ridiculous. My websites and my computers (both Windows and macOS) in my office are âwide open like a barn doorâ for more than 20 years, and yet theyâve never been hacked. By whom, anyway? Sure, you could say, âYou just got lucky.â But the fact that new security vulnerabilities keep appearing only proves that the internet is inherently insecure, and these security measures are basically just a kind of competitive sport.
I do think that higher security standards should apply where money is involved or where sensitive personal data is stored. But for purely informational websites, itâs not necessary. The worst a hacker could do is destroy some data. But why would they even bother? Why go through the effort? No one breaks into a garage when they know all theyâll find is an old, rusty bicycle and a canister of used oil. Hackers arenât malicious for the sake of itâtheyâre greedy. They want data that can be turned into money or that might be useful to a competitor.
And letâs be honestâwhat Concrete5 user is storing that kind of data online?
It would be great if new security technologies were always offered as an option rather than a requirement. My website (C5.6, PHP 5.6) has been running for over ten years, listing just four lectures and speakers per year. It definitely doesnât need the latest security featuresâŚ
If your sites have a form, then they store personal data, unless that behaviour has been overridden by the developer.
With the ICO giving out large fines, we do need to take security seriously.
Some v8 sites had a serious vulnerability where anyone could âlogin to the siteâ, we scrambled to update those quickly to avoid issues.
That being said, there is definitely a disparity between hosts rolling out v8 of PHP and removing support for recent old versions over night, and actually getting clients sites updated. We host around 150+ sites now and I have clients that simply wonât pay out for updates and think that because it isnât broken today, it wonât be tomorrow.
I donât host that many sitesâonly eight. I also have no problem paying my provider around âŹ8 more per month per site to keep PHP 7.1 or 5.6 running. Iâm sticking with C5 for these sites and will migrate them to version 5.9.
However, since many features (for me, primarily modified page lists) will no longer work in C5.9, Iâm simply offloading this data to external SQL databases and integrating them later into default.php. That means Iâll have to create tables and PHP scripts with forms for the production data, but this way, I avoid the tedious setup of page types, attributes, and forms that apparently donât transfer wellâor at allâduring version upgrades.
For instance, in one website, I integrated over 11,000 historical letters (each with 36 attributes) into a C5.7 installation using an external database query. That works perfectly. If I had created those 11,000 letters as pages with 36 attributes each, I would have lost both the overview and the stability that the external database provides.
(This reminds me: the useful database backup feature in C5.6 was already gone in version 7âjust like that. Thereâs no way that had anything to do with securityâŚ)
The output of page lists can be implemented quite easily in PHP, and the source code can then be included in default.php via include or require. The same applies to sliders and similar add-ons.
Offloading the data also allows for an advanced search function. (C5âs built-in search remains a constant disappointmentâŚ)
At this point, Concrete5 is really just a frame that generates some layout. Whether such a âtankerâ with all its unnecessary features is even needed anymore is questionable. A C5-Light versionâthat would be great.
There was some discussion on moving some core code back into a packages a few years ago, possibly with a privileged layer of packages âCore Extensionsâ to distinguish from marketplace packages.
Things like Express, Calendar, ⌠whatever âŚ
General conclusion was, whilst that may de-clutter the user interface, it wouldnât make much difference to the overall size of the core.
If you look at where the Mega Bytes are, about half of it is in vendor libraries.
Core functionality that could be viewed as optional fluff for many sites doesnât have a significant impact on core size.
If you host personal data of EU citizens, the GDPR (DSGVO) applies to you. Which is the case if you have a shop system, a form where people can put their Name and Email and and andâŚ
If you have a data leak of any kind, you can be fined. Depending on the kind of data (personal, financial, medical), those fines can be significant.
Youâre basically stating that you do not try to protect your customersâ data.
As a customer, I would not like that.
I do think that higher security standards should apply where money is involved or where sensitive personal data is stored. But I donât have any customers data.
Well yes of course you can host in any way you like.
Any hoster that offers âManaged Hostingâ will prefer the most modern version of a programming language because it will receive automatic updates, thus reducing the probability for manual intervention.
That is why you have to âpay extraâ for older versions - they increase the probability of manual work to fix stuff.