Setup Tips

Tips on set up and development

Setting up CW4 “shipping ranges”

What is Local Calculation?

In Cartweaver 4, along with the options for live rates returned by services like UPS, US Postal Service and FedEx, there is a robust system for calculation of shipping based on the customer’s country, and a defined set of price ranges for either the order total or the total weight of the customer’s shopping cart. When setting up your Cartweaver 4 eCommerce site, you can associate a set of shipping price ranges with each active country in your site, to determine the prices charged at checkout.

This is useful when your store does not use or require a live account, when you want to determine the exact price to specific countries, for specific weights or cart totals, or when one of the live connections return an error message or has a problem with the customer’s address, etc (see fallback, below).

Setting up Local (CW) Shipping Methods

How to set up Cartweaver “localcalc” shipping, in a nutshell:

Start by activating or adding all of the countries you want to make available to the site’s shoppers. (See the options for Shipping/Tax > Countries/Regions in the Cartweaver Administration area.)
Then, check your shipping settings and select whether you want to calculate the shipping cost based on  cart weight or order total. (Shipping/Tax > Shipping Settings)
Next, create the shipping methods for each country, and set up the ranges. (Shipping/Tax > Shipping Methods and Shipping Ranges in the admin menu.) Be sure your first range starts with 0. The Cartweaver Shipping Ranges admin will fill in the next one-cent value higher than the previous range when adding a new one, so all you will need to do is enter the ending numbers for each range. The last one should end with a number higher than your highest expected order total.
With a shipping method for each active country in your site, and local calculation ranges within each method, you are ready to start taking orders with your shipping costs in place.
Once the shopper has selected a country, either during checkout or on the ‘my account’ page, the CW system will attempt to
get rates for each shipping method for that country. (A country may have multiple active methods, creating a multiple choice shipping option for the shopper.)
If any shipping method is set to “localcalc”, the shipping ranges will be used. Details about the cart are passed to the shipping functions in cw-func-shipping, and the rate is returned based on the order total, or the cart weight total, depending on the store settings. For example, if you have a range that goes from 100-150 , based on cart total, and the customer’s cart total is $114, the rate from that range will be applied.

Shipping Ranges as a Fallback for Live Rate Services

The shipping ranges also come into play as a fail safe, or fallback rate, when a non-local lookup fails or returns an error. So if you are using USPS, UPS or FedEx live rates, you can set up the ranges to approximate what those services would return, and the customer will be shown that amount as the rate for that method at checkout, even if the live connection is unavailable, or the address is not valid for the live system.

Fine Tuning the Local Shipping Cost
Once you have your local calculation shipping rates working as expected, you can further fine tune the cost of shipping on specific shipping methods, or specific items by adding a base rate to the shipping method (e.g. a $5 ‘handling charge’ in addition to the variable ship cost ranges) or tack on an additional ship cost value in the Sku admin (Products > select a product > Skus tab > Ship Cost field), to add a flat additional fee per item.
If charging by “cart weight”, you can use the sku weight value to adjust the shipping for oversize items, forcing the order to the next range by entering a value higher than the item’s actual weight, or for items that are free or very cheap to ship, to reduce the calculation applied for that line item in the cart.
There are also a number of ways that discounts can be used to apply free or reduced shipping costs to your orders. Explore the options in your Cartweaver administration area, and check your results by logging in as customers in various countries. Once you are satisfied with your shipping rates and the site is processing live transactions, be sure to monitor the shipping charge being applied as your orders come in, knowing you have the tools to adjust these systems as needed, anytime.
See this page of the Cartweaver 4 documentation for more specific instructions related to third-party shipping services:
http://docs.cartweaver.com/index.cfm?pagename=manage-shipping-3rd-party 
and this page for more about  shipping ranges, and Cartweaver 4 shipping settings in general:
http://docs.cartweaver.com/index.cfm?pagename=manage-shipping .

