Admin redirect to install/index.php

Hi

I have just updated my version of OC to v1.5.6 and now cannot access the admin.

If I type http://phoenixyarns.co.uk/admin/ it's automatically redirecting to http://phoenixyarns.co.uk/install/index.php

Can you please advise, I'm not massively familiar with OC so any help woudl really be appreciated.

I have a Themeforest template installed and all was working fine until the software update

Happy to provide FTP access

Thanks
Taryn

Well, you may be fortunate enough to have been visited by a benign hacker who with mirth kindly inserted a call in an undeleted /install/ to go to the store -- or unfortunate enough to have a bungled theme. The store showing with the /install/ URL seems to be working as the store, but with the wrong URL in the address bar. You need to look at your tree. IF /install/ is there, then for the moment RENAME NOT DELETE it. See what the index.php in /install/ says inside it (ascii pure text editor). Then see what it does. In generated source I am seeing as /install/index.php seems normal for the proper /index.php (no injection at bottom, either) but for one red flag -- catalog/view/theme/forest_classyshop/ -- which seems to mean that your theme might be classydud. Review the theme's installation instructions, maybe YOU blew it. If not there is a way out. Ask the theme author. Delete your /install/ directory.

Hi

Thanks for coming back to me, some of that made sense, not a lot though!!

I have had the theme re-installed today by their helpdesk so I know it's not down to my installation (which to be fair I'd thought it probably was!!)

So can you tell me in very basic terms what I need to be looking for? I tried doing a re0nstall of the admin files and added the install but that didn't seem to help.. Sorry

Taryn

PM the ftp . . .

UPSHOT.-- While /admin/ would not fire after the upgrade, which itself may have been abortive in its script, /admin/ could NOT fire, because there WAS NO /admin/config.php, and THAT may have owed to abortive script attributable to infection of and access from /download/. Foredoomed, no .htaccess was active (was still .htaccess.txt). Themes default/ and forest_classyshop/ apparently okay. Improper /vqmod/ files; replaced, reinstalled. Sanitized, repaired.

UPSHOT.-- BEFORE executing an upgrade, EMPTY /download/, set permissions to dir 755, files 644. WHEN UPGRADED DELETE /install/ or at least disarm it with an unguessable name (...1 is easy to guess).

General status.-- Done. Permissions properly 755/644, no .dir/, themes default/ and forest_classyshop/ appear normally populated (cursory check, pending the rest).

(1) There being no /admin/config.php to support it, /admin/index.php could not fire.

(2) Infected, two files in /download/, both executable, session-setting mime attack. Both deleted.

2013 apr 07, 6 kb, first 13 lines compiled, then next 16 lines pure ascii php:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.jpg.fd58050cbf9fcd468bdd5476d6f83e19

2013 apr 09, 1 kb, pure ascii php 16 lines following those 13 above (same as the then 16 above):
route.php.jpg.5c2eca98121d6a0c1379659129165e34

For overview of how such extensions become executable see:
http://forum.opencart.com/viewtopic.php ... 60#p431729
http://forum.opencart.com/viewtopic.php ... 60#p440953
. . . along with the entire 4 pp. of that thread.

(3) Foredoomed, no .htaccess was active (was still .htaccess.txt). Now active.

(4) While /install/ was renamed /install1/ in address bar it still displayed as /install/ until the infection was deleted and /install1/ was further renamed to be unaddressable via http. Addressing /install/ then gave 404.

(5) Both OC system log and primary php logs available. Consistent complaint, hundreds fold:

[22-Oct-2013 01:07:50] PHP Warning: PHP Startup: Suhosin Extension does not officially support PHP 5.2 and below anymore, because it is discontinued. Use it at your own risk. in Unknown on line 0

That is a php.exe .so extension, specifically a bona fide patch on the server itself (php installation), from hardenedphp project. That was simply a server error, having nothing to do with OC. To be reported to support, apparently upgraded without following, um, instructions (RTFB, sub RTFM principles).

