Is there interest in keeping the 5.6 branch alive because of its great UI?
Permalink 4 users found helpful
Before I discovered C5, I had worked with a large number of CMS for over a decade. After that, every new client project I started was based on C5 - it was just the perfect mix of a pleasant UI, clean structure, and easy customizability, suitable for small and large projects. I am not exaggerating when I say I was happy to have finally found the perfect CMS!
Sadly, much of that went away with the introduction of 5.7. After a number of aborted attempts (projects which I started on 5.7 but quickly reverted to 5.6) I recently finished a multi-month project (a major web site relaunch maintained by 5 people) with 5.7 and am every bit as frustrated with it as I was before.
I'm not generally someone to complain even about major UI changes - if there's some way for me to convince myself that they are, ultimately, actually *improvements.* 5.7's UI philosophy just doesn't work for me, nor anyone I know. It's less easily readable, many essential features take way more clicks to reach, the WYSIWYG editor feels clunky, the palettes and menus generate loads of Ajax requests and feel slow... I respect how huge an undertaking 5.7 has been, and things under the hood are AWESOME - a beautiful, complete rewrite that many project owners dream of. But the UI is more important, as that'll be what my clients work with, and while the new UI looks modern, it has lost the simplicity and straightforwardness it used to have, for non-technical customers as well as this 20-year web dev veteran. So far I haven't come across anyone who is more happy about 5.7's UI than about 5.6's.
C5.6 is still functional, but it doesn't currently work well on PHP 7. That puts a natural limit on its lifetime, as PHP 5.x will eventually be phased out.
There was an effort to get someone to port 5.6 to PHP 7:https://github.com/concrete5/concrete5-legacy/pull/1927...
But it would take some resources and money and raising that hasn't gone anywhere.
- Is there anyone else interested in seeing 5.6 continue, or am I the only one who is seriously missing its user experience?
- Are there any ongoing efforts to port the 5.6 branch to PHP 7?
- Is there any other development going on in the 5.6 branch?
Sadly, much of that went away with the introduction of 5.7. After a number of aborted attempts (projects which I started on 5.7 but quickly reverted to 5.6) I recently finished a multi-month project (a major web site relaunch maintained by 5 people) with 5.7 and am every bit as frustrated with it as I was before.
I'm not generally someone to complain even about major UI changes - if there's some way for me to convince myself that they are, ultimately, actually *improvements.* 5.7's UI philosophy just doesn't work for me, nor anyone I know. It's less easily readable, many essential features take way more clicks to reach, the WYSIWYG editor feels clunky, the palettes and menus generate loads of Ajax requests and feel slow... I respect how huge an undertaking 5.7 has been, and things under the hood are AWESOME - a beautiful, complete rewrite that many project owners dream of. But the UI is more important, as that'll be what my clients work with, and while the new UI looks modern, it has lost the simplicity and straightforwardness it used to have, for non-technical customers as well as this 20-year web dev veteran. So far I haven't come across anyone who is more happy about 5.7's UI than about 5.6's.
C5.6 is still functional, but it doesn't currently work well on PHP 7. That puts a natural limit on its lifetime, as PHP 5.x will eventually be phased out.
There was an effort to get someone to port 5.6 to PHP 7:https://github.com/concrete5/concrete5-legacy/pull/1927...
But it would take some resources and money and raising that hasn't gone anywhere.
- Is there anyone else interested in seeing 5.6 continue, or am I the only one who is seriously missing its user experience?
- Are there any ongoing efforts to port the 5.6 branch to PHP 7?
- Is there any other development going on in the 5.6 branch?
Hi @pekka
I would love to see 5.6 running on PHP7, I have looked at @Remo's hacks and whilst I was able to get the core to function in PHP7 there were a few addons that I could not hack enough for them to work.
My thoughts are exactly aligned with your own and would also add that some addon developers appear to have lost interest in developing for Concrete5 since Version 5.7 and 8 have displaced the excellent Version 5.6.
I would love to see 5.6 running on PHP7, I have looked at @Remo's hacks and whilst I was able to get the core to function in PHP7 there were a few addons that I could not hack enough for them to work.
My thoughts are exactly aligned with your own and would also add that some addon developers appear to have lost interest in developing for Concrete5 since Version 5.7 and 8 have displaced the excellent Version 5.6.
True, most of the users are willing/wanting to move forward to version 5.7/8.x, since these get new stuff and have things like Express, composer packages, and are far more enjoyable to develop for. As a developer, you'd be a robber of your own wallet if you build packages/Add-Ons for 5.6, since you won't get real sales... If one builds for the 5.6 marketplace, one would actually be building it for themselves and then decide "hey, maybe it's of use for others too". Other than that, I don't see people bringing new stuff for 5.6 (as good as it may be for some, UI-wise).
If you really don't like the design or something, try to find ways around it. I personally don't really like the dashboard design either and went ahead and changed it myself. Not much you can do about the Ajax requests for the side panels but hey... if they really are slow for you, it probably is your hosting, since I have seen slow loading on some hosts too, but these just haven't updated their hardware...
If you really don't like the design or something, try to find ways around it. I personally don't really like the dashboard design either and went ahead and changed it myself. Not much you can do about the Ajax requests for the side panels but hey... if they really are slow for you, it probably is your hosting, since I have seen slow loading on some hosts too, but these just haven't updated their hardware...
Over the last 2 months, about 2/3 of my addon sales have been for 5.6 sites. For the preceding 4 months about 1/3 were for 5.6 sites. So I could say 50% overall.
My development customers show a similar split of 5.6 to 5.7/8. Much of the 5.6 work is for bespoke functionality on new sites, so c5.6 is by far from fading out.
With 5.7/8, once you get beyond simple block/packages, the way the core fits together is both more complicated and less well documented. Working out how to do things by code archaeology requires greater expertise with 5.7/8. As a consequence I have customers asking me to develop functionality for 5.7/8 that in 5.6 they could have worked out for themselves.
The great thing about 5.6 is that it is easy for the self-taught garden shed developers to build code for. The 5.7/8 architecture has abandoned those developers.
5.6 is robust. You can generally be sure an edit or dashboard action in 5.6 will work. In 5.7/8 the slide out panels and edit dialogs are fragile. Every now and then a dialog will 'randomly' fail and we have to refresh a page, try again and hope that nothing is broken in the database. We see tips in the forums on how to fix databases after such failures. This is an inconvenience for a developer with expertise. It can be a considerably worse problem for everyone else, including when we hand a site over to a customer.
Being cynical, 5.7/8 has been good for my business. My skills are more in demand because DIY is more diffiucult. But I remain to be convinced that 5.7/8 has been good for the future of c5 as an open source CMS.
The WordPress core is, apart from php7 compatibility, based on a code architecture more primitive than 5.6, yet WordPress continues to grow. What concrete5 has lost sight of is that embracing all the cleverest and latest ideas to emerge from a computer science lab does not equate to a better product for everyone else.
My development customers show a similar split of 5.6 to 5.7/8. Much of the 5.6 work is for bespoke functionality on new sites, so c5.6 is by far from fading out.
With 5.7/8, once you get beyond simple block/packages, the way the core fits together is both more complicated and less well documented. Working out how to do things by code archaeology requires greater expertise with 5.7/8. As a consequence I have customers asking me to develop functionality for 5.7/8 that in 5.6 they could have worked out for themselves.
The great thing about 5.6 is that it is easy for the self-taught garden shed developers to build code for. The 5.7/8 architecture has abandoned those developers.
5.6 is robust. You can generally be sure an edit or dashboard action in 5.6 will work. In 5.7/8 the slide out panels and edit dialogs are fragile. Every now and then a dialog will 'randomly' fail and we have to refresh a page, try again and hope that nothing is broken in the database. We see tips in the forums on how to fix databases after such failures. This is an inconvenience for a developer with expertise. It can be a considerably worse problem for everyone else, including when we hand a site over to a customer.
Being cynical, 5.7/8 has been good for my business. My skills are more in demand because DIY is more diffiucult. But I remain to be convinced that 5.7/8 has been good for the future of c5 as an open source CMS.
The WordPress core is, apart from php7 compatibility, based on a code architecture more primitive than 5.6, yet WordPress continues to grow. What concrete5 has lost sight of is that embracing all the cleverest and latest ideas to emerge from a computer science lab does not equate to a better product for everyone else.
That's a very interesting perspective, thanks!
> Not much you can do about the Ajax requests for the side panels but hey... if they really are slow for you, it probably is your hosting, since I have seen slow loading on some hosts too, but these just haven't updated their hardware...
Yeah, there's some aspects one can fix oneself... although not the underlying philosophy, sadly (not in a reasonable time frame at least!)
The speed difference is really weird. It can't be the hosting, as I have a number of 5.6 sites chugging along happily there with no speed problems at all. I've tried PHP 5.3, 5.5. 5.6, 7.0 and 7.1 but C5.7's backend performance has always been dismal (even cached - but that is a different can of worms that I'm opening when the project is finished).
Yeah, there's some aspects one can fix oneself... although not the underlying philosophy, sadly (not in a reasonable time frame at least!)
The speed difference is really weird. It can't be the hosting, as I have a number of 5.6 sites chugging along happily there with no speed problems at all. I've tried PHP 5.3, 5.5. 5.6, 7.0 and 7.1 but C5.7's backend performance has always been dismal (even cached - but that is a different can of worms that I'm opening when the project is finished).
I decided to pull the emergency brake in our major project before launch (the problems just kept stacking up) and port the entire thing from 5.7 to Wordpress. So sad. C5 used to be so, so awesome. :( :( :(
<removed>
<removed>
I'll check it out, thanks!
I got one 5.6 website running on PHP7 using suggested code changes on github, but it didn't use many addns like core_commerce etc which I couldn't get working on another one.
I find the 5.7 backend runs quick on PHP7. I'm running nginx with PHP7.0, opcache and SSD drives.
Also with composer forms, it is much quicker and easier to add pages, especially important for blogs.
I like the way the UI uses the screen size more, although it is too chunky. On a 24" screen, a short composer form should fix, I don't need labels and inputs to be massive.
I find the 5.7 backend runs quick on PHP7. I'm running nginx with PHP7.0, opcache and SSD drives.
Also with composer forms, it is much quicker and easier to add pages, especially important for blogs.
I like the way the UI uses the screen size more, although it is too chunky. On a 24" screen, a short composer form should fix, I don't need labels and inputs to be massive.
@pekka - I agree with what you've written, and this a really interesting and timely post. I'm currently trying to decide on best course of action myself...
Something to add to the mix that is of note, and relates to one of your points...
I have approximately 30-40 sites still running on Concrete 5.6.3.4/5. Quite a few of these are not 'mission-critical' and are on shared servers. This week I have been in touch with the hosting companies in question to see when they will be switching to php7, and I am hearing back that most are planning to make the switch by about September/October this year - so in about 3-4 months time. As such, I need to do something quite quickly about these sites - Either migrate them to another server with more control where I can have php5.6 for a little longer (although this would just be a 'stay of execution'), or look to re-build all those sites either in Concrete5.8 / another CMS - it would seem to me that this is the most realistic option right now.
I would expect that this will be quite a common problem, so felt it was worth sharing.
Something to add to the mix that is of note, and relates to one of your points...
I have approximately 30-40 sites still running on Concrete 5.6.3.4/5. Quite a few of these are not 'mission-critical' and are on shared servers. This week I have been in touch with the hosting companies in question to see when they will be switching to php7, and I am hearing back that most are planning to make the switch by about September/October this year - so in about 3-4 months time. As such, I need to do something quite quickly about these sites - Either migrate them to another server with more control where I can have php5.6 for a little longer (although this would just be a 'stay of execution'), or look to re-build all those sites either in Concrete5.8 / another CMS - it would seem to me that this is the most realistic option right now.
I would expect that this will be quite a common problem, so felt it was worth sharing.
Wow, 30-40 sites is a lot! If the time you save from not having to re-build those could translate into a budget you can spend, It might be worth talking to Remo (see the link above) about porting 5.6 to PHP7 after all... if you chose to make that Open Source, I'm sure you would be doing a lot of people a huge favour. Many of them probably don't even yet know how huge until their providers tell them they're switching off PHP5 support! :)
Myself, as mentioned above, I've pulled the plug on a major 5.7 relaunch and am currently moving everything mission critical to Wordpress, with a heavy heart.
Myself, as mentioned above, I've pulled the plug on a major 5.7 relaunch and am currently moving everything mission critical to Wordpress, with a heavy heart.
Yes, I will definitely take a look at what Remo's been doing.
If there was any realistic way to stay with 5.6 I would be happy to. I think it was close to perfection. My clients love using it in a way I have not really experienced with any other CMS I've used, but - for all the reasons the core team originally gave for not being able to provide an upgrade path - at the moment it feels almost inevitable to me that 5.6 will need to be left behind.
+ (saying this very quietly) I am also guilty of getting back on board with WordPress on some recent projects. Not happy about it though!
Cheers.
If there was any realistic way to stay with 5.6 I would be happy to. I think it was close to perfection. My clients love using it in a way I have not really experienced with any other CMS I've used, but - for all the reasons the core team originally gave for not being able to provide an upgrade path - at the moment it feels almost inevitable to me that 5.6 will need to be left behind.
+ (saying this very quietly) I am also guilty of getting back on board with WordPress on some recent projects. Not happy about it though!
Cheers.
I guess a version 5.x that IS compatible with PHP7.x, should be a new release. So perhaps those who need it, can work together to make this happen. Rebuilding loads of sites will cost huge amounts of money... It's not a couple of hours we're talking about if you want to switch from 5.6 to 8.x.
But then again.. some plugins may have deprecated code too. So you'd have to contact the developers of those third party Add-Ons or either fix them yourselves for the whole bunch of sites.
I'd advice to stay up-to-date though and update to new versions where possible. Of course, not an easy/minor task for some sites... but that's software. It updates and gets deprecated (for a reason). Version 5.7 is around since somewhere mid 2014 right? So 5.6 is around 3 years ago. Kind of expected, seeing the first release of 5.6.x is even years before these mentioned 3 years.
(p.s. never going to WordPress myself, never-ever haha)
But then again.. some plugins may have deprecated code too. So you'd have to contact the developers of those third party Add-Ons or either fix them yourselves for the whole bunch of sites.
I'd advice to stay up-to-date though and update to new versions where possible. Of course, not an easy/minor task for some sites... but that's software. It updates and gets deprecated (for a reason). Version 5.7 is around since somewhere mid 2014 right? So 5.6 is around 3 years ago. Kind of expected, seeing the first release of 5.6.x is even years before these mentioned 3 years.
(p.s. never going to WordPress myself, never-ever haha)
Just want to point out that rebuilding sites with version 8 may seem to be a good solution, But, what about the user editing interface.
Some existing 5.6 sites have multiple users that have been trained to use the existing 5.6 GUI.
Many of those users have little or no knowledge of website editing but have managed to grasp the concept by using the super easy 5.6 editing methods.
I can see that trying to re-educate users to the new not-so-easy version 8 methods would mean that many users will simply walk away and look for an alternative to a site built on Concrete CMS.
Some existing 5.6 sites have multiple users that have been trained to use the existing 5.6 GUI.
Many of those users have little or no knowledge of website editing but have managed to grasp the concept by using the super easy 5.6 editing methods.
I can see that trying to re-educate users to the new not-so-easy version 8 methods would mean that many users will simply walk away and look for an alternative to a site built on Concrete CMS.
As one of the "the self-taught garden shed developers" I am more than interested in saving c5.6's live.
I feel just like you do, the UI is clunky, and sometimes I struggle with it more than with wordpress UI.
I hate wordpress and avoid it like the plague, but from an end user's standpoint it has attractions
what frustrates me almost as much as the horrible UI in c7/8 is the fact that developers have abandoned their c5.6 themes and add-ons. just like rats and the sinking ship
I think this fact will kill off c5.6 much faster that the phasing out of php5
Looking for a suitable theme for a client all I find are notices all over the place that this isn't supported any longer, that hasn't been updated in three years, support tickets have been in progress for years, and great things like pro-blog have simply been taken out of the marketplace.
I have been designing sites in c7/8 too, but I struggle at every turn. Things that are simple in c5.6 are giving me headaches in c7/8.
Not to speak about bugs, which have already been mentioned.
I do not feel comfortable with c7/8 and I cannot see any of my clients happy with it - I still use only c5.6 for clients and will continue to do so until it becomes an impossible task.
I feel just like you do, the UI is clunky, and sometimes I struggle with it more than with wordpress UI.
I hate wordpress and avoid it like the plague, but from an end user's standpoint it has attractions
what frustrates me almost as much as the horrible UI in c7/8 is the fact that developers have abandoned their c5.6 themes and add-ons. just like rats and the sinking ship
I think this fact will kill off c5.6 much faster that the phasing out of php5
Looking for a suitable theme for a client all I find are notices all over the place that this isn't supported any longer, that hasn't been updated in three years, support tickets have been in progress for years, and great things like pro-blog have simply been taken out of the marketplace.
I have been designing sites in c7/8 too, but I struggle at every turn. Things that are simple in c5.6 are giving me headaches in c7/8.
Not to speak about bugs, which have already been mentioned.
I do not feel comfortable with c7/8 and I cannot see any of my clients happy with it - I still use only c5.6 for clients and will continue to do so until it becomes an impossible task.
But you can self-teach you the new version of the CMS as well, right? I mean, it may take you a bit more time, but that's with everything that is new. Things change.
As for keep using 5.6 for clients, it may be a bit unfair. They may think you have an up-to-date CMS installed with the latest techniques and such. But in truth, you are using a version of it that is about 2+ years old and not being updated anymore (other than big security issues and such). Also, as you stated, the marketplace is quite dead for this version of the CMS, just because everyone is using the latest versions. Of course, no money can be made anymore for this version, but probably the developers themselves aren't using this version either anymore for their clients.
I haven't been developing marketplace items for version 5.6, so I can't tell you anything about it, but it only makes sense to me. I started the marketplace on version 5.7 and I do create Add-Ons that work with 5.7 AND the latest 8.x, but sometimes there's too much to work around and I just make them for version 8 instead (where earlier versions still work for 5.7 though). At one point, you'd have to drop it for multiple reasons. Code is getting bloated, executing the Add-On will get slower, what percentage is still using this version of the CMS et cetera.
More or less the same what you see with iOS (Apple Software) where some latest versions only work if you got the latest iPhone. Or that your Samsung Galaxy S4 can't update to the latest Android, since it's not supported on such an old device anymore. They more or less force you to stick with what you can stick with or update your hardware (in this case) to make use of the latest available stuff.
As for keep using 5.6 for clients, it may be a bit unfair. They may think you have an up-to-date CMS installed with the latest techniques and such. But in truth, you are using a version of it that is about 2+ years old and not being updated anymore (other than big security issues and such). Also, as you stated, the marketplace is quite dead for this version of the CMS, just because everyone is using the latest versions. Of course, no money can be made anymore for this version, but probably the developers themselves aren't using this version either anymore for their clients.
I haven't been developing marketplace items for version 5.6, so I can't tell you anything about it, but it only makes sense to me. I started the marketplace on version 5.7 and I do create Add-Ons that work with 5.7 AND the latest 8.x, but sometimes there's too much to work around and I just make them for version 8 instead (where earlier versions still work for 5.7 though). At one point, you'd have to drop it for multiple reasons. Code is getting bloated, executing the Add-On will get slower, what percentage is still using this version of the CMS et cetera.
More or less the same what you see with iOS (Apple Software) where some latest versions only work if you got the latest iPhone. Or that your Samsung Galaxy S4 can't update to the latest Android, since it's not supported on such an old device anymore. They more or less force you to stick with what you can stick with or update your hardware (in this case) to make use of the latest available stuff.
Ramon, there is a big difference between the technical background you have and the average developer who was comfortable with c5.6.
>Also, as you stated, the marketplace is quite dead for this version of the CMS, just because everyone is using the latest versions.
That seems to be in direct contradiction to what other marketplace sellers have been saying in this very thread.
That seems to be in direct contradiction to what other marketplace sellers have been saying in this very thread.
I hardly ever sell a 5.6 add on, but my 5.7+ add ons are selling on the time.
Recently I did some work on a 5.6 site for a client, it had been a very long time since I worked with 5.6 and I do agree with you the UI was a delight to use and I have always thought it better than 5.7x.
But really, abandon 5.7 for Wordpress, that's just nuts!
Recently I did some work on a 5.6 site for a client, it had been a very long time since I worked with 5.6 and I do agree with you the UI was a delight to use and I have always thought it better than 5.7x.
But really, abandon 5.7 for Wordpress, that's just nuts!
> But really, abandon 5.7 for Wordpress, that's just nuts!
Why? For me and most of the folks who use the sites I set up, the end user UI was C5's big selling point until 5.6. That is gone now.
On the back end, I agree you have a beautiful, clean code structure - but on the web hosts I use, it is much slower than 5.6 used to be even with all caching on. Sure, I could rent a dedicated server with an opcode cache - but why bother doing that for a bad UI experience, when Wordpress has a decent-ish user interface, does everything C5 can, serves pages quickly even on mediocre hosting with WP super cache, and is infinitely better supported than C5?
It no longer adds up.
Why? For me and most of the folks who use the sites I set up, the end user UI was C5's big selling point until 5.6. That is gone now.
On the back end, I agree you have a beautiful, clean code structure - but on the web hosts I use, it is much slower than 5.6 used to be even with all caching on. Sure, I could rent a dedicated server with an opcode cache - but why bother doing that for a bad UI experience, when Wordpress has a decent-ish user interface, does everything C5 can, serves pages quickly even on mediocre hosting with WP super cache, and is infinitely better supported than C5?
It no longer adds up.
Ramon, my clients do not think they have a new or updated CMS. They do not think about code or any background things at all. Why should they?? They are end users, they are no webdesigners, no coders.
What they think is - I have a CMS that makes it easy for me to keep my site updated. They think - whoa, this is great, how I can add my own images and videos and text make it look nice without any headache!
Yes - I can teach myself the new c5 version. But why take away end user friendly things?
I don't know if it was really necessary.
Why not keep the UI intact while updating the code in the background?
What they think is - I have a CMS that makes it easy for me to keep my site updated. They think - whoa, this is great, how I can add my own images and videos and text make it look nice without any headache!
Yes - I can teach myself the new c5 version. But why take away end user friendly things?
I don't know if it was really necessary.
Why not keep the UI intact while updating the code in the background?
Well they may not think about code, but what if some random developer messaged them saying "Hey, your site's CMS is about 3 years old - it's time to update because of speed issues and have new options and such". The client might then think, "Three years old... this website just got developed a few days/weeks ago, how can this be YEARS old?".
Seems an unlikely situation, but I've had a client of a client who was messaged saying their version was 2 years old (yeah, it wasn't updated for 2 years and it is 5.7) and they wanted to know why it wasn't updated (yet). So always be careful with things like this. Explicitly let them know you'll be using an old(er) version of the CMS along with the reasons why, and you should be covered. If you don't, I'd feel weird too if I got a website developed for me that is build on a CMS version that's from years ago.
I am not a core concrete5 developer, so I don't know why some UI things have changed. But maybe if you specifically let us know what you think should be brought back into the current UI, maybe that can happen as an Add-On or as an option within the core at some later point. Things change, and not everyone likes it. So there always very well may be someone/something to change that. I didn't like the backend/dashboard really either, so I made a new "skin" for it. That's how I got around my main issue.
Just my 2 cents.
Seems an unlikely situation, but I've had a client of a client who was messaged saying their version was 2 years old (yeah, it wasn't updated for 2 years and it is 5.7) and they wanted to know why it wasn't updated (yet). So always be careful with things like this. Explicitly let them know you'll be using an old(er) version of the CMS along with the reasons why, and you should be covered. If you don't, I'd feel weird too if I got a website developed for me that is build on a CMS version that's from years ago.
I am not a core concrete5 developer, so I don't know why some UI things have changed. But maybe if you specifically let us know what you think should be brought back into the current UI, maybe that can happen as an Add-On or as an option within the core at some later point. Things change, and not everyone likes it. So there always very well may be someone/something to change that. I didn't like the backend/dashboard really either, so I made a new "skin" for it. That's how I got around my main issue.
Just my 2 cents.
actually 5.6.3.5 is about two months old ...
and, ahem, if any of my clients received an email from a random web developer about their CMS they would most likely just treat it as spam
and, ahem, if any of my clients received an email from a random web developer about their CMS they would most likely just treat it as spam
OK, that could be true. I was browsing the download archive here:
https://www.concrete5.org/developers/developer-downloads...
This version you mentioned isn't in there and the latest 5.6.x was 2 years ago. So my bad, they still need to update that list then.
A comparison I did want to make was, it's sort of like selling Windows 8 or Windows 7 instead of the latest Windows 10. It still may receive updates, but new stuff won't be released for it. Developers won't be building new stuff for 5.6.x (or maybe they will, but for 1 developer building for 5.6 are 99 for 5.7/8.x). Also, 5.6 originally is base code from years ago. They didn't build 5.7 for nothing, they needed to get their code up-to-date and a simple rewrite wasn't going to cut it.
I'm not talking trash about 5.6, but I just think it's outdated by now. But I'm a (PHP) developer and know the code/structure. My view on it may be a bit more different. People buying a Galaxy S4 without the newest Android (because it can't run the newest) may be satisfied too. So in the end, it's all about the client/end user. Do what feels good to you, not what others shove down your throat.
https://www.concrete5.org/developers/developer-downloads...
This version you mentioned isn't in there and the latest 5.6.x was 2 years ago. So my bad, they still need to update that list then.
A comparison I did want to make was, it's sort of like selling Windows 8 or Windows 7 instead of the latest Windows 10. It still may receive updates, but new stuff won't be released for it. Developers won't be building new stuff for 5.6.x (or maybe they will, but for 1 developer building for 5.6 are 99 for 5.7/8.x). Also, 5.6 originally is base code from years ago. They didn't build 5.7 for nothing, they needed to get their code up-to-date and a simple rewrite wasn't going to cut it.
I'm not talking trash about 5.6, but I just think it's outdated by now. But I'm a (PHP) developer and know the code/structure. My view on it may be a bit more different. People buying a Galaxy S4 without the newest Android (because it can't run the newest) may be satisfied too. So in the end, it's all about the client/end user. Do what feels good to you, not what others shove down your throat.
"Hello, {{random mail-merged name}}, we noticed your web site was built using Wordpress. The fundamental software architecture behind Wordpress is messy and antiquated. We would like to offer you the chance to rebuild your web site with the latest Concrete version 8.2.1. Concrete5 v8 is built using all the latest concepts to escape from a computer science lab, so by definition it is way better than Wordpress and will therefore be much better for your business. Kind regards, {{mail-merged sales consultant name}}"
If that worked, the Wordpress market share would be shrinking and the concrete5 share would be taking over.
But that has never worked for competing against Wordpress, so why should it work for v8 against concrete5.6?
c5.6 and v8 are different products. c5.6 is a mature product in the stable part of the bathtub curve. v8 is still a new product with lots of behind the scenes features (that are irrelevant to 75% of web sites that are purely brochure-ware) and still on the leading edge of the bathtub curve. Use whichever of these products suits a customer and their requirement.
( bathtub curve, for anyone not familiar:https://en.wikipedia.org/wiki/Bathtub_curve... )
If that worked, the Wordpress market share would be shrinking and the concrete5 share would be taking over.
But that has never worked for competing against Wordpress, so why should it work for v8 against concrete5.6?
c5.6 and v8 are different products. c5.6 is a mature product in the stable part of the bathtub curve. v8 is still a new product with lots of behind the scenes features (that are irrelevant to 75% of web sites that are purely brochure-ware) and still on the leading edge of the bathtub curve. Use whichever of these products suits a customer and their requirement.
( bathtub curve, for anyone not familiar:https://en.wikipedia.org/wiki/Bathtub_curve... )
Further to Mr theFish's bathtub, I'd be worried about the 'wear-out' part of the curve. Web hosts phase out support for old versions of php and mysql (and probably php plugins), and caching systems are rapidly evolving. Sooner or later, one such change will break c5.6, which assumes old or backward-compatible versions of the things on which it depends. More recent editions of c5 will continue to operate for at least several years longer.
Software environment is not a risk. There is enough other software with similar requirements that there will always be hosting options with php5.6 etc. While some hosts update to php7 by default, only the worst few do so without maintaining a fallback for those who need it. The cost of VPS is steadily reducing, where the environment can be configured to whatever is needed. Its very much cheaper to move an old site to a new host than it is to rebuild in v8.
The main threat for end of life bathtub would be discovery of a significant new security threat and a lack of a security update to fix it.
Getting completely esoteric into engineering philosophy, higher entropy of software arises from higher complexity and results in a shorter floor of the bathtub curve. v8 has more than twice as much code in it as 5.6, so is at least 2x as complex and in some schools of thought 4x as complex. A lack of developer documentation is another factor that can lead to higher entropy. It could be argued that while v8 is newer, it may consequently have a shorter lifespan.
Despite all of that, v8 has its use. There are projects suited to v8 and projects where c5.6 is a better choice. But sites shouldn't be coerced into the higher complexity of v8 by false FUD about 5.6.
The main threat for end of life bathtub would be discovery of a significant new security threat and a lack of a security update to fix it.
Getting completely esoteric into engineering philosophy, higher entropy of software arises from higher complexity and results in a shorter floor of the bathtub curve. v8 has more than twice as much code in it as 5.6, so is at least 2x as complex and in some schools of thought 4x as complex. A lack of developer documentation is another factor that can lead to higher entropy. It could be argued that while v8 is newer, it may consequently have a shorter lifespan.
Despite all of that, v8 has its use. There are projects suited to v8 and projects where c5.6 is a better choice. But sites shouldn't be coerced into the higher complexity of v8 by false FUD about 5.6.
To anyone interested in running concrete5 Legacy (5.6) with PHP 7+: I just submittedhttps://github.com/concrete5/concrete5-legacy/pull/1955... that makes 5.6 run with any PHP version ranging from 5.3.2 to 7.2.0.
I tried my best to fix all the issues, but since concrete5 is such a big project, I really can't test every line of code, so any feedback is welcome.
I tried my best to fix all the issues, but since concrete5 is such a big project, I really can't test every line of code, so any feedback is welcome.
Exciting news + Good work!
I will trial it on a few of my 5.6 sites this week and report back.
Many thanks.
I will trial it on a few of my 5.6 sites this week and report back.
Many thanks.
This sounds really cool! Will be checking it out!
Thank you so much, - runs like lubricated.
I am testing this on one of my 5.6 sites and it is working flawlessly.
I simply replaced the concrete folder with the one found in the web folder of the download, turned on php short-open-tag in my wamp server and ran the index.php/tools/required/upgrade?force=1 script.
Mike, is it necessary to run any of the composer/grunt files etc, or can we do as I have done already and simply use the web/concrete folder?
Great work by the way, this will be a great boost to those of us who prefer the 5.6 architecture to the 5.7/version 8 architecture.
I simply replaced the concrete folder with the one found in the web folder of the download, turned on php short-open-tag in my wamp server and ran the index.php/tools/required/upgrade?force=1 script.
Mike, is it necessary to run any of the composer/grunt files etc, or can we do as I have done already and simply use the web/concrete folder?
Great work by the way, this will be a great boost to those of us who prefer the 5.6 architecture to the 5.7/version 8 architecture.
Thanks for checking, David!
The short tags problem is caused by the way concrete5-legacy is deployed. We may update thehttps://github.com/concrete5/concrete5-legacy... repository by expanding the short tags, but that would be for another pull request ;)
About the grunt file: I din't touch any JavaScript/CSS asset, so it's not necessary to rebuild them (you need to keep the files you currently have in the concrete/js and concrete/css directories).
And about composer: we don't use it in concrete5-legacy (and that's one of the many reasons why I prefer concrete5 version 8).
The short tags problem is caused by the way concrete5-legacy is deployed. We may update thehttps://github.com/concrete5/concrete5-legacy... repository by expanding the short tags, but that would be for another pull request ;)
About the grunt file: I din't touch any JavaScript/CSS asset, so it's not necessary to rebuild them (you need to keep the files you currently have in the concrete/js and concrete/css directories).
And about composer: we don't use it in concrete5-legacy (and that's one of the many reasons why I prefer concrete5 version 8).
Thanks for clarifying that the method I used was correct, that has put my mind at rest..
I saw the remove-short-tags.js file in the build/tasks/ folder and wondered if it should be run somehow to 'clean-up' the short open tags.
But, if we don't need to run any of the grunt files etc. then all is good.
I saw the remove-short-tags.js file in the build/tasks/ folder and wondered if it should be run somehow to 'clean-up' the short open tags.
But, if we don't need to run any of the grunt files etc. then all is good.
Please note that the End of Life date has been set for legacy concrete5 (versions earlier than v5.7). Please see the official announcement here:https://www.concrete5.org/about/blog/community-blog/official-end-lif...
*Edit:* in summary, End of Life means that no changes will be made by the core team for any reason after that date, including changes to address any future security vulnerabilities. Until that time, the only changes made by the core team will be to address security vulnerabilities (as has been the case for some time now). of course, anyone is free to modify the software as they see fit, but official support will end on that date.
*Edit:* in summary, End of Life means that no changes will be made by the core team for any reason after that date, including changes to address any future security vulnerabilities. Until that time, the only changes made by the core team will be to address security vulnerabilities (as has been the case for some time now). of course, anyone is free to modify the software as they see fit, but official support will end on that date.
That is a misleading phrase "End of Life" in my opinion it should be "End of Support".
"End of Life" gives the impression that all 5.6 sites will die, break down or stop functioning on the given date, like its got a built-in self destruct function!
"End of Life" gives the impression that all 5.6 sites will die, break down or stop functioning on the given date, like its got a built-in self destruct function!
@weyboat I understand your point, but it's a quite common term, see for example this page for PHP: http://secure.php.net/eol.php
I can see both sides of this. Perhaps @Myq can clarify his post on the various threads to make it clear to non-technical users that EOL does not mean their sites will not suddenly stop working overnight.
Noted and updated. The linked announcement should provide further clarification.
Although 5.6.3.5 was just recently released. If you haven't already seen it, check out this recent blog post:
https://www.concrete5.org/about/blog/community-blog/legacy-concrete5...
However, most of the marketplace developers (myself included) has any intention of developing for 5.6. In fact, all new marketplace submissions that come in are all for 5.7 and up.
5.8 works really well on PHP 7, and I'm happy with it, so now I'm strictly working with 5.7 and 5.8 versions, as they are forward-thinking.