On new host, all transactions zero out database field values

I'm sorry if this is obvious but I've searched pretty extensively and not been able to find anything.

I moved an existing site to a new host with many, many changes and wasn't able to enter orders afterwards. So I backed off and did a new full install but found the problem exists even on a new install.

The install went completely normally. All fields that are configured at install time are all set up correctly. However, once installed I can't make any changes without zeroing out the record I'm trying to change.

The issue is that any time I try and make a change in the admin interface instead of making the change the value of that field is set to null. So for instance if I edit the store address it will be set to "" after the edit. I've confirmed that the values of edit fields are indeed set to null in the database.

I'm using a brand new install of 1.3.8a. Apache is 2.2.11.

PHP is 5.2.8

'./configure' '--prefix=/usr/local/php5' '--enable-force-cgi-redirect' '--enable-fastcgi' '--with-readline' '--enable-sigchild' '--with-config-file-path=/usr/local/php5/lib' '--disable-safe-mode' '--enable-zend-multibyte' '--enable-mod-charset' '--enable-sigchild' '--disable-debug' '--enable-filter' '--enable-calendar' '--enable-exif' '--with-pcre-regex' '--with-pgsql' '--with-mysql=/usr' '--with-pdo-mysql=/usr' '--with-gd' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-zlib-dir=/usr' '--with-xpm-dir=/usr' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-gd-jis-conv' '--with-zlib-dir' '--with-bz2' '--with-curl' '--with-openssl' '--with-ldap' '--with-ldap-sasl' '--with-db4' '--enable-mbstring' '--with-imap-ssl=/usr' '--with-imap=/usr/local/lib/c-client'

The biggest difference on this host is that PHP is set to run fastcgi. I've seen the warnings about fastcgi in the installer but everything else I've seen says that it works fine with fastcgi.

Is there something special I need to do with fastcgi?

Chris

You did not state if this is a Linux or windows server???

This should run flawlessly on either if the host knows what they are doing

kobra:

You did not state if this is a Linux or windows server???

This should run flawlessly on either if the host knows what they are doing

I guess I thought that was obvious from the configure options but this is a linux box (2.6.24.5).

We're hosting it ourselves and while I'd like to think we know what we are doing perhaps not because this sure doesn't work.

Chris

owenc67202:

I moved an existing site to a new host...

... However, once installed I can't make any changes without zeroing out the record I'm trying to change.

All indicators suggest that the host you moved to is configured oddly and normal PHP and MySQL operation are not functioning correctly.
I suggest fixing the PHP and MySQL operation as the first step.

You mentioned fast-cgi. That may or may not be the issue. You may have to experiment to find out. That's where the server administrator should come in handy.

DrByte:

All indicators suggest that the host you moved to is configured oddly and normal PHP and MySQL operation are not functioning correctly.
I suggest fixing the PHP and MySQL operation as the first step.

PHP and MySQL are working on the box just fine for every other vhost and every other application other than Zen Cart. The box is pretty new but has probably 30-40 hosts on it all doing a variety of PHP/MySQL things (including things like Drupal) with no problems.

DrByte:

You mentioned fast-cgi. That may or may not be the issue. You may have to experiment to find out. That's where the server administrator should come in handy.

I am the server administrator. Unfortunately, its a little hard to do fastcgi and non-fastcgi testing as you can't have both configured on a single instance of apache.

Chris

Okay. Well ... I'm sorry, I don't know where to tell you to start "fixing" things. With several hundred thousand installs of Zen Cart on tens of thousands of different webservers, I've never seen or heard of the symptoms you describe.

