Cannot reset downloads after migration to new VPS

Hello,

Hostgator upgraded our VPS from an older package to a new VPS package. I am not sure, but I suspect they migrated from one VPS container (Parallels) to a new container.

Everything is working great on our Zen-Cart site so far until this morning. The following is happening:

1. We cannot reset downloads on orders that occurred before the VPS change. When we click on the yellow button, the screen refreshes, we get a notice on the top of the page saying it was reset, but the download still is still expired. We tried clearing the cache, using different browsers, etc.
2. Orders that took place before the VPS change, and are not yet expired, are not working. When the customer clicks on the download link they get a blank page.

Newly placed orders (after the VPS change) can be downloaded by customers, and we can reset those downloads. So the problem appears to be all of our orders (thousands of them) that happened before the VPS move.... yikes!

We are running ZC 1.5.1.

Any help is much appreciated as we are in crisis mode!!:shocking:

Thanks,
Bryan

Please provide the information requested in "Posting Tips" at the top when you reply

What version of Zen Cart are you using? 1.5.1
Has your site been upgraded? When? From what version(s)? VPS container upgraded but not ZC.
If you've upgraded, HOW did you upgrade? (official upgrade procedure or an automated script from your hosting company?) N/A
What plugins/addons have you installed? When? If your problems are payment-related, what payment module(s) are you using? If it's shipping-related, which shipping module(s) are you using? Testimonials, Ultimate SEO, MailBeez, Wishlists, CEON URI, Google Analytics, Sitemap, Pinterest Pinit, Google Merchant Center, RSS Feed, Zen Lightbox, currency converter, Image Handler 4
If your problems are language-pack related (non-English), have you checked that all the language files are loaded and correct? N/A
HOW did you install Zen Cart? (upload via FTP and run zc_install, or a one-click install from your hosting company? (one-click installs might mean you don't have enough information about your site/server to make customizations easily)) Unknown, as programmer did this.
What version of PHP and MySQL is your server using? (See Admin->Tools->Server Info) PHP 5.3.23, MySQL 5.1.73-cll
WHEN did the problem "start"? How does that compare with other events of your hosting company, changes you've made to your site files/addons, or your admin settings, etc? After Hostgator moved us from an old VPN package to a new VPS package
Please post the contents of related "debug logs" generated by Zen Cart (wrap the content in ```
and

If this is your first store, have you tested all aspects of transactions before going live? Yes, site has been working for 5 years.
In what ways is your site customized or different from a brand new uncustomized install? Unknown
Please post your site URL* so we can take a look at it. This is especially important if you're encountering display/layout problems, so the problem can be seen directly. http://dollargraphicsdepot.com
If you're encountering problems that could be related to your server or hosting company, include the name of your hosting company (not their URL). HostGator
HAVE YOU LOOKED IN THE FAQ AREA for answers to your question? (ie: a search for your error message or what you want to edit/change, etc) Yes
Have you searched the FORUM for your error message or for answers to the question you're asking? Yes, found one article back in 2010 that did not have a final solution.

Ultimate SEO, CEON URI
Probably not both - which one??
MySQL 5.1.73-cll
This version is old but may or may not be causing issues
When the customer clicks on the download link they get a blank page.
https://www.zen-cart.com/content.php?124-i-am-getting-a-blank-page-%28or-blank-part-of-a-page%29
Do not know how to generate debug logs
ZenCart generates them for you - they will be in your /cache or /logs folder

Both mods are installed, but I believe Ultimate SEO is the one running.

I looked at the link (thanks for sending), but the download files themselves are fine. We tested and found that downloads fail on customer orders placed before the VPS upgrade, and those same downloads work if an order was placed after the VPS upgrade. We also cannot reset download links on orders before the VPS upgrade, but can reset download links on orders after the VPS upgrade.

Debug logs:

MailChimp: All errors relate to email address already being subscribed so not relevant.

RSS Feed: Over 3,000 files going back since when programmer setup new site (2013). We knew it was having issues and has been happening for years before the VPS upgrade.

Sorry, I wanted to clarify on the logs a bit more. In public_html I did not find a /logs folder, but I did find a /cache folder which is where the logs I mentioned in the previous post were located.

The only other files located in the /cache folder were .htaccess and index.php. No other files present.

Get rid of all those old debug files
Test a download - or a reset then see if there are any new debug files generated

Also, if there is no logs directory then 1) the installation/upgrade was done wrong/benefit of separating the cache and logs directory not realized, 2) the directory should be created after 3) review of the includes/configure.php and admin/includes/configure.php files to see what is set for DIR_FS_LOGS...

kobra:

Get rid of all those old debug files
Test a download - or a reset then see if there are any new debug files generated

Debug files removed yesterday when I discovered them. Only files there before and after resetting download are:

1. .htaccess
2. mailchimp.log
3. index.php
   4-6) rssfeed logs

mc12345678:

Also, if there is no logs directory then 1) the installation/upgrade was done wrong/benefit of separating the cache and logs directory not realized, 2) the directory should be created after 3) review of the includes/configure.php and admin/includes/configure.php files to see what is set for DIR_FS_LOGS...

Thanks. I looked at both files and they both reference /public_html/logs which does not exist. I created a /logs folder and it was assigned permissions of 755 automatically.

After creating the /logs folder it immediately started dumping log files in the directory. 32 in a space of a minute.

[04-Oct-2015 09:58:36 America/Denver] PHP Warning:  htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: charset `CHARSET' not supported, assuming iso-8859-1 in /home/dollarme/public_html/includes/classes/seo.url.php on line 184

[04-Oct-2015 10:01:53 America/Denver] PHP Warning:  htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: charset `CHARSET' not supported, assuming iso-8859-1 in /home/dollarme/public_html/includes/classes/seo.url.php on line 1300
[04-Oct-2015 10:01:53 America/Denver] PHP Warning:  htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: charset `CHARSET' not supported, assuming iso-8859-1 in /home/dollarme/public_html/includes/classes/seo.url.php on line 184
[04-Oct-2015 10:01:53 America/Denver] PHP Warning:  htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: charset `CHARSET' not supported, assuming iso-8859-1 in /home/dollarme/public_html/includes/classes/seo.url.php on line 184

So, it appears that our programmer decided the "solution" was to remove the folder to prevent all of the error logs from being generated...

bowerstech:

After creating the /logs folder it immediately started dumping log files in the directory. 32 in a space of a minute.

[04-Oct-2015 09:58:36 America/Denver] PHP Warning: htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: charset `CHARSET' not supported, assuming iso-8859-1 in /home/dollarme/public_html/includes/classes/seo.url.php on line 184

> 
> ```
[04-Oct-2015 10:01:53 America/Denver] PHP Warning:  htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: charset `CHARSET' not supported, assuming iso-8859-1 in /home/dollarme/public_html/includes/classes/seo.url.php on line 1300
[04-Oct-2015 10:01:53 America/Denver] PHP Warning:  htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: charset `CHARSET' not supported, assuming iso-8859-1 in /home/dollarme/public_html/includes/classes/seo.url.php on line 184
[04-Oct-2015 10:01:53 America/Denver] PHP Warning:  htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: charset `CHARSET' not supported, assuming iso-8859-1 in /home/dollarme/public_html/includes/classes/seo.url.php on line 184

So, it appears that our programmer decided the "solution" was to remove the folder to prevent all of the error logs from being generated...

If the uri rewriter is Ultmate SEO URis, supported by lhungil, then I would 1) verify up-to-date, and 2) seek some assistance on the forum for that mod. No such/similar issue occurs with CEON uri, but there are noticeable differences between the two.

We tested resetting a download again. I downloaded all 8 of the debug files but they all referenced the errors listed above relation to SEO and didn't mention anything relating to the problem we have been discussing.

So, while we do have a SEO error, is it safe to assume that is not the source of this problem? We can/will address the SEO problem, but our immediate issue is that we can no longer reset any downloads from before the VPS migration. All downloads on orders after the VPS migration are working fine. Any thoughts on that?

Is there some sort of token/session/hash that needs to be reset when you move from one server to another? That's essentially what happened when Hostgator moved us from an old VPS container to a new VPS container.

Thanks!

bowerstech:

We tested resetting a download again. I downloaded all 8 of the debug files but they all referenced the errors list above relation to SEO and didn't mention anything relating to the problem we have been discussing.

Just to be sure, also refreshed the ftp window, waited "a moment" between trying and checking?

Okay, just thought of something... If the old records are broke, but the new records work or vice versa, there is also information posted about errors and defaultng to iso-8859, this leads to question what is the language/collation being used/attempted against the database and as such could that possibly be the issue a change from old to new without changing the historical?

Suggest following the direction associated with the plugin db2utf8 which includes backup of it and checking of settings in other files.

bowerstech:

After creating the /logs folder it immediately started dumping log files in the directory. 32 in a space of a minute.

[04-Oct-2015 09:58:36 America/Denver] PHP Warning: htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: charset `CHARSET' not supported, assuming iso-8859-1 in /home/dollarme/public_html/includes/classes/seo.url.php on line 184

> ...
The filename "seo.url.php" indicates the site is running an older version of Ultimate (SEO) URLs (or another plugin for alternate URLs). Would strongly suggest upgrading (make sure to read the support thread for important bugfixes to apply after upgrading). At the time of writing the current version is  Ultimate URLs 2.215.

The "CHARSET" not supported indicates an issue with the installed language files. If this constant is missing, it can cause issues with not only Ultimate URLs, but also with core Zen Cart code. I'm not sure how far back Zen Cart introduced the constant "CHARSET", but I can for certain say it exists in Zen Cart 1.3.9h and newer (I no longer operate any test sites running anything older).

The constant "CHARSET" is used by Zen Cart to determine how to communicate character data between the Web Server (output by PHP) and the client's browser. "CHARSET" should be defined in "/includes/languages/name-of-language.php" and "/your_admin_folder/includes/languages/name-of-language.php".

The contents of "/includes/languages/name-of-language.php" can also be overridden by placing a copy at "/includes/languages/template-name/name-of-language.php". This is commonly done to alter the site's tagline or other common language components.


> **mc12345678:**
>
> ... Okay, just thought of something... If the old records are broke, but the new records work or vice versa ... what is the language/collation being used/attempted against the database and as such could that possibly be the issue a change from old to new ...
Good thought. Could be the new server has a different default collation and / or charset. If the import did not maintain these from the old version (depends on how the database was exported / transferred)...

Another possibility is PHP on the new server defaulting to a different character set compared to the old server. And because your installation is missing the "CHARSET" define, Zen Cart is using the PHP default... Which could be problematic...


**Check Download Settings:**
Doubt these are the issue, but just wanted to ask to be sure.

Are the downloads using the same locations on the new server? Are DIR_FS_DOWNLOAD and DIR_FS_DOWNLOAD_PUBLIC in "configure.php" correct for the new server? Have you verified everything is configured as outlined in [Important Facts and Permissions for Downloads](https://www.zen-cart.com/content.php?113#post_message_395633)?


**Check Database Collation:**
You can check the collation in the database on the products_download table (in particular the orders_products_filename field). What is the collation (and if you still have access to the old server is it the same)? What is the setting for "DB_CHARSET" (communication between PHP and the Database Server for transferring character data) in your "/includes/configure.php" and "/your_admin_folder/includes/configure.php"?

Most modern database servers support "utf8" (DB_CHARSET) and most modern browsers support "UTF-8" (CHARSET). UTF-8 supports the majority of written languages around the world, so is often used to provide the widest compatibility. Different CHARSETs can be used by different languages as needed support cases where the language is not supported by UTF-8.

Check out [Should I convert my store to UTF-8?](https://www.zen-cart.com/content.php?313-should-i-convert-my-store-from-iso-8859-1-to-utf8)

You can also see if there is a difference in the data stored in the products_download table from the working versus not working orders.


**Check and Fix CHARSET:**
I would strongly recommend fixing your language files so they correctly define "CHARSET" (and stop the log files from piling up). 

For the "English" language and a template of "classic", the store (customer facing) files to check would be "/includes/languages/english.php" and "/includes/languages/classic/english.php".

Compare against the a clean copy from the Zen Cart 1.5.1 distribution zip. If the store is using a different language, you may need to upgrade to a newer "Language Pack" (or manually add the CHARSET define to both the store and admin language files).


**Check all Files:**
If the constant "CHARSET" is missing (as the error you posted indicates), I wonder what else may be missing from core Zen Cart files (or modified)... You indicated the store is running Zen Cart 1.5.1. I would suggest you download a copy of the production website and [compare the files](https://www.zen-cart.com/wiki/index.php/Troubleshoot_-_Diagnosing_Obscure_Issues) against a clean copy of Zen Cart 1.5.1.

Look for anything missing (compared the the clean Zen Cart 1.5.1 files) and where modifications have been made to add / change functionality.


**Future:**
I would also recommend looking into the pre-requisites for Zen Cart 1.5.4 (or the upcoming 1.5.5 release) and start planning your upgrade path. Newer versions of Zen Cart include numerous fixes, enhancements, and better compatibility (PHP 5.4+ support, etc). I would recommend using the [Rebuild Method](https://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading) and only installing compatible plugins, themes, and other modifications as needed (instead of trying to keep all the old ones).

Thanks for all of the input above. Those things are above my level of comfort so I might need to get a programmer involved.

That being said, I was poking around because I remembered something about sessions when we moved to a new server a long time ago. In Configuration, Sessions, Sessions Directory I noticed that site is referencing a folder that does not exist and is not the cache folder I was looking at in the previous posts. Could this possibly be the source of the issue relating to the downloads (not the SEO ones obviously)?

Would it be wise to correct this entry to the proper location since it's pointing to a directory that doesn't exist?

Thanks,
Bryan

Sessions Directory I noticed that site is referencing a folder that does not exist
What is it set to?

public_html/store/cache is what is setup in admin. The public_html/store folder has nothing inside of it except index.php. This was an old installation from way back when.

public_html/cache is the folder I was talking about with you in earlier messages.

bowerstech:

public_html/store/cache is what is setup in admin. The public_html/store folder has nothing inside of it except index.php. This was an old installation from way back when.

public_html/cache is the folder I was talking about with you in earlier messages.

Well, I don't think it will fix the download issue, but one thing for sure if it's not right it's wrong. :P

public_html/store/cache is what is setup in admin
Well since you stated that you are using ZenCart v1.5.1 - this should be

public_html/logs

And you need to check your configure.php file for what you have for

define('DIR_FS_LOGS'

And that you do have a folder under public_html - named "logs"