concrete5 5.6.1b1
Permalink
concrete5 5.6.1b1 is now available for download! While the interface is largely unchanged and there aren't a lot of new user-facing features, it's quite different and more efficient under-the-hood. Please check it out!
Download concrete5:
http://www.concrete5.org/developers/downloads/...
Full Release Notes of 5.6.1:
http://www.concrete5.org/documentation/background/version_history/5...
In short, this update should dramatically improve performance, completely replaces the full page caching library, fixes bugs and cleans up some very minor vulnerabilities.
Please feel free to post bugs to the 5.6.0.2 bug tracker if you find anything new that 5.6.1 introduces. I will be cleaning that out over the coming days, as well as going through github.
Download concrete5:
http://www.concrete5.org/developers/downloads/...
Full Release Notes of 5.6.1:
http://www.concrete5.org/documentation/background/version_history/5...
In short, this update should dramatically improve performance, completely replaces the full page caching library, fixes bugs and cleans up some very minor vulnerabilities.
Please feel free to post bugs to the 5.6.0.2 bug tracker if you find anything new that 5.6.1 introduces. I will be cleaning that out over the coming days, as well as going through github.
Live site updated a bit quicker and have moved folder up from updates.
Page rendering went from just over 9 seconds to just over 3 seconds.
Reload is almost instant, even with default cache settings.
FTB is up.
Page speed dropped but less errors showing?
YSlow has given an 'A', only failed on CDN!
Roll on 5.7...
Page rendering went from just over 9 seconds to just over 3 seconds.
Reload is almost instant, even with default cache settings.
FTB is up.
Page speed dropped but less errors showing?
YSlow has given an 'A', only failed on CDN!
Roll on 5.7...
That is excellent excellent news
Looks great from here too for now. definitely speedup the website compare to 5.6.0
One remark. Can you add the UI rework on bootstrap actually in 5.7 branch in the release of 5.6.1. It fix the grid overlap with c5 core bootstrap which is quite annoying.
This would be awesome since 5.7 release date looks like not be anytime soon
By the way. I already have this glitch before but it still here (also happen with 5.7 branch from github) when a theme is using bootstrap framework there is a styling glitch with the admin edit bar in fronted. The intelligent search input is a bit overweight XD. See attachment.
Thank for your hard work
One remark. Can you add the UI rework on bootstrap actually in 5.7 branch in the release of 5.6.1. It fix the grid overlap with c5 core bootstrap which is quite annoying.
This would be awesome since 5.7 release date looks like not be anytime soon
By the way. I already have this glitch before but it still here (also happen with 5.7 branch from github) when a theme is using bootstrap framework there is a styling glitch with the admin edit bar in fronted. The intelligent search input is a bit overweight XD. See attachment.
Thank for your hard work
Have you tried looking at your theme css?
I had a similar issue with the 'IS', but mine was very small.
Had to remember to 'wrap' the 'h' tags.
I had a similar issue with the 'IS', but mine was very small.
Had to remember to 'wrap' the 'h' tags.
i do when i look at the log console. it's an overlap from my theme css. The node which create the problem come from bootstrap framework.
The complete node.
The glitch coming from this line exactly, if you remove it then it looks fine.
But i do not want to hack bootstrap core
You can fix it by adding the following line to your theme css. But it would be better if this can be add to concrete core
hope it can help
The complete node.
select, textarea, input[type="text"], input[type="password"], input[type="datetime"], input[type="datetime-local"], input[type="date"], input[type="month"], input[type="time"], input[type="week"], input[type="number"], input[type="email"], input[type="url"], input[type="search"], input[type="tel"], input[type="color"], .uneditable-input { display: inline-block; -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; min-height: 34px; padding: 6px 9px; margin-bottom: 10px; font-size: 14px; line-height: 20px; color: #555555; vertical-align: middle; background-color: #ffffff; border: 1px solid #cccccc; border-radius: 4px;
Viewing 15 lines of 22 lines. View entire code block.
The glitch coming from this line exactly, if you remove it then it looks fine.
min-height: 34px;
But i do not want to hack bootstrap core
You can fix it by adding the following line to your theme css. But it would be better if this can be add to concrete core
div.ccm-ui input[type="search"] { min-height: 12px; }
hope it can help
Suggestion.
When an update script is run. It should ignore user overrides.
User overrides are always older versions of the core (many with custom modifications) and cause a vast amount of the upgrade issues. Although they may still cause issues after update, they shouldn't prevent the core being updated.
When an update script is run. It should ignore user overrides.
User overrides are always older versions of the core (many with custom modifications) and cause a vast amount of the upgrade issues. Although they may still cause issues after update, they shouldn't prevent the core being updated.
Another suggestion.
Full page caching (FPC) has been vastly improved and now reduces TTFB by a factor of 10. However. If it can be used is very dependent on whether blocks support it. Most pages cannot use it (take for example all the pages on the Greek Yoghurt default).
It would be nice to have an indication showing which blocks are preventing full page caching (like the guestbook and search blocks, for example) as I think many blocks that prevent FPC can support it but have not been "tagged" as such. A small exclamation triangle or other indicator in the corner of a block when in edit mode would enable easy identification of which blocks are preventing FPC and the developer can then either override the setting for that page (if appropriate), or improve the block to remove the limitation.
Full page caching (FPC) has been vastly improved and now reduces TTFB by a factor of 10. However. If it can be used is very dependent on whether blocks support it. Most pages cannot use it (take for example all the pages on the Greek Yoghurt default).
It would be nice to have an indication showing which blocks are preventing full page caching (like the guestbook and search blocks, for example) as I think many blocks that prevent FPC can support it but have not been "tagged" as such. A small exclamation triangle or other indicator in the corner of a block when in edit mode would enable easy identification of which blocks are preventing FPC and the developer can then either override the setting for that page (if appropriate), or improve the block to remove the limitation.
This is a great idea. We will think about how we might get something like this integrated.
Will try live.
This is gonna be a good year!