Homar

Try: {if $IS_USER} Your content here... {/if}

Check your skin's config.xml file. If I remember correctly, there's a quality property in there where the image sizes are defined.

I just came across the variable {$SECTION_NAME}. It seems that the developers did consider this after all. This variable can take the values: homecheckoutproductdocumentdownloadsaleitemscategoryloginorderaccountgiftcertificategatewayregister You should now be able to do something like this (untested): {if isset($SECTION_NAME) && ($SECTION_NAME == "home")} {include scope=parent file="skins/$SKIN_FOLDER/templates/main.home.php"} {else} {include scope=parent file="skins/$SKIN_FOLDER/templates/main.normal.php"} {/if}

You can only output the variables available to the current scope. The smarty debug console shows the variables available to the current page. You cannot, for instance, add {$BREADCRUMBS} to the content.product.php file. This is because that variable is only available to the main.php file (or any files that you "{include}" from the main.php file with parent scope). This isn't really ideal and differs from Wordpress in this way. So there are some limitations.

Woah. Ok. Let me try to clarify. The logic is used to decide which template file to render. We might envisage two main template files. In my example, I called them main.normal.php and main.alternate.php, but they could be called anything. One might have a one column layout whilst the other might have a two column layout. They would essentially contain all the code that you would normally put in the main.php template file. The main.php template file is then only used to select between these two template files. To select one or the other, some logic is required (as described earlier). The real problem is that CC5 does not make it easy to distinguish what area of the site is being viewed. As such, I suggested identifying variables that are only present on certain pages or areas of the site. As an example, the $PRODUCT variable might be available to only the product page. We could then test for whether this variable exists as part of our logic and subsequently decide to render a different template file. If you want to render a different template file for the homepage, you will need to identify a variable that is only set on the homepage (perhaps $LATEST_PRODUCTS). Naturally, this would be far easier if a single variable were available that indicated the page being viewed. Instead of having to identify variables that are only set on certain pages, it should be fairly easy to create a small plugin that provides this single variable (mentioned above). With regards to "Products >> Related Products >> Popular Products all on the one page". I'm not sure exactly what you're trying to achieve. The main.normal.php and main.alternate.php files would act exactly like an original main.php file. In other words, you can choose what to display in each one. However, you are limited to the variables that are passed to the main.php file. You cannot, for instance, have your popular products markup in these files. You only have access to the $POPULAR_PRODUCTS variable, which contains the markup from the rendered box.popular.php file. If you did want to have different markup for the popular products depending on what page is being viewed, you would need to repeat the procedure for the box.popular.php template file (i.e. creating box.popular.normal.php and box.popular.alternate.php and then implementing some logic to select between the two inside of box.popular.php). In summary, using smarty's {include} is, for most intents and purposes, the same as using PHP's include construct (http://www.smarty.net/docsv2/en/language.function.include.tpl). Smarty has a debug console, which is different from CubeCart's debug output. You can run Smarty's debug console by adding {debug} to your main.php template file. When you reload the page, you should be greeted by a popup that lists all the variable available to the current page. I just suggested using this for identifying which variables could be used to distinguish between which page is currently being displayed. The example code provided would be inserted inside of the main.php file. It could be the only code in the main.php file. All the usual page markup (<head>, <body>, etc.) would be in the main.normal.php and main.alternate.php template files. But it's entirely up to you what code you put where. You could, for instance, include markup that is common amongst both template files inside of the main.php file. This might then look like: MAIN.PHP: <html> <head>...</head> <body> <div id="page"> {if isset($PRODUCT)} {include scope=parent file="skins/$SKIN_FOLDER/templates/main.alternate.php"} {else} {include scope=parent file="skins/$SKIN_FOLDER/templates/main.normal.php"} {/if} </div> </body> </html> I hope that this clarifies things somewhat. N.b. SMARTY does not know the difference between a .tpl template file and a .php template file. The extension is not important, so all the documentation available on the SMARTY website is still applicable. See: http://www.smarty.net/docs/en/smarty.for.designers.tpl

It should be possible to use alternate templates for separate sections of the store without modifying the CubeCart classes. Smarty allows for the inclusion of additional template files. This allows you to render alternate templates from the main.php file - e.g: {include scope=parent file="skins/$SKIN_FOLDER/templates/main.alternate.php"} Note that the scope is set to "parent" so that all the SMARTY variables accessible in the main.php file are also accessible in the main.alternate.php template file. You now only need some logic to differentiate between pages (e.g. homepage, product pages, category pages, etc). You can do this by testing for the existence of specific variables that are only accessible to certain areas of the store. You can add {debug} to the main.php template file to bring up the smarty debug console. This will present you with all the variables available to the current page and should assist in selecting suitable variables to test for. As an example, you might do {if isset($PRODUCT)} to test if a product page is being viewed. This would certainly be cleaner if a variable was made available that denoted the page being viewed (e.g. {if $PAGE == "home"}). Perhaps that's a feature request for the bug tracker. So... your main.php file might look like this: {if isset($PRODUCT)} {include scope=parent file="skins/$SKIN_FOLDER/templates/main.alternate.php"} {else} {include scope=parent file="skins/$SKIN_FOLDER/templates/main.normal.php"} {/if} You would then place all the usual HTML markup inside of main.normal.php and main.alternate.php. Really do avoid modifying any core PHP files. There is rarely any need and it will make updates a painful process. You can create a small plugin instead and upload it to CCF.org for the whole community.

See this bug report: http://bugs.cubecart.com/view.php?id=2677

Sounds like a session issue. There were some reports of this on the CubeCart bug tracker. Unfortunately, session issues are difficult to recreate. Try clearing your browser cookies and restarting the browser for a temporary fix.

See: http://bugs.cubecart.com/bug_view_advanced_page.php?bug_id=1550 The delimiter for exploding on the product options string (don't ask me why it was designed this way) was changed from: @ to {@} and from | to {|}. You need to ensure that the delimiters are consistent throughout. If the delimiter is set to @, try changing it to {@}. Also, try doing the same for the other delimiter (i.e. the pipe). I forget exactly in which file this is set. It might be the cart class?? Hope this points you in the right direction.

I should clarify that I was speaking in the context of an online/ecommerce store when asking "why you would want to do this?". Speaking generally, the key is to interpret and amend as necessary that provided by any translation service - or exactly as you put it "tweaked by a group of volunteers to proofread the raw translation". I don't think that any issue is made regarding the use of a Google translate widget.

I think this is rather reasonable. Including a translate tool on your website is not against the guidelines. Automated translation and insertion of content (without editing) into your CMS, blog or store is. But why would you want to do this anyway? If you (or one of your staff) does not speak the language, how are you going to be able to support or communicate with your global customer base? Google don't want sites with pretty useless automated translations outperforming their native (well written) counterparts.

I too am receiving this error. Interesting... Have you logged a bug?

I would advise against this. Redirects should be performed by Apache. You can specify 301 redirects in the .htaccess file (search google for more information). Also, if you plan on keeping your skin, I would suggest that you rename it such that the directory name does not contain spaces - just to avoid any problems down the line. Although my opinion may be biased , I do think that you would benefit from using a different skin. The HTML markup in the stock skins is abysmal at best. I personally believe that Magento is a much better piece of software than CC4. But I would question whether you need everything that Magento offers. CC4, whilst not as powerful, caters to a different market in many respects. You should also be able to easily upgrade to CC5 if and when it is released.

I'm not sure why CubeCart doesn't index its foreign keys. I remember that this was highlighted some time ago. Thanks for posting!

Unfortunately, this is not easily possible due to the way sessions are handled in CubeCart. There is no API in CubeCart V3 or V4.

I'm unable to find a Clear Cache or Session type option, any idea where (4.3.8)? I had to disable SQL Caching in order to see code changes on my Categories Box. Use your FTP client to delete all the files/folders inside of the /cache/ directory.

I'm not sure why this is happening, although it is not a fault of the skin. The skin selection is controlled though the administration panel. My guess is that you have the skin selection stored locally using the front-end skin selector tool. Try clearing your browser cookies.

I am not aware of any such files in CC3. You should speak with your host.

CI is a framework. CubeCart does not use a framework. How do you want to integrate the two?

Complete an utter rubbish. In order to be PCI compliant, you need to have your server and network (amongst other things) audited. If you do not store credit card information on your servers, the best you can do is ensure that the data is passed from one point to the other in a safe and secure manner - SSL is a must here! These guys do not know whether or not you are PCI compliant. They're simply betting that you're not and trying to scare you into paying for a service that you probably don't need: welcome to marketing. They certainly should not be contacting your clients. If they are, insist that they desist immediately.

Try the tar.gz

The latest zip (downloadable via the customer panel) is not corrupted.

See: http://forums.cubecart.com/index.php?showtopic=39444&hl=

Sir William tells me that the corruption was fixed some time this afternoon. Nevertheless, the other issues are still present.