it appears that php.exe was upgraded but extensions and the large master php.ini were not properly reviewed. If you see errors relating to suhosin.so or Suhosin Extension merely tell support the server's own php.exe is not properly upgraded or installed with that extension operative or even present.

(6) VQMod missing its pathReplaces.php and its own .htaccess, file size of its vqmod.php wrong. Replaced with current vqmod, reinstalled vqmod (took; natch). All vqmod and system cache files flushed. Extensions disable_download.xml (MarketInSG, http://forum.opencart.com/viewtopic.php ... 20#p403255, download http://forum.opencart.com/download/file.php?id=16828), backup_improved.xml (rph, http://forum.opencart.com/viewtopic.php ... 62#p401314, download http://forum.opencart.com/download/file.php?id=16761) uploaded. Others' uploads pending.

(7) Originally,
checkout goes to http: //phoenixyarns .co.uk/index.php?route=checkout/checkout OKAY DID AND DOES
account goes to http: //phoenixyarns .co.uk/index.php?route=account/register OKAY DID AND DOES
home goes to http: //phoenixyarns .co.uk/index.php?route=common/home OKAY DID AND DOES
admin and domain both go to http: //phoenixyarns .co.uk/ OKAY DID NOT THEN DID AND NOW DOES
BUT EVEN WITH /install/ renamed yet undeleted
/install/ went to http: //phoenixyarns .co.uk/install/ NOT RIGHT, NOW OKAY GOES TO 404
installer .php went to http: //phoenixyarns .co.uk/install/index.php NOT RIGHT, NOW OKAY GOES TO 404

[EDITS PENDING.]

With the immediately foregoing problem resolved (somewhat), there are two further wrinkles.

(1) The main reason, apparently, that admin tries to fire but throws all-white nullities is that the installer failed:

[21-Oct-2013 16:22:16] PHP Notice: Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AFTER `price`' at line 1<br />Error No: 1064<br />ALTER TABLE `oc_profile` CHANGE `frequency` `frequency` ENUM AFTER `price` in [path]/phoenixyarns.co.uk/system/database/mysql.php on line 50

That jibes with "spontaneous" appearance of a newly timestamped incomplete set of files outside admin. (I later replaced the admin tree itself with a fresh known good set of 1.5.6.0 files, and admin still would not fire.)

There is a fix for the 1064 error thrown by the script (start with overview http://forum.opencart.com/viewtopic.php ... 77#p434624 and then go to 1st and 6th above it). (The replacement script is now sitting on the server, RTR but protected; NOT to be run before database is backed up anew in phpMyAdmin).

(2) There is likewise an ongoing cumulatively heavily logged problem with the theme:

2013-10-22 18:03:26 - PHP Notice: Undefined variable: filter_name in [path]/phoenixyarns.co.uk/catalog/view/theme/forest_classyshop/template/common/header.tpl on line 112

That has been going on for a very long time. Ask the author or get rid of the theme.

Scarcely a finale, we have here also a case study in why 1.5.6.0 (and essentially any other version of OC) may just plain not work owing to nothing more than the server. OC itself is server sensitive -- not surprisingly, because it is fairly complex software in the first place. That OC works very well in the wide range of server environments where it is installed is actually a trifle remarkable -- outright remarkable. In this instance phpinfo.php shows 5.2.17 but php.exe throws even 5.2 errors over even 5.2 .so files under the server's sole control on its side of the inner sanctum, underlying all accounts.

In this instance phpinfo.php also shows that the two OC php,ini files (accordingly silenced now) are completely ignored by this server, whose own php.ini controls everything. For context,

On php.exe and php.ini:
http://forum.opencart.com/viewtopic.php ... ni#p426535
On master php.ini:
http://forum.opencart.com/viewtopic.php ... 80#p444711
http://forum.opencart.com/viewtopic.php ... r+#p445305

(1) A separate underlying problem is the server's own php installation. You have essentially two solutions. The better one is to change hosts outright, since unless the server's own inner sanctum was hacked, the configuration should never have happened even if it was "outsourced" to certain areas of the world. The other one is to tell support to mop up whatever was not done right in the php.exe subsystem of the server itself.

In addition to the suhosin.so problem (above), there are several others in the logs. These three gems spring from the other side of the wall, not from OC or anything about OC itself. Two of the error logs are cumulatively enormous, now archived and pruned, because every iteration of either index.php throws server-related errors. These are a few:

[22-Oct-2013 07:37:44] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/timezonedb.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/timezonedb.so: cannot open shared object file: No such file or directory in Unknown on line 0
[22-Oct-2013 07:37:44] PHP Warning: PHP Startup: Suhosin Extension does not officially support PHP 5.2 and below anymore, because it is discontinued. Use it at your own risk. in Unknown on line 0
[22-Oct-2013 17:49:22] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/timezonedb.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/timezonedb.so: cannot open shared object file: No such file or directory in Unknown on line 0

Those are server paths, not yours.

(2) Fortunately, you have three kinds of logs going on at once. The /vqmod/logs/ are silent. The /system/logs/ primary log is not silent. The others are primary php logs kept by php itself, in each of several directories (where .php files fire). One of those logs is only 4.6 mb but runs through 18,549 lines from "[20-Aug-2012 10:35:58] PHP Fatal error:" through "[22-Oct-2013 17:56:36] PHP Warning: PHP Startup: Suhosin Extension does not officially support PHP 5.2 and below anymore, because it is discontinued. Use it at your own risk. in Unknown on line 0". In that one are such gems as these, all involving .so (modules of the server's own mastery):

[12-Sep-2013 00:14:04] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/gdchart.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/gdchart.so: cannot open shared object file: No such file or directory in Unknown on line 0

right on through

[22-Oct-2013 17:56:36] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/timezonedb.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/timezonedb.so: cannot open shared object file: No such file or directory in Unknown on line 0

One wonders where they got . . . never mind. Whee. Lewis Carroll, Mark Twain, George Carlin, and Monty Python together in one room at once would probably never have come up with some servers.

The initial problem and trail of wonderfulness seem resolved. The storefront and the admin have both fired properly after further changes, one of which worked. The host is an abomination. Moving to a real host is recommended.

(A) The server has several idiosyncrasies:
1/ Magic quotes cannot be turned off in either .htaccess or php.ini and apparently not in control panel or support, either.
2/ The server ignores php.ini as repeatedly checked via nested phpinfo.php change by change.
3/ The server throws 500 if corrections to php.ini settings are made in .htaccess instead.

(B) OC fired but admin did not fire with magic quotes on and a nominally proper .htaccess either active OR omitted, in conjunction with correct config.php; php.ini values could not be changed; slipping .htaccess into /install/ for the sake of installation or upgrade in either root or a new directory was to no avail. The curious aspect was that .htaccess could be normal or not there, and still storefront fired but admin did not fire. Whether the database might be screwy remained uncertain but a backup was on hand for the sake of forcibly reinstalling or upgrading OC.

(C) Bingo, changing in .htaccess (each one, with two OC copies in effect) this
Options +FollowSymlinks
to this
# Options +FollowSymlinks
enabled both storefront and admin to fire, and (with appropriate config.php in place) enabled both the install and upgrade alternatives in to fire, in both root/install/ and the new directory/install/ copies of OC. The database was not notably screwy.

(D) There was then no further need to forcibly reinstall or upgrade the root copy of OC, and the directory copy of OC was easily installed as well as upgraded. The two OC copies currently have different prefixes. There results a working OC and a working reserve OC with different prefixes in one database.

(E) The sole errors thrown afterward sprang from search filters in the header.tpl in the theme, into system but not vqmod logs. The default theme threw none into empty system logs and vqmod logs.