Is there interest in keeping the 5.6 branch alive because of its great UI?3 users found helpful
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?
Although 184.108.40.206 was just recently released. If you haven't already seen it, check out this recent blog post:
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.
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.
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...
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.
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 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.
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 220.127.116.11/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.
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.
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!
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)
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.
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.
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.
That seems to be in direct contradiction to what other marketplace sellers have been saying in this very thread.
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!
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.
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?
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.
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
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.
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... )
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.
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 will trial it on a few of my 5.6 sites this week and report back.
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.
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 ;)
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).
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.