bsandall

I don't have any experience selling digital goods either, but I don't think physical goods should be sent to the PayPal address - customers may need to ship items to a job site, an alternate location, or even be purchasing a gift to send somewhere. Similarly for digital goods, how would you handle a gift purchase if it forced the digital product to be sent to the PayPal email address? As to your specific issue: in the PayPal module settings, there should be a 'Payment Action' setting - set that to 'Authorization' instead of 'Sale'. This way PayPal will authorize the funds and allow you to review the order before manually capturing the funds from within your PayPal account. You will then also need to manually set the order to 'Complete'. With that setup, you could implement a policy in your ordering process that any time the PayPal and delivery email addresses don't match, you email the customer's PayPal address and request confirmation, giving you both a chance to prevent fraud.

True, it could potentially increase the severity of a security breach, but it does solve the problem at hand. Wish I knew of a more secure solution.

Can we not make a call to run mysqldump.exe on the desired databases / tables? It seems to me that this would be the ideal solution, as mysqldump is a tool written explicitly for this purpose and would avoid all of the issues with trying to iterate over large amounts of data in PHP. This tool is also a part of nearly all database installations - on one of my non-CubeCart sites, I wrote a cron script to automate the database backup: require_once ($_SERVER['DOCUMENT_ROOT'] === 'C:/wamp/www/' ? 'C:/wamp/www/git/site_name' : '/home/site_name') . '/public_html/includes/config.inc.php'; require_once BASE_URI . 'hidden/db_cred.inc.php'; $pass = BASE_URI . 'hidden/my.cnf'; $exe = ($_SERVER['DOCUMENT_ROOT'] === 'C:/wamp/www/' ? 'C:/wamp/bin/mysql/mysql5.6.17/bin/mysqldump' : 'mysqldump'); $day = date('N'); // Day of week as numeral: 1 (Monday) to 7 (Sunday) if ((int) $day === 7) { $date = date_parse(date('Y-m-d')); $day = 'w' . ceil($date['day'] / 7); // weekly backups maintained on rolling basis for 4 weeks } else { $day = "d$day"; // daily backups maintained on rolling basis for 1 week } $filename = escapeshellarg(BASE_URI . "hidden/backups/site_name_db-$day.sql" . (LIVE ? ".gz" : "")); $cmd = "$exe --defaults-file=$pass -h " . escapeshellarg(DB_HOST) . " -u " . escapeshellarg(DB_BACKUP_USER) . " --single-transaction " . escapeshellarg(DB_NAME) . (LIVE ? " | gzip" : "") . " > $filename"; $output = shell_exec($cmd); if (!empty($output)) { throw new \Exception("Error(s) running script db_backup.php:\n$output"); } This requires that there exist a file `my.cnf` containing the lines: [client] password=your_db_password That allows the command line to execute the mysqldump command without the user needing to input their password.

Note that anyone that has visited your store before will likely have the same problem and not know to clear their browser cache; since the icon sizing is handled in the css file, a simple trick to force their browsers to re-download the css file is to edit the css url your skin's `/templates/main.php` file and add `?v=1` or a similar parameter to the `cubecart.css` url: // original line 22: <link href="{$STORE_URL}/skins/{$SKIN_FOLDER}/css/cubecart.css" rel="stylesheet"> // change to: <link href="{$STORE_URL}/skins/{$SKIN_FOLDER}/css/cubecart.css?v=1" rel="stylesheet"> I'm pretty sure that the CSS file can still be cached, but if not you can always change it back after a week or two - the extra time it might take to download the .css file is far more acceptable than having visitors see a store with giant mangled icons, in my opinion.

I'm not sure why your category SEO paths are all set to custom=1 (perhaps they are indeed custom paths?), but the naming / display issue for custom paths is a result of this change - I have submitted a fix.

Would you define modifying the code as manual intervention? As far as I am aware, there is no way to accomplish that automatically with the default store setup. There may be a plugin, but I don't have experience with those. I think the easiest solution* is to simply edit the orders as they come in, either removing and refunding shipping fees or adding a free item. * Granted this does not scale well - it's easy enough for 10 orders, but 100 not so much and definitely not 1000+.

