Notice: CMSB v2.64 Beta 2 (Feb 4th, 2014)

24 posts by 6 authors in: Forums > CMS Builder
Last Post: February 17, 2015   (RSS)

By Dave - January 19, 2015 - edited: February 4, 2015

Hi All, 

*UPDATE Feb 4th* We've just released beta 2

We've just released v2.64 beta 1 (beta list members will get an email with a download link shortly). 

The major new feature are:

  • Universal Error Logging - A new admin menu "Error Log" logs errors from the CMS and on EVERY page on your site that loads CMS viewer libraries.  This is a major new feature and will make it incredibly easy to monitor, track and resolve even the smallest PHP error anywhere on your site.  
  • Flash Uploader Code - We updated how the flash uploader works to address some compatibility issues people were having with some browsers and servers.  
  • Dozens of bug fixes and improvements - Many minor bugs, issues, and annoyances have been addressed.  See the changelog for more details.

If you're not already on the beta tester email list and you'd like to help beta test (you must own at least 1 CMSB license) you can sign up here: http://www.interactivetools.com/news/manage.php

Please post any feedback, questions, or bugs you find! Thanks! 

Thanks! :) 

Dave Edis - Senior Developer
interactivetools.com

Notice: CMSB v2.64 Beta 1 (Jan 19th, 2014)

By Deborah - January 19, 2015

Damon, I reviewed the v2.64 beta 1 changelog, but am not clear as to whether this release addresses the login error with v2.63 I have been seeing frequently (and at least one client has seen):

"Security Error: No _CSRFToken exists in session. Try reloading previous page."

I've followed related forum posts, implemented suggestions provided, but still have the same issue from time to time (only with v2.63). If this isn't something that was pinpointed and resolved in this beta, could one of you have a look at one of my setups?

~ Deborah

Notice: CMSB v2.64 Beta 1 (Jan 19th, 2014)

By Dave - January 19, 2015

Hi Deborah, 

Yes, this release resolves an issue that was causing CSRF errors (actually the underlying problem was that PHP sessions weren't writable) , but, if you have any other problems at ever and continue to get that or any other errors please email me direct at dave@interactivetools.com and I can take a look at your server and resolve any issues.

Hope that helps!

Dave Edis - Senior Developer
interactivetools.com

Notice: CMSB v2.64 Beta 1 (Jan 19th, 2014)

By Perchpole - January 27, 2015

Oh Lordy -

I absolutely love Universal Error Logging!

:0)

Perch

Notice: CMSB v2.64 Beta 1 (Jan 19th, 2014)

By Toledoh - January 27, 2015

+1 for Universal Error Logging

Cheers,

Tim (toledoh.com.au)

Notice: CMSB v2.64 Beta 1 (Jan 19th, 2014)

By Djulia - February 2, 2015 - edited: February 3, 2015

Hi Dave,

I obtained this warning:
PHP Notice:  Undefined index: REMOTE_ADDR in ../errorlog_functions.php on line 151

I think that is obtained since a script in cron mode. An idea?

Thanks!
Djulia

Notice: CMSB v2.64 Beta 1 (Jan 19th, 2014)

By Djulia - February 3, 2015

Hi Dave,

>Universal Error Logging

If we had the possibility of activating or of deactivating the option, it would be really user-friendly.

That can be useful during the development of the sites...

Thanks!

Djulia

Notice: CMSB v2.64 Beta 2 (Feb 4th, 2015)

By Dave - February 4, 2015 - edited: February 4, 2015

Hi All, 

We've just released v2.64 beta 2 (beta list members will get an email with a download link shortly). 

If you're not already on the beta tester email list and you'd like to help beta test (you must own at least 1 CMSB license) you can sign up here: http://www.interactivetools.com/news/manage.php

Please post any feedback, questions, or bugs you find! Thanks! 

PS: If there are no more major issues this will be become the official release in the next few days.

Dave Edis - Senior Developer
interactivetools.com

Notice: CMSB v2.64 Beta 1 (Jan 19th, 2014)

By Djulia - February 5, 2015 - edited: February 5, 2015

Hi Dave,

>So you'd want to clear them after development is complete and from time to time, but I think we'd always want to log them?

In fact, I would like to be able to deactivate it completely.

The option can be interesting during the development. But with a site in production, it seems really risky for the Mysql server.

I have just made this experiment. I made a mistake in my code and my server was completely slowed down (several tens of lines of recorded errors).

I would not like to make this experiment again whereas I do not have the eyes on the Mysql server.
In the best of the cases, I will be informed by Google Webmaster. But I would not like that it is the customer. ;)

I use a function which records these errors in a file on the server. This approach does not have any negative effect on the Mysql server.

Thanks again!

Djulia