Updating Cartweaver 4 to the Latest Version

When updates to Cartweaver 4 are released, developers have two persistent questions – how to find the changes, and how to apply them. With the right tools and information, applying these updates to your existing Cartweaver 4 site is a routine and relatively easy process.

Finding and Applying Changes to Cartweaver 4

To find the current version of Cartweaver 4, log in to the Cartweaver.com website and look at the “Downloads” tab under “My Account”. The current version is always listed along with the download link for Cartweaver PHP or CFML.

To find your current version, simply log in to your Cartweaver admin and look at the “Global Settings” section. The version number is listed there as an editable field. This value is set automatically with each use of the Database Update Utility.

As with any dynamic, database-driven application, Cartweaver updates may include any number of file or database changes. These are applied in different ways.

Updating the database:

Along with the purchased version of Cartweaver in your “My Account” area, you will see a free download for the Cartweaver Database Update Utility. Follow the instructions inside the downloaded file, to apply the latest CW4 updates to your database. This utility automatically detects your current Cartweaver version and applies any differential updates to your database.

Be sure to select the “Cartweaver 4 (CF or PHP) Database Update Utility”, this is different from the database migration utility for older CW3 site upgrades.

As each new version of Cartweaver is released, a new .sql file will be included in the Update Utility. You can replace the entire utility on your web server, or simply drop the newest .sql file into the appropriate location in your previously-installed Update Utility location.

Updating your files:

As each version is released, we collect our code management difference notes, and make them available on the “My Account page“ at Cartweaver.com. Below the “Downloads” section you will see the appropriate update notes for your version (CFML or PHP). This color-coded report lists all of the changed files since the previous release, along with full documentation of the lines of code that were changed.

See this post for more on applying file changes to customized CW sites.

Note: it is recommended to run the Database Update Utility before merging file changes, as the code changes are often dependent on new content or settings in the database.


Good Practices = Good Results

These are the general steps required to update a Cartweaver site:
- run the database update utility for the new version
- identify and download the file changes,
- and apply the changed files to your site.

Keep in mind, while highly recommended, it is not absolutely mandatory to apply Cartweaver updates. You may want to check the difference notes to see if any small bug fixes or other adjustments apply to your site. Each version of Cartweaver contains all of the fixes of the previous version, so when you update your site at any point, you know you have all of the previous changes and enhancements. However, you must apply BOTH the database and file changes as included with any version. Applying only the file changes, without also updating the database, will usually result in errors appearing on your site.

By applying these general practices and following these steps in order, you can safely and efficiently apply each new release to your existing Cartweaver sites, making sure you have every possible feature, bug fix and security enhancement as time goes on.

See this post for a detailed tutorial on using file comparison programs to merge these updates into your code, and always be sure to mark your changes when making edits to Cartweaver. 

Moving Cartweaver Data Between Databases

It is common practice for many developers to build a web application, such as a Cartweaver ecommerce site, on a local or development server, separate from the final destination on the live hosting server, often referred to as the production server, where the site will end up when it is done. While we seldom get questions about moving files from one place to another (FTP makes this easy), we do get asked about the best way to move data from development to production, when it is time to take the site live.

Navicat Makes it Easy