Keep in mind that the UPC column can only contain up to a maximum of 20 characters, so the above would be truncated to something like 'Chicago Cubs - Atlan'. You could modify the database column to allow more characters with a corresponding increase in the max limit allowed in the text input field in the HTML. Making them 'clickable' would be easily accomplished so long as the fields are easily searchable. Click here to see an example - there is a list of brands (manufacturers) each with a clickable logo that brings you to a search results page filtering by that manufacturer. While I wouldn't say it would be trivial to accomplish for your purposes, it is certainly not out of the question. It sounds like bhsmither might have some code you could use to search the UPC column - if that works, it shouldn't be too hard to either add a second column to the search query or modify it slightly to allow non-exact matches (if you go with using only one increased-length column and the search snippet isn't already set up for that). Once you get that sorted out, it's simply a matter of displaying a search link for each team in your store skin like in the example site I linked to earlier.

That is certainly a possibility, but it isn't very scalable - you have to add a new field or change an existing one as well as re-modify the search query each time you need an extra team. So for example let's say we think 2 possible team associations per product is fine and we do all the work to add that in, but then down the line we find out we have a product that needs 3; now we have to go back and do a bunch of work again to make that possible, whereas it could be done now in a way that allows any number of associations. Whether that is worth doing, however, depends on whether that situation will ever actually come up, as it is certainly easier to just add 2 fields and call it good.

The edits you made to modify 'UPC code' in your skin is basically all you have to do to add a new field as well, e.g. instead of modifying one of the lines, add a new one: // Existing line: <div><label for="upc_code">{$LANG.catalogue.product_upc}</label><span><input name="upc" id="upc" class="textbox" type="text" value="{$PRODUCT.upc}" maxlength="20"></span></div> // Add new field: <div><label for="team">{$LANG.catalogue.product_team}</label><span><input name="team" id="team" class="textbox" type="text" value="{$PRODUCT.team}" maxlength="50"></span></div> // remaining fields // In your store front skin, add the new field: <div id="product_description"> {$PRODUCT.description} <p><strong>{$LANG.catalogue.product_code}</strong>: {$PRODUCT.product_code}</p> <p><strong>{$LANG.catalogue.product_team}</strong>: {$PRODUCT.team}</p> </div> // One extra change is needed to the database (not sure on max length for your team names - I chose 50 just to be fairly safe): ALTER TABLE `CubeCart_inventory` ADD COLUMN `team` VARCHAR(50) NULL DEFAULT NULL AFTER `mpn`; Speaking of which, there is a `brand` column that could suit your needs and appears to be currently unused (with no way to edit it) - you could simply add that into the editable fields for the product: // Existing line: <div><label for="upc_code">{$LANG.catalogue.product_upc}</label><span><input name="upc" id="upc" class="textbox" type="text" value="{$PRODUCT.upc}" maxlength="20"></span></div> // Add new field: <div><label for="brand">{$LANG.catalogue.product_brand}</label><span><input name="brand" id="brand" class="textbox" type="text" value="{$PRODUCT.brand}" maxlength="20"></span></div> // remaining fields In any of the above cases, you would need to swap `upc` for either `team` or `brand` in the search code bhsmither is going to provide for you. And just to reiterate - none of these solutions solves the problem you mentioned earlier, namely that you need the ability to have more than one team associated with each product. If that's still a requirement, I suggest you create a table to hold product_id:team_id relationships - that will, however, make searching that much more complex.

Never mind, I thought you were trying to install a local copy, but looking closer it seems you are creating a second live installation - I don't have any experience with that

By that do you mean add an additional column that has all the properties (e.g. searchability) of the original Product Code field? Sure, that's possible, but it boils down to the same amount of work as I was describing above - you still need to add the column, ability to edit it in the admin product panel, and modify all of the search code to include it. Besides, how will adding that one additional column help your requirement for multiple team associations? In other words, sure you can do it, but it will be just as much work as and less effective than creating a table for multiple associations.

Allowing multiple teams for a single product is a more complicated question. If you just want to allow users to search for said products using either of those team names, all you have to do is include them in the product description. If you want to allow admins to filter products by those team names via the admin search bar, you're going to have to modify the search code to either: Include the product description in the search (assuming you added the team names to the description) OR include the manufacturer(s) column in the search Choosing the second option introduces further complications, as by default CubeCart only supports one manufacturer per product; you'd probably need to make an additional table for the product:manufacturer associations in a one-to-many relationship, and then query that in your search as well as modify the admin product interface to allow setting multiple manufacturers. If you are or have at your disposal a competent developer, the latter changes could be made in perhaps a few hours, more or less depending on how complicated it actually turns out to be.

That is not something CubeCart supports out of the box - it expects that each product will have a defined price, and options will modify that price. If every option has an absolute price rather than a modifier, then those options should probably be separate products. That said, you can modify the matrix to allow absolute pricing per option combination, but CubeCart will still expect there to be a base product with a defined (non-zero) price. In my own store which is modified to allow matrix-level pricing, I typically choose one of the option combinations as the 'default' product for purposes of entering pricing, product code, etc. in to the base product, so there is always something for CubeCart to display. If that doesn't work for you, then it is possible to modify the code to select the lowest (or highest) matrix price in case the base product's price is zero, but that will require more work and depends greatly on what modifications you have made to your store, if any.

Could you perhaps use the `manufacturer` column for the team name? You could edit your language file to show 'Team Name' instead of 'Manufacturer'. Otherwise, you'll need to add a column and edit your skin to display it, as well as tweak the admin files to allow you to edit / save and search by that field.

The problem is CubeCart_order_notes no longer has a TIMESTAMP column - `time` is stored as a simple integer, whereas your database backup still has the old timestamp format. You can convert TIMESTAMP into INT by running a portion of the 6.1.2.sql upgrade script: # add a temporary column for the conversion: ALTER TABLE `CubeCart_order_notes` ADD `time_tmp` INT(11) NOT NULL AFTER `time`; #EOQ # set the data in that column to the INT version of each existing TIMESTAMP: UPDATE `CubeCart_order_notes` SET `time_tmp` = UNIX_TIMESTAMP(`time`); #EOQ # Drop the old column and rename the new one: ALTER TABLE `CubeCart_order_notes` DROP `time`; #EOQ ALTER TABLE `CubeCart_order_notes` CHANGE `time_tmp` `time` INT(11) UNSIGNED NOT NULL; #EOQ # This is the part we discussed before where the it adds the incorrect index # Instead of running this query, you may want to run the one I wrote earlier. # ALTER TABLE `CubeCart_order_notes` ADD INDEX( `time`); #EOQ # i.e.: # ALTER TABLE `CubeCart_order_notes` DROP INDEX `admin_id`; # followed by either: # ALTER TABLE `CubeCart_order_notes` ADD INDEX `admin_id` (`admin_id`, `cart_order_id`); # or: # ALTER TABLE `CubeCart_order_notes` ADD INDEX `admin_id` (`admin_id`, `cart_order_id`, `time`);

CubeCart chose to make all products 'featured' by default in order to maintain consistent behavior with previous versions. In my own store, I prefer to have only a few select products featured and thus have all new products default to NOT featured. If you are interested in maintaining the ability to enable featured products but don't want them all featured by default, make the following changes: // In admin/sources/products.index.inc.php, line 974, change: // from: 'featured' => 1, // to: 'featured' => 0, // Update your database to set all products to not featured: UPDATE `CubeCart_inventory` SET `featured`=0; // If you ever import products, remove the following lines (163-165) from admin/sources/products.import.inc.php: if(!isset($product_record['featured']) || empty($product_record['featured'])) { $product_record['featured'] = 1; }

It requires quite a few changes to update the code and database to allow matrix-level pricing. You can certainly go this route if you wish - I did - but in the meantime, if your options are that distinct, it may be easier / better to have each as its own unique product.

It depends on which language you are writing in - each one has its own syntax. PHP and most if not all C-based languages (among others) use `//` and `/* ... */` for comments; `#` is used in many languages as well, most notably SQL; `{* ... *}` is I believe a Smarty-only syntax; `<!-- ... -->` is HTML. Anyway, glad that got rid of the error message for you - I'll make a PR in GitHub for it.

The lines I posted are meant to replace the first 3 lines in the section you commented out, so it should be: if($GLOBALS['session']->has('version_check')) { $extension_updates = $GLOBALS['session']->get('version_check'); $file_ids = (is_array($extension_updates) && !empty($extension_updates) ? array_keys($extension_updates) : array(-1)); $extension_updates = $GLOBALS['db']->select('CubeCart_extension_info', false, array('file_id' => $file_ids)); if($extension_updates) { $GLOBALS['main']->addTabControl($lang['dashboard']['title_extension_updates'], 'extension_updates', null, null, count($extension_updates)); $GLOBALS['smarty']->assign('EXTENSION_UPDATES', $extension_updates); } } If that still crashes, try changing the `array(-1)` to `array(0)`. If that also crashes, post the error message. Also, '{*' is not correct syntax for PHP comments - you should use '/* .... */' instead. That could be why your code is crashing.

Perhaps something like: if($GLOBALS['session']->has('version_check')) { $extension_updates = $GLOBALS['session']->get('version_check'); $file_ids = (is_array($extension_updates) && !empty($extension_updates) ? array_keys($extension_updates) : array(-1)); $extension_updates = $GLOBALS['db']->select('CubeCart_extension_info', false, array('file_id' => $file_ids));

I didn't mean to imply you didn't - I did as well and ran into some issues. Personally I wouldn't worry about the indexes on this table, but if you want them to match: ALTER TABLE `CubeCart_order_notes` DROP INDEX `admin_id`; ALTER TABLE `CubeCart_order_notes` DROP INDEX `cart_order_id`; ALTER TABLE `CubeCart_order_notes` ADD INDEX `admin_id` (`admin_id`, `cart_order_id`); Or, if you'd prefer to have your table structure match the current install script: ALTER TABLE `CubeCart_order_notes` DROP INDEX `admin_id`; ALTER TABLE `CubeCart_order_notes` DROP INDEX `cart_order_id`; ALTER TABLE `CubeCart_order_notes` DROP INDEX `time`; ALTER TABLE `CubeCart_order_notes` ADD INDEX `admin_id` (`admin_id`, `cart_order_id`, `time`);

It's hard to say what Al intended - in the install script, the table is created with a combined key named 'admin_id' on three columns: 'admin_id', 'cart_order_id', and 'time'. However, in the upgrade script, the 'time' column is dropped, re-added, and given its own index. So, my table has 'admin_id' on columns 'admin_id' + 'cart_order_id', and does NOT have the individual 'cart_order_id' index, but is otherwise the same as yours. It's not likely to have a huge impact either way, but if you ran the actual scripts as they are written, I believe you should have ended up with what I have.

Are you running the MySQL queries via phpMyAdmin? That's what I did, and while I got errors due to the fact that those indexes didn't exist in my tables (I may have already ran those particular queries), I didn't get blank page. I would simply check the indexes for each of those tables: SHOW INDEX FROM `CubeCart_alt_shipping` That will list all existing indexes for that table, and you can compare them to what is expected based on the SQL queries above. Do that for each affected table.

Ah, I see now, you want the customers to be able to edit their orders. I'm not familiar with Estelle's Text Input Mod or any version of CubeCart prior to v6, but as far as I am aware, that is not possible in v6 - once the customer places the order, the only way it can be edited is by contacting the store admin / customer service and asking them to change it. I'm not sure if it is this way through an intentional design decision or that the ability to edit pending orders as a customer was just never implemented - you could create a feature request on GitHub and see what sort of response you get, but it sounds like you've already got yourself sorted out. As for editing an in-progress shopping cart, I think that would be an excellent customer experience improvement, but care would need to be taken not to make the cart too cluttered. Perhaps an 'edit' link which takes you back to the product page with the options you've chosen pre-selected, where adding to the cart would replace whichever entry you clicked from?

Are you sure you had the correct version? Here is a screenshot of editing item options, and it works the same for pending orders: