problem with upgrade from v151 to v153 - help please

DK_Scully:

The newest error message says:

[30-Oct-2014 14:32:13 America/Chicago] PHP Warning: require_once(/home/carnal1/public_html/zencart/../includes/classes/vendors/password_compat-master/lib/password.php): failed to open stream: No such file or directory in /home/carnal1/public_html/zencart/includes/classes/class.zcPassword.php on line 52

[30-Oct-2014 14:32:13 America/Chicago] PHP Fatal error: require_once(): Failed opening required '/home/carnal1/public_html/zencart/../includes/classes/vendors/password_compat-master/lib/password.php' (include_path='.:/opt/php54/lib/php') in /home/carnal1/public_html/zencart/includes/classes/class.zcPassword.php on line 52

I tried using the new login I created this morning, and it refused that one...the only one it would accept was the original one that I've been using all along.

When I have come across that (and I have) I think I have gone to zencart/includes/classes/class.zcPassword.php on line 52 and starting at that line (possibly having to work backwards a little) removed the ../ that precedes the includes folder portion. And then after upgrade, restored that. If you go the route of renaming the file, be sure it does not end with .php otherwise new errors will occur. Sorry I don't have access at the moment to files to tell you exactly where to make that edit.

I have the file open, but don't see anything about 'the includes folder portion.' I have no idea what I'm looking for.

DK_Scully:

I have the file open, but don't see anything about 'the includes folder portion.' I have no idea what I'm looking for.

Line 52 reads something like: require_once (DIR_FS_CATALOG . DIR_WS_CLASSES . 'vendor. Etc... Etc...

Because I have only seen this issue in installation, I haven't gone to figure out why it happens yet. But. In your case, if you replace:

DIR_FS_CATALOG . DIR_WS_CLASSES

With:

'/home/carnal1/public_html/zencart/includes/classes/'

That line should successfully complete. Again, be prepared to restore that file after completing the upgrade.

public function __construct($phpVersion = PHP_VERSION)
{
if (version_compare($phpVersion, '5.3.7', '<')) {
require_once (DIR_FS_CATALOG . DIR_WS_FUNCTIONS . 'password_compat.php');
} elseif (version_compare($phpVersion, '5.5.0', '<')) {
require_once (DIR_FS_CATALOG . DIR_WS_CLASSES . '/home/carnal1/public_html/zencart/includes/classes/');

No, it didn't help. Still white screen of death.

I replaced the wrong thing, didn't I?

Okay, I got the right part changed this time, and uploaded it, and ran the zc_install. This time...gasp...it actually worked! So I restored the original file, and renamed zc_install to something different, just in case I need it again later...oh, I hope not!!!

BUT..............................

Now there's an error message at the top of the page that says:

NOTICE: The website is currently Down For Maintenance to the public

It most certainly is not...so how do I get THAT to go away??

Never mind...I found it under Configuration / Website Maintenance.

Do I even want to know how that switch got set to the wrong thing? What worries me is, what else has gotten screwed up through this whole process. :-/

Thank you, everyone, for helping me get this fixed!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

On a side note, both of those constants are what are "defined" at the beginning of the revised general.php file. It would seem that the one that uses the zen function is resulting in the addition of two periods. At least when run in a subdirectory.. (I think this is the case and would have to test/prove that out to see), and if so, then perhapsbefore declaring the define, the string should be checked for the /.. Appended and evaluate whether that extra path information is essential for other portions of the install leading up to the above line 52... If that is essential there, but the DIR_WS_CLASSES could besomething different then perhaps itneeds to have the cart's subdirectory prepended to it... This also would require evaluation of impact. Further it assumes that the includes/configure.php is/was properly constructed, so alsoan eval there as well. Or lastly could be that the updated patch described in thethread referenced on pageone of this thread has already addressed this... :)

DK_Scully:

Never mind...I found it under Configuration / Website Maintenance.

Do I even want to know how that switch got set to the wrong thing? What worries me is, what else has gotten screwed up through this whole process. :-/

So, in the upgrade process, the cart is put into maintenance mode.(The condition you found it). That way you can test the functionality without others seeing the "problems" that might exist. Overall should have no other major changes, but two things have happened, the php version has been upgraded, and the database is now being accessed differently. The biggest effect would be on the other plugins you have/may have if they don't support ZC 1.5.3 and the new database access methods. But if they were written using ZC functions, all should be good. :) (famous last words) :)

DK_Scully:

public function __construct($phpVersion = PHP_VERSION)
{
if (version_compare($phpVersion, '5.3.7', '<')) {
require_once (DIR_FS_CATALOG . DIR_WS_FUNCTIONS . 'password_compat.php');
} elseif (version_compare($phpVersion, '5.5.0', '<')) {
require_once (DIR_FS_CATALOG . DIR_WS_CLASSES . '/home/carnal1/public_html/zencart/includes/classes/');

No, it didn't help. Still white screen of death.

I replaced the wrong thing, didn't I?

In working to close the loop on some of the remaining questions in this thread, yes the wrong part was replaced and I would say that the solution was to replace only the first two constants not the period and quoted text that followed it. :)

DK_Scully:

I tried using the new login I created this morning, and it refused that one...the only one it would accept was the original one that I've been using all along.

I haven't looked at the code, but my guess and one reason I suggested earlier not to try to login to the admin with this username and password is that in the concept of security, the new user was not considered a verified user as the script used to create that user establishes the user to require changing to password upon login. So, during the upgrade process the upgrader is not offered the opportunity to update the password andi believe something in the validation process prohibits the action(s) from progressing. Had this been the sole reason to not be able to progress, I had a suggestion on how to populate the database to recognize that the password (temporary as it should be) would not be considered expired or needing to be updated. But that is no longer the situation as it is/was discovered that basically the PHP version was too low to support the process... There was an additional issue, but that is described above and may have a more permanent solution in the near future.

Btw DK_Scully, remember to delete that newly created user (Admin/admin) from the list of users.

Just when you thought it was safe to enter the water....................

Another error appears to have cropped up through this whole upgrade process. I don't have any details yet, but all customers who have tried to order books since we finished this upgrade have reported 403 errors when they tried to download their books. I've asked for specifics from each of them, but haven't heard back yet. I can say, however, that ZenCart's Customers / Orders screen shows that they did download them. Apparently nothing came through on their end.

Does anyone have any suggestions on this? For the moment we're manually e-mailing all purchases to them...but obviously we can't continue doing that indefinitely.

Thanks!!

What is the extension to the downloadable material and is it recognized in the applicable .htaccess? There are some file types already permitted, but if not one of those (and it is case sensitive), then a 403 is likely to occur andthe receipt of the content not made.

It would be .azw3, .epub, .mobi, .txt, .fb2, .htmlz, etc. All the ebook formats.

There are several .htaccess files...which one should I be looking for?

The .htaccess file should be in the same folder as your downloadable files. See the second post of this thread for an example adding another allowed file extension (in the public downloads folder - but same change applies to the download folder used for purchased files).

That would be the one in my /download/ folder. Fortunately I had a copy of the original on my PC...I always do file-by-file backups (in addition to a cPanel full backup) before I risk changing anything, so it had all the extra formats properly listed. I re-uploaded that to my /download/ folder.

Thanks very much for the quick fix, guys!!

That didn't help...or perhaps didn't help enough. Should the updated list of formats be uploaded in any other locations?

DK_Scully:

That didn't help...or perhaps didn't help enough. Should the updated list of formats be uploaded in any other locations?

Before testing, was the cache of the browser cleared (or an alternte browser tried), and was it applied to both the download and pub folders or just the download? What are the settings for configuration->attribute settings related to downloads? What test was performed to indicate that "that didn't work"?

The test performed was that the customer tried re-downloading his books after I told him the problem was fixed. I did the same on my end, using the backdoor script to access his account. I don't know whether he cleared his cache or not, but I did. And in his case and mine, the downloads failed.

Per lhungil's suggestion, I uploaded the original enhanced file to the /download/ folder. He (she?) didn't mention any other place I should upload it. I gather, from your question, that it should also be re-uploaded to the /pub/ folder. Doing that now.