Homar

Hello Eddie, I believe this to be a bug in the latest CubeCart release. After disabling the Fusion plugin and all of its hooks, line 116 of the cubecart.class.php file still returns false for all products (whether they are in stock or not): $product['ctrl_stock'] = (!$product['use_stock_level'] || $GLOBALS['config']->get('config', 'basket_out_of_stock_purchase') || ($product['use_stock_level'] && $GLOBALS['catalogue']->getProductStock($product['product_id'], null, true))) ? true : false; Digging a little deeper... This line calls the Catalog::getProductStock() method, which is returning empty strings. I can therefore only conclude that this issue is not being caused by either the Vector theme or Fusion plugin.

For things like this, you should contact CubeCart support directly.

There is some user submitted documentation on the third party forums, but this is pretty basic. Regardless, as has already been mentioned, the developers should be the ones to provide complete documentation considering CubeCart is commercial software. I would like to see something comparable to LemonStand's documentation. LemonStand is also commercial software and their team originally consisted of just two developers. We should remember though that any time spent writing documentation would come at the expense of further development - and the current rate of development isn't exactly quick. OpenCart is quite different. Being open source, OpenCart has a considerably larger user base and the community can contribute towards both the development and the documentation.

I believe that recent releases of CubeCart V5 contain rewrite rules that map old (V4) URLs to their new ones. If you open up your .htaccess file, you should see that it contains the following: ######## START v4 SEO URL BACKWARD COMPATIBILITY ######## RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule cat_([0-9]+)(.[a-z]{3,4})?(.*)$ index.php?_a=category&cat_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule prod_([0-9]+)(.[a-z]{3,4})?$ index.php?_a=product&product_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule info_([0-9]+)(.[a-z]{3,4})?$ index.php?_a=document&doc_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule tell_([0-9]+)(.[a-z]{3,4})?$ index.php?_a=product&product_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule _saleItems(.[a-z]+)?(?.*)?$ index.php?_a=saleitems&%1 [NC,L] ######## END v4 SEO URL BACKWARD COMPATIBILITY ######## I looked into displaying the primary product image in the image tab. I do agree that this should be added. Unfortunately, the $PRODUCT array does not contain the image path. The GUI class does provide a getProductImage method, but the $GLOBALS variable is not available to the templates and is required in order to call this method. The best way forwards is to open a bug ticket if you have not already done so. This is a simple addition and should only take a few minutes for the developers to implement.

Look for {$option.symbol} in the content.product.php template file.

See http://memcached.org/ for more detail. In short, it's a key-value store that can be used for caching almost anything - database queries, fully or partially rendered template files, ect. It's generally used for database heavy high traffic sites. CubeCart offers it as a caching storage mechanism. With memcached you won't have hundreds or thousands of files stored in the /cache/ directory. The key-value hash is stored in memory. This can give much faster access than file based caching. If you want to use it, you'll need a memcached server. Some hosting companies offer this as an addon (e.g. https://addons.heroku.com/memcache). I should say that it will probably have very little benefit for small low traffic websites.

You should be able to put the code into the index.php file in the root directory of your store.

Some text editors allow you to search through all the files in a directory structure. TextMate on the Mac does this. I believe Sublime Text (Linux, Mac & Windows) also allows you to do this. Might save you some time. http://www.sublimetext.com/

I think that this might be being output from one of the PHP files. I say this because the message is also in the AJAX cart response. Developers can sometimes add messages like this to test various things. In this case, it looks like someone has forgotten to remove it. Did you get someone to work on your store recently?

You only ever need to include the jQuery library once. It gets included from common.html and so it is best to leave this file as it is and simply omit the inclusion of jQuery from any scripts you are adding. In common.html, there are the following inclusions: <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script> <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.12/jquery-ui.min.js"></script> <script type="text/javascript" src="{$STORE_URL}/js/plugins.php"></script> <script type="text/javascript" src="{$STORE_URL}/js/common.js"></script> This file is then included into the main.php template file through the statement: {include file='js/common.html'} Dealing with each script individually: jquery-ui.min.js - This is the jQuery library that is required. query-ui.min.js - The jQuery UI (User Interface) library. I have no idea why this is in here or if it is even required for the front-end. I have removed this from my themes since it comes with a hefty file size and I don't see why it is necessary. plugins.php - Used to load in all of the JS files from the /js/plugins/ directory. Again, many of the files in there are not required for the front-end but CubeCart loads them in anyway. The only files you will probably need are jquery.colorbox-min.js, jquery.magnifier.js and jquery.rating.min.js. I would remove the inclusion of the plugins.php script and instead include these three scripts in your main.php template file. common.js - Essentially an application file that makes use of all of the plugins included above. You'll probably want to keep this one! I hope this helps.

I often find myself repeatedly clicking the reload button until something vaguely legible appears. It's certainly not ideal and it wouldn't surprise me if this adversely affects your client's conversion rates. Unfortunately, CC5 doesn't have an alternative to reCaptcha. I would love to see CubeCart utilise the Akismet service (http://akismet.com/) to filter out spam reviews and comments. I view captchas as being far too restrictive and also a fairly weak form of protection. Perhaps try submitting a feature request through the bug tracker.

Just a warning... If you edit the gui.class.php file, you will need to make the same modifications each time you update CubeCart to the latest release. CC5 has a plugin system, which would certainly be the preferred method of adding any additional features - or indeed changing existing behaviours. The class.gui.display hook may be used for this purpose. However, if you don't need to pass any new PHP variables to your sidebox, you can utilize SMARTY's {include} tag. So, instead of adding {$YOUR_BOX}, you can add the following to the main.php template file: {include file="skins/{$SKIN_FOLDER}/templates/box.yourbox.php"} Either of these methods will allow you to easily update CubeCart when the next release comes along.

Your site does seem to wait quite a few seconds before transferring data, which would suggest a server issue rather than any client-side scripts. I did notice that you have some 810 pages of products, which I estimate to equate to around 14,000 products. However, assuming that you have caching enabled (and it is working as caching should), your homepage should (at the very least) be quick to load. I have never worked with a store having anything like 14,000 products, so I don't know how CubeCart should behave under these conditions. Nevertheless, I would imagine that even a low-spec dedicated server should be able to handle a database of this size (assuming well-designed SQL queries). My guess is that the database is to blame. The last time I checked there were no indexed fields (other than primary keys). Foreign keys should nearly always be indexed. As an analogy, consider searching through a telephone directory. Since the telephone directory is indexed, you can quickly narrow in on the name you are looking for. If the directory was not indexed and all the names were ordered randomly, you would need to search one-by-one through the list - which is obviously much slower. Indexing appropriate fields could yield a healthy return. To repeat bsmither, a server administrator (which I am not) should be able to sniff out the culprits. He/she may then return to you with a bunch of slow SQL queries, which you can present to Devellion.

Can you supply us with a URL? There are various tools that we can use to help identify the cause of a slow site. It might not be down to the server. I quite frequently see JavaScript inclusions to third-party sites that can block page rendering. Nevertheless, you will want to ensure that caching is enabled - particularly for stores with many products, categories, orders or visitors.

Caching really can make a difference. However, a slow site can be caused by a number of different things. Can you provide URL to your store?