Fatal error uncaught exception error could not load model

Because I was this time updating 2.0.3.1 -> 2.3.0.2, as opposed to 1.5.6.4 -> 2.0.3.1, and because the problems I was experiencing were being caused by the codebase files, and because I had already run the 2.3.0.2 database schema update, it was relatively easy to install a fresh copy of the codebase, then copy across the image directory and the two config files. This means that the fresh 2.3.0.2 instal is now pointing at the updated 2.0.3.1 database, and with the exception of the bug I mentioned above, it seems to be functioning as expected.

However, this does not allow for any of the many extensions/mods we have been running for the client, nor for the theme, which I had been growing increasingly unhappy with each time the theme was updated. The theme has lots of snazzy ‘bells and whistles’ features, but the more I had reason to study the files, the more I realised that they had not been coded particularly well or efficiently, and the more I understood why the site was so damn slow!

So I decided that with the introduction of a clean 2.3.0.2 codebase, and one with an HTML and Bootstrap layout structure that is considerably better than what opencart was a few years ago, that now was the time to design my own theme, working predominantly with CSS, so that I only need to update the header and footer file when updating opencart in future. Why the header and footer? …because I also recognise one of the reasons opencart is so slow (regardless of the theme): because so many separate CSS and JavaScript files are loaded from the document head.

So this time round I have set up a sass/gulp workflow inside the custom theme directory, so that I can tweak all the bootstrap variables prior to loading bootstrap (saving the need for overrides), then load the opencart and extension CSS files, then my theme tweaks, then concatenate and compress (and a few more tricks besides) everything into one minimised and optimised CSS file. I’ve done the same thing with the JavaScript files and call them from the footer, and the site’s speed increase is noticeable (as expected). This is all exactly what I do for normal websites and apps, but it’s a bit more involved with opencart due to the wide distribution of CSS and JavaScript files throughout the codebase.

The only downside to moving the JavaScript down the page is that any JavaScript written by a module or extension ‘in the page’ has to be wrapped with a DOMContentLoaded event listener. But this is a small price to pay (and to have to repeat during updates) for the faster load times. As you say, upgrades are a pain, so I’m now doing my best to keep the codebase as clean as possible, and in the case of the javascript wrappers, I would rather manually update the core ‘default’ view files (God forbid … «burn him!»), than have to run override theme files that might go out-of-date without me noticing.

So this is what I am in the middle of right now, as well as having to clean up the database of now-redundant theme and extension tables, and write or find new extensions and mods to restore functionality that our client cannot do without. If the client wasn’t also a very good friend, I’m not sure I would spend this amount of time treating the project to such an in-depth upgrade, but I also see it as a challenge to try and get the best out of opencart despite its many problems, most of which stem from the collaborative nature of its life, and the endless pace of technological innovation and advancement in recent years.

As for the update of all the product data from 1.5.6.4 -> 2.0.3.1, well that was an experience I went through a year ago, and one that I would not want to repeat. Any automated update tools available at the time failed miserably, so I studied the 1.5.6.4 database schema in depth, then did the same for the 2.0.3.1 schema, then manually converted each and every product-related table across from v1 to v2 format/schema/structure. All turned out well but I would not recommend it unless you are already confident that you know what you are doing.

I would also suggest that if you don’t have hundreds or thousands of products in your database as we do, there might be a case for simply starting all over again with a completely clean instal, and manually entering your product data from scratch. It depends how many products you have, of course, but don’t underestimate the time involved in all the things I’ve described above. Good luck, whichever way you go.

The upgrade issue is a bug reported and solution explained in their forum, here.

Summary (copy/paste for posternity):

BUG: Error: Could not load model total!

Two-part bug. Part one: Event Compatibility cuts off too many parts of
the route when trying to load the older extension format. ex.
«extension/total/sub_total/getTotal» route gets turned into
«total/sub_total» instead of «total/sub_total/getTotal». This causes
it to try and load a model with no name throwing the exception. Part
Two, this compatibility is being loaded fine when the route is
«extension/total/subtotal» but is also loading when the route is
«extension/total/sub_total/getTotal». I think this event should not be
triggered for compatibility because it is a getTotal is a function
call, not a model load. This causes the verification to fail and try
to load the 2.2.x version which has other bits missing and throws
different errors. Haven’t figured out why the function call is going
down the event path. But basically the attempt to support backwards
compatibility with 2.2 mods is causing problems.

