bsmither

I noticed that there is an /admin/ folder, as well as an /admin_xxxxx/ folder. But I can't conclude that this would matter. We need to find out where the /public_html/ is coming from when real_path() is executed. In the admin script: Find: ## Include the ini file (required) require 'ini.inc.php'; Change to: echo "Filename: ".__FILE__."<br/>"; echo "Directory: ".dirname(__FILE__)."<br/>"; echo "Path: ".realpath(dirname(__FILE__))."<br/>"; ## Include the ini file (required) require 'ini.inc.php'; This is before CubeCart does anything. The filename should be what is expected, so too the directory. Put this in the index.php script as well. For just long enough for you to see what it shows.

I have not seen this control panel, so excuse the stupid questions. The Home Directory column shows a simple name (newshop, shop, etc), but how does the folder /subdomains/ come into play? Is this just "understood"? That is, when a subdomain is created, this control panel automatically creates the folder and automatically puts it in /subdomains/? Well, the storefront seems to work -- so the above line of questioning is irrelevant. So, making wild guesses: Is there anything suspicious in the "shop" site's .htaccess file? Anything suspicious in the site's globals.inc.php file? Does the term "DYNSRV" mean anything?

I see this, but please examine your Cpanel "Subdomains". I think the "shop" subdomain should have a Document Root of: <house icon>/shop where <house icon> is your "home directory" (as seen somewhere in Cpanel's General Information).

Nothing from the try/catch??? How unfortunate. Well, this script has determined that it is sitting in /public_html/. But you say otherwise. But the error_log (re: tcp wrapper) says this so. Are you sure you are not in /public_html/?

My bad: From: echo realpath(dirname(__FILE__)."<br/>"; To: echo realpath(dirname(__FILE__))."<br/>"; My programmer's editor is configured to not auto-complete delimiters. Thus, sometimes I forget to match opening and closing parens.

So we are still crashing on the Smarty->fetch() statement. It is not liking something, although there should be a template at that location. echo "test4"; ini_set('error_log', 'error_log'); ini_set('log_errors', 'on'); echo "template: ".$global_template_file['session_false']."<br/>"; $smarty_template_dirs = $GLOBALS['smarty']->getTemplateDir(); echo "template_directories: ".print_r($smarty_template_dirs,true)."<br/>"; echo realpath(dirname(__FILE__)."<br/>"; echo CC_ROOT_DIR."<br/>"; try {$template_content = $GLOBALS['smarty']->fetch('templates/'.$global_template_file['session_false']);} catch ( ErrorException $e ) { $debug_backtrace = debug_backtrace(); echo print_r($debug_backtrace,true); echo $e->getMessage()."br/>"; echo "First 32 bytes of ".strlen($template_content)." total bytes:<br/>"; echo substr($template_content,0,32); } I haven't tried this try/catch approach. It will be interesting to see what it does.

Welcome RetroDan! Glad to see you made it to the forums. Using a programmer's text editor, open the Mican skin template main.php. Find: {$MAIL_LIST} Change to: {* $MAIL_LIST *}

The template directory is an array. Interesting. echo "test4"; echo "template: ".$global_template_file['session_false']."<br/>"; $smarty_template_dirs = $GLOBALS['smarty']->getTemplateDir(); echo "template_directories: ".print_r($smarty_template_dirs,true)."<br/>"; $template_content = $GLOBALS['smarty']->fetch('templates/'.$global_template_file['session_false']); echo "First 32 bytes of ".strlen($template_content)." total bytes:<br/>"; echo substr($template_content,0,32); This time, we are switching to capturing Smarty's template rendering using fetch(). Smarty's display() sends the rendered template directly to the output stream.

For the next test: echo "test4"; echo "template: ".$global_template_file['session_false']."<br/>"; echo "template_dir: ".$GLOBALS['smarty']->getTemplateDir()."<br/>"; ob_start(); $GLOBALS['smarty']->display('templates/'.$global_template_file['session_false']); $ob_output = ob_get_contents(); echo "First 32 bytes of ".strlen($ob_output)." total bytes:<br/>"; echo substr($ob_output,0,32); ob_flush();

Extensions will do everything themselves. It will be up to you to download unzip, and FTP the extension, and place the named folder in the proper /modules/ subfolder (gateway, plugins, shipping, etc). When you next call up the admin Manage Extensions page, you should see the named module in the list.

I don't know about that, but an internet search for php ziparchive godaddy has a couple of GoDaddy knowledgebase articles.

Your site is running under a build of PHP in which seems it has not been compiled with PHP's ZIP functionality. There are three main places CubeCart uses the ZipArchive features: unzipping an extension downloaded using the Marketplace's Lightning Bolt code number, making a backup or restoring a backup, and creating a sitemap. In admin, PHP Info, view the Configure Command value in the top table. Somewhere in there MUST appear "--enable-zip". If it isn't, see about getting your version of PHP upgraded and hope the upgraded version has been compiled "--enable-zip". If still no, get your hosting provider to compile a version of PHP with "--enable-zip" for your account.

According to Bing Ads, once you have a Google AdWords campaign set up, you can just have Bing access that data from Google. So, maybe focusing on getting Google AdWords set up is the priority. But, having zero knowledge about what AdWords is all about, I can't say if submitting a list of your inventory is appropriate.

Do these entities detail the contents of the file they will accept? If they do not like CSV, then maybe they can use XML. But XML has node names and attributes and maybe a lot more. For example: <product> <name lang="en-US">Foo</name> <name lang="de-DE">Fur</name> </product> <item> <nomenclature lang="en-US">Bar</name> <nomenclature lang="de-DE">Bahr</name> </item> Note that the name of the node that designates inventory could be 'product' or 'item'. Then what the inventory is called could be 'name' or 'nomenclature' or 'designation'. So, we would need to know the "schema" of the file they will accept.

Since we are editing a skin template, be sure to clear the cache (admin, Maintenance, Rebuild tab, Clear Cache, Submit). Also, there are two places in the language file: the <catalogue> group, and the <common> group.

A CSV formatted file is used to transport data in the most plain and pain-free of ways possible. By "Catalogue", CubeCart is referring to a simple list of the products and the relevant details about each respective product. A spreadsheet can load a CSV file which allows one to make some simple analysis. In a somewhat more elaborate format, an XML file can be 'manipulated' in more imaginative ways. It is an XML file that search engines are wanting, and there are ways to get an output of the inventory (the 'catalogue') in that format. In the Marketplace, there are a few "Product Feeds" that will deliver a custom file in the format required by the respective entity. We would like to ask, in what final format would want your inventory report? I would caution against an output that resembles an actual "catalogue", the type that you would associate with Sears, Victoria's Secret, and Swiss Colony.

I think that's it. Whatever select option you choose for "condition", it gets saved in the database CubeCart_inventory, the column 'condition' as is. You've tried it and are having problems?

Now that TSO is aware of CubeCart's need for the PHP function 'file_exists()' to have a "tcp wrapper" available, can we assume they will do something to remedy that situation? "A different subdomain on the same host." I know that subdomains can point to different servers, but I think maybe that doesn't happen all that often on many types of hosting plans. And, as you say, CubeCart was working. CubeCart does not change its code (unless you upgrade it, and you would know if that happened). But hosts do all manner of things that could affect what is hosted: moving you to another server, upgrading the operating system that runs the server, upgrading PHP that runs your applications, etc -- all without a care in the world having the courtesy of notifying you. Create this file and place it in CubeCart's main folder: Name: phpinfo.php Contents: <?php phpinfo(); ?> Request the page: www.store.com/phpinfo.php. The top table will give you the version, build date, and other info. Your duplicate installation of CubeCart (you say it is working), in admin, view the PHP Info page. Compare versions, builds, etc.

You will need to upload some sort of file and select that on the Digital tab of the product's screens. In admin, Downloads, upload the file on this screen. It will then appear on the product's Digital file picker window. Unless a file is assigned, CubeCart will consider the product tangible. As such, the "Allow physical orders" setting mentioned above is necessary. Using a programmer's text editor, open the file: In the skin template 'main.php' and 'main.checheckout.php', find: <div class="medium-5 large-5 columns"> {$SOCIAL_LIST} <div class="row collapse"> Change to: <div class="medium-5 large-5 columns"> {* $SOCIAL_LIST *} <div class="row collapse"> Because an edit has been made to a skin template, you will need to clear the cache. In admin, Maintenance, Rebuild tab, check Clear Cache. Click Submit.

Hopefully, their response will say something like the version of PHP was upgraded, and the new version did not have some necessary functions compiled into it (the 'tcp' wrapper). Or PHP's session management was not configured correctly. Even so, if the file_exists() function fails, CubeCart should start saving session files in CubeCart's own /extra/ folder. See if there are any files in extra that start with 'sess_'. A malfunctioning session probably would not cause a blank page, but will prevent logins and carts mysteriously getting emptied. If no files, then I think the Warning is not relevant to why the admin page comes back blank. It could be a case of some path of executing the script that leads to a dead end -- which is not really an error.

Currently, that ability is not available. But it is being worked on.

We would ask that you create the error_log. Perhaps there is a clue there.

Welcome vickif! Glad to see you made it to the forum. In admin, Store Settings, Features tab, please check the box for "Allow physical orders even if no shipping options are available". But, if the conference store is selling registrations (thus nothing is tangible - just digital), there should be no issues with not having any shipping modules installed. On the other hand, if registrations are digital, CubeCart needs a file to associate with that product. An easy thing to do with that requirement is to create a simple PDF file with conference information. (I did conference registration stores using CC3. Fun times!)

These issues in the Github may shed a bit of light: https://github.com/cubecart/v6/pull/812 https://github.com/cubecart/v6/issues/1260 Hopefully, you can get some clues from the error_log file. Send me a PM with you email address and I will work with you as much as I can.

I think this was worked on in another conversation. I'm not sure of the solution, but please check to see if the intended extension has a properly formatted config.xml file.