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) {

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.

Leave a Reply

Your email address will not be published.