bsmither

Any error message that indicates an undefined index or variable can be ignored. The CubeCart developers took the "Don't bother declaring your variables" approach to coding, and PHP is giving a gentle reminder of that. I believe in CC618, if you turn off debugging, then these Notice entries will no longer get logged. The Warning array_keys() entry is (probably) a known issue, however.

From the logic of this code, the value found in the Store Settings, Email Log Retention field would need to be either something that for every character looked like a digit, or was blank. Assuming the execution of the code reached this point. CubeCart's Mailer functions are used regardless whether one chooses PHP-Mail or SMTP. The Mailer communicates with the sending agent accordingly, but this is the code that initiates the email, populates its contents, and logs its departure out of CubeCart. The error message you got would indicate that the email server your hosting provider uses is configured to allow only so many emails to be accepted for sending out server-wide, and that has been exceeded. So, either the server your site is located is overloaded, or one or more sites on that server is using more than its share of the server's email program (maybe Exim?) (From an internet search of 421 Too many concurrent SMTP connections.)

I am not finding any significant differences that would explain the behavior. Still looking.

Just to verify that CubeCart has a log in the database, please use an external utility, such as phpMyAdmin, a tool in your hosting control panel, and verify there is a table named CubeCart_email_log. Have the utility show you the records contained within it. Then, in your CubeCart installation, open the file /classes/mailer.class.php, scroll to near line 222, and verify there is code that deals with $log_days and the database table CubeCart_email_log.

The background-repeat: repeat; is not assigned to any selector. Consider adding this inside the .inner-wrap selector. But I am not saying this is the cause of the problem. I haven't tried it myself as yet.

