Installing EasyPopulate and BackupZC Plugins Procedure?

[homebre]

I've downloaded BackUp ZC and Easy Populate and I'm worried about #%@*&! up the installs.

I'm sure I'm not supposed to overwrite existing files on the server, but the way I read the install directions, it almost sounds like it.

Do I go into my YOUR_ADMIN folder (obviously not what I call it), open each individual folder, and copy each set of files to the corresponding folder, going as deep into the file structure as necessary to not overwrite existing files (Example: the local file MYADMIN/easypopulate.php copies to MYADMIN/, the folder MYADMIN/includes/boxes copies as an entirety into MYADMIN/includes (since there's no existing MYADMIN/includes/boxes folder on the server), etc.

It just sounds like it would be easy to miss a file along the way, especially on the really deep folders (e.g. copying the file MYADMIN/includes/languages/english/extra_definitions/easypopulate.php to the server).

Sorry if this sounds stupid, but I'm a rookie and could use a little hand-holding.

BackUp ZC has this for installation:
-----------------------------------------------
Unzip backup_zc_v???.zip file to a temp area on your local computer.
Rename the YOUR_ADMIN folder to match the admin folder name that you are using on your Zen Cart site.

Upload all files from the newly renamed "admin" folder as-is to your server, retaining folder structures.
-----------------------------------------------
Easy Populate says this:
-----------------------------------------------
1) Change the name of the "admin" directory in this package to suit your zencart installation's renamed admin directory
2) The temp folder is configured to reside in your store directory. If you store is not in the
site root (eg. /mystore/) then the temp directory must also go in this directory.
3) If you want to re-name the uploads (temp) folder, ensure that you configure Easy Populate to
reflect this change after installation
4) Upload all files in their respective directories.
-----------------------------------------------

[gjh42]

Uploading files one at a time does risk misplacing one, and since any well-written mod will have all of its files in the correct folder structure already, it is generally more reliable to upload the whole mod /includes/ or /your_admin/includes/ folder to the Zen Cart root. If you are confident of your ability to place all of the files in the correct locations, doing it individually will give you a clear sense of what additions you are making.

The /admin/includes/boxes/ folder was eliminated in v1.5.0 in favor of a different method of handling admin features, so if your mod needs a /boxes/ folder, it may not be compatible with v1.5.0.

[torvista]

This is a good question, I’ve been wanting to rant about what I wish someone had told me three years ago.

This is what I do to ensure I never have a broken shop...it may not be for everyone but this procedure means I learn something along the way, gain confidence and knowledge about the thousands of files in Zen Cart and don’t blindly install something.

1) Do ALL changes and testing on a local development server.
People argue with reason that it’s better to use another remote dev server that mirrors the environment of the real shop.
I just find it easier to manipulate and search for things on my local pc than on some remote site.

I use Beyond Compare to ensure the files and structure are IDENTICAL to the real shop and use the Backupmysql plugin to take a copy of the real shop database and import it into the dev version every time I am about to do anything.
I NEVER do any experimentation on the live shop, EVER, no matter how trivial it seems.

2) Installing plugins
a) Read the support thread, decide if you trust it?
Plugins are not quality-controlled by the Zen Cart devs as far as I know, I think they just check them to ensure they are not malicious.
Any fool can upload a plugin, I have 22 listed which implies expert knowledge..completely unjustified! Beware.
The plugin may have been hacked to work with the uploaders shop and than not checked for a problem-free install on a vanilla ZC 1.5 site nor with table prefixes.

b) Read the sql that comes with the plugin, most of it you can figure out like INSERT and CREATE and ALTER.
Don't expect to understand the detail but over time you'll learn something and at least get an idea of what the plugin is adding or altering in your database.

c) Compare (Beyond Compare again) the plugin files and structure to your dev shop files and structure so you get an idea what is going where. Try and understand why.
You can see easily where files are going to be overwritten and also where the code in core files in plugins are not up to date with your 1.5 versions: merge carefully and write detailed comments in your files.
I also comment at the start of every core file I edit to help with future core file updates.
I also ensure that any files I do merges on, I subsequently open in some syntax-checking editor to spot stupid errors and avoid white screens of death.

d) Backup the dev database before you run the plugin sql as often it fails/half installs and then always fails subsequently because it half-installed the first time. Hence an easy way to repeatedly restore the db while you figure out the problem is essential.
What you are trying to ensure is that it will all work first time on the real shop.

e) Copy and merge the plugin files as necessary.

f) Test it until you are blue in the face.
Check for debug errors.
Check for html errors the plugin may have introduced (Firefox + HTML validator add-on) and faulty javascript (Firebug addon and IE developer console)

g) If you are happy the plugin does what you want/expected, run the sql/upload the files to the real shop using Beyond Compare again.
If not, download the real shop files and overwrite/delete the plugin files on the dev shop so you are back to square one.

h) More testing as f) on the real shop.

I keep copies of all the plugins or code I have installed from day one.

That’s my ten cents. Its tedious, nit-picking, anal, paranoid etc...but I have a 100% valid HTML shop, no debug errors and a hell of a lot of plugins and modified code in there working happily. I will also see immediately if something has been added or changed on the real site without my knowledge.