One option, and a favorite of our development team, is a robust utility called Navicat. (You can get a free trial here: http://www.navicat.com/en/download/download.html .) This desktop application, available for Windows, Mac and Linux, allows you to connect to multiple databases, just as you might store multiple connections in your FTP program. You can browse the tables as easily as looking at pages in a spreadsheet, and manage data with a wide range of tools.

In the case of the question at hand, the answer, using Navicat, is extremely simple. Just connect to both databases, select all the tables in the development database that start with “cw_” , and drag them into the production database… Navicat does the rest. There is also a MS SQL version of Navicat, which has many of the same features.

Dump and Execute

Another option for mySQL users, which can be utilized using Navicat or a free program like the ubiquitous and well-known phpMyAdmin, is to export the entire database as a .sql file, often called a “dump” (Note, do not confuse this with “drop” which is a SQL delete command).

In any mySQL management program, you can export or dump the database to a text file, usually ending in “.sql”, e.g. mydatabase.sql. Once you have the sql dump file you can “execute” this file into your new database using phpMyAdmin, or a tool like Navicat, and all of the database tables will be recreated in the new location.

Create Your Own Installer

One other thing to keep in mind, the Cartweaver database installation file (db-mysql.sql) is simply a dump of a default CW database, with some sample data entered in the admin. You can replace the contents of this file with your own .sql dump, and run the installer as if it were a new site, to create a copy of your database using the CW installation utility. Simply replace the existing db-mysql.sql file contents with a copy of your database dump file, browse to cw4/admin/db-setup.php (or .cfm), and follow the steps exactly if this were a new site. When you’re done you should have all of the data from the dump file imported into the new database, in place of the CW default content. (Be aware this will drop all existing cw_ tables from the destination database, only use this method if you want to completely replace the contents of your db).

Back It Up

As with any database operation, be sure to back up your source and destination databases before proceeding.
Creating or exporting the “dump” file as explained above is also a great way to back up your database. Just dump out the contents using phpMyAdmin or Navicat (or any other SQL admin tool) and save the file as a safe backup of your entire database and its contents. If you have made any customization to your CW database, such as adding new columns or tables, those changes will be preserved in the dump file as well.

Extending UPS Shipping Methods

The default Cartweaver UPS shipping integration for both PHP and CFML uses three of the most common UPS methods, which are referred to as “upsgroundcalc”, “ups3daycalc” and “upsnextdaycalc”.
These are in a list of options when setting up a new shipping method in the admin (shipping settings > shipping methods) and can be assigned as an available selection for customers in any country.

In the Cartweaver code, the selection of shipping method is passed as a numeric UPS Code to a custom function: CWgetUpsRate, which communicates with the UPS server.
The selection of method (e.g. “upsgroundcalc”, which has a code of “03″) tells UPS which type of rate to return, in this case, the standard UPS Ground shipping rate.

Before requesting a rate from the UPS serer, the CWgetUpsRate function compiles a specially formatted block of XML, which contains a number of attributes related to the order. While the most pertinent of these attributes are dynamically generated based on the details of the customer’s order, some of these are hard coded, attempting to mimic averages for package size,  package type, unit of measure and other variables which may affect the rates returned by your UPS account.

To adjust the default UPS shipping options in Cartweaver 4, you have a few options.

1) Adjust UPS Global Defaults

First, open up the file named cw-func-shipping (cfm/php) and look for the “CwgetUpsRate” function.
Below the queries and other logic, you will see a block of <?xml code being compiled, and within that, a section that starts with <Package>

There you have PackagingType, Dimensions, and other values which are provided as plain text within the code. Feel free to alter these numbers and values as you see fit.
The changes you make will affect all methods of UPS shipping.

2) Switch Defaults dynamically

With a little extra logic, you could change these defaults based on any triggers you like – items in the cart, total weight, or some custom attributes that determine actual package size. By adding attributes to the  CWgetUpsRate function, you could use those values to change the hardcoded defaults. Or put some conditional if/else code right in the CWgetUpsRate function, that switches these based on the “calctype” being provided.

3) Create your own UPS method

For example, to create a new method called “UPS Carrier Pigeon”, you could:

- Add a new <option> to the select list in the code of admin/ship-methods, such as
<option value=”upspigeon”<?php if($_POST['ship_method_calctype']==’upspigeon’) {?> selected=”selected”<?php }?>>UPS Carrier Pigeon</option> 

- Then, add a new “case” block to the code in cw-func-shipping, copying an existing block, e.g.

