OpenCart Issues

iPage Causing OpenCart Websites to Stop Functioning

We recently had someone come to us for OpenCart support after out of the blue the website stop functioning and the following error was being shown instead:

Warning: require_once([redacted]/system/startup.php): failed to open stream: No such file or directory in [redacted]/index.php on line 17 Fatal error: require_once(): Failed opening required ‘[redacted]/system/startup.php’ (include_path=’.:/usr/local/lib/php-5.5.22-amd64/lib/php’) in [redcated]/index.php on line 17

The error message seemed to indicate that a file was missing, but when we checked the files the file in question, /system/startup.php, was still there. With a closer look at the message we could see that the file was being requested from a different location than it seemed it should. What we then found was that web host for the website, iPage, had for some reason changed the directory path for the account of the website. The configuration files still had the old location included in the directories listed in them. This wasn’t a one off issue, as while we were looking into the issue we found another instance of that involving another OpenCart based website two months ago.

The quickest solution to the issue is to simply update the path for various settings in the /config.php and /admin/config.php files. The limitation with that is that if iPage changes the directory path again the website would stop working again.

To workaround that we then tried to use relative paths for the various directories listed in those files, which worked except images were not showing up. In troubleshooting that we noticed the “src” attribute for images was empty. We the found that the cause of that was the following code in the file /catalog/model/tool/image.php (also in /admin/model/tool/image.php):

if (!is_file(DIR_IMAGE . $filename) || substr(str_replace('\\', '/', realpath(DIR_IMAGE . $filename)), 0, strlen(DIR_IMAGE)) != DIR_IMAGE) {
	return;
}

The second check in that if statement would fail causing no image to be specified.

Removing that check would resolve that issue, but the problem would reoccur after any upgrade due to the new version of the file restoring that code.

Ultimately we added code to the configuration files to get the current directory path using getcwd(), so that if iPage changes it again then the new one will be used automatically and the website won’t go down.

Restoring the Tax ID to Customer Data in OpenCart 2.x and Above

When upgrading from OpenCart 1.5 to a newer version there are some significant changes. One that we recently dealt with for a client was restoring the Tax ID field that was previously available as part of the information entered during checkout by customers and was removed in OpenCart 2.0. There two steps to accomplish this.

The first step is to restore the Tax ID field to the customer data and to checkout. That can be done by creating a custom field, which can be done from the Customers menu in the admin area of OpenCart. You are provided with a number of options when setting up a new custom field, including what customer groups you wish it to be shown to:

The second step is to copy over the existing Tax IDs to the new custom field. The existing Tax IDs are stored in the tax_id column of the address table in the database and the custom field in the custom_field column in the customer table. Because of the formatting used for the custom_field column you cannot simply copy over the values from one to the other. The simpler method technically to copy the data is to enter the values from the tax_id column in to the customer’s details in the admin area. For those technically minded you can use a bit of coding to get the values from the one column, convert them to the formatting for the second, and then copy them over.

Fixing OpenCart Login Failure Due to Missing Logs Directory

We recently had someone come to us for OpenCart support after out of the blue they were unable to login to the admin area of OpenCart anymore. When they tried to log in with the correct credentials they were getting the following messages and nothing else:

Warning: fopen([redacted]/system/logs/openbay.log): failed to open stream: No such file or directory in [redacted]/system/library/log.php on line 6Warning: Cannot modify header information – headers already sent by (output started at [redacted]/admin/index.php:85) in [redacted[/system/library/response.php on line 12

Similar messages were being shown on other pages on the website.

The first warning shown indicated that there was a failure to open a file at /system/logs/openbay.log. When we started looking into things we noticed that there was no directory at /system/logs/, which was the defined location for the logs directory in the config.php file for OpenCart. After creating that directory the warning messages were gone and the website’s owner was able to successfully able to log in.

It is isn’t clear why the issue propped up at the time it did because the file that was unable to be written to was created but empty after the directory was created, so it didn’t seem like there was something that suddenly need to be written to that hadn’t before.