It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by apmuthu
The latest Unicenta works on Java 8.
It's "thriving community support" site is dead.
Determine what database your Unicenta POS runs on (it supports MySQL).
If both applications run off the same DB server, all you may need is just a few cron jobs or triggers for db data synching locally.
The Wiki and the forum have many good leads to guide you thru.
Apache 2.4.3 ?
I've tested it on WinXP-XAMPP and Debian Squeeze with Apache 2.2+ and PHP 5.3.x on WindowsXP/7/8.1 clients
Please use the FA v2.3.24+ snapshot instead of the release version and see if that makes a difference.
Does this have anything to do with the LinuxMint GUI on the client side? Check with FireFox versions like 37.0.2 (after which the http port on the client PC was opened up for the browser) or older.
Even though the insert.js is the one controlling the keystrokes and their intended functionality, it is possible that the underlying OS (LinuxMint) does not allow it's international functionality and controls to be overridden.
FA v2.3.24+ works fine with no fix done. Tested on FireFox 34+ and XAMPP 1.7+ on standard default theme.
What browser and what server and client OSes did you test it on and what themes needed it?
Is it that you are using a very old version of FA.
The entire revision set history for the said file from v2.2.1 onwards (Dec 2009) till date version wise is here.
The history from Aug 2008 on a commit-wise basis is here.
Is this raking up this old post?
Yes - as appropriate to the theme chosen and extensions activated for the company.
Whenever you change themes or put in extensions that depend on new js files, it is good to delete all js files in the company/#/js_cache folder where # is the company number.
The expression version_compare(PHP_VERSION, "5.3.0") does indeed return -1 or false, but the interpreter / parser fails if the script has the preg_replace_callback function which does not exist in PHP 5.2.17. Hence the include_once workaround suggested.
Wonder how MySQL 5.5 and PHP 5.2.17 got together in bluehost server!
Here is a list of server details for simulation:
# uname -a
Linux box1243.bluehost.com 3.12.35.1418868052 #1 SMP Wed Dec 17 20:04:02 CST 2014 x86_64 x86_64 x86_64 GNU/Linux
# php -m | grep -i "mbstring"
mbstring
# yum update
CRITICAL:yum.cli:Config Error: Error accessing file for config file:///etc/yum.conf
# php -v
PHP 5.2.17 (cgi-fcgi) (built: Oct 2 2013 09:23:52)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies
# mysql --version
mysql Ver 14.14 Distrib 5.5.42-37.1, for Linux (x86_64) using readline 5.1It appears that most hosting providers like justhost.com and hostmonster.com too use the same kernel initramfs-3.12.35.1418868052.img and the files can be seen here.
Clear the browser cache, logout, close the browser. Now open the browser and login and see if the problem disappears. Try in PHP 5.3 if it is okay.
@gwidlgoose: Actually solving this issue helped us understand how to implement deprecated functions replacements better. Your trust in placing your server in our hands is valued. Change credentials forthwith.
@joe: Need to implement the "include_once" of a separate file for the PHP 5.3+ code in reporting/includes/html_entity_decode_php4.php
It now works after the following commit by Joe on 2014-11-07 was reverted for PHP v5.2.17 prevalent in your BlueHost server:
Fixed deprecated preg_replace in php >= 5.3.0 with the /e flag in utf8 reports.
Although the if (version_compare(PHP_VERSION, '5.3.0') >= 0) works as expected, the code in the file refers to the function preg_replace_callback() which does not exist in PHP v5.2.17 and the interpreter fails - hence the reversion in this instance.
It is best that the PHP v5.3 bit of code is kept in another file and included inside it's place in the "if" construct here.
This issue has been wikied.
Had to upload the missing fonts (dejavu and FreeSans) into the reporting/fonts folder as they are not part of the FA download.
Put it up on GitHub and pull from one another.
This has to do with "SHTML Wrapper - 500 Server Error" on the bluehost box you are on. They decided to change security permissions to prevent the execution of any file with permissions > 644 and folders > 744.
See this bluehost forum post.
Working on it.
Do not use the import_items extension to start with, as the CSVs do not respect the changes in your FA installs' specific Chart of Accounts especially if they differ in field order from the stock en_US-new.sql CoA. The presence of db schema customizations and/ or changes brought in by installation of extensions (I am assuming your are using the Git Snapshot of the FA 2.3.x stable version) too must be factored in.
My Wiki article on import of items into FA (straddles several tables) has been extended with what to do in case the field order is different from the standard en_US-new.sql CoA - it now appears quite frightening when I look at it though!
If and only if you cannot still get it done, pm the access details and I can get it done. Going forward it will be a hassle to keep bulk updating it if your are then unable to use the import_items extension as is. Work involved would be hex cleanup of the data and sanitising it for CSV / SQL import besides managing it's field and table dependancies and business computation rules.
Can try SumatraPDF
FA still works with some very old Adobe Acrobat reader plugins.
The FA 2.4 Config.php page has been put up in the wiki. Please go through the contents and suggest / make changes as required.
The following variables are no longer there in the config.php file:
$no_zero_lines_amount = 1;
$save_report_selections = 0;
$use_date_picker = 1;
$show_po_item_codes = 0;
$def_print_destination = 0;
$def_print_orientation = 0;
$accounts_alpha = 0;
$loc_notification = 0;
$print_invoice_no = 0;
$alternative_tax_include_on_docs = 0;
$suppress_tax_rates = 0;
$allow_negative_prices = 1;
$print_item_images_on_quote = 0;
$js_path = $path_to_root.'/js/';'''
$js_static = array('JsHttpRequest.js', 'behaviour.js', 'utils.js', 'inserts.js');
$js_lib = $js_userlib = array();Many of the above variables are still referred to in the code in files like header.inc and needs to be verified with it's counterpart now being in the sys_prefs table.
PM me the details
@joe: thanks!
Expect you are now in the stable version. Install the stable snapshot and see if your problems clear away.
Since the company must be chosen in the login form, the forgot password flag must need to be in the config.php file. A user with the same email id can be present in more than one company in the same install and the company choice makes it unique.
Fork FA on GitHub and make a branch for your UI contributions and make a pull request with the link in the forum (since FA still relies on Git from SF and the GitHub repo is only it's mirror).
@joe: please restore the "Config.php" link in the Wiki left menu to point to:
https://frontaccounting.com/fawiki/index.php?n=Main.Config
@joe: Thanks for the info. Attached screenshots.
@joe: Nice suggestion by @kvvaradha for forgot password implementation atleast in FA 2.4
nl_NL-2.3.14-1.mo and nl_NL-2.3.14-1.po can be deleted.
Install the FA v2.3.24+ (snapshot) instead of the release version.
English strings are taken when there are no Dutch translations available for them.
You can however, edit the nl_NL-2.3.19-3.po file replacing the
msgstr ""
with the appropriate Dutch translations for their English Equivalents in the
msgid " english phrase "
and then compile them into the nl_NL-2.3.19-3.mo using PoEdit or other editors in Windows or natively in Linux using
msgfmt -i nl_NL-2.3.19-3.po =o nl_NL-2.3.19-3.mo
The new nl_NL-2.3.19-3.mo should be used to overwrite the old one.
Done and it works:
UPDATE `db_name`.`0_users` SET `password`=MD5("MySecretPwd"), `inactive`=0 WHERE `user_id`='admin';Excessive tries with wrong password will set the inactive field in the users table to 1 and that needs to be reset.
Also we need to put in the MD5 hash of the password into the password field instead of the raw plaintext password itself.
PM me the details
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.