2 Solutions

FIX 1: Give up on 2.2.x compatibility and delete the following
left-over folders:

     catalog/model/total
     catalog/model/payment
     catalog/controller/payment
     catalog/model/shipping
     catalog/controller/module
     admin/controller/total
     admin/controller/payment
     admin/controller/shipping
     admin/controller/module

FIX 2: Add a hack to bypass the event when the function call for
«getTotal», «getMethod», or «getQuote» are passed in. This is
experimental but should at least restore support for 2.2.x mods for
now. This is NOT a permanent fix. Just a work around.
EDIT: catalog/controller/event/compatibility.php FIND:

'model/' . $route. '.php'

REPLACE WITH:

'model/' . ((strpos($route,'get') !== false) ? dirname($route) : $route) . '.php'

This should let routes like «extension/total/sub_total» work but block
«extension/total/sub_total/getTotal» calls which fail on the directory
check.

private $registry;

public function __construct($registry) {
$this->registry = $registry;
}

public function controller($route, $data = array()) {
// $this->event->trigger(‘pre.controller.’ . $route, $data);

$parts = explode(‘/’, str_replace(‘../’, », (string)$route));

// Break apart the route
while ($parts) {
$file = DIR_APPLICATION . ‘controller/’ . implode(‘/’, $parts) . ‘.php’;
$class = ‘Controller’ . preg_replace(‘/[^a-zA-Z0-9]/’, », implode(‘/’, $parts));

if (is_file($file)) {
include_once($file);

break;
} else {
$method = array_pop($parts);
}
}

$controller = new $class($this->registry);

if (!isset($method)) {
$method = ‘index’;
}

// Stop any magical methods being called
if (substr($method, 0, 2) == ‘__’) {
return false;
}

$output = »;

if (is_callable(array($controller, $method))) {
$output = call_user_func(array($controller, $method), $data);
}

// $this->event->trigger(‘post.controller.’ . $route, $output);

return $output;
}

public function model($model, $data = array()) {
// $this->event->trigger(‘pre.model.’ . str_replace(‘/’, ‘.’, (string)$model), $data);

$model = str_replace(‘../’, », (string)$model);

$file = DIR_APPLICATION . ‘model/’ . $model . ‘.php’;
$class = ‘Model’ . preg_replace(‘/[^a-zA-Z0-9]/’, », $model);

if (file_exists($file)) {
include_once($file);

$this->registry->set(‘model_’ . str_replace(‘/’, ‘_’, $model), new $class($this->registry));
} else {
trigger_error(‘Error: Could not load model ‘ . $file . ‘!’);
exit();
}

// $this->event->trigger(‘post.model.’ . str_replace(‘/’, ‘.’, (string)$model), $output);
}

public function view($template, $data = array()) {
// $this->event->trigger(‘pre.view.’ . str_replace(‘/’, ‘.’, $template), $data);

$file = DIR_TEMPLATE . $template;

if (file_exists($file)) {
extract($data);

ob_start();

require($file);

$output = ob_get_contents();

ob_end_clean();
} else {
trigger_error(‘Error: Could not load template ‘ . $file . ‘!’);
exit();
}

// $this->event->trigger(‘post.view.’ . str_replace(‘/’, ‘.’, $template), $output);

return $output;
}

public function helper($helper) {
$file = DIR_SYSTEM . ‘helper/’ . str_replace(‘../’, », (string)$helper) . ‘.php’;

if (file_exists($file)) {
include_once($file);
} else {
trigger_error(‘Error: Could not load helper ‘ . $file . ‘!’);
exit();
}
}

public function config($config) {
$this->registry->get(‘config’)->load($config);
}

public function language($language) {
return $this->registry->get(‘language’)->load($language);
}
}