// UPS PIGEON
case “upspigeon”:
// lookup ups rate, passing $through
$rateValue = CWgetUpsRate(
$ups_access_license,
$ups_userid,
$ups_password,
$ups_url,
’77′,
$customer_id,
$cartWeight,
$weight_uom
);
// if numeric rate is not returned, handle error string
if (strlen(trim($rateValue)) && !is_numeric($rateValue)) {
  $calcValue = trim($rateValue);
}
break;

In CFML it would obviously be different but the workflow is the same – find a <cfcase> block inside the UPS function, and duplicate it.
In the example above, “77″ would be the UPS code for carrier pigeon… if this really works for you, let us know.

That code number gets passed as the value of “ups_service_code”.
So, if you want to adjust any values inside the CWgetUpsRate function based on the specific method being used, as mentiond above, you could write if/else statements based on the value of that variable,
#xmlData.ups_service_code# or $xmlData["upsServiceCode"] for cfml or php.

With all the complexities of the UPS API, and the multitude of products, packaging and delivery methods available, our goal was to not only allow for a common base, but to provide the hooks, as illustrated above, for all sorts of specific integration.

For help with advanced customization, visit the Cartweaver forum at http://forum.cartweaver.com or contact our development team for assistance.

Debugging Paypal Remote Transactions

Cartweaver 4 supports a number of popular payment gateways, and contains a robust set of connection options which allow integration with almost any payment processor or provider.

In general, all of the payment processing companies fall into one of two categories, either a remote payment processor like PayPal, whereby the customer leaves the Cartweaver site to make a payment and the processor passes information back to Cartweaver  or an inline payment gateway like Authorize.net, where the customer inputs credit card information directly in the checkout page, without leaving the site. While an inline solution is generally preferred as a more robust, professional solution, integration with PayPal continues to be a popular feature, and is widely used and accepted.

How PayPal Payments Work

In Cartweaver 4, the PayPal payment processing code has been greatly enhanced. Though the core variables and logic are basically the same as in previous versions – user goes to Paypal, makes payment, PayPal posts an invisible confirmation back to the store – we have added a few robust features to help any developer get up to speed, and see what is happening behind the scenes.

Here’s how a PayPal payment works in Cartweaver, in simple terms:

1) customer checks out, selecting PayPal as the payment method
2) customer is directed to merchant’s page at PayPal.com
3) payment is made either by credit card, or by PayPal payment
4) optional: customer is returned to the Cartweaver store, where a confirmation message is shown
5) meanwhile, PayPal posts an http confirmation to the CW store, which contains the Order ID
*this may or may not happen before the customer is returned to the confirmation page on the Cartweaver site
6) the store posts the exact same information back to PayPal, adding a special code (cmd=_notify-validate)
7) PayPal response to this confirmation with a message, usually either “Verified” or “Invalid”
8a) If the response is “Verified”, the order is marked as Paid in Full in the Cartweaver database
8b) If the response is “Invalid”, or anything other than Verified, the order is left as Pending)

While other processors such as WorldPay have their slight differences, the general flow is the same for any third-party payment processing integration.

What Can Possibly Go Wrong?

As you can see there are a number of steps to this process. And while the entire scenario is well-tested and widely used, there are still a few places that things can get off track. The usual problems and questions include:

- PayPal settings are not correct, sandbox or live account being used incorrectly
- Details posted back from PayPal do not match an existing Order ID
- Payment amount does not match order amount
- PayPal IPN (Instant Payment Notification) settings are incorrect or incomplete
- The wrong confirmation page URL is being sent to PayPal (incorrect admin settings for site urls)
- Customer abandons process at PayPal, without completing payment

Inspecting the Invisible

Though the transactions between Cartweaver and the PayPal server happen invisibly, out of sight or reach of the customer or developer, we have included robust error handling via email, right within the PayPal payment file for Cartweaver 4 (in your CW4 files, this is cw-auth-paypal.cfm or .php)