Hmm. Even the emails sent to the admin get logged. However, only proper emails will cause the log to be 'pruned' of entries older than 30 days. Which is to say, an email sent via the "Test" button on the Advanced tab does not get logged. But, a test send of a newsletter will get logged. In Newsletters, Create Newsletter (if you haven't created one as of yet), enter some miscellaneous stuff. Then on the Send Test Email tab, enter an email that is not of your store's domain - such as a personal gmail account. Let us know if you get it. See if it shows in the log.

The observed behavior is due to how the browser has been instructed to render it, based on the HTML and CSS sent to it. So, I will be able to compare what the browser gets from your page and what the browser gets from a stock Foundation skin.

In Store Settings, Advanced tab, what do you have entered for Email Log Retention?

As of a recent version, CubeCart now logs most, if not all, emails sent out. If the Email Log shows messages sent to customers, then the loss is outside of CubeCart. If the logs show a problem, or the emails are not logged at all, then we can start tracing down the problem.

I've been looking at your site, and I see that you have removed (or commented out, or CubeCart has decided to just not show them) several parts of the header contents. I haven't found it yet, but I am wondering if there is a loss of row - column(s) - row - column(s) arrangement.

Assuming there have been no edits to the skin that prevents showing the description, then, in admin, editing a product, the Description tab, there are editors to enter the product's description. If there is description, but it is not showing when viewing that product on the storefront, we need to examine the skin code. The template content.product.php has the variables related to the product. Open that template for editing, and at the bottom, add {debug}. Save the template. When viewing the product page, the browser will want to show a pop-up - let that happen. The pop-up is a list of all the variables assigned to the template and their values. Scroll to the variable $PRODUCT. There will be an array of values relating to the product. Make sure the description is shown (may be somewhat truncated).

This anomaly will be the result of having the file /admin/sources/maintenance.index.inc.php and the file /includes/functions.inc.php at differing versions. Also, CC617 shipped with statements that should have been changed, but wasn't until CC618, to match the requirements of the relative function. If you do not want to, or cannot upgrade to CC618 just yet, try at least just using the file maintenance.index.inc.php from CC618. Regardless of the anomaly's effect, the work was performed. The problem is when CubeCart tells your browser what page to fetch next.

If your hosting provider has set your site to be externally cached, you will need to have a conversation with them. But, during developing your CubeCart store, it is advisable to switch off CubeCart's cache. In admin, Store Settings, Advanced tab, disable the cache. You will notice that CubeCart still creates a rendered template and caches it (in /cache/skin/), but does not use that cached copy.

In the PayPal_Pro folder, open for editing the file gateway.class.php and find: Near line 606: if($this->_api_method=='Sale' || ($this->_api_method=='Authorization' && $this->_module['authProcess']=='1')) { Change to: if($this->_module['paymentAction']=='Sale' || ($this->_module['paymentAction']=='Authorization' && $this->_module['authProcess']=='1')) { I think this version of the PayPal Pro module (v1.1.9) is using the wrong variable here.

So we will assume that the response was dealt with, as you say there is a log item for this order - the transaction ID matches and the amount matches. The next step in the code is to set the order to Processing. Let's add some diagnostic code. I'll be back with specific edits for CC617.

PayPal Pro module uses CubeCart's Request functions, which will log what was sent to PayPal and what was returned, if anything. In admin, Request Log, find the entry for the order you just made a test with, 'x'-out any personal info, and copy the entry here. We may be able to confirm or deny the problem exists at this stage.

Anytime CubeCart was working, then, for no apparent reason, it stopped working, then we can blame your hosting provider. They may have changed the version of PHP that is running your site, or implemented some sort of security measure (mod_sec). You should contact them. In the meantime, maybe creating an error log will help. This particular error log assumes that CubeCart actually started up, and the 500ISE was not caused by something that the web server disagreed with.

I always had a concern that a website may be very popular, and the application (like WordPress, CubeCart, etc) that runs it might connect to the database that many number of times of visitors. So, if 30 visitors are viewing your site within, maybe, 5 seconds, does that translate to 30 connections to the database? I don't know. I haven't made those kinds of experiments. However, CubeCart keeps copies of standard queries to the database along with the returned recordsets and are stored in its /cache/ folder. (There are events which will clear the cache. And a query can go 'stale' such that CubeCart makes a fresh query to the database.) So, in admin, Store Settings, Advanced tab, check to see if caching is enabled. In my opinion, on the one hand, the structure of data in the database (the 'schema') is not overly complex. Any optimization here would only affect the amount of time it would take to return a recordset. On the other hand, I am aware of numerous instances where the queries themselves could be better formulated to reduce the number of total queries made. But looking at my database's query logs on my development system, I see one connection that comprise numerous queries. So the number of queries it takes to get all the data needed to populate a page, in my opinion, does not affect the number of connections per user. I would think the number of simultaneous page requests would be the triggering factor, and the only way I know how to limit the number of page requests per slice of time is to implement a web server module like mod_bandwidth or mod_qos.

@dan168, you can install to localhost. There will be some specific statements added to /includes/global.inc.php (search the forums for localhost). I recommend not using localhost but rather the actual IP 127.0.0.1. Then, if needed, you can create a "self-signed" security certificate and configure your localhost web server to use it. Do an internet search for how to create one of these. Your browser will complain about the certificate being self-signed, but you can then tell your browser to make a permanent exception for this certificate at IP 127.0.0.1. (Disclaimer: I am only up to CC615 at the moment, so I have not had the opportunity to experience any anomalies regarding weird CSRF issues with the latest versions.)

Specifically where depends on the skin, but examine the skin template content.checkout.php and locate the HTML that has: <h2>{$LANG.checkout.your_basket}</h2> Your indicated location would be new code directly after that.

I understand what you are trying to do. As of CC615 (haven't really looked at later versions in depth), I do not see how this is possible with stock code, unless there is a plugin to manage this.

In the field for "Advisory Title".

Rapidly expends your monthly allotment of bandwidth!

In CubeCart's admin, Documents, click the Edit icon of the HomePage document (as indicated by the table row with the radio button ticked in the Homepage column). When the edit screen comes up, on the Content tab, right-click on the image and select Image Properties. For the Image Properties dialog window, on the Advanced tab, change the Advisory Title phrase. Click OK. Save the document.

Were those URLs ever possible? The search engine may not as yet fully purged those ancient URLs from its index.