You are here:  » What minimum files are needed for the new 13/03A upgrade?


What minimum files are needed for the new 13/03A upgrade?

Submitted by Capricorn on Sun, 2013-04-14 02:00 in

Hi David,

I have made a lot of modifications to my 12/10B scripts, and I would like to know what are the only files that are needed in order to upgrade just these features:

1 - HTML5/CSS3 standard template update
2 - Zero down-time import
3 - Improved index strategy for faster search

Because after comparing 12/10B and 13/03A, if I use all of the new files as an upgrade, I will lose all the old modifications I have made.

Thanks.

Submitted by support on Sun, 2013-04-14 09:40

Hi Capricorn,

Re: 1/
The template modifications are confined to default.css and the HTML modules in the /html/ folder; however it is likely that a customised installation will already have numerous changes in those files (which are where most customisations are made). If you wanted to go through the process of converting your existing /html/ files to HTML5/CSS3 valid it may be easier to modify your existing files using the W3C markup validation service at http://validator.w3.org/.

However, before starting, modify your html/header.php to use the standard HTML5 declaration so that the validator knows what schema to validate against. To do this, look for the following code beginning at around line 9:

<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
<html lang='en' xml:lang='en' xmlns='http://www.w3.org/1999/xhtml'>

...and REPLACE with just:

<!DOCTYPE HTML>
<html>

Then run your pages through the validator. The validator output can look a little daunting at first but bear in mind that since much of the output is generated in loops (e.g. for each featured product, for each search result etc.) making one fix will actually clear a much larger number of errors / warnings.

For validating the search results page, it's probably best to use a search that only returns a single product (e.g. search for an exact product name) as that will make sure that the validator only needs to process the minimum code necessary. Once you have a single product search result page validating move on to a search result producing more than one page in order to validate the navigation bar code.

Re: 2/
The zero down time modification is documented in this thread. If you're not sure of any of the changes of course email me your versions and I'll apply the changes for you.

Re: 3/
The new index strategy involves a bit of re-structuring of search.php and products.php - not straight forward to describe but I can make the changes very quickly for you if you'd like to email me those files I'll upgrade them for you.

Cheers,
David.
--
PriceTapestry.com

Submitted by Capricorn on Tue, 2013-04-30 07:18

Hi David,

I have decided keep my V12/10B scripts and not upgrade all the files to 13/03A because I have made a lot of modifications to the V12/10B scripts.

But, I just need to find a way to make the Zero down-time import to work.

I have follow that 2010 thread: http://www.pricetapestry.com/node/3355 line by line, but I think I am getting stuck somewhere, because even though I get the temporary table created and at the end it gets renamed to the live products table, I still have the same problems that other members have posted.

When using the Slow Import Tool from the /admin/feeds_import_slow.php, the script goes one by one thru the Registered CSV Feeds, but every feed that gets imported disappears from the live products table and Site Home, until the end of the Import All task.

At first it didn't bother me that much because the whole process was done in less than five minutes, but now that I am adding more feeds and more products, I need a way to fix this.

While I thought that maybe the problem maybe was just when I run the Slow Import Tool from the /admin/feeds_import_slow.php, today I tried to use the CRON script for the first time, but I run into more trouble.

I tried many of the CRON process I have found all over the forum and the only one that I got working was this one:

/usr/bin/wget --max-redirect=9999 -O /dev/null "http://www.example.com/path/to/scripts/import_slow.php?password=ADMINPW&filename=@@ALL"

But, that one is doing the same as when I use the Slow Import Tool from the /admin/feeds_import_slow.php, with also the extra big email I get from (Cron Daemon)

What files should I send you in order to apply the changes I need for the import_slow from the admin area, and for the import_slow by CRON?

includes/admin.php
scripts/import_slow.php
scripts/cron.php
admin/feeds_import_slow.php

If those are the only files you need let me know so I will send you a zip file with those four files.

Thanks.

Submitted by support on Tue, 2013-04-30 08:31

Hi Capricorn,

No problem - forward those files across in a .zip and I'll port the zero down time for slow import for you..

Cheers,
David.
--
PriceTapestry.com

Submitted by Capricorn on Tue, 2013-04-30 08:41

I just sent the zip file, I hope I used the right mailto: email.

Submitted by support on Tue, 2013-04-30 08:45

All received thanks - will follow up by email!

Cheers,
David.
--
PriceTapestry.com

Submitted by Capricorn on Wed, 2013-05-01 00:05

Thank you very much, David!

Now the Zero down-time import works perfect from the admin page, and from the cPANEL CRON job.

--------------------------

On a related note, is there a way to get the CRON Report email for the import_slow like the CRON Report email that the: cd /home/sitename/public_html/scripts/; /usr/bin/php -f fetch.php @ALL, sends?

What I mean is that when using the CRON to get the feeds the email report is cleaner and don't include the password=ADMINPW anywhere on that email, but when getting the email from the:
/usr/bin/wget --max-redirect=9999 -O /dev/null "http://www.example.com/path/to/scripts/import_slow.php?password=ADMINPW&filename=@@ALL"

Not only is that email long, but it also shows the password=ADMINPW all over the email.

My only concern is with the ADMIN password showing on the email, but if that can't be fix with any mod, no problem, because I can manually use the import_slow from the ADMIN area, and not get that email with the password on it.

Thanks again, David!

Submitted by support on Wed, 2013-05-01 07:56

Hi,

The CRON job email is a function of the server's CRON process, but can be controlled in one of 2 ways. If you are setting up your CRON jobs using your hosting control panel, look for a Settings tab, where you can normally disable or enter the email address used for the CRON output.

If you're manually editing crontab for your user account, then simply add the following line to the top of the file:

MAILTO=""

...and that should disable the email report.

Cheers,
David.
--
PriceTapestry.com

Submitted by Capricorn on Thu, 2013-05-02 02:16

Hi David,

I was able to stop the CRON job email by going to my cpanel and adding this: >/dev/null 2>&1 at the end of the command

Example:

/usr/bin/wget --max-redirect=9999 -O /dev/null "http://www.example.com/path/to/scripts/import_slow.php?filename=@ALL&password=ADMINPW" > /dev/null 2>&1

And now everything still works fine, and I don't get that big email no more.

Thank you.