[homebre]

OK, I'm still unsure of what to do.

By Zen Cart root, I'm understanding that to mean the /catalog folder which contains ZC's MY_ADMIN.

However, the directions tell you to rename the PLUGIN ADMIN folder to match that, i.e. to be MY_ADMIN.

I'd think that plunking a second MY_ADMIN into the folder will over-write the existing MY_ADMIN folder, along with all of its contained files, wreaking havoc on the program.

Schematically,
Existing structure: /catalog/MY_ADMIN/ (current MY_ADMIN)
New structure: /catalog/MY_ADMIN/ (plugin's new MY_ADMIN)

I have extreme trepidation about attempting this. I've tried installing the entire package (folder backup_zc_v1.1, containing /MY_ADMIN et al) at the both the ZC root (i.e. within public_html/catalog/) and the site root (public_html), but when I log in to admin the backup option doesn't appear.

I'm using Arvixe as my hosting service, and it's on a Linux server.

[stevesh]

FTP will not override folders, just files, and most, if not all, will ask you if you want to replace a file before it acts.

My inclination tends to be 'push the button and see what happens', but I always install mods on a test site before I do so on a live site.

[homebre]

<< I always install mods on a test site before I do so on a live site. >>

OK. Unfortunately, I don't have that option right now.

I will be backing the entire site up to my local computer. Is that adequate?

[schoolboy]

Good FTP programs do not overwrite FOLDERS - just the FILES (if there are any identically-named files in the stated directory PATH).

Similarly, if there are completely UNIQUE files to be sent to the server, then there is nothing to over-write, so your EXISTING files will not be harmed.

By porting the entire INCLUDES folder (for example) you do not overwrite the existing INCLUDES folder... all that happens is that the file contents of the includes folder on YOUR machine, are sent to the includes folder on the REMOTE machine.

And if there are sub-directories involved, it ports just the FILE CONTENTS of these sub folders.

If however, there is a FOLDER inside the includes folder on YOUR machine, that does not already exist on the server, then the FTP program says "Ah... I see a FOLDER on the local machine which does not exist yet, on the remote machine... so I'd better create that folder first, then send its contents.)

For all FOLDERS that already exist, FTP will just send the FILES over.

We use WS-FTP Pro - a really good FTP program from Ipswitch, and only costs a few dollars. we use it because it is extremely reliable and robust, and secure. It is also very easy to see what's going on.

WS FTP Pro loads showing TWO "window frames", side by side.

We usually use the LEFT frame to display our LOCAL MACHINE, and the RIGHT frame to connect to the REMOTE SERVER.

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

When we are going to install a plugin, we follow this procedure:

1. We UNZIP the plugin on a local machine and then open the README file(s) and VERY THOROUGHLY read everything in there.
2. We open up the plugin's folders so we can see what sub-folders exist, and what FILES they contain.
3. We RE-NAME folders where necessary, to MATCH corresponding folders on our remote server. The README is generally the guide here...

(Then, on the server...)
1. We connect to our remote server and take a good look at all the folders the plugin uses, that are already on our remote server.
2. We see if there are any FILES that have identical names in the relevant (and identical PATHS).
3. If there are identically named FILES in identical PATHS, then we make BACKUPS of all these files.
(It is important to make sure you are in the identical PATH - because in zencart's case, there are some instances where FILE NAMES will be identical - but the PATH will be different. For example - in the /includes/modules/pages/ area, you will see header.php in ALL the page-folders - but they will all contain DIFFERENT code. You cannot put the header.php code for the page-folder called account, into the page-folder called account-edit.

4. For identical filenames that exist in BOTH the plugin AND are on the SERVER (in the same PATH) - we bring the server's copy to our local machine (to a different directory) and we do a FILE COMPARE (using winmerge) to compare the SERVER's file, with the PLUGIN's file.
5. If the PLUGIN's version has special bits of code, we MERGE this into the SERVER's version, and prepare it for sending BACK to the server.

Once we are sure that all files are correctly modified, we BACKUP THE SITE AND THE DATABASE.

Then we FTP the plugin's files to the server.

[stevesh]

OK. Unfortunately, I don't have that option right now.

May I ask why ?

If you have a folder on the remote server named folder1 which contains files named file1.php and file2.php, and a folder on your local computer named folder1 which contains a file named file3.php, dragging and dropping the folder1 from your local computer to the remote server will add the file3,php to the folder1 folder.

[homebre]

<< stevesh: May I ask why ?

If you have a folder on the remote server named folder1 which contains files named file1.php and file2.php, and a folder on your local computer named folder1 which contains a file named file3.php, dragging and dropping the folder1 from your local computer to the remote server will add the file3,php to the folder1 folder. >>

I was referring to having a "test site" running in addition to the live site.

I was saying I'd copy the live site files to local, so if anything went wrong, I'd have the original intact. As a matter of fact, I'm doing that as we "speak."

[homebre]

Thanks to everybody for their help and suggestions.

The installs went fine.

Alles klar.