bsmither

It seems there is a mismatch in versions of files in the /classes/ folder: a later version of the Ajax class script calls for a function in the FileManager class script that isn't there in the older version of the FileManager class script. If you have made any edits to the filemanager.class.php script file, please double-check those edits. If not, see if there is, in fact, a getDirectories() function. If not, consider the possibility that this file, and perhaps others, did not get overwritten on an update, or this file got copied over from a store having an older version.

The admin folder's name and the text value given to the $glob array for the admin folder must match. It does not matter at all what that name actually is - as long as they match. Please follow these instructions to create CubeCart's system error log. The spinning "busy" thing that doesn't go away is probably caused by either the javascript that powers loading this file-picker has crashed, or CubeCart has some difficulty in delivering the list. The error log (which catches more things than the admin error Log) may have a clue.

I believe the AIOS module uses the setting set in CubeCart's admin, Store Settings, Stock tab, "Weight Unit".

I think I have seen a plugin in the Marketplace that sorts items of an order to individual fulfillment centers. (I've written one myself, as well.) But this approach supposes that those disparate parts of an order are managed and fulfilled by distinct entities. So, as you say you have "different people", do you also ship an order in parts by category?

I have no knowledge of mod_security, but my reading of the error message implicates a request for the file /js/common.js, and in the request for this file - in the Request Headers - there is what looks like cookie data (really? I can't tell). One of the headers in any request for a page is the "referrer" - the web address where the page that contains the link or source tag. That is, once a browser has received the HTML of a page (index.php) and is scanning through it making follow-on requests for CSS, javascript, and image files, those follow-on requests will have the "referrer" header. This includes someone else's page having a link to your site, such as a search engine results page. This is so that an analysis can be made of where requests are coming from. So, it looks like PayPoint is sending back it's IPN data, but in doing so, is also accepting the whole page and making follow-on requests for the page's resources - for no reason. T only thing PayPoint should be wanting to see is the 200OK response from your web server. (Maybe the reason for handling more than the 200OK response is in their API documentation.) I believe that the web address PayPoint has been told to use to send it's transaction reply is in error. CubeCart has a special URL format that will cause it to activate code in the PayPoint gateway module, followed by an orderly shutdown (200OK) without sending anything back. While the problem is manifesting as a mod_security rule getting tripped, I think the real problem is with PayPoint: the URL format being used to send transaction data, and PayPoint asking for page resources.

The re-write code I posted earlier is the standard .htaccess code CubeCart needs for any seo-friendly URL to be calculated. What we want you to do is make sure that code (exactly as seen above) is in your .htaccess file. (There is more than just that in the file, but all those directives above must be present.) Then, as for the /test/test.html file, make sure that it is actually a real file located in a real sub-directory,

Click on "Air Systems" in the Category Name column. When the new page is displayed, you will see the sub-cats listed.

This is something your hosting provider should be able to fix. If this server is under your total control, then you will need to re-install (re-build) PHP and all the extensions using the same compiler.

That code is executed after the Debug class is executed. The Debug class sets the error reporting level to not include Notices. So I think some other code is being executed just after the Debug class that is changing the error reporting level. Perhaps a quick switching off of all plugins and snippets may reveal something.

Yes, a huge list. As you scroll through the list, are there more than one image marked: starred and/or checked?

Ok, then maybe there is some code elsewhere that changes the error reporting level. To find that, one would need to have a scanner search through all the code looking for what may be changing the error reporting level. Perhaps, once having cleared the log, we can identify when the first occurrence of a notice appears. Then look backwards.

That's a weird problem. What happens to the image picker list if you click "Show all images"?

A browser will show the "title" (or "alt") text parameter of the <img> tag (usually the same as the product name) if there is no actual image data received. It appears that the browser is styling that text which makes it look weird.

One of the installations must be using a different build of PHP. The errors above are saying that the MySQL functions are not available (where MySQLi is probably what is available), and the Multi-byte functions are not available. If your hosting environment is set up so that you can control what extensions are enabled for PHP, please check that. The latest version of CC needs Multi-byte and also a ZIP Archive extension enabled.

Please double-check the code that you have for /classes/debug.class.php with the file in the downloaded CC618 package. Especially near line 85 in CC618: error_reporting(E_ALL ^ E_NOTICE);

The code in CC6 allows for a document to be created, and most of the parameters are ignored if it has a Document URL. (The title is still needed.) This document is an actual file that exists somewhere. Also, if the file is on your site, the .htaccess rewrite code must be able to find that file. This part of the re-write code: RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !=/favicon.ico RewriteRule ^(.*)\.html?$ index.php?seo_path=$1 [L,QSA] The first directive says to only do the rewrite if the filename requested is not where it is supposed to be, that is, not found. So, if test.html actually exists in the /test/ folder, this directive will evaluate to false, the rewrite will not happen, and the web server will find and respond with the document at /test/test.html. Now, as with any URL, there are complete, absolute, and relative styles. Your browser will figure out how to deal with this. So, make sure the web server is behaving appropriately as regards the conditions and rules for rewriting URLs.

CubeCart's programmer's will need to investigate why the resultant URL was created in this way. I think you did nothing wrong.

Putting PHP code in a Document, a product's Description, or a category's Description is nearly impossible. The text is treated by CubeCart as a value to assign to a variable. This variable and assigned text value never sees anything that could execute embedded PHP code. As mentioned by Noodleman, there is a way by using hooks to get the results of what you may be wanting. Feel free to send me a PM if you want to learn how to do this.

Having removed the rewrite directives that CubeCart needs from the .htaccess file, when CubeCart checks for the presence of these directives and finds them missing, CubeCart will add them back. CubeCart (version 6) needs these rewrite directives to function correctly. www.example.com/testfile.html This URL matches the pattern specified in the rewrite directive. So, the directive will rewrite the URL to: www.example.com/index.php?seo_path=testfile Your store probably will not have a document, product, or category named "Testfile". So, CubeCart sends its internal 404 page. With dynamically generated pages, it up to the application that generates the pages to handle the scenario of what to do when there is no relevant data to create a dynamic page.

Viewing the page is not my intent. If you give me a URL that looks like: www.example.com/this-product-does-not-exist.html I will say that the rewrite directives in the .htaccess file will send to CubeCart this URL: www.example.com/index.php?seo-path=this-product-does-not-exist CubeCart will not find 'this-product-does-not-exist' in the database and will therefore send out its 404 page. So, I am asking for that part of the URL, that does not include the domain name, that does not work as expected. We will use this to see how the .htaccess directives are suppose to handle it.

In admin, make sure you have more than one language installed and enabled. Then, list the documents. Note the table's right-most column: there is a green circle with a white plus in it. This allows you to create a "child-document" that is a different language. You are actually creating a new document, but this new document has a "parent". When the customer clicks a link to a document, CubeCart checks to see if the language being used is not the store's default, and if it isn't, checks to see if there is a child-document in the foreign language. If so, that child-document will be shown.

Please give us a URL that you know should cause Guardian to handle the 404 but isn't.

If the URL matches CubeCart's friendly seo-path format (basically anything ending in .html), the URL rewrite code in the .htaccess file will do its thing and send the resulting rewritten URL to CubeCart. CubeCart, then, will not find what you are experimenting with and will execute its internal 404 response code. There may be little to no way Guardian can determine if the seo friendly URL actually points to a product, document, or category. I do not how a PHP script can inform the web server to execute a separate auxiliary program to custom handle a 404 situation.

You can move the language to en-US, and clear CubeCart's cache.

The 'Please ship to:' hard phrase isn't in the email, so I think the edited mask didn't take. You can try to edit the definitions.xml file in /languages/, or make sure you chose the correct language to make changes to in admin. Either way, see if clearing CubeCart's cache (admin, Maintenance, Rebuild tab, Clear Cache) will have CubeCart reload the language file.