RC 8.2.0 Released

Permalink
ConcreteOwl
 
JohntheFish replied on at Permalink Reply
JohntheFish
Just tried installing. Install page pukes immediately:
An unexpected error occurred.
DateTime::createFromFormat(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.

Refresh or 'Go back to home' and the above repeats.
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
I installed this on my WAMP box and it installed without a hitch...
JohntheFish replied on at Permalink Reply
JohntheFish
MrKDilkington replied on at Permalink Reply
MrKDilkington
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"
mesuva replied on at Permalink Reply
mesuva
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!
Steevb replied on at Permalink Reply 1 Attachment
Steevb
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
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
Yes @Steevb, I can confirm the Search function error, I am seeing the same multiples of search results..
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
I have posted this issue to Github now
Steevb replied on at Permalink Reply
Steevb
Okay, but what about the logout issue, r u seeing that?
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
No I can't replicate that, I have used the themes logout link and the dashboard logout and they both work okay for me?
tallacman replied on at Permalink Reply
tallacman
Logout dumps me to the root folder of MAMP too. Not the front page of the site. Preety urls off.
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
Did you set a Canonical URL during install?
I didn't set one.
Might be worth a look if you did.
tallacman replied on at Permalink Reply
tallacman
No canonicals for me. On the welcome page, clicking on the "View Original Image" link takes me to:http://tidyhq.com/
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
Yes it takes me there too.
Steevb replied on at Permalink Reply
Steevb
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?
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
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
mlocati replied on at Permalink Reply
mlocati
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)
patej replied on at Permalink Reply
patej
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:
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?
tallacman replied on at Permalink Reply
tallacman
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
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
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?
Steevb replied on at Permalink Reply
Steevb
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
Gondwana replied on at Permalink Reply
Gondwana
logout failed for me too (on xampp Win7 php5.6).
okapi replied on at Permalink Reply
okapi
@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.
MrKDilkington replied on at Permalink Reply
MrKDilkington
@Gondwana

I can confirm that logging out redirects me to localhost/root.

@okapi

What specific issues are you experiencing with thumbnail generation?
okapi replied on at Permalink Reply
okapi
@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.
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
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..
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
Can anyone confirm or deny this issue with uppercase file extensions?
Steevb replied on at Permalink Reply
Steevb
Cannot replicate extension error, sorry.
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
Thanks Steevb, Saves me going on a wild goose chase..
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
I believe this Uppercase error is caused when you enable the 'Automatically Resize Uploaded Images' in the 'Image Uploading' section of 'System & Settings'.
MrKDilkington replied on at Permalink Reply
MrKDilkington
@weyboat

I was unable to reproduce this.
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
@MrKDilkington
I will try again on a live server and post results back here.
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
@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..
Steevb replied on at Permalink Reply
Steevb
Vivid thumb not working for me with php 7+, needs a bit code change.
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
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...
Gondwana replied on at Permalink Reply
Gondwana
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:

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!
MrKDilkington replied on at Permalink Reply
MrKDilkington
A GitHub issue was created for the log out redirect.

Logging out redirect to root/localhost #5644
https://github.com/concrete5/concrete5/issues/5644...
kfog replied on at Permalink Reply
kfog
confirming that logging goes to localhost/root.

loggin back in, the startup image, defined in applications/config/concrete.php dissapears, getting the white bricks.
Steevb replied on at Permalink Reply
Steevb
@okapi
Thanks, looking at all my add-ons and themes for glitches.
Steevb replied on at Permalink Reply
Steevb
@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.
okapi replied on at Permalink Reply
okapi
Thanks, Steev, i have sent you a PM.
okapi replied on at Permalink Reply 1 Attachment
okapi
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.
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
@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..
Steevb replied on at Permalink Reply
Steevb
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...
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
Yes @steevb, It is working for me..
okapi replied on at Permalink Reply
okapi
@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.
barkingtuna replied on at Permalink Reply
barkingtuna
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.
biplob replied on at Permalink Reply
biplob
I’ve got an error after upgrading from 8.0.3 to 8.2.0 RC2.
Plural rule of merging text domain is not compatible with the current one
on
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.
MrKDilkington replied on at Permalink Reply
MrKDilkington
@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)
mlocati replied on at Permalink Reply
mlocati
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...
biplob replied on at Permalink Reply
biplob
@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.
NickKN replied on at Permalink Reply
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.