1

I got to install the update of an already existing extension (in the community code) in my project. So, I got the files gathered in a zip file. I've got files for the code, for the shell, js, skin. Anyway, there are a lot of files, and I was wondering (since it is gonna be my first time to update an extension) whether I should just replace all the files, that already exist, with the files that I've been given, by copy-paste, or there is a simpler way?

2

I think the only way is to copy and paste the files into the root folder. The best way to do something like this is to create a test environment with a copy of the code and the database. Even better is to do that in a VM. Create snapshots along the way for each major step until you get it working. Mark the snapshots with meaningful names. Then for the working test environment, update the extension and see if it works. You can now mess with everything without consequences. If something goes wrong, revert to a previous snapshot and start over.

Many times I've experienced problems with extensions. Now you can test, search for a fix if it doesn't work, without risking your production environment. If something goes wrong it can get difficult to get it working again.

When you apply the update to the production environment, make a list of what should be tested when the update is live. Then make a copy of the code on the same server, with all rights preserved (Linux: cp -rp htdocs htdocs-backup for instance). Then make a backup of the database, apply the update, and test.

1

The extensions should always be packaged in a standard way and be installed in a standard way. There are 2 options to install an extension correctly:

  1. via Magento Connect GUI
  2. via command line tool ./mage

Both methods ensure proper installation and registration of extension by Magento. There are some special XML files under var folder that should not be removed. Extensions that are installed properly can be versioned, upgraded and uninstalled. This helps to retain control over your Magento solution.

Never install anything directly to production. As an absolute minimum use 2-tier environment: development and production. In a good setup there are four tiers:

  1. development (one or more developer machines)
  2. testing (dev company internal test)
  3. staging (customer test or pre-live)
  4. production

It is all glued together by GIT version control and good deployment processes. A working CI server is a plus.

Lot of Magento extension developers distribute their free or premium extensions via their own webstores as ZIP archives. ZIP archives are a non-standard. Extensions should be packaged with Magento extension packager and the result is a properly packaged .tgz file that can be distributed to users.

  • I forgot to address Phil's original problem. The best way is to add this 3rd party extension to a separate repository, link it to your dev Magento with modman and then package it with Magento Extension Packager. After that remove modman symlinks and deps and install the package to the same dev Magento. Commit to git, push and pull changes to next tier. – Sven Nov 12 '13 at 5:33
  • although nice then the .tgz and pear does not give you much of a benefit from development perspective as you need separate tools and layer in deployment to manage those and you still have no (meaningful) versioning in terms of one single code unit in your codebase. Deployment plan that includes modman (as it separates the extensions from core) would be far better choice as it is more modular and accessible. If you are fucked by pear update then you are just fcked , handling it with modman you at least get a fast diff of the f*cked state and have the same rollback functionality. – Anton S Nov 12 '13 at 7:30
  • Thanks for thinking along, Anton! First it should be noted that symlinks that are created by modman and that are enabled in Magento backend can create a security threat. Secondly - development, staging and production should be quite clearly separated. My view is that a whole solution in production should be viewed as a "package". It can have subpackages, modules etc, but all these should be versioned. I don't mean source code version control here. I mean solution component version control and total solution configuration control and management. – Sven Nov 19 '13 at 14:22
  • modman can place files directly to your source tree if you prefer on time of development or on time of deploying to production – Anton S Nov 19 '13 at 22:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.