zombiesbyte

Fair enough keat, if you were looking for a quick workaround to the problem then that may have been practical but from the numbers you're getting through I suppose it's not. Regardless, it appears the issue has been resolved: (https://github.com/cubecart/v6/issues/764) You need to enable the setting: "Force Order Completed Emails" in admin. It's unclear if the bug with regards to SMTP password clearing after updating settings has been addressed yet so just watch out for that in case it hasn't.

Not sure if this is an acceptable work-around but setting the order state to cancelled and saving then going back in and setting back to complete triggers the email sending. The customer will get two emails though, one that says cancelled and the other that states completed again. You could change the message in something like the "fraud" email template to say something like "your gift certificate is being validated" then use this setting as a step for using this work-around until the issue is resolved. I think it comes from the fact that gift certs are automagically set to completed and miss the catch for email sending queue (as a guess). Hope this helps James

Thanks to the final comment contributions, Al. Regarding your check on the DB encoding my official PHPMyAdmin shows the correct encoding as utf8_general_ci so I'm not sure if this was a problem with the phpmyadmin I setup temporary. Regardless I know to use utf8_general_ci It's a shame that this looks to be insensitive to data only and not table names. bsmither. Yeah, everything worked as all I saw locally and live was the table names in lowercase. I had no idea that there was any reference to "###_CubeCart_..." and as specified by MySQL naming standards these should always be labelled lower-case for cross platform support/compatibility. havenswift-hosting. By extremely small number of people I presume you still understand that that would equate to many hundreds of thousands if not millions in the whole scheme of things. WAMP and XAMPP (the two most popular virtual server suites) are not maintained for small numbers of users otherwise it would be pointless. I know little about 1&1's hidden setup but I imagine everything is controlled in a VM style fashion. Regardless of the underlying OS platform the environment they serve from is still Linux otherwise I would not have had these problems. DB shows that it is sitting on Server version: 5.5.50-0+deb7u2-log - (Debian). Maybe there's something I've got wrong with this but regardless the issue is resolved. I would like nothing more than to say that everything should be geared to a single platform type using one browser brand and have one email client but unfortunately we live in a multi-level world full of various brands, devices and platforms. I can't see any issues with what I've done other than any future updates (or plugins/extensions) needing to be re-calibrated back to lowercase db table naming. This is something I accept I need to do but for the general user it may not be appropriate but people who just want to build using CC's admin panel offering only would probably have installed it on their environment using the installer. My version is obviously FTP'ed across and the database exported which is where it had caused the issue. It's all cool, I'm up and running and I think there's a good deal of information to be utilised in the future for anyone following this thread in hopes of a resolution. I know Al had mentioned this happens every once in a while but I had not come across any information to point me in the direction of database table casing. Thanks for everyone's time on this, I appreciate the help. I'm still extremely impressed with CC's coding standards, style and community spirit. Kind regards James

I was just about to post this when I noticed your reply: I can confirm that the renaming of "CubeCart_" to "cubecart_" on anything that addresses the database seems to (so far) resolve all issues. I'm interested in finding out if there was anything particular that you'd be concerned with other than upgrades (my copy of CC isn't so straight forward anyway due to small changes made at core to help produce features I wanted/needed). I wonder if it would be worth noting a change request for future editions of CC to lowercase the table names. Regardless, looks like I'm up and running fingers crossed

Hi Al The other problem I've got is that I maintain various other projects on my XAMPP and having multiple environments is starting to sound like a nightmare. Can you think of any issues with the plan I proposed about the code change on my copy of CC?

Hi Al The problem is when I tried going down this route it wasn't working. I originally thought perhaps my config wasn't using the my.ini but after further investigation this workaround won't work on InnoDB table types apparently. Update: FYI: I won't be able to modify the hosting environment settings for MySQL engine

Thanks Al I've been trying to get the XAMPP environment which I use to develop on in line with the Linux environment. The thing is these two need to be interchangeable as any future changes I roll out need to be synchronised directly without having to then force manual changes. The DB calls use a prefix but I can't see the option for changing "_CubeCart_" prefix anywhere as it looks hardcoded. I've identified 996 matches across 64 files which I intend to change the code directly for calling the "CubeCart_" to "cubecart_" thus solving the issue with casing although I imagine this causes an issue with potentially any automatic updates which I'll need to perhaps avoid doing on the live version of my site. Updates on my local dev copy would then just need to have the "CubeCart_" to "cubecart_" casing changed again. Can you see any potential issues with this workaround?

Files are all uploaded. Same error as before I've noted straight away that the debug is not on which tells me that communication with the database for this setting is not being read or used. Ran the script on the live staging: (same as off-line dev) We have a non-false result from making the query.Array ( [name] => name [array] => array )

Hi bsmither. Not sure what I'm to expect with this one. I'm still uploading so this is the result of that script locally (the version of my website that works) We have a non-false result from making the query.Array ( [name] => name [array] => array ) I'll run it on the staging once I've completed my upload

In the mean time, http://test.zombiesbyte.com/setup/ has a fresh install which is working fine. I'll be removing this probably tonight so the link won't work for anyone reading this in the future. I'm just uploading the fresh copy now. I've enabled caching rules (CC admin settings) and turned on debugging mode too Fingers crossed

I've managed to setup an error log to see what else is caught since this seems strange for it to just die like this I can that my error log is looking a lot like this post by matchattaxoutlet matchattaxoutlet talks with the hosting provider which reports that it is down to server load. I'm with 1&1 and they are quite good at handling bulky tasks so I'm surprised if it is down to resources but everything is starting to look that way. I'm not sure what I should be doing next ...update: I'm re-uploading everything again.

Thanks bsmither I understand. Just as a final angle, I've been working with the where function on line 768 of database.class.php in an effort to understand what is going on. I include this small section of code: <?php /** * Builds a WHERE string * * @param string $table * @param array $whereArray * @return string */ public function where($table, $whereArray = null) { echo "call to function where:\n"; echo "\$table: {$table}\n"; echo "\$whereArray::\n"; print_r($whereArray); echo "\n\n"; ... Locally this produces approximately 218 calls While online it stops after only 62 calls. Interestingly the error occurs 2nd call in (or so it seems but this maybe an output buffer delay or something) The last group of results are different, they seem to get stuck in a loop of: call to function where: $table: CubeCart_inventory $whereArray:: Array ( [status] => 1 [featured] => 1 ) I've left this on for you to see. Does this help identify the problem? (view page source, it's easier to read if you're not already) http://preview.zombiesbyte.com/

I've jumped ahead a step and got data too: <?php //... variables as before $dbport = ini_get('mysqli.default_port'); $dbsocket = ini_get('mysqli.default_socket'); echo "<br>\ndbport from ini_get('mysqli.default_port'): " . $dbport . "<br>\n"; echo "dbsocket from ini_get('mysqli.default_socket'):" . $dbsocket . "<br>\n"; $mysqli = new mysqli($dbhost, $dbusername, $dbpassword, $dbdatabase, $dbport, $dbsocket); try { echo "Total tables found using mySQLi: " . count(mysqli_fetch_all($mysqli->query('SHOW TABLES'))) . "<br>\n"; } catch(Exception $e) { echo "problem connecting to db using mysqli"; } echo "Lets get the column names from ###_cubecart_config table<br>\n"; print_r(mysqli_fetch_all($mysqli->query('SHOW COLUMNS FROM `###_cubecart_config`'))); echo "Lets get the first 3 rows of data from ###_cubecart_config table<br>\n"; print_r(mysqli_fetch_all($mysqli->query('SELECT * FROM `###_cubecart_config` LIMIT 3'))); //output dbport from ini_get('mysqli.default_port'): 3306 dbsocket from ini_get('mysqli.default_socket'):MySQL Total tables found using mySQLi: 64 Lets get the column names from ###_cubecart_config table Array ( [0] => Array ( [0] => name [1] => varchar(100) [2] => NO [3] => PRI [4] => [5] => ) [1] => Array ( [0] => array [1] => text [2] => NO [3] => [4] => [5] => ) ) Lets get the first 3 rows of data from ###_cubecart_config table Array ( [0] => Array ( [0] => All_In_One_Shipping [1] => eyJzdGF0dX...{shortened this for display purpsoses} ) [1] => Array ( [0] => config [1] => eyJzdG9yZV...{shortened this for display purpsoses} ) [2] => Array ( [0] => Contact_Form [1] => eyJzdGF0dXM...{shortened this for display purpsoses} ) ) I can confirm that this is exactly the same live as it is locally. http://preview.zombiesbyte.com/conchecker.php

Hi bsmither I've updated the script to use the port and socket: <?php $dbdatabase = '{removed-for-security}'; $dbhost = '{removed-for-security}'; $dbpassword = '{removed-for-security}'; $dbprefix = '{removed-for-security}'; $dbusername = '{removed-for-security}'; $dbport = ini_get('mysqli.default_port'); $dbsocket = ini_get('mysqli.default_socket'); echo "<br>\ndbport from ini_get('mysqli.default_port'): " . $dbport . "<br>\n"; echo "dbsocket from ini_get('mysqli.default_socket'):" . $dbsocket . "<br>\n"; $mysqli = new mysqli($dbhost, $dbusername, $dbpassword, $dbdatabase, $dbport, $dbsocket); try { echo "Total tables found using mySQLi: " . count(mysqli_fetch_all($mysqli->query('SHOW TABLES'))) . "<br>\n"; } catch(Exception $e) { echo "problem connecting to db using mysqli"; } Which results in the table connecting as before and both values actually being supplied when parsing //Output dbport from ini_get('mysqli.default_port'): 3306 dbsocket from ini_get('mysqli.default_socket'):/tmp/mysqld.sock Total tables found using mySQLi: 64 As far as I can see my script is connecting at every turn, even the CC mysqli class is connecting. Many thanks James

Hi bsmither phpini added I realise PDO wasn't used but left it in on my tests anyway. I've updated the script to die() with error if it tries to use the old mysql connection type. It never loads it so the mysqli has passed and is always used. I can't find anything in PHP info that stands out but I've left it on for you to look at if you need it. Many thanks James