My evaluation

Permalink
The first thing I discovered about 5.7.4.1 was its, surprising, move towards being quite unfriendly. The main thing I liked about Concrete was it was user friendly to the point that your average waitress could quite easily edit a site. Clients loved it. This ability made it so I could live with the massive amount of space it needed and its lack of speed.
We have recently had one client that wanted to move to responsive so I begrudgingly took the task of converting their older Concrete site and hope that they can manage the new version (a waitress looks after it).

I like the way the responsive is integrated, that seems to work well.

This is a list of some of the problems I ran into:

1. I usually start with an empty site and found this to be not so much of a good idea as building a blog page from scratch was not on my list of fun things to do (you use to simply add it).

2. Every time I returned to the website from the dashboard I wound up on a page that said "Download file Invalid file" instead of the home page.

3. Adding a page using composer usually didn't work and resulted in doing it through the sitemap.

4. The editor is flakey at best. If you unbold something it doesn't actually remove the strong tags, it adds more to contradict them. Getting rid of br tags could only be done through source code, same with an extra list bullet that would not go away when I finished a list. I had to spend a lot of time in source code cleaning up extraneous code. I figure it took me at least twice as long to convert the site over with 5.7.4.1 than it ever did to convert from any other format to 5.6.

5. Adding content is less efficient. You use to click on an empty block select content, click again to select type. Everything was under your cursor. Now you have to travel across the page to select the content. Even if the content sidebar looks cool it's a waste of valuable time.