Along with the important settings for the store’s PayPal connection, is a special setting called “settings.errorEmail”, which defaults to the “Developer Email” set in the Cartweaver admin under Developer Settings. As long as your store has a valid Developer Email, or an email address is entered directly in the PayPal setting for errorEmail in place of the store default, an email message will be sent to that address any time PayPal the response (step 7 above) is anything other than “Verified”.

This message contains a number of useful tidbits to show the developer what actually happened. By matching the details of the error message to the PayPal processing code (search the paypal file for “Payment Insertion Error” for example, if that is in your alert email), it is fairly easy to see which part of the process had the problem.

But… PayPal Says Everything Was Fine

Even if PayPal shows a valid payment, an order can still be left at “Pending” status, if the final steps of the IPN and confirmation process do not complete. Again, the error emails are your friend (even if you don’t get any).

Since a message is sent on any error, if you are not getting these messages sent (and you have a valid errorEmail address in place), this can be equally as useful – since the PayPal auth file sends an alert on anything other than a successful transaction, no messages at all mean that PayPal is not even hitting the confirmation page, and there is probably a setting out of line in either the IPN settings or the URL settings sent to PayPal as part of the transaction.  (This is assuming your site is set up to send email – test general email sending by using the ‘forgot my password’ option on the customer account or checkout page.)

Also, check your PayPal IPN Logs for possible clues or details. Sometimes PayPal will record useful information about the attempted confirmation, which can lead you or the Cartweaver support team directly to the source of the problem.

Once the problem has been fixed, and your store is up and running, you can disable these messages by removing any value from the errorEmail setting (i.e set it to blank “” ), or leave it in place for a long-term view of any payment processing problems.

Keeping your Cartweaver Code Update-Safe with Custom Comments

Now that Cartweaver 4 for ColdFusion and PHP has been available for some time, we are seeing some interesting modifications. Cartweaver users and developers have shared a range of wonderful additions being made to the core product, including unique navigation menus, additional order processing logic, custom css skins and themes, changes to the ecommerce admin area, and a number of additional tweaks and enhancements.

Along with these customizations come specific, inevitable questions, such as “What is the best way to apply a Cartweaver 4 update, once I have made changes to the original code” or, “How can I find what I’ve changed in my Cartweaver files?”

Pay it Forward – Leave Yourself a Note

While the workflow and methods may vary between users, the first and most important step is to
MARK YOUR CHANGES using code comments, and a custom string you can find anytime.

By this we mean, anywhere you make any change to a Cartweaver .php or .cfm file, you should leave yourself a note, in the form of a php or cfml comment. This comment should contain your unique brand or identifier, and an explanation of what was changed. Your future self will thank you, as will any future developers who attempt to modify or update your Cartweaver eCommerce site.

By way of example, suppose our company was named Blue Widget Studios. We might come up with an easy to remember string like “bwsedit”. (Since it is unlikely to appear anywhere in any text or code, you could just “bws”, “bluewidget” or any other unique string.)

So, a php comment marking a single line change might look like this :

<?php
      // bwsedit: changed widget to whatzit
      ?>
Changed code here 

and a ColdFusion comment, like this:

<!— bwsedit: changed widget to whatzit —>
     Changed code here

While this does take a few extra clicks of the keyboard, the benefits are immediate and obvious. When reading through the code, your comments will appear along with all of the robust CW4 inline documentation. The simplest of notes or explanations can save a lot of guesswork or confusion later on. And with the the custom text string in every comment, you can use your editor’s code search (usually “ctrl+f”) to find the string “bwsedit”. Whether searching a directory for changes, to get a list of edited files in your CW4 site, or searching within a single file for changes, you will have a foolproof, update-safe method for finding and merging any customizations to your Cartweaver core files with future version updates and enhancements.  As long as you stick to this practice, it will soon become habit, and you’ll wonder why you ever made changes to anything without also leaving yourself a useful note.