Maybe start at the basics with a clean new install with just demo data and see what happens. (before you tell me you already did that, your first post isn't clear, as it talks about clean installs and old databases and old sites copied over, and so on)
Take it step by step. Process of elimination.

Maybe your PHP configuration is set to too small a POST size and thus content is truncated when input.
Maybe you have security software that's intercepting things.
It could be any number of things.

You said other software works fine on other domains. But what about on the domain you're complaining about right now? Maybe you've got your vhost configured wrong?

Maybe you need to research server config ideas someplace where webserver administrators hang out, such as webhostingtalk.com ?

DrByte:

Maybe start at the basics with a clean new install with just demo data and see what happens. (before you tell me you already did that, your first post isn't clear, as it talks about clean installs and old databases and old sites copied over, and so on)
Take it step by step. Process of elimination.

By clean install I meant:

I blew away the /store/ directory completely, deleted everything in the database with a zen_ prefix and reinstalled from scratch. I've done it 6-8 times with various settings but the last 3-4 times it was totally from scratch.

DrByte:

Maybe your PHP configuration is set to too small a POST size and thus content is truncated when input.
Maybe you have security software that's intercepting things.
It could be any number of things.

The POST size is the default but the last time I did a fresh install all I tried to do was change the store address to "dog" and that failed so it is failing even with a POST of less than 10 bytes. I also used myphpadmin when I was first trying to do an upgrade rather than a fresh install and it allowed me to post the full database which was a 900K file.

I'm not sure what you mean by "security software" but there isn't anything between me and the server if that's what you mean. I'm not using Windows at any point so there isn't any sort of inlines scanning crap or anything like that.

DrByte:

You said other software works fine on other domains. But what about on the domain you're complaining about right now? Maybe you've got your vhost configured wrong?

This vhost has quite a bit of custom code including a bunch of user management, signup sheets, calendars and other things like that that all work fine. It also has myphpadmin which works fine. The main reason for moving it to the new host was to install Media Wiki and that works like a charm too.

The Zen Cart installer also works just fine. So did the upgrade process the first couple of times when I installed it. The installer correctly updates the fields that it asks about--like store address--just fine. Its just that once the install is complete all writes then zero out the 'value' field.

DrByte:

Maybe you need to research server config ideas someplace where webserver administrators hang out, such as webhostingtalk.com ?

Well I'm certainly open to that idea but I've just not seen any other issues with anything other than Zen Cart so I don't think there is anything generically wrong with the install. One of our customers does a lot of crazy custom stuff and all of their stuff is working which I considered a minor miracle so I'm pretty confident in the general setup.

I was just hoping this was a known issue. I guess not.

Chris

owenc67202:

All fields that are configured at install time are all set up correctly. However, once installed I can't make any changes without zeroing out the record I'm trying to change.

The issue is that any time I try and make a change in the admin interface instead of making the change the value of that field is set to null. So for instance if I edit the store address it will be set to "" after the edit. I've confirmed that the values of edit fields are indeed set to null in the database.

owenc67202:

Its just that once the install is complete all writes then zero out the 'value' field.

So, I've re-read your posts, and it seems your explanations of the problem suggest that you're only talking about this happening when editing settings under the Admin->Configuration menu.

But ...

What happens if you edit a customer's address from the admin?

What happens if you log into your customer account on the store, and go to the My Account area, and edit the name, address, etc?

Does all the data stay intact? Or do those wipe out the data too?

DrByte:

So, I've re-read your posts, and it seems your explanations of the problem suggest that you're only talking about this happening when editing settings under the Admin->Configuration menu.

But ...

What happens if you edit a customer's address from the admin?

What happens if you log into your customer account on the store, and go to the My Account area, and edit the name, address, etc?

Does all the data stay intact? Or do those wipe out the data too?

This is actually interesting. I hadn't done much on the user side of things because when I did the upgrade I was unable to put things in my cart. Since then I'd focused on the admin side of things because that was clearly broken.

If I go to the user side and create a new user that seems to work just fine. The account gets set up and fully populated. If I then go to "My Account" and make a change that also seems to work just fine.

However, if I edit the customer account in the admin section something different happens. If I load the user and then change say the first name, after I hit the submit button the form reloads again but completely blank except for the birthdate field with is set to "0001-01-01". If I then go back to the customer list and reload the user a second time all the data is actually there but with no changes.

So perhaps this isn't a problem with MySQL commands but rather an issue with variables getting populated when processing the forms.

I didn't load any sample data this time so I'm going to reinstall and see what happens with ordering.

Chris

owenc67202:

I didn't load any sample data this time so I'm going to reinstall and see what happens with ordering.

OK, I've reinstalled again this time with sample data. I've confirmed the original problem that started all this does exist on a new install.

I can register and edit my info but not add anything to the cart. Any time I hit "add this to my cart" I'm returned to the main page without any errors but the main page says "Your Shopping Cart is empty."

So it isn't limited to the admin section but that seems to be where the majority of the issues are. I can't really test the checkout because I can't get anything in my cart.

I can write a review though. And perhaps more interestingly I can approve that review in the admin section. However, that may make some sense since approving a review is a GET and not a POST.

Chris

If you can't add something to your cart, then your PHP sessions aren't working properly.

DrByte:

If you can't add something to your cart, then your PHP sessions aren't working properly.

Session are definitely being added to the database and I'm not having to log on again once I do so once.

I assume that register_long_arrays and friends are not required to be on? I turned them on when testing but it didn't seem to matter.

What about any of these (basically just a grep for 'Off' in php.ini)

zend.ze1_compatibility_mode = Off
asp_tags = Off
zlib.output_compression = Off
implicit_flush = Off
allow_call_time_pass_reference = Off
safe_mode = Off
safe_mode_gid = Off
display_errors = Off
display_startup_errors = Off
ignore_repeated_errors = Off
ignore_repeated_source = Off
track_errors = Off
register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
allow_url_include = Off
define_syslog_variables = Off
sql.safe_mode = Off
mysql.trace_mode = Off
mysqli.reconnect = Off
pgsql.auto_reset_persistent = Off
sybase.compatability_mode = Off
mssql.compatability_mode = Off
mssql.secure_connection = Off
tidy.clean_output = Off

The installer didn't complain about any of these but the only issues we run into so far on this host was the need for some things to have depreciated stuff turned on.

I have confirmed that this is actually a problem with parsing the forms. Working on why now.

The mysql command that is being executed is:

update zen_configuration set configuration_value = '', last_modified = now() where configuration_id = '12'

I've checked and:

$_POST['configuration_value'] is indeed blank.

What is the value of $_POST when forms are submitted?

DrByte:

What is the value of $_POST when forms are submitted?

It is empty and I just found out why. I don't have time to fix it right now but it should be easy. I just wanted to follow up here because it was all on me (or at least I think so).

Basically the issue was this. The store was located at /members/store/. /members/ is a password protected directory (htaccess). Because of the htaccess and some other things that go on in that directory all of /members/ is behind SSL. To enforce that there is a redirect for http://members/ to https://members/

For some reason (that I've not figured out yet) Zen seems to be sending me from SSL to non-SSL. When that happens the redirect is sending me back to SSL. Apparently the redirected strips off all the POST data (which I wasn't aware of but I suppose it makes some sense).

From the browser this was completely transparent though. It looked like it was staying SSL the entire time.

BTW, I only figured this out because one of the developers ask me if he could log in and before I did that I wanted to move the store outside of the password protected directory. So really finding this is on him. Many thanks.

Thanks much for your help. I'm glad to see this was just something on my end.

Still don't know why Zen was kicking me to non-SSH but I should be able to figure that out.

Chris

Ya, I asked wilt to peek into it, and he mentioned to me that he had PM'd you and that triggered the awareness of the server configuration that's interrupting normal operation.

Maybe you should just set the SSL URL as the main URL in your configure.php files? If you're going to make everything operate in SSL anyway, just use HTTPS for everything. (SSL runs slower, but, if that's your goal, it's that easy inside ZC.) Whether you have to do something else to your server config to prevent the other problems is uncertain as yet.

Still don't know why Zen was kicking me to non-SSH
non-SSL...
Check your configure.php for the front end "Enable SSL"
One does not really want to operate the full frontend in SSL as for most websites this slows things down quite a bit

kobra:

non-SSL...
Check your configure.php for the front end "Enable SSL"
One does not really want to operate the full frontend in SSL as this slows things down quite a bit

But this is all behind htaccess so SSL is required.

The time difference is very trivial though. The main page of the stock install takes 600ms to load over HTTP. It takes 680ms to load over SSL. I can live with 80ms :smile:

What's weird is that where this is happening is only where it was SSL to start with and then it sends me non-SSL. As I said though I just haven't had time to follow up. I just wanted to post here so that no one else wasted any time on what is definitely my problem.

Chris

owenc67202:

I just wanted to post here so that no one else wasted any time on what is definitely my problem.
Glad we helped narrow down the source of your problem, or at least some approximation thereof.