Notice: CMSB v2.06 Beta!

Hi,

I have just made the update and I have sometimes a error message with the use of the plugin MEMBERSHIP.

Notice: session_start(): ps_files_cleanup_dir: opendir(/tmp) failed: Permission denied (13)
in ../lib/init.php on line 324

You have an idea ?

Thanks, Djulia

Djulia,

Who do you use for hosting? I've seen this issue on some shared hosts and occasionally on a cloud host we use.

Here's how I have been able to fix it:

If you are experiencing a problem with the standard way sessions are stored, you can change how your PHP sessions are handled by using a .htaccess file.

Just open your .htaccess file (or create a new one if one doesn't already exist) and add the following:

php_value session.gc_probability 1
php_value session.gc_divisor 100
php_value session.gc_maxlifetime 3600
php_value session.save_path /full/path/to/your/site/

Note that the save_path should be the full path to your site on the server. You can find this in CMSB under Admin > General Website Root Directory

Let me know if that works for you!

- Brunello

This has never occurred before and I've been using CMSB since around v1.20 and it's only occured with this v2.06 beta release.

After uploading the new release to whatever site I'm installing it on, I then download via FTP the modified site. It seems in most directories wherever there is the WS_FTP.LOG file that the ftp transfer errors and crashes out. This prevents the next directory to download, etc. Since the WS_FTP.LOG file exists in a LOT of the versions subdirectories this becomes a tedious nightmare. Is there a fix because the error occurs even if downloading to a fresh directory tree on the base computer?

Hello folks,

Thanks for the great feedback so far! :)

@Djulia: Please make the change as suggested by your host. From what I've read, your host will be doing their own session garbage collection outside of PHP. We're looking into the problem and a permanent fix right now. If changing that 1 to a 0 doesn't help for whatever reason, please just comment out both of the new lines that were added:

ini_set('session.gc_maxlifetime', 60*60*24 ); // session garbage-collection code starts getting randomly called after this many seconds of inactiity
//ini_set('session.gc_probability', 1 ); // after gc_maxlifetime is met old session are cleaned up randomly every (gc_probability / gc_divisor) requests
//ini_set('session.gc_divisor', 250 ); // after gc_maxlifetime is met old session are cleaned up randomly every (gc_probability / gc_divisor) requests
ini_set('session.use_trans_sid', false );

Thanks for reporting this! Expect a proper fix shortly. :)

Hi equinox69,

Your FTP client, WS_FTP is creating those files. Leaving them on your webserver is sometimes seen as a security vulnerability, since it's considered bad form to let hackers know your directory structure. There are [url http://www.google.com/search?hl=en&ie=UTF-8&q=inurl%3Aws_ftp.log]thousands of these files publicly viewable on the web[/url].

There haven't been any new files or directories added in 2.06 (only the contents of the files has changed.) CMS Builder won't read, write, or do anything to these log files at all. I can't figure out how this new version might affect WS_FTP or its logs in any way.

You'll want to check with the WS_FTP people to see if this crashing bug is known about. Or you could try upgrading WS_FTP. Or another FTP client. Or you could try asking WS_FTP not to keep logs:

1. Click on the Options button.
2. Click on the General tab.
3. Uncheck the checkbox labeled Enable log.

I hope this helps!

Hi Chris,
Thanks for responding so quickly. I'll follow your suggestion(s). Just strange, haven't modified Ws_ftp settings for a LONG time...so strange. Thanks!