Even Better – Date and Document Your Changes

Suggested additions include a date stamp, and some type of [start] and [end] notation for longer changes. For example, in PHP you might have

      <?php
      // bwsedit [start] 20120803: remove this, add that instead
      /* some original CW code here
      more original code here */
     ?>

my new code here
more of my new code here

     <?php
      // bwsedit [end] 20120803: remove this, add that instead
?>

 and similarly, in CFML

      <!— 
      bwsedit [start] 20120803: remove this, add that instead
      some original CW code here
      more original code here
      —> 

      my new code here
more of my new code here

     <!—
      bwsedit [end] 20120803: remove this, add that instead
—>

In this way, by commenting out (but not deleting) any original Cartweaver code, then adding start and end comments for your changes, you will never have to wonder what was changed. A code search of your entire site for your custom string will find all of the places you made changes to your site.

Make it Easy – Use a Snippet

To make it easy, many code editor and snippet applications let the user save and reuse custom bits of code, including the ability to insert custom variables, and keyboard shortcuts, like the CFeclipse snippets which were used extensively in building and documenting Cartweaver 4. Using custom snippet variables, CFeclipse will automatically insert the current date and prompt the user for the descriptive text, and the option for the start or end note, all launched by a simple keyboard shortcut.

However you create and implement your custom comments, the regular, methodical use of a custom text string in your code edits will give you ultimate peace of mind when it comes to finding, replicating or preserving the changes you make to your Cartweaver eCommerce site.

Be Creative – Be Consistent

We encourage our designer and developer customers to bend and adjust our core code to their will. That is not only expected, it is somewhat the entire point of an eCommerce suite like Cartweaver 4! As we roll out and explain some of the advanced features and modular coding methods behind the scenes, we expect these custom Cartweaver sites to become even more dynamic and divergent from the core CW code. Cartweaver version 4 is built from the ground up to be modified and reused for powerful, concise options to create any number of layouts, displays and customer experiences.

So, yes, please do tweak and change our code! And be sure to share your Cartweaver with the community and forums.
As you do so, be mindful of your workflow, take the time to make those custom comments, and you’ll never have to worry about keeping things up-to-date.

While there are certainly more ways to keep your custom code safe and reusable, leaving yourself a custom code comment for each change you make is the simplest, easiest step you can take. Do it!

Extending CW4 to use multiple images (admin)

This is a quick explanation of setting up multiple images in your Cartweaver 4 store admin, in both PHP and CFML.

As of this post, the Cartweaver 4 product details admin contains a single image upload area. The user can browse for a photo on the local computer, upload the image, and the image will be resized into the 4 standard formats (thumbnail, zoom etc).

However, extending this functionality to include multiple image upload areas is simply a matter of adding some records to the table “cw_image_types”.  Simply put, you want to copy the existing 5 rows, and change the ‘upload group’ number. That’s it.

To explain, here is the mySQL dump of the cw_image_types table containing 6 separate image upload areas - SEE BELOW - and a screenshot from our favorite db admin program, Navicat, showing the data in spreadsheet format.

 

Note the all-important “imagetype_upload_group” column, which specifies not only how many image uploader areas there are in the admin, but which sizes are created.

And here is  a screenshot of the admin area, with 6 image upload slots, ready to go.

This SQL script can be pasted into your own db-sql.sql file before setup, in place of the current cw_image_types section, or simply execute the queries from group 2 through 6 (below) in your own mySQL admin program.

Also, Navicat and other db admin tools will let you copy and paste records just like rows of a spreadsheet.

However you approach it, the concept is the same,  duplicate the existing default entries in cw_image_types, and change the “upload group” to create the various uploader areas on the images tab.

