Version 1.24 crashes Apache on my dev box

Hey CrystalDawn,

I am digging into this further and am zeroing in on two 'culprits'...

* First, unrelated to your latest mod update, I _may_ have an OpenSSL dll conflict that may be impeding things. I have been working on non-SSL related stuff of late and there is always the chance that my dev box config has gotten stepped on. The libeay32.dll and related OpenSSL-related libraries are notorious for having conflicts on Windows since so many developers throw their version into their install packages and path priorities can bung things up. I found over forty copies of this library in a variety of versions when I checked today. I most cases, if the calling app and the library are in the same directory they can 'live in their own little world' and cause no problems. When path and environment variables come into play, however, you can get into a mess of misdirection. So... I am sorting this out first to make sure that this isn't an underlying problem.

* What I suspect is happening (once this first issue is resolved) is one mod-related change in this latest version _may_ be biting me. That is, the prior versions admin screen seems to have requested (but not enforced) the http/https domain entries that are stored as Drupal variables. With this release, what was something like this in uc_ssl_run:

uc_ssl_http_request('https://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);

is now using the vars like this:

uc_ssl_http_request($ssl_domain . $_SERVER['REQUEST_URI']);

where the uc_ssl_ssl_domain var is being used.

I routinely grab a full DB copy of my public site to my dev sandbox to make sure that I am 'as close to what is'. On the dev box I have virtual hosts with 'jfs' (my initials) rather than 'www' for domain name prefixes. I have a little script that changes my Ubercart live PayPal payment settings to the PayPal sandbox settings is about the only substantive difference that I've dealt with when using this 'quick grab' DB strategy. In the past, then, uc_ssl didn't 'burp' when I tossed the DB back and forth even though its var values were for the 'www.example.com' public site.

So... at the moment the bottom line is likely 'not to worry'. I'm still shaking down my OpenSSL config along with testing this latest update. At most, it appears, that perhaps this issue (once closed) will be a reminder to devs that might hit this same 'gotcha' to note that the current and future releases strictly use those admin domain settings while earlier versions did not.

IOW, in all likelihood, this situation will only impact a small number of devs who need to be a bit more specific with their configs when moving databases between testing and production servers... which leads me to suggest a possibility. You _might_ consider expanding your admin settings to allow setting both a production set and development/testing set of domains. A simple settings-file flag or similar telltale could let your module know which sever it was running on. This would allow 'database swapping' between testing and production set ups without having to remember to change these variables each time.

I'll update this issue soon...

--Sohodojo Jim--

Hey CrystalDawn... I nailed it (again!)

It's a 'undead' reappearance of double quotes in the Description field of your info file as per my issue (http://drupal.org/node/960770) of 16 weeks ago.

You don't need single or double quotes around any of the info fields in your info file. (The Drupal packaging system double-quotes all its auto-generated entries at the bottom of the file which can be confusing, but the ones that you create should not have them.)

For whatever reason, these quotes apparently don't bother a 'nix config as the 'as is' 1.24 release installed and ran fine on my CentOS public server. Run this package under Windows, however, and you will see connection-resets of Apache when _update_process_info_list is run in update.compare.inc. Go figure!?

Anyway... if you simply clean out the quotes from your info file in your next version you should have a 'run everywhere' release.

And while you are at it, it would be a good idea to adjust the coding convention that you are using in the 1.24 release which is not consistent with Drupal standards. That is, the initial left-bracket following a function declaration's parenthesized parameter list should be on the end of the same line as the function declaration, not as the first character on the next line. Sure, the code will run either way, but there are the Drupal standards that have been adopted for consistency sake so the hordes of contributors code is as consistent as possible.

At any rate... keep up the good work as this is a lean and functional module that does 'just enough, just right' which makes it a winner for me every time when doing Ubercart sites! :-)

--Sohodojo Jim--

Hey CrystalDawn,

Thanks for the quick turn-around on this and the menu-rebuilding issue.

That fluky quotes in info files is one of those WTF kind of non-code gotchas that is especially hard to figure out.

I hear you on the coding standards vs. personal preferences front. With the increased role of peer code reviews and growing code base it gets to be somewhat unpredictable to know what is a 'hard' standard and which are 'soft' ones. There are, after all, suggestions (like we'd like it if you did X) and 'suggestions' (you don't have to but you'd better really do this if you want to keep your seat to the table...).

Anyway, thanks for this great module.
--Sohodojo Jim--