RC 8.2.0 Released
Permalink
In case you missed it
https://www.concrete5.org/about/blog/community-blog/first-public-rel...
https://www.concrete5.org/about/blog/community-blog/first-public-rel...
I installed this on my WAMP box and it installed without a hitch...
issue
https://github.com/concrete5/concrete5/issues/5617#issuecomment-3112...
Associated pull by mlocati fixes it
https://github.com/concrete5/concrete5/issues/5617#issuecomment-3112...
Associated pull by mlocati fixes it
Thank you for posting this, weyboat.
It is very important that people download and test the 8.2 release candidates. Once 8.2 goes final, if you find a bug, especially a bug that affects you personally, you will then have to wait until the next release for it to be resolved. The bottom line is don't wait until it is final to test it, test it now so unseen issues can be fixed.
For everyday users, you can test 8.2 RC2 by installing it in a subdomain of your web hosting account. For designers and developers, in addition to testing on a subdomain, you can test it on a local server.
As an open source project, testing is a great opportunity for you to get involved.
"given enough eyeballs, all bugs are shallow"
It is very important that people download and test the 8.2 release candidates. Once 8.2 goes final, if you find a bug, especially a bug that affects you personally, you will then have to wait until the next release for it to be resolved. The bottom line is don't wait until it is final to test it, test it now so unseen issues can be fixed.
For everyday users, you can test 8.2 RC2 by installing it in a subdomain of your web hosting account. For designers and developers, in addition to testing on a subdomain, you can test it on a local server.
As an open source project, testing is a great opportunity for you to get involved.
"given enough eyeballs, all bugs are shallow"
I've just tried a fresh install, as well as an update of a 8.1 site (with Community Store installed) and it's seemed to go very smoothly. Really loving all the updates and fixes, especially for things like pagination of results in the dashboard.
I share MrKDilkington's sentiment that it's really critical that lots of people (of all different experiences) test out release candidates like this to find last minute and obscure bugs.
It's not just about testing the core release too, it's also about catching potential issues in add-ons. For example, tonight I found in Community Store that a helper had been loaded in a way that worked fine in 5.7 and 8.1 but not longer works in 8.2. It wasn't a bug in 8.2, it was that the code in Community Store wasn't following the documented way of handling things and it just got away with working before - a quick update fixed things for 8.2, but also remained compatible with 5.7. Those kind of fixes are always better to do _before_ committing to an actual production site update!
The more eyes on this the better!
I share MrKDilkington's sentiment that it's really critical that lots of people (of all different experiences) test out release candidates like this to find last minute and obscure bugs.
It's not just about testing the core release too, it's also about catching potential issues in add-ons. For example, tonight I found in Community Store that a helper had been loaded in a way that worked fine in 5.7 and 8.1 but not longer works in 8.2. It wasn't a bug in 8.2, it was that the code in Community Store wasn't following the documented way of handling things and it just got away with working before - a quick update fixed things for 8.2, but also remained compatible with 5.7. Those kind of fixes are always better to do _before_ committing to an actual production site update!
The more eyes on this the better!
What my eyes see…
Fresh install 8.2.0
Set pretty urls. Turned off all caching.
Installation seemed to work well and quite quickly.
However trying to log out does not work for me, sends me down tohttp://localhost:8888/, not home page.
All references using ‘do_logout’ (six pages) seems to be the issue. If I remove ‘do_’ all works.
Do I need to change something else or is this a C5 hiccup?
Search results repeats over 50 times, gave up after 5 pages worth? See attached.
Newish iMac running OS Sierra 10.12.5. 2.8GHz i5.
MAMP Version: 3.4 (will update to 4 at some point soon).
# concrete5 Version
Core Version - 8.2.0RC2
Version Installed - 8.2.0RC2
Database Version - 20170626000000
# concrete5 Packages
None
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).
# Server Software
Apache/2.2.29 (Unix) mod_wsgi/3.5 Python/2.7.10 PHP/5.6.10 mod_ssl/2.2.29 OpenSSL/0.9.8zh DAV/2 mod_fastcgi/2.4.6 mod_perl/2.0.9 Perl/v5.22.0
# Server API
apache2handler
# PHP Version
5.6.10
# PHP Extensions
apache2handler, bcmath, bz2, calendar, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imap, intl, json, ldap, libxml, mbstring, mcrypt, mysql, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, yaz, zip, zlib
# PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 1000
memory_limit - 128M
post_max_size - 32M
sql.safe_mode - Off
upload_max_filesize - 32M
ldap.max_links - Unlimited
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
pgsql.max_links - Unlimited
pgsql.max_persistent - Unlimited
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
Fresh install 8.2.0
Set pretty urls. Turned off all caching.
Installation seemed to work well and quite quickly.
However trying to log out does not work for me, sends me down tohttp://localhost:8888/, not home page.
All references using ‘do_logout’ (six pages) seems to be the issue. If I remove ‘do_’ all works.
Do I need to change something else or is this a C5 hiccup?
Search results repeats over 50 times, gave up after 5 pages worth? See attached.
Newish iMac running OS Sierra 10.12.5. 2.8GHz i5.
MAMP Version: 3.4 (will update to 4 at some point soon).
# concrete5 Version
Core Version - 8.2.0RC2
Version Installed - 8.2.0RC2
Database Version - 20170626000000
# concrete5 Packages
None
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).
# Server Software
Apache/2.2.29 (Unix) mod_wsgi/3.5 Python/2.7.10 PHP/5.6.10 mod_ssl/2.2.29 OpenSSL/0.9.8zh DAV/2 mod_fastcgi/2.4.6 mod_perl/2.0.9 Perl/v5.22.0
# Server API
apache2handler
# PHP Version
5.6.10
# PHP Extensions
apache2handler, bcmath, bz2, calendar, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imap, intl, json, ldap, libxml, mbstring, mcrypt, mysql, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, yaz, zip, zlib
# PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 1000
memory_limit - 128M
post_max_size - 32M
sql.safe_mode - Off
upload_max_filesize - 32M
ldap.max_links - Unlimited
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
pgsql.max_links - Unlimited
pgsql.max_persistent - Unlimited
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
Yes @Steevb, I can confirm the Search function error, I am seeing the same multiples of search results..
I have posted this issue to Github now
Okay, but what about the logout issue, r u seeing that?
No I can't replicate that, I have used the themes logout link and the dashboard logout and they both work okay for me?
Logout dumps me to the root folder of MAMP too. Not the front page of the site. Preety urls off.
Did you set a Canonical URL during install?
I didn't set one.
Might be worth a look if you did.
I didn't set one.
Might be worth a look if you did.
No canonicals for me. On the welcome page, clicking on the "View Original Image" link takes me to:http://tidyhq.com/
Yes it takes me there too.
Nope. Just installed normally as I've done a thousand times. I've actually done a second fresh install getting same issue, maybe it's my environment?
Hi Steevb, here is my environment info
# concrete5 Version
Core Version - 8.2.0RC2
Version Installed - 8.2.0RC2
Database Version - 20170626000000
# concrete5 Packages
Neat (0.9.2), Stucco (2.1.2)
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).
# Server Software
Apache/2.4.23 (Win64) PHP/5.6.25
# Server API
apache2handler
# PHP Version
5.6.25
# PHP Extensions
apache2handler, bcmath, bz2, calendar, com_dotnet, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imap, intl, ionCube Loader, json, ldap, libxml, mbstring, mcrypt, mhash, mysql, mysqli, mysqlnd, odbc, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, tokenizer, wddx, xdebug, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend OPcache, zip, zlib
# PHP Settings
max_execution_time - 600
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 2500
memory_limit - 1G
post_max_size - 256M
sql.safe_mode - Off
upload_max_filesize - 256M
ldap.max_links - Unlimited
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
odbc.max_links - Unlimited
odbc.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
xdebug.max_nesting_level - 256
xdebug.max_stack_frames - -1
xdebug.var_display_max_children - 128
xdebug.var_display_max_data - 512
xdebug.var_display_max_depth - 3
opcache.max_accelerated_files - 2000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5
# concrete5 Version
Core Version - 8.2.0RC2
Version Installed - 8.2.0RC2
Database Version - 20170626000000
# concrete5 Packages
Neat (0.9.2), Stucco (2.1.2)
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).
# Server Software
Apache/2.4.23 (Win64) PHP/5.6.25
# Server API
apache2handler
# PHP Version
5.6.25
# PHP Extensions
apache2handler, bcmath, bz2, calendar, com_dotnet, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imap, intl, ionCube Loader, json, ldap, libxml, mbstring, mcrypt, mhash, mysql, mysqli, mysqlnd, odbc, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, tokenizer, wddx, xdebug, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend OPcache, zip, zlib
# PHP Settings
max_execution_time - 600
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 2500
memory_limit - 1G
post_max_size - 256M
sql.safe_mode - Off
upload_max_filesize - 256M
ldap.max_links - Unlimited
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
odbc.max_links - Unlimited
odbc.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
xdebug.max_nesting_level - 256
xdebug.max_stack_frames - -1
xdebug.var_display_max_children - 128
xdebug.var_display_max_data - 512
xdebug.var_display_max_depth - 3
opcache.max_accelerated_files - 2000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5
https://github.com/concrete5/concrete5/pull/5646 should fix the logout issues, but a feedback is needed... (you may need to clear the browser cache, because before that fix we did a permanent redirect, and the browser could remember that)
I just tried upgrading from 5.7.5.13 on a MAMP setup by replacing the concrete directory and running /index.php/ccm/system/upgrade?force=1 which resulted in:
Also, for some reason the environment info on the error page now shows a mismatch on the versions:
Any ideas?
An exception occurred while executing 'insert into Pages (cID, siteTreeID, ptID, cParentID, uID, cInheritPermissionsFrom, cOverrideTemplatePermissions, cInheritPermissionsFromCID, cDisplayOrder, pkgID, cIsActive) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' with params ["994", "0", 0, "992", "1", "TEMPLATE", "0", null, 0, 0, 1]: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'cInheritPermissionsFromCID' cannot be null
Also, for some reason the environment info on the error page now shows a mismatch on the versions:
Concrete5 Version 8.2.0RC2 Installed Version 5.7.5.13 Concrete Configuration concrete.version 8.2.0RC2 concrete.version_installed 5.7.5.13 concrete.version_db 20170626000000
Any ideas?
Onhttp://localhost:8888/Eightpointtwo/index.php/dashboard/pages/singl...
click on Welcome page link gives me:
Call to a member function getEntity() on null
< Back to Home
click on Welcome page link gives me:
Call to a member function getEntity() on null
< Back to Home
Must be a MAMP thing, I just went tohttp://mysite/index.php/dashboard/pages/single... and clicked on the Welcome link which took me to the Welcome page?
Must be a MAMP thing. Will have to look at updating MAMP, have to work and test everything locally.
Installed on live server and everything is working perfectly, so far!
# concrete5 Version
Core Version - 8.2.0RC2
Version Installed - 8.2.0RC2
Database Version - 20170626000000
# concrete5 Packages
None
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).
# Server Software
LiteSpeed
# Server API
litespeed
# PHP Version
5.6.30
# PHP Extensions
bcmath, bz2, calendar, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imap, intl, json, libxml, litespeed, mbstring, mcrypt, mhash, mysql, mysqli, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, readline, Reflection, session, SimpleXML, sockets, SPL, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, Zend OPcache, zip, zlib
# PHP Settings
max_execution_time - 60
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 120
max_input_vars - 5000
memory_limit - 128M
post_max_size - 100M
sql.safe_mode - Off
upload_max_filesize - 100M
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
opcache.max_accelerated_files - 2000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5
zend_optimizerplus.max_accelerated_files - 2000
zend_optimizerplus.max_file_size - 0
zend_optimizerplus.max_wasted_percentage - 5
Installed on live server and everything is working perfectly, so far!
# concrete5 Version
Core Version - 8.2.0RC2
Version Installed - 8.2.0RC2
Database Version - 20170626000000
# concrete5 Packages
None
# concrete5 Overrides
None
# concrete5 Cache Settings
Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 6 hours (default setting).
# Server Software
LiteSpeed
# Server API
litespeed
# PHP Version
5.6.30
# PHP Extensions
bcmath, bz2, calendar, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imap, intl, json, libxml, litespeed, mbstring, mcrypt, mhash, mysql, mysqli, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, readline, Reflection, session, SimpleXML, sockets, SPL, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, Zend OPcache, zip, zlib
# PHP Settings
max_execution_time - 60
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 120
max_input_vars - 5000
memory_limit - 128M
post_max_size - 100M
sql.safe_mode - Off
upload_max_filesize - 100M
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - <i>no value</i>
session.gc_maxlifetime - 7200
opcache.max_accelerated_files - 2000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5
zend_optimizerplus.max_accelerated_files - 2000
zend_optimizerplus.max_file_size - 0
zend_optimizerplus.max_wasted_percentage - 5
logout failed for me too (on xampp Win7 php5.6).
@Steevb
Steev, have you tried your Fluid Gallery on 8.2RC2? There seems to be a big problem with thumbnail generation in 8.2RC2, that affects also other galleries i've tested so far.
Steev, have you tried your Fluid Gallery on 8.2RC2? There seems to be a big problem with thumbnail generation in 8.2RC2, that affects also other galleries i've tested so far.
@Gondwana
I can confirm that logging out redirects me to localhost/root.
@okapi
What specific issues are you experiencing with thumbnail generation?
I can confirm that logging out redirects me to localhost/root.
@okapi
What specific issues are you experiencing with thumbnail generation?
@MrKDilkington
For most galleries i've tested so far, thumbnails are broken or do not show up at all (while they worked nicely on 8.1). Thumbnails for the core image block are created without problem. Also on dashboard no issues with thumbnails.
(Upgrade from 8.1 to 8.2RC2, running on PHP 7)
I can provide details and credentials if needed.
For most galleries i've tested so far, thumbnails are broken or do not show up at all (while they worked nicely on 8.1). Thumbnails for the core image block are created without problem. Also on dashboard no issues with thumbnails.
(Upgrade from 8.1 to 8.2RC2, running on PHP 7)
I can provide details and credentials if needed.
What I have found (so far) is, that if the image has an uppercase extension such as JPG instead of jpg, the file_manager_listing thumbnail does not get created.
Uploading an image with the JPG extension throws this error "Invalid JSON response from server" but it does appear as a placeholder in the file manager.
But, if you right click the placeholder and choose Thumbnails and then click 'Edit' on the File Manager Thumbnails and then 'Save', the thumbnail gets created with the Uppercase extension.
This must be an bug in the code that creates the file_manager_listing thumbnail because all other thumbnails are created (if the image is large enough).
If I try to delete an image that is only being displayed as a placeholder, an error is thrown stating that the image does not exist in the application/files/thumbnails/file_manager_listing/xxx folder and the image does not get deleted.
BUT, If I manually add the image to that folder, it will then successfully get deleted ..
Also, regarding Galleries, I have installed the vivid_thumb_gallery that works for me on this RC2
This is what I have found so far..
Uploading an image with the JPG extension throws this error "Invalid JSON response from server" but it does appear as a placeholder in the file manager.
But, if you right click the placeholder and choose Thumbnails and then click 'Edit' on the File Manager Thumbnails and then 'Save', the thumbnail gets created with the Uppercase extension.
This must be an bug in the code that creates the file_manager_listing thumbnail because all other thumbnails are created (if the image is large enough).
If I try to delete an image that is only being displayed as a placeholder, an error is thrown stating that the image does not exist in the application/files/thumbnails/file_manager_listing/xxx folder and the image does not get deleted.
BUT, If I manually add the image to that folder, it will then successfully get deleted ..
Also, regarding Galleries, I have installed the vivid_thumb_gallery that works for me on this RC2
This is what I have found so far..
Can anyone confirm or deny this issue with uppercase file extensions?
Cannot replicate extension error, sorry.
Thanks Steevb, Saves me going on a wild goose chase..
I believe this Uppercase error is caused when you enable the 'Automatically Resize Uploaded Images' in the 'Image Uploading' section of 'System & Settings'.
@weyboat
I was unable to reproduce this.
I was unable to reproduce this.
@MrKDilkington
I will try again on a live server and post results back here.
I will try again on a live server and post results back here.
@MrKDilkington
I can confirm that on a live server the issue of uppercase file extensions does not occur.
Clearly, something awry with my WAMP environment..
I can confirm that on a live server the issue of uppercase file extensions does not occur.
Clearly, something awry with my WAMP environment..
Vivid thumb not working for me with php 7+, needs a bit code change.
Yeah, I have changed the controller code to make it work on PHP 7
I have it working on a test site here
http://weymouth-angling.co.uk/
phpinfo can be seen here
http://weymouth-angling.co.uk/phpinfo.php...
I have it working on a test site here
http://weymouth-angling.co.uk/
phpinfo can be seen here
http://weymouth-angling.co.uk/phpinfo.php...
Re the logout issue, I tried logging RC2 out on linux XAMPP, and it failed as it did on Windows. There's nothing in the apache/php error logs, but I did notice potentially significant things in the access log. When RC2 logs out (and fails), it seems to do it via a 301 redirect in the first instance:
For comparison, a c5.7 site goes via a 302 in the first instance—and it's also more specific about the cID to go to:
HTH!
127.0.0.1 - - [29/Jun/2017:07:17:01 +1000] "GET /concrete5-8.2.0RC2/index.php/login/do_logout/1498684599%3Ad97836ff5fa569c7da87669a68d2ec27 HTTP/1.1" 301 248 "http://localhost/concrete5-8.2.0RC2/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" 127.0.0.1 - - [29/Jun/2017:07:17:02 +1000] "GET / HTTP/1.1" 302 - "http://localhost/concrete5-8.2.0RC2/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" 127.0.0.1 - - [29/Jun/2017:07:19:08 +1000] "GET /concrete5-8.2.0RC2/ HTTP/1.1" 200 21325 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0"
For comparison, a c5.7 site goes via a 302 in the first instance—and it's also more specific about the cID to go to:
127.0.0.1 - - [29/Jun/2017:08:18:57 +1000] "GET /concrete5_dirty/index.php/login/logout/1498688333%3A51ac56ccc72e2a6f3eada1ff2d2e5998 HTTP/1.1" 302 412 "http://localhost/concrete5_dirty/index.php?cID=1" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" 127.0.0.1 - - [29/Jun/2017:08:19:03 +1000] "GET /concrete5_dirty/application/files/cache/css/elemental/main.css HTTP/1.1" 200 44836 "http://localhost/concrete5_dirty/index.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" 127.0.0.1 - - [29/Jun/2017:08:18:58 +1000] "GET /concrete5_dirty/index.php HTTP/1.1" 200 28866 "http://localhost/concrete5_dirty/index.php?cID=1" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0"
HTH!
A GitHub issue was created for the log out redirect.
Logging out redirect to root/localhost #5644
https://github.com/concrete5/concrete5/issues/5644...
Logging out redirect to root/localhost #5644
https://github.com/concrete5/concrete5/issues/5644...
confirming that logging goes to localhost/root.
loggin back in, the startup image, defined in applications/config/concrete.php dissapears, getting the white bricks.
loggin back in, the startup image, defined in applications/config/concrete.php dissapears, getting the white bricks.
@okapi
Thanks, looking at all my add-ons and themes for glitches.
Thanks, looking at all my add-ons and themes for glitches.
@okapi,
Updated the fluid gallery to cover both 5.7 and 5.8, let me know if it works for you.
BTW: Looking to completely redesign, rewrite and resubmit the gallery with a new name.
Updated the fluid gallery to cover both 5.7 and 5.8, let me know if it works for you.
BTW: Looking to completely redesign, rewrite and resubmit the gallery with a new name.
Thanks, Steev, i have sent you a PM.
On a fresh 8.2.RC2 installation, Fluid Gallery block with a small file set (17 images, 700px width) takes 25 seconds and multiples page refreshes (!) in order to get all thumbnails and images for the lightbox created in application/files/cache/thumbnails.
As soon as all files are created, the gallery loads fast and works nicely, also after clearing the browser cache.
So i think it's the procedure of thumbnail creation that's causing the problem, for whatever reason.
As soon as all files are created, the gallery loads fast and works nicely, also after clearing the browser cache.
So i think it's the procedure of thumbnail creation that's causing the problem, for whatever reason.
@okapi, I am seeing the same behavior with thumbnail creation, I also have to refresh the browser multiple times for the thumbnails to appear.
Have you tried to 'Rescan' an image, I am seeing weird behavior on this as well?
EDIT
Ignore this Rescan issue, it is due to my WAMP environment.
I don't see an issue with Rescan on a live server..
Have you tried to 'Rescan' an image, I am seeing weird behavior on this as well?
EDIT
Ignore this Rescan issue, it is due to my WAMP environment.
I don't see an issue with Rescan on a live server..
My gallery seems to work fine with php 7.1.6 (even on my mobile).
Does it work for u:http://five-eight.55web.uk/contact...
Does it work for u:http://five-eight.55web.uk/contact...
Yes @steevb, It is working for me..
@steevb
Steev, it's not that Fluid Gallery doesn't work, - once all thumbnails have been successfully loaded and stored in application/files/cache/thumbnails, the page is loading without problems and the gallery is working fine.
Issues only occur with thumbnails being created for the first time after the cache has been cleared, this is of course particularly noticeable on large galleries.
Since Fluid Gallery, as far as i can see, does not only store preview thumbnails in the thumbnail cache, but also resized image files for the lightbox view, for a gallery with 80 images for instance, there have to be 160 files to be created and stored, which takes quite some time.
But the real show stopper turned out to be a change in the way how thumbnails are getting created in 8.2RC2, and this has nothing to do with your gallery:
https://github.com/concrete5/concrete5/issues/5618...
A timeout is the result, when a gallery with 80 images is being called for the first time with empty thumbnail cache:
http://www.webpagetest.org/result/170629_BB_H0M/...
There is simply not enough time for creating all files in the thumbnail cache for the first time.
I'm confident that this problem will be resolved soon.
Steev, it's not that Fluid Gallery doesn't work, - once all thumbnails have been successfully loaded and stored in application/files/cache/thumbnails, the page is loading without problems and the gallery is working fine.
Issues only occur with thumbnails being created for the first time after the cache has been cleared, this is of course particularly noticeable on large galleries.
Since Fluid Gallery, as far as i can see, does not only store preview thumbnails in the thumbnail cache, but also resized image files for the lightbox view, for a gallery with 80 images for instance, there have to be 160 files to be created and stored, which takes quite some time.
But the real show stopper turned out to be a change in the way how thumbnails are getting created in 8.2RC2, and this has nothing to do with your gallery:
https://github.com/concrete5/concrete5/issues/5618...
A timeout is the result, when a gallery with 80 images is being called for the first time with empty thumbnail cache:
http://www.webpagetest.org/result/170629_BB_H0M/...
There is simply not enough time for creating all files in the thumbnail cache for the first time.
I'm confident that this problem will be resolved soon.
FYI... by toggling "CSS and JavaScript Cache" ON and OFF, I found that it is the culprit for Thumbnail issues in the File Manager. With it OFF, they show up fine.
I’ve got an error after upgrading from 8.0.3 to 8.2.0 RC2.
on
What I’ve found that, it’s generating when it’s trying to translate from existing Japanese language file. If we update the file the issue is solved.
Possible reason might be-
https://www.concrete5.org/community/forums/internationalization/erro...
But my concern is as a CMS-
- Should the site be down only for language files?
- Though the site locale is set to ‘ja_jp’ but my member account language is set to ‘en_us’. At least, in this case I shouldn’t get the error.
@hissy think, we can update the language files also during concrete5 upgrade.
Plural rule of merging text domain is not compatible with the current one
concrete/vendor/zendframework/zend-i18n/src/Translator/TextDomain.php
What I’ve found that, it’s generating when it’s trying to translate from existing Japanese language file. If we update the file the issue is solved.
Possible reason might be-
https://www.concrete5.org/community/forums/internationalization/erro...
But my concern is as a CMS-
- Should the site be down only for language files?
- Though the site locale is set to ‘ja_jp’ but my member account language is set to ‘en_us’. At least, in this case I shouldn’t get the error.
@hissy think, we can update the language files also during concrete5 upgrade.
@biplobc5
If you can get others to confirm the bug, then I would create a GitHub issue.
That is pretty much the rule for GitHub:
- first search to see if anyone else reported the bug
- the bug was confirmed by another person
- the bug was found in the latest develop (or in this case the latest release candidate)
If you can get others to confirm the bug, then I would create a GitHub issue.
That is pretty much the rule for GitHub:
- first search to see if anyone else reported the bug
- the bug was confirmed by another person
- the bug was found in the latest develop (or in this case the latest release candidate)
I think that the cause of the "Plural rule of merging text domain is not compatible with the current one" error is that you are giving concrete5 one or more language files with wrong plural rule definition.
For instance, for Japanese, we have only 1 plural rule: all the Japanese language files must have 1 plural forms definition. You can inspect .po/.mo files online with a tool I recently made:https://mlocati.github.io/jsgettext/...
About the user's preferred language: you can tell concrete5 to allow users to set their preferred language at /dashboard/system/basics/multilingual (when users will login, they'll be able to choose the language they want).
PS: I prefer a CMS that tells me that there's an error, instead of behaving mysteriously...
For instance, for Japanese, we have only 1 plural rule: all the Japanese language files must have 1 plural forms definition. You can inspect .po/.mo files online with a tool I recently made:https://mlocati.github.io/jsgettext/...
About the user's preferred language: you can tell concrete5 to allow users to set their preferred language at /dashboard/system/basics/multilingual (when users will login, they'll be able to choose the language they want).
PS: I prefer a CMS that tells me that there's an error, instead of behaving mysteriously...
@mlocati
Thank you! You are absolutely right. And I understood it from your forum post.
And thank you for the online tool.
@MrKDilkington
I've tested it a bit more. It works fine with new installation but generates error with some of our Japanese website. I know, it's being resolved if we update the translation files. But what I was trying to say that, it shouldn't get down only for language files.
- We can prompt user to update the language files. (as mlocati said)
- We can update translation files automatically on concrete5 upgrade (as hissy said)
- We can skip the error, because some packages may have old version of language files.
Let's see, if someone else has this issue.
Thank you.
Thank you! You are absolutely right. And I understood it from your forum post.
And thank you for the online tool.
@MrKDilkington
I've tested it a bit more. It works fine with new installation but generates error with some of our Japanese website. I know, it's being resolved if we update the translation files. But what I was trying to say that, it shouldn't get down only for language files.
- We can prompt user to update the language files. (as mlocati said)
- We can update translation files automatically on concrete5 upgrade (as hissy said)
- We can skip the error, because some packages may have old version of language files.
Let's see, if someone else has this issue.
Thank you.
A further confirmation that logout defaults to root - a nice surprise to be told by the apache homepage telling me it works !
I much appreciate being able to choose max-height for thumbnails - as most of my images are portrait, it is much needed - and I've tested with extreme portrait (8:1 proportions) It works.
Select attributes in express still sort alphanumerically rather than the user order expected.
I much appreciate being able to choose max-height for thumbnails - as most of my images are portrait, it is much needed - and I've tested with extreme portrait (8:1 proportions) It works.
Select attributes in express still sort alphanumerically rather than the user order expected.
Refresh or 'Go back to home' and the above repeats.