/*DROP TABLE IF EXISTS `cw_image_types`;

CREATE TABLE `cw_image_types` (
 `imagetype_id` int(11) NOT NULL AUTO_INCREMENT,
 `imagetype_name` varchar(100) DEFAULT NULL,
 `imagetype_sortorder` float(11,3) DEFAULT '1.000',
 `imagetype_folder` varchar(50) DEFAULT NULL,
 `imagetype_max_width` int(10) DEFAULT NULL,
 `imagetype_max_height` int(10) DEFAULT NULL,
 `imagetype_crop_width` int(10) DEFAULT NULL,
 `imagetype_crop_height` int(10) DEFAULT NULL,
 `imagetype_upload_group` int(2) DEFAULT '1',
 `imagetype_user_edit` tinyint(1) DEFAULT '1',
 PRIMARY KEY (`imagetype_id`)
) ENGINE=MyISAM AUTO_INCREMENT=31 DEFAULT CHARSET=utf8;
-- ----------------------------
-- Records of cw_image_types
-- ----------------------------
INSERT INTO `cw_image_types` VALUES ('1', 'Thumbnail', '1.000', 'product_thumb', '160', '160', '0', '0', '1', '1');
INSERT INTO `cw_image_types` VALUES ('2', 'Details', '2.000', 'product_full', '420', '420', '0', '0', '1', '1');
INSERT INTO `cw_image_types` VALUES ('3', 'Zoom', '3.000', 'product_expanded', '680', '680', '0', '0', '1', '1');
INSERT INTO `cw_image_types` VALUES ('4', 'Cart', '4.000', 'product_small', '80', '80', '0', '0', '1', '1');
INSERT INTO `cw_image_types` VALUES ('5', 'SquareThumb', '5.000', 'product_thumb_square', '160', '160', '50', '50', '1', '0');
INSERT INTO `cw_image_types` VALUES ('6', 'Thumbnail', '1.000', 'product_thumb', '160', '160', '0', '0', '2', '1');
INSERT INTO `cw_image_types` VALUES ('7', 'Details', '2.000', 'product_full', '420', '420', '0', '0', '2', '1');
INSERT INTO `cw_image_types` VALUES ('8', 'Zoom', '3.000', 'product_expanded', '680', '680', '0', '0', '2', '1');
INSERT INTO `cw_image_types` VALUES ('9', 'Cart', '4.000', 'product_small', '80', '80', '0', '0', '2', '1');
INSERT INTO `cw_image_types` VALUES ('10', 'SquareThumb', '5.000', 'product_thumb_square', '160', '160', '50', '50', '2', '0');
INSERT INTO `cw_image_types` VALUES ('11', 'Thumbnail', '1.000', 'product_thumb', '160', '160', '0', '0', '3', '1');
INSERT INTO `cw_image_types` VALUES ('12', 'Details', '2.000', 'product_full', '420', '420', '0', '0', '3', '1');
INSERT INTO `cw_image_types` VALUES ('13', 'Zoom', '3.000', 'product_expanded', '680', '680', '0', '0', '3', '1');
INSERT INTO `cw_image_types` VALUES ('14', 'Cart', '4.000', 'product_small', '80', '80', '0', '0', '3', '1');
INSERT INTO `cw_image_types` VALUES ('15', 'SquareThumb', '5.000', 'product_thumb_square', '160', '160', '50', '50', '3', '0');
INSERT INTO `cw_image_types` VALUES ('16', 'Thumbnail', '1.000', 'product_thumb', '160', '160', '0', '0', '4', '1');
INSERT INTO `cw_image_types` VALUES ('17', 'Details', '2.000', 'product_full', '420', '420', '0', '0', '4', '1');
INSERT INTO `cw_image_types` VALUES ('18', 'Zoom', '3.000', 'product_expanded', '680', '680', '0', '0', '4', '1');
INSERT INTO `cw_image_types` VALUES ('19', 'Cart', '4.000', 'product_small', '80', '80', '0', '0', '4', '1');
INSERT INTO `cw_image_types` VALUES ('20', 'SquareThumb', '5.000', 'product_thumb_square', '160', '160', '50', '50', '4', '0');
INSERT INTO `cw_image_types` VALUES ('21', 'Thumbnail', '1.000', 'product_thumb', '160', '160', '0', '0', '5', '1');
INSERT INTO `cw_image_types` VALUES ('22', 'Details', '2.000', 'product_full', '420', '420', '0', '0', '5', '1');
INSERT INTO `cw_image_types` VALUES ('23', 'Zoom', '3.000', 'product_expanded', '680', '680', '0', '0', '5', '1');
INSERT INTO `cw_image_types` VALUES ('24', 'Cart', '4.000', 'product_small', '80', '80', '0', '0', '5', '1');
INSERT INTO `cw_image_types` VALUES ('25', 'SquareThumb', '5.000', 'product_thumb_square', '160', '160', '50', '50', '5', '0');
INSERT INTO `cw_image_types` VALUES ('26', 'Thumbnail', '1.000', 'product_thumb', '160', '160', '0', '0', '6', '1');
INSERT INTO `cw_image_types` VALUES ('27', 'Details', '2.000', 'product_full', '420', '420', '0', '0', '6', '1');
INSERT INTO `cw_image_types` VALUES ('28', 'Zoom', '3.000', 'product_expanded', '680', '680', '0', '0', '6', '1');
INSERT INTO `cw_image_types` VALUES ('29', 'Cart', '4.000', 'product_small', '80', '80', '0', '0', '6', '1');
INSERT INTO `cw_image_types` VALUES ('30', 'SquareThumb', '5.000', 'product_thumb_square', '160', '160', '50', '50', '6', '0');

 

As for how to use these images on the front end, in your site’s display, the key to getting any image is to duplicate the existing image display code, and change the number for the ‘image type’, which will match the value of the ‘imagetype_id’ in the the cw_image_types table (first column in the table view screenshot).

We look forward to seeing what you create with your Cartweaver store!

 

Duplicating online and local data source for an easy workflow!

There are some things you can do when developing and testing locally that can ease your work-flow when it comes time to move your site to the online server, here’s one of them that I was surprised to learn a lot of developers weren’t using.

Mirroring your database / data source set up

Although Cartweaver CF supports Access database, it is always our recommendation that you move to a true database server such as MySQL or SQL Server. The advantages of speed, security, and stability are undeniable and well worth the additional set up and learning curve if you are not yet familiar with a these DBS’. Since both the ColdFusion and PHP versions of Cartweaver support MySQL I’ll use it as the example here, although the principle apples equally to SQL Server.

Same user, both places.

It’s a pretty simple procedure that will save you a lot of headaches. I was surprised to find that many developers will keep different sets of data source files, one for local work and one for the server. The reason for this is they have different log on and permissions locally. This can really lead to confusion and potentially an emergency if the local files are unintentionally uploaded to the server thus overwriting the server settings and breaking your site.

So here’s a simple tip.

Using your Database admin – I’ll use Navicat (my absolute favorite database admin tool) in this example – set up your local development database. Give this database the exact same name as you or your host used when setting up your database on the server.

Then in the user admin, create a new user and assign the exact same username and password you will be using on your host server. Finally when you set up your data source name (DSN) use the exact same DSN you have on the server… When I say exact, this includes CASE as well, due to the fact that many hosted MySQL servers are on Unix / Linux boxes and are therefore case sensitive. For ease of set up, go ahead and give the local user full permissions to the database for this application, the permissions don’t have to mirror the server exactly.

Now, when setting up your local data source direct your DSN to this database using the username and password you just created. Now when moving files back and forth between your host server and your local development environment you wont have to worry about maintaining two data source set ups, since they are both identical it wont matter where the files are.

If you haven’t been using this set up already, by all means start today, I hope you find this as big of a time saver as I did when I first discovered it.

 Scroll to top