6. Then there is the weight of the site. The 5.6 version came in at 54.4M for files (cache cleared) and 9.1M for dbase (old versions cleared). 5.7.4.1 holds at 110.9M for files (cache cleared) and 3.3M for dbase (old versions cleared. Okay, the dbase is smaller but that is a whopping 104% increase in file size for the same content, maybe less content as there may have been extra images in the file manager in the original. This is absolutely unacceptable.
Concrete5.7.4.2 comes in at 105M with sample content (This is over the max of some of the hosting we have encountered)
Joomla comes in at 37.4M with sample content (It's still less friendly).
Wordpress comes in at 21.6M and seems to be friendlier (I refuse to use it as it is the worst site for being hacked)

What to do about it?
I understand the effort that goes into development but this one needs to go back to the drawing board.
I am going to continue to use 5.6 as long as it functions and see if I can incorporate Bootstrap into it. I will keep my eyes on future versions hoping that there will be a return to simplicity and less fat. If not, unfortunately, Concrete will no longer be my choice.

scorpa54
 
goodnightfirefly replied on at Permalink Reply
goodnightfirefly
1. You can install the sample content to get a blog set up, and remove any content you don't need. Or copy how the blog from sample content is set up. Super quick.

2. Fixed in 5.7.4.2: "Fix download file script leading to 404 errors after you go to the dashboard and hit the back button"

3. Describe "didn't work" so we can pinpoint the issue you are having.

4. Haven't had any issues myself but others have reported problems with Redactor.

5. You can add a Block to an Area in the same way 5.6 did. Click the Area name and select Add Block. Moving the mouse over to the left a bit is certainly not "a waste of valuable time" and seems like an exaggeration.

6. A 5.7.4.2 site I just set up is 66.2MB. 54% of the weight comes from the 3rd party libraries like ZendFramework, Doctrine ORM, Symfony etc. A 5.6 site of mine is coming in at 37.4MB, I'm not sure why your numbers are so much higher.
scorpa54 replied on at Permalink Reply
scorpa54
I appreciate your response, thanks.
1. I understand that you can set up a site with sample content and basically I was saying that is the way to go in order to have all pages at your disposal, by saying installing an empty site was not the way to go.
2. Nice to know but it still doesn't account for my main issue, user friendliness for the end user (my clients).
3. Did not have a functioning "Page location" option under composer and the "Location/Choose location" function worked intermittently.
4.
5. Even seconds add up when you're on the clock.
6. The 5.6 numbers were with a finished project as a comparison to the exact same project finished in 5.7.4.1. The 5.7.4.2 sample content numbers could be higher as Mac tends to read higher than Windows.
MrKDilkington replied on at Permalink Reply
MrKDilkington
@scorpa54

Are you using responsive images in your theme? If so, this will increase the size of your site.

Each image you upload to your site will generate thumbnails of multiple sizes. While this may increase the size of your install, it offers a significant benefit to those viewing your site.

More information on responsive image use in themes:
https://www.concrete5.org/documentation/developers/5.7/designing-for...
scorpa54 replied on at Permalink Reply
scorpa54
That I am but with the tools I have the images add up to about 7M on the original site and 8.5M on the new site so the difference in stored image size is not an issue that I am concerned about.
exchangecore replied on at Permalink Reply
exchangecore
1. As @scrorpa pointed out, starting with a base can be a helpful thing if you want to avoid having to set up the page types yourself. This is why the sample content is in place. It's also completely feasible for someone to work up their own starting point to be used on sites that they want to build so that if you just want a blog installed without all the other cruft, you can do that. Empty means bare bones and you're going to end up doing a lot of the heavy lifting yourself, which I personally prefer when I'm building many of my sites so I'd like that option to stay the way it is.

2. As mentioned, this is fixed in 5.7.4.2. "User Friendliness" is ultimately a subjective measurement so I'm not going to touch that one.

3. I haven't had issues with this. When you save, it should tell you that there is an invalid location if that's the piece that's missing and if I recall there is a link to open the panel which allows you to set the page location. There are NUMEROUS threads discussing the new mannerisms of user experience here. You will be pleased to know that this is on the core teams radar as outlined inhttps://github.com/concrete5/concrete5/issues/2060.... I'm not sure there is a plan in place to fix it yet, but it's at least acknowledged as being a problem so I hope you'll find some comfort in that.

4. I'm unable to replicate the issue you're producing. If you could, please produce steps / screenshots on how we can reproduce the issue. Once you're certain you can reproduce it post the steps to the bug tracker athttp://www.concrete5.org/developers/bugs/.... This helps to verify that others are seeing the same thing you are and ultimately helps get problems in concrete5 resolved. Personally, i'm quite font of the new redactor wyswig editor and am super excited about the newly added extendibility of it within concrete5 to allow redactor plugins to be hooked into it.

5. As I mentioned in #2, user experience is a very subjective matter. I'm going to leave this one alone as I've made my peace with it and it's not likely that this will change anytime soon in the core. That said, I imagine if someone wanted to they could build a plugin which re-introduced the "Add Block" functionality by clicking on an area on the page, I'm just not sure how much work it would take. I think if you want this one to get "resolved" you're going to have to look for other methods outside of the core team to get it done. (Though I'm sure they read these and I'm sure they weigh these in their decisions every day)

6.100mb when compared to other frameworks seems like a lot, I'll completely agree with you on that one. Ultimately though if you are running your website on a web host that restricts you to 100mb of disk space you are most likely a) using a free webhost b) paying less than a buck a month for web hosting c) getting ripped off. There are countless hosts out there that provide you with enough space to run 5 or more concrete5.7 sites for $3-5 a month (and if you need pointed in the right direction check outhttps://www.concrete5.org/get-started/hosting... or simply ask me via pm for my extremely biased opinions). Typically when we set clients up we get them a "small" 3gb disk account or thereabouts and that's enough to run their main website, a test website, and their email for years.

You also mention the lack of speed. I'll just point out that concrete5 has numerous levels of caching that can be enabled / disabled / adjusted depending on your use case. I can also tell you that in my environment my page load times are running right around 350-400ms without page caching turned on. To me this is completely reasonable for what concrete5 does behind the scenes (which is necessary to provide it's huge level of extendibility).
JohntheFish replied on at Permalink Reply
JohntheFish
I think (3) and the linked usability issue on github (@exchangecore's link works without the period on the end) is the crux of many usability issues.
https://github.com/concrete5/concrete5/issues/2060...
I am disappointed (but not surprised given the history of usability issues in 5.7) that it is only classified as 'minor'. I am very disappointed that it only 'showed up in a usability test' in March, when community members have been raising the same issues with adding pages since the first 5.7 demonstration well over a year ago.
Korvin replied on at Permalink Reply
Korvin
I'm with you on that, can you link to any git issues created for this prior to march?
scorpa54 replied on at Permalink Reply
scorpa54
Well, I just went live with the site and it is far worse than I could have imagined.
After turning on all the cache settings the front end has fairly reasonable load times of around 9 seconds on the larger pages.
The backend, however, is taking 15 MINUTES and more to get from login to loaded home page.
I wanted to edit a form on one of the pages and the scenario went like this:
login, wait 15 minutes before I can select the page I wish to go to.
Select that page, wait 15 minutes for it to load
Click "edit mode", wait 15 minutes and give up in disgust because it hasn't loaded yet.

I absolutely cannot inflict this upon my client nor can I say "I am charging you for the time I had to sit there and watch my browser grind away while steam poured out of my ears".
I am going to set things back to their older version and find another alternative for going responsive.

In my humble opinion, you had something that was awesome and worked really well then you improved upon it to the point of destruction. It saddens me that this is the case and that it seems, from what exchangcore has said, that it is not going to be rectified. So for my "what to do about it" I've started to write my own system.
Good luck and goodbye.
MrKDilkington replied on at Permalink Reply
MrKDilkington
@scorpa54

What is the address of the live site?

"So for my "what to do about it" I've started to write my own system."

If you have the skill set to create your own CMS, why not contribute code to the project to make it better? Starting a CMS from scratch is a massive undertaking.
ramonleenders replied on at Permalink Reply
ramonleenders
Probably just bad hosting. I've had sites on some hostings that took like a second longer than on my more or less cheap hosting. You just have to find a good fit I guess. Perhaps take a look at concrete5 hosts instead of the unknown ones.
scorpa54 replied on at Permalink Reply
scorpa54
We have 4 other Concrete sites on the same hosting, 5.6 versions that load in under 3 seconds.
scorpa54 replied on at Permalink Reply
scorpa54
http://www.pioneerhouserestaurant.com/

Won't be there for long, will be putting thing back to 5.6 sometime this weekend.

As far as contributing to the project I would be lost as I have no idea how these things connect, it is just too massive to follow. With my own code I know where I am going with it.
MrKDilkington replied on at Permalink Reply
MrKDilkington
@scorpa54

If you are concerned with performance, there are some areas that need attention.

A few recommendations:
1. enable GZIP
2. enable browser caching
3. optimize images
- you are using JPG images that are using default compression
Example:
slide-7.jpg is 500KB and could be compressed to 65KB without adding noticeable artifacting
- you have multiple PNG files that are photographic images that don't use transparency, these should be saved to JPG
Example:
box-1c.png is 105KB and could be saved as a JPG with a file size of 15KB

Your site currently weighs in at around 4MB. Optimizing it would bring that down to under 1.5MB.

When I view your site, the DOM is loading in around 1.5 seconds and full site load around 5 to 5.5 seconds. This is not bad at all, especially considering the page size and my distance from the server.

If you cut the unnecessary page weight, the DOM and full site load times will drop dramatically.
scorpa54 replied on at Permalink Reply
scorpa54
Allow me to repeat myself, the frontend load times are a bit slower than Concrete56 with the exact same content but acceptable. It is when I'm trying to move around in the backend that things are beyond horrible.
JohntheFish replied on at Permalink Reply
JohntheFish
I am not a fan of 5.7 in its current state, I have many issues with it. But I have yet to experience 15-minute load times when editing. My experience is that speed in 5.7 is comparable to a slow 5.6 site.

With load times like that, there must be something else that is seriously wrong with the installation or the server.
exchangecore replied on at Permalink Reply
exchangecore
Agreed. I've seen over 1 minute load times while XDEBUG is enabled, but you shouldn't be running this in a production environment (or when you don't need it for that matter). I'd say something else probably isn't right, either with the specific concrete5 instance or with the hosting.
scorpa54 replied on at Permalink Reply
scorpa54
Don't know what to say other than I used a stop watch and actually got a 40 minute grind, after posting the update, while trying to go from one page to another in the backend. Those pages don't seem to be caching.
Korvin replied on at Permalink Reply
Korvin
There is just no way that concrete5 is hanging for 40 minutes, it must be waiting for the database or for an email server or something. This is for sure some custom code that you have in your site or a borked database or apache not sending or something. Have you attempted debugging in a different environment?
scorpa54 replied on at Permalink Reply
scorpa54
I know I certainly did not get any times anywhere near that on my localhost even with caching turned off. If I had I would never have loaded it up.
JohntheFish replied on at Permalink Reply
JohntheFish
Any chance it could still be using the database from the localhost. That would slow it down.
scorpa54 replied on at Permalink Reply
scorpa54
No, I have my localhost set to not accept any external queries and it has been turned off during the whole transfer process.
scorpa54 replied on at Permalink Reply
scorpa54
More fun. Tried to delete the site only to find that the Application folder hangs on like a virus and will not be deleted.
Tried deleting through cPanel's file manager and also through Filezilla.
Tried to chmod through Filezilla.
How does one get rid of this folder and contents?
Thank you kindly.
mesuva replied on at Permalink Reply
mesuva
That sounds like a broader permissions issue with your hosting.
I have seen this before, but it wasn't specific to concrete5 - it was an incorrectly set up server.

I'd say have a chat with your hosting.
scorpa54 replied on at Permalink Reply
scorpa54
Thanks, from what the tech says it's the way Concrete creates its cache, it sets the owner to unknown.