Topic: New Installation a complete disaster.

After spending a full day getting this thing installed I have yet to see if will be of any value to the way I would like to setup my business.

However, I have figured out and corrected all the code necessary to make a new install that is free of any php errors.
I'm going to give those corrections to you so that no one else has to go through what I went through just to evaluate your program.

First off, my server:
MySQL version: 5.0.51b-community-nt
php: 5.2.6
Http server type: Apache/2.2.16 (Win32) mod_ssl/2.2.16 OpenSSL/0.9.8o
Server system: Windows 2003 Server

Problem #1.
Running install hung and never got to the 6th step (ie. install complete) however it did install but I couldn't login.
Loging in just timed out.
Cause:
My php.ini had: zlib.output_compression = On
This must be set to Off, or deal with the output buffering so that it doesn't hang.
Recommendation:
Test for "zlib.output_compression" in your startup "system_test.inc" file.

Now it runs but with a whack of php errors.  Suppressing errors still adds entries to the php error log.
Suppressing errors is just simply lazy.

File: install/index.php
The lazy incorrect way
@include($path_to_root . "/installed_extensions.php");
The right way.
if(is_file($path_to_root . "/installed_extensions.inc")) include($path_to_root . "/installed_extensions.php");

call to hyperlink_no_params() must come before session_unset(); or the link to login will not appear.
Line 387:
    case '6': // final screen
    subpage_title(_('FrontAccounting ERP has been installed successsfully.'));
    display_note(_('Please do not forget to remove install wizard folder.'));
    // move to here instead
    hyperlink_no_params($path_to_root.'/index.php', _('Click here to start.'));
    session_unset();
    session_destroy();
    //hyperlink_no_params($path_to_root.'/index.php', _('Click here to start.'));
    break;
I don't know why it is affected by session_unset() and didn't bother trying to figure it out.

includes/lang/language.php
The lazy incorrect way
@include_once($path_to_root . "/lang/installed_languages.inc");
The right way.
if(is_file($path_to_root . "/lang/installed_languages.inc"))  include_once($path_to_root . "/lang/installed_languages.inc");

File: includes/current_user.inc:    Line 494: Invalid argument supplied for foreach())
  In front of the foreach() add: if(is_array($haystack))
  And
File: includes/system_tests.inc:    Line 258:  Invalid argument supplied for foreach()
   In front of the foreach()  add: if(is_array($installed_languages))

On install
  File: includes/archive.inc:   Line 411: touch(): Utime failed: Permission denied (because the file doesn't exist so test for it)
  The lazy incorrect way.
  @touch($file['name'], $file['stat'][9]);
  The right way.
  if(is_file($file['name'])) touch($file['name'], $file['stat'][9]);

Missing language *.po files.
  This error will occur even after a successful install because there is no "C" directory below the lang dir.
  To both the root/lang dir and the root/install/lang dir, add /C/LC_MESSAGES
  Then add C.php and C.po
  These files need to be included in the download zip file.
I created them by down loading the en_US lang file, then copied and renamed the "en_US-2.3.0-1.php" to "C.php" etc. in the dirs I created above.

Now you can actually run a complete installation and not have any php errors accumulating in an error log file.

But wait!
You're creating all the sessions in the root directory of the program..... Thats just plain DUMB.
As per your note in session.inc
/*
    Uncomment the setting below when using FA on shared hosting
    to avoid unexpeced session timeouts.
    Make sure this directory exists and is writable!
*/
//ini_set('session.save_path', dirname(__FILE__).'/../tmp/');
Your install script tests for this dir so use it. Get rid of the note and uncomment the line.

And finally... also in session.inc
You have, ini_set('session.gc_maxlifetime', 36000); // 10hrs
which allows sessions to accumulate .
Within about 20 minutes of exploring the program options the /tmp directory had 85 session files totaling over 500MB.
Clearly you need to see why new sessions are being created after every click.

Anybody that leaves there books open and unattended for 10 hours should be "fired" so I suggest you change the garbage cleanup value to about 30 minutes. This of course would also get rid of all the abandoned session files until such time as you can properly fix what going on with your sessions.

OK, that's it.
If you do as I have suggested a New User will have half a chance of properly evaluating your accounting package.

Glen

Re: New Installation a complete disaster.

Hello, We have hade some bad experiences with PHP 5.2.6, however I will notify Janusz about this to be incorporated in the system check etc..

/Joe

Re: New Installation a complete disaster.

Glen, thank you for all your investigation effort.

Following problems has been fixed in hg repo, and will be released with next version:
* Hangouts on php installations with zlib module on (after the change FA can be used regardless the zlib module is used or not).
* Automatic removal of old session files has been added.
* All the smaller issues which resulted in warnings written to  errors.log during installation has been fixed.

No change is required for the following non-issues:
* hyperlink_no_params() does not use session data, and the code does work right, so it is leaved as is.
* session.save_path is leaved commented out as so far. If session files are created in application directory - means  you have dumb configuration on your server. Properly set www server writes session files to /var/lib/php5 folder  or something like that.
* login timeout have nothing to do with session.gc_maxlifetime. The login timeout is configured in Company Settings, and can be set to any value form 10s to just 10hours. It is up to end user to decide which value is optimal, and I see no reason to put additional constraints here.
* Regarding the array_search_value() function it is also leaved as is i.e. without additional arguments checks. The logging system in FA is designed to register any suspicious warnings into errors.log, to help analyse potential problems. As the warnings during install process were only one time issue, we have ignored them so far. Thanks to your investigation they are now fixed.

Thanks again for your help in debugging FA.
Janusz