TL:DR Update did not change all the config variables. How to fix?
Upgraded from version 2 to version 3.x.x.maintenence. Worked fine on local desktop but I was unable to log in to admin in the isp-hosted remote instance. No error messages -> eventually gave up.
Upgraded local instance from 3.x.x to 4: warnings and errors which turned out to be because the code was using 'old' version names of variables, while the dbase uses newer versions. The warning is: "Warning: Undefined array key in .../admin/controller/startup/language.php on line 22
Warning: Trying to access array offset on value of type null in .../admin/controller/startup/language.php on line 22".
The offending line is: "$this->config->set('config_language_admin', $code);"
The PROBLEM is that 'config_language_admin' has been changed to 'config_admin_language'.
Similarly, config_language_id has become config_language.
There are over 100 references to config_language_id in .../admin/catalog and more in other places.
Searching the code in github shows that most instances of the 'old' version occur in .../upload.
QUESTION: I am assuming that for whatever reason the patch scripts did not run/work properly. Does anyone know of a quick method to correct these omissions? (Yes, I could write a script to grep the instances and use sed to fixup the files. Problem there is that I don't know all of the changes. I found 2 because they were referenced immediately on login. I am now down to find the same in localisation.php, in a different place in 3 than in 4. So flying blind.
Can I re-trigger the update patches without causing damage? If so, how?
The problem could be with this part of the upgrade code.
https://github.com/opencart/opencart/bl ... hp#L77-L84
The key should probably be 'config_language_admin'.
https://github.com/opencart/opencart/bl ... hp#L77-L84
The key should probably be 'config_language_admin'.
If I read the code correctly, it adds a value config_admin_language against the key 'config_pagination_admin'. The problem is that the only existing keys are
config_language and config_admin_language
The new 'upgraded' php CODE uses 'config_language_id' and 'config_language_admin'.
These are typos or brain-fade mistakes, but I *think* that there are others. My problem is determining 'the others' and correcting the mistake.
For example: from a new download of version 4.0.0.1:
[root@tor1 controller]# pwd
.... /opencart/upload/admin/controller
[root@tor1 controller]# grep -RHn 'config_language_id' *
sale/order.php
$config->set('config_language_id', $language_info['language_id']);
sale/order.php
$config->set('config_language_id', $this->config->get('config_language_id'));
startup/language.php:21: $this->config->set('config_language_id', $language_data[$code]['language_id']);
[root@tor1 controller]# grep -RHn 'config_language_admin' *
localisation/language.php:323: if ($this->config->get('config_language_admin') == $language_info['code']) {
setting/setting.php:132: $data['config_language_admin'] = $this->config->get('config_language_admin');
startup/language.php:14: $code = $this->config->get('config_language_admin');
startup/language.php:22: $this->config->set('config_language_admin', $code);
The error is also seen in the upgrade patch #4:
[root@tor1 controller]# pwd
... /opencart/upload/install/controller
[root@tor1 controller]# grep -RHn 'config_language_admin' *
upgrade/upgrade_4.php:234: $this->db->query("UPDATE `" . DB_PREFIX . "setting` SET `value` = 'en-gb' WHERE `key` = 'config_language_admin' AND `value` = 'en'");
The key 'config_language_admin' does not exist.
So the new 'upgraded' code will never work... it also throws a rather mis-directing warning/error:
Warning: Undefined array key "" in .../admin/controller/startup/language.php on line 22
Warning: Trying to access array offset on value of type null in ... /admin/controller/startup/language.php on line 22
The offending line in language.php is: $this->config->set('config_language_admin', $code);
It should be: $this->config->set('config_admin_language', $code);
The key is undefined because the call attempts to reference a config value which does not exist. (It took .... a little(!) .... time to find the actual error.)
config_language and config_admin_language
The new 'upgraded' php CODE uses 'config_language_id' and 'config_language_admin'.
These are typos or brain-fade mistakes, but I *think* that there are others. My problem is determining 'the others' and correcting the mistake.
For example: from a new download of version 4.0.0.1:
[root@tor1 controller]# pwd
.... /opencart/upload/admin/controller
[root@tor1 controller]# grep -RHn 'config_language_id' *
sale/order.php
$config->set('config_language_id', $language_info['language_id']);sale/order.php
$config->set('config_language_id', $this->config->get('config_language_id'));startup/language.php:21: $this->config->set('config_language_id', $language_data[$code]['language_id']);
[root@tor1 controller]# grep -RHn 'config_language_admin' *
localisation/language.php:323: if ($this->config->get('config_language_admin') == $language_info['code']) {
setting/setting.php:132: $data['config_language_admin'] = $this->config->get('config_language_admin');
startup/language.php:14: $code = $this->config->get('config_language_admin');
startup/language.php:22: $this->config->set('config_language_admin', $code);
The error is also seen in the upgrade patch #4:
[root@tor1 controller]# pwd
... /opencart/upload/install/controller
[root@tor1 controller]# grep -RHn 'config_language_admin' *
upgrade/upgrade_4.php:234: $this->db->query("UPDATE `" . DB_PREFIX . "setting` SET `value` = 'en-gb' WHERE `key` = 'config_language_admin' AND `value` = 'en'");
The key 'config_language_admin' does not exist.
So the new 'upgraded' code will never work... it also throws a rather mis-directing warning/error:
Warning: Undefined array key "" in .../admin/controller/startup/language.php on line 22
Warning: Trying to access array offset on value of type null in ... /admin/controller/startup/language.php on line 22
The offending line in language.php is: $this->config->set('config_language_admin', $code);
It should be: $this->config->set('config_admin_language', $code);
The key is undefined because the call attempts to reference a config value which does not exist. (It took .... a little(!) .... time to find the actual error.)
The issue was mentioned here. https://github.com/opencart/opencart/is ... -756615901
With the fix being.
https://github.com/opencart/opencart/co ... 105b2e463c
Which should of changed config_admin_language to config_language_admin in the database on upgrade.
However, the code looks wrong and should maybe be.
With the fix being.
https://github.com/opencart/opencart/co ... 105b2e463c
Which should of changed config_admin_language to config_language_admin in the database on upgrade.
However, the code looks wrong and should maybe be.
Code: Select all
if (isset($settings['config_admin_language'])) {
$missing[] = [
'key' => 'config_language_admin',
'value' => $settings['config_admin_language'],
'code' => 'config',
'serialized' => 0
];
}Something doesn't fit quite right with this fix ...
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Quite right that something doesn't quite fit right. The problem is that TWO different versions of the same config variable have been used.
In version 3:
There are 14 uses of the code 'config_admin_language' and zero uses of 'config_language_admin'. ( I had that backwards in my original post as to which was where).
There are 478 uses of the code config_language_id and 37 of config_language'.
The database key after the upgrade to version 4 is 'config_admin_language'.
In version 4:
There are 10 uses of the code 'config_admin_language' and 9 uses of 'config_language_admin'. (So config_language_admin has been *added*).
There are 355 uses of the code config_language_id. For example: admin/controller/checkout/confirm.php:300: $order_data['language_id'] = $this->config->get('config_language_id');
There appear to be about 400 uses of 'config_language' alone. Very hard to grep these instances as they may terminate with a comma, or apostrophe or close parens . For example: admin/catalog/controller/startup/startup.php:88: $code = $this->config->get('config_language');
The database key is config_language.
So we have MIXED USAGES in version 3 and carried forward into version 4 and MADE WORSE! Easy enough to grep the 9 config_language_admin errors and change those, and possibly not that horrendous to change the config_language_id entries, but that would require analysis of every point.
WHAT WORRIES ME is whether some other similar brain-fade error affects other variables. As noted, the error which results is quite obscure as the error results from trying to use a non-existent variable value.
WHAT IS REALLY WEIRD is that this code seems to run for many people. It threw warnings for me, on attempted login and died immediately thereafter on attempting localisation instantiation.
In version 3:
There are 14 uses of the code 'config_admin_language' and zero uses of 'config_language_admin'. ( I had that backwards in my original post as to which was where).
There are 478 uses of the code config_language_id and 37 of config_language'.
The database key after the upgrade to version 4 is 'config_admin_language'.
In version 4:
There are 10 uses of the code 'config_admin_language' and 9 uses of 'config_language_admin'. (So config_language_admin has been *added*).
There are 355 uses of the code config_language_id. For example: admin/controller/checkout/confirm.php:300: $order_data['language_id'] = $this->config->get('config_language_id');
There appear to be about 400 uses of 'config_language' alone. Very hard to grep these instances as they may terminate with a comma, or apostrophe or close parens . For example: admin/catalog/controller/startup/startup.php:88: $code = $this->config->get('config_language');
The database key is config_language.
So we have MIXED USAGES in version 3 and carried forward into version 4 and MADE WORSE! Easy enough to grep the 9 config_language_admin errors and change those, and possibly not that horrendous to change the config_language_id entries, but that would require analysis of every point.
WHAT WORRIES ME is whether some other similar brain-fade error affects other variables. As noted, the error which results is quite obscure as the error results from trying to use a non-existent variable value.
WHAT IS REALLY WEIRD is that this code seems to run for many people. It threw warnings for me, on attempted login and died immediately thereafter on attempting localisation instantiation.
Replace 4.0.1.1 with 4.0.2.0 because has less bugs, but better wait for 4.0.x.x to be ready for production....
https://github.com/opencart/opencart
https://github.com/opencart/opencart
Upgrade Service | OC 2.3.0.2 PHP 8 | My Custom OC 3.0.3.8 | Buy me a beer
I find no instances of 'config_admin_language' in 4.0.1.1, other than the upgrade script. Which suggests you are not using all the latest files. You would still need to fix the upgrader in 4.0.1.1 for that to work.
Sadly these issues are often common in new OpenCart versions.
Sadly these issues are often common in new OpenCart versions.
I am using a download of 4.0.11 from January 4, 2023.
config_admin_language appears in upgrade_4.php.
[root@tor1 keep]# cd opencart/
[root@tor1 opencart]# ls
CHANGELOG.md INSTALL.md LICENSE.md opencart-4.0.1.1.zip README.md UPGRADE.md upload
[root@tor1 opencart]# cd upload/
[root@tor1 upload]# grep -RHn 'config_admin_language' *
install/controller/upgrade/upgrade_4.php:78: if (isset($settings['config_admin_language'])) {
install/controller/upgrade/upgrade_4.php:81: 'value' => $settings['config_admin_language'],
BUT the files to be uploaded, contained in upload/ have 9 instances of config_language_admin
[root@tor1 upload]# grep -RHn 'config_language_admin' *
admin/view/template/setting/setting.twig:211: <select name="config_language_admin" id="input-language-admin" class="form-select">
admin/view/template/setting/setting.twig:213: <option value="{{ language.code }}"{% if language.code == config_language_admin %} selected{% endif %}>{{ language.name }}</option>
admin/model/localisation/language.php:208: $this->db->query("UPDATE `" . DB_PREFIX . "setting` SET `value` = '" . $this->db->escape((string)$data['code']) . "' WHERE `key` = 'config_language_admin' AND `value` = '" . $this->db->escape($language_query->row['code']) . "'");
admin/controller/localisation/language.php:323: if ($this->config->get('config_language_admin') == $language_info['code']) {
admin/controller/setting/setting.php:132: $data['config_language_admin'] = $this->config->get('config_language_admin');
admin/controller/startup/language.php:14: $code = $this->config->get('config_language_admin');
admin/controller/startup/language.php:22: $this->config->set('config_language_admin', $code);
install/opencart.sql
(0, 'config', 'config_language_admin', 'en-gb', 0),
install/controller/upgrade/upgrade_4.php:234: $this->db->query("UPDATE `" . DB_PREFIX . "setting` SET `value` = 'en-gb' WHERE `key` = 'config_language_admin' AND `value` = 'en'");
And 203 instances of config_language_id:
[root@tor1 upload]# grep -RHn 'config_language_id' * | wc -l
203
SOOOOOO, what to do? change all the 'wrong' instances in upload and try to upgrade again? (Hate to think what this might do the the database... but I *think*, not much... (fingers crossed!)).
And is there any assurance that there are no OTHER errors?
WHAT TO DO?
config_admin_language appears in upgrade_4.php.
[root@tor1 keep]# cd opencart/
[root@tor1 opencart]# ls
CHANGELOG.md INSTALL.md LICENSE.md opencart-4.0.1.1.zip README.md UPGRADE.md upload
[root@tor1 opencart]# cd upload/
[root@tor1 upload]# grep -RHn 'config_admin_language' *
install/controller/upgrade/upgrade_4.php:78: if (isset($settings['config_admin_language'])) {
install/controller/upgrade/upgrade_4.php:81: 'value' => $settings['config_admin_language'],
BUT the files to be uploaded, contained in upload/ have 9 instances of config_language_admin
[root@tor1 upload]# grep -RHn 'config_language_admin' *
admin/view/template/setting/setting.twig:211: <select name="config_language_admin" id="input-language-admin" class="form-select">
admin/view/template/setting/setting.twig:213: <option value="{{ language.code }}"{% if language.code == config_language_admin %} selected{% endif %}>{{ language.name }}</option>
admin/model/localisation/language.php:208: $this->db->query("UPDATE `" . DB_PREFIX . "setting` SET `value` = '" . $this->db->escape((string)$data['code']) . "' WHERE `key` = 'config_language_admin' AND `value` = '" . $this->db->escape($language_query->row['code']) . "'");
admin/controller/localisation/language.php:323: if ($this->config->get('config_language_admin') == $language_info['code']) {
admin/controller/setting/setting.php:132: $data['config_language_admin'] = $this->config->get('config_language_admin');
admin/controller/startup/language.php:14: $code = $this->config->get('config_language_admin');
admin/controller/startup/language.php:22: $this->config->set('config_language_admin', $code);
install/opencart.sql
(0, 'config', 'config_language_admin', 'en-gb', 0),install/controller/upgrade/upgrade_4.php:234: $this->db->query("UPDATE `" . DB_PREFIX . "setting` SET `value` = 'en-gb' WHERE `key` = 'config_language_admin' AND `value` = 'en'");
And 203 instances of config_language_id:
[root@tor1 upload]# grep -RHn 'config_language_id' * | wc -l
203
SOOOOOO, what to do? change all the 'wrong' instances in upload and try to upgrade again? (Hate to think what this might do the the database... but I *think*, not much... (fingers crossed!)).
And is there any assurance that there are no OTHER errors?
WHAT TO DO?
There is no 4.0.1.1 from january 4....
4.0.1.1 was released on August 27, 2022.
And run your_site/install for upgrade...or from admin if is 4 to 4.
Upgrade Service | OC 2.3.0.2 PHP 8 | My Custom OC 3.0.3.8 | Buy me a beer
The setting was config_admin_language in OpenCart 3. It was deliberately renamed to config_language_admin in 4.0.1.1. The issue is that the upgrade script failed to rename the setting in the database.rgnewbury wrote: ↑Sat Jan 07, 2023 11:21 amSOOOOOO, what to do? change all the 'wrong' instances in upload and try to upgrade again? (Hate to think what this might do the the database... but I *think*, not much... (fingers crossed!)).
And is there any assurance that there are no OTHER errors?
WHAT TO DO?
As I have already stated.
viewtopic.php?t=230379#p851968
Anyone installing 4.0.1.1 from scratch would not see the issue as the config_language_admin setting would be added to the database on istallition.
The quickest fix would be to rename the setting in your database (backup up first).
Code: Select all
UPDATE `oc_setting` SET `key` = 'config_language_admin' WHERE `key` LIKE 'config_admin_language'Firstly, to xxxvirusxxx, I used version 4.0.1.1 DOWNLOADED on January 4th, so 'old files' NOT
Secondly, it is not just that the upgrade failed to change the database, there are TWO (2) different versions of the key *in the code*.
Should I change all 10 instances of config_admin_language to config_language_admin?
Should I change all 355 instances of config_language_id to config_language?
That would no be too difficult and I can do that. No-one has ventured to guess whether it will work..
AND no-one has answered whether there are any OTHER hardcoded mistakes ready to blow things up.
"Better still stick to 3.0.3.8 maintenance as 4.0.1.1 is still quite buggy." Well that is true!
But reverting to using my version 3 instance is a no-go. Version 3 works well on my desktop instance, using http. But using https on the web-host site is broken. I cannot log in to admin AND THERE ARE NO ERROR MESSAGES. None. Anywhere. I log in and the login page re-writes. Using bad credentials returns the expected error message and re-writes the page. Otherwise nothing. See:
viewtopic.php?t=229814
So the web-hosted site is still on 3.x.maintenance and I cannot log in. The main page is messed up, but I cannot apply the default theme because ... no admin.
The desktop on Version 4 shows part of the main page, including 2 screens of a banner set, and an error message: Warning: Undefined array key "directory" in /misc/html/mandamus.ca/catalog/model/localisation/language.php on line 24. When I attempt to log in to admin, it accepts the user and password and returns HTTP Error 500; localhost is currently unable to handle this request. I suspect that the language.php error is because the model folder has over a hundred instances of config_language_id in the code and the database is now config_language. (It is the config_admin_language which is wrong in the db.)
Anyone got any suggestions?
Secondly, it is not just that the upgrade failed to change the database, there are TWO (2) different versions of the key *in the code*.
Should I change all 10 instances of config_admin_language to config_language_admin?
Should I change all 355 instances of config_language_id to config_language?
That would no be too difficult and I can do that. No-one has ventured to guess whether it will work..
AND no-one has answered whether there are any OTHER hardcoded mistakes ready to blow things up.
"Better still stick to 3.0.3.8 maintenance as 4.0.1.1 is still quite buggy." Well that is true!
But reverting to using my version 3 instance is a no-go. Version 3 works well on my desktop instance, using http. But using https on the web-host site is broken. I cannot log in to admin AND THERE ARE NO ERROR MESSAGES. None. Anywhere. I log in and the login page re-writes. Using bad credentials returns the expected error message and re-writes the page. Otherwise nothing. See:
viewtopic.php?t=229814
So the web-hosted site is still on 3.x.maintenance and I cannot log in. The main page is messed up, but I cannot apply the default theme because ... no admin.
The desktop on Version 4 shows part of the main page, including 2 screens of a banner set, and an error message: Warning: Undefined array key "directory" in /misc/html/mandamus.ca/catalog/model/localisation/language.php on line 24. When I attempt to log in to admin, it accepts the user and password and returns HTTP Error 500; localhost is currently unable to handle this request. I suspect that the language.php error is because the model folder has over a hundred instances of config_language_id in the code and the database is now config_language. (It is the config_admin_language which is wrong in the db.)
Anyone got any suggestions?
I told you....better replace with 4.0.2.0, but you don't want to listen...
https://github.com/opencart/opencart
Also about config_language_admin should be changed only in database....not in the files...
Regarding no admin login on 3.x.x.maintenence there is a bug with Time Zone settings.
And yes, https work just fine....
LE. And fix redirection issue...
viewtopic.php?t=183503
https://github.com/opencart/opencart
Also about config_language_admin should be changed only in database....not in the files...
Regarding no admin login on 3.x.x.maintenence there is a bug with Time Zone settings.
And yes, https work just fine....
LE. And fix redirection issue...
viewtopic.php?t=183503
Upgrade Service | OC 2.3.0.2 PHP 8 | My Custom OC 3.0.3.8 | Buy me a beer
There IS no version 4.0.2 listed in github. Unless you mean the present 'master' repo branch. But you did not say that.
The code *cannot* work if it uses the wrong variable names to call the database.
FIX
I decided to bite that bullet, and changed all instances of config_admin_language in the code, to config_language_admin, and all 355 instances of config_language_id to config_language, so that both match the database.
I can now log-in to admin, but attempting to access system- -> settings from the dashboard fails immediately with:
TypeError: Unsupported operand types: string * int in ../<site>/admin/controller/setting/store.php on line 102
This is at: <site>/admin/index.php?route=setting/store&user_token=2a495c2e3c7bdcd2d889d44d32f32406
Progress....?
This error exists because of an error in upgrade_4.php. I have posted the actual bug as a separate post, with suggested corrective code.
FIX 2
Changing the value of 'config_pagination_admin' from 'en-GB' to '10' (to match the numeric value in config_pagination) fixes this particular problem.
I am marking this as SOLVED although it I am not out of the swamp yet. I can get in to the dashboard, but it seems I cannot, for example, actually apply the default theme, nor amend any of the Information pages. Attempting to amend the 'About Us' page for example creates a 'Warning... error' notice, and fails on attempted 'Save', kicking me out to the admin log-in. But progress!
The code *cannot* work if it uses the wrong variable names to call the database.
FIX
I decided to bite that bullet, and changed all instances of config_admin_language in the code, to config_language_admin, and all 355 instances of config_language_id to config_language, so that both match the database.
I can now log-in to admin, but attempting to access system- -> settings from the dashboard fails immediately with:
TypeError: Unsupported operand types: string * int in ../<site>/admin/controller/setting/store.php on line 102
This is at: <site>/admin/index.php?route=setting/store&user_token=2a495c2e3c7bdcd2d889d44d32f32406
Progress....?
This error exists because of an error in upgrade_4.php. I have posted the actual bug as a separate post, with suggested corrective code.
FIX 2
Changing the value of 'config_pagination_admin' from 'en-GB' to '10' (to match the numeric value in config_pagination) fixes this particular problem.
I am marking this as SOLVED although it I am not out of the swamp yet. I can get in to the dashboard, but it seems I cannot, for example, actually apply the default theme, nor amend any of the Information pages. Attempting to amend the 'About Us' page for example creates a 'Warning... error' notice, and fails on attempted 'Save', kicking me out to the admin log-in. But progress!
Better pay a developer....
Upgrade Service | OC 2.3.0.2 PHP 8 | My Custom OC 3.0.3.8 | Buy me a beer
Don't do that you will just create more problems for yourself.rgnewbury wrote: ↑Mon Jan 09, 2023 12:38 amThere IS no version 4.0.2 listed in github. Unless you mean the present 'master' repo branch. But you did not say that.
The code *cannot* work if it uses the wrong variable names to call the database.
FIX
I decided to bite that bullet, and changed all instances of config_admin_language in the code, to config_language_admin, and all 355 instances of config_language_id to config_language, so that both match the database.
I can now log-in to admin, but attempting to access system- -> settings from the dashboard fails immediately with:
TypeError: Unsupported operand types: string * int in ../<site>/admin/controller/setting/store.php on line 102
This is at: <site>/admin/index.php?route=setting/store&user_token=2a495c2e3c7bdcd2d889d44d32f32406
Progress....?
This error exists because of an error in upgrade_4.php. I have posted the actual bug as a separate post, with suggested corrective code.
FIX 2
Changing the value of 'config_pagination_admin' from 'en-GB' to '10' (to match the numeric value in config_pagination) fixes this particular problem.
I am marking this as SOLVED although it I am not out of the swamp yet. I can get in to the dashboard, but it seems I cannot, for example, actually apply the default theme, nor amend any of the Information pages. Attempting to amend the 'About Us' page for example creates a 'Warning... error' notice, and fails on attempted 'Save', kicking me out to the admin log-in. But progress!
config_language_id and config_language are two different settings. You can see in the code at the two links below.
https://github.com/opencart/opencart/bl ... hp#L20-L22
config_language_id should be an integer such as 1, which is the index in the language database table. config_language should be a string that is the language code for that language, such as 'en-gb'.
For the fourth time. There is a bug in the upgrade script.
Look at.
https://github.com/opencart/opencart/bl ... hp#L77-L84
Which shows.
Code: Select all
if (isset($settings['config_admin_language'])) {
$missing[] = [
'key' => 'config_pagination_admin',
'value' => $settings['config_admin_language'],
'code' => 'config',
'serialized' => 0
];
}The correct code should be.
Code: Select all
if (isset($settings['config_admin_language'])) {
$missing[] = [
'key' => 'config_language_admin',
'value' => $settings['config_admin_language'],
'code' => 'config',
'serialized' => 0
];
}You really need to get version 3 working on your web host first. Looking at the topic you linked to, it looked like a configuration issue. You will just be wasting your time upgrading to version 4 locally, because it still isn't going to work when you upload it to your web host.rgnewbury wrote: ↑Sun Jan 08, 2023 6:05 am"Better still stick to 3.0.3.8 maintenance as 4.0.1.1 is still quite buggy." Well that is true!
But reverting to using my version 3 instance is a no-go. Version 3 works well on my desktop instance, using http. But using https on the web-host site is broken. I cannot log in to admin AND THERE ARE NO ERROR MESSAGES. None. Anywhere. I log in and the login page re-writes. Using bad credentials returns the expected error message and re-writes the page. Otherwise nothing. See:
viewtopic.php?t=229814
So the web-hosted site is still on 3.x.maintenance and I cannot log in. The main page is messed up, but I cannot apply the default theme because ... no admin.
The desktop on Version 4 shows part of the main page, including 2 screens of a banner set, and an error message: Warning: Undefined array key "directory" in /misc/html/mandamus.ca/catalog/model/localisation/language.php on line 24. When I attempt to log in to admin, it accepts the user and password and returns HTTP Error 500; localhost is currently unable to handle this request. I suspect that the language.php error is because the model folder has over a hundred instances of config_language_id in the code and the database is now config_language. (It is the config_admin_language which is wrong in the db.)
Anyone got any suggestions?
ADD Creative. You are right about version 4! plus it uses a completely new structure for themes, extensions, etc. which makes no sense on first glance. I will be reverting to version 3.0.0.8 or 3... maintenance.
I now understand the problem with the code... that config_language_id and config_language are different items. The only problem I foresee with your code fixes is that config_pagination_admin is not created at all and appears to be necessary.
I went ahead and poked the sleeping bear and I may have completely munged the database! I should have a backup old enough to avoid the version 4 changes, but it now appears that even version 3.. maintenance requires some database poking. And some code pokes too I think. There are some odd things going on there!
Worst damn case, I can nuke it all from orbit and install to a brand new database. I now understand enough about how it all works, that it should not take anywhere near as much time as the first installation passes. (And now I probably *have* jinxed myself!). Thanks for your help in both of my horror-story posts.
I now understand the problem with the code... that config_language_id and config_language are different items. The only problem I foresee with your code fixes is that config_pagination_admin is not created at all and appears to be necessary.
I went ahead and poked the sleeping bear and I may have completely munged the database! I should have a backup old enough to avoid the version 4 changes, but it now appears that even version 3.. maintenance requires some database poking. And some code pokes too I think. There are some odd things going on there!
Worst damn case, I can nuke it all from orbit and install to a brand new database. I now understand enough about how it all works, that it should not take anywhere near as much time as the first installation passes. (And now I probably *have* jinxed myself!). Thanks for your help in both of my horror-story posts.
Probably not helpful to you now, but config_pagination_admin should be created from config_limit_admin by the code in the upgrader at the link below. I'm guessing the other bug caused it to be overwritten with the wrong value.
https://github.com/opencart/opencart/bl ... hp#L87-L94
Sadly going from one major version of OpenCart to another is often never simple. It's often recommended to export your product data, install a clean new version and then import the product data. A search on these forums may give you some tips.
https://github.com/opencart/opencart/bl ... hp#L87-L94
Sadly going from one major version of OpenCart to another is often never simple. It's often recommended to export your product data, install a clean new version and then import the product data. A search on these forums may give you some tips.
Who is online
Users browsing this forum: No registered users and 2 guests
