I always install my Magento extensions manually so for me downloading and looking over an extension before copying it into my SVN repo is important. I don’t actually recommend using Magento Connect to install things on production stores (no one does that, right?) – it’s a bit like playing Russian roulette really. You might be able to install 1 or 2 extensions with Magento Connect, but if you install 6, you’ll definitely
blow your brains out hose your Magento store.
Here’s a quick few steps to take so you can do that yourself. I’ll assume you have a local development version of Magento running on your laptop or desktop.
1) Jump into the root of your development store:
2) Download the extension with pear:
./pear download magento-community/Netzarbeiter_CustomerActivation
3) For simplicity, I move the file over to my downloads directory to extract and inspect it:
mv ~/Documents/web/magento/126.96.36.199/Netzarbeiter_CustomerActivation-0.2.9.tgz ~/Downloads/
Then you can unarchive the extension, take a look at the files, scrutinize to your hearts content before you decide it’s a good extension and install it into your SVN repo manually. Then when you update your staging site you can check everything works, before releasing to production. Of course in this particular case I’ll install the extension blindly, Vinai codes elegant extensions that are certain to work!
Some things I look for:
- Schema scripts in the sql directory that make drastic schema changes
- Ugly phone-home calls (you know who you are!)
- Comments like “TODO: remove this before releasing”
- Comments like “TODO: implement this”
- Check what models the extension is overriding, it’s one way to avoid extension clashes
Any I missed let me know? And yes I am fully aware that most of my extensions would fail my own criteria 😛
2010 is now well and truly behind me and I am sitting inside on a sunny day (sunburnt) reflecting on the year that was. It’s been a busy year. I thought, more so for my own sake than yours, that I would jot down a few notes to wrap things up.
Firstly my blog, Aschroder.com. 2010 has been good to me in several respects. From a traffic point of view my final tally (according to Google Analytics at least) clocked in at a touch over 100 thousand visitors and over 200 RSS subscribers, I feel like this is a recognition of the quality of my continued articles on Magento development.
Continue reading 2010 ☑ Bring on 2011
A few people have asked with regards to my Magento Speed Test, how to create a sitemap.xml for their Magento store so that they can test their speed/performance.
So here we go:
1) Go to Catalog->Google Sitemap in the admin
2) Click ‘Add Sitemap’
3) Enter these details:
That should do the trick. You can now see how fast your Magento store is performing. Note that once you have a sitemap, you should submit it.
Just a quick little note. I took the work I had done in this article on siege testing Magento and basically made it into a little script you can run to test your own Magento store from the comfort of your web browser.
You can see the app in action at Magento Speed Test.
The features include:
- Testing for a specified amount of time with a specified number of concurrent users.
- Having your results emailed to you when they are ready.
- Optionally choosing to publish your results to the home page
- Tweet your results.
Note that you do need a standard Magento sitemap.xml in order for the testing to work properly. But you should have one anyway.
It’s still in beta mode – but I’d really love for people to try it out and give me some feedback and ideas. Here are a couple of features I think would be cool:
1) Run tests every 12 or 24 hours against various hosting company demo stores. That way we’ll get to see how they are performing and who is the fastest (for my little test at least).
2) Show a leader board for the home page, not just the 5 latest published results. I could add comments/notes so people can learn tips and tricks for speeding up Magento.
3) Less cool but important, I need to optimize the App with some memcaching – the Google App Engine Gods get angry when you run lots of un-cached queries.
But I’d appreciate hearing your feature ideas.
As I alluded to in my excuses for not posting in ages blog post the other day I am working on a new Magento hosting review for a company called MageMojo. In doing so I’m trying out the performance testing tool called Siege. Siege was mentioned several times at the Magento Developers Paradise, so I have been wanting to try it ever since.
This is a little article that summarizes the steps I took to do the testing, in case you want to test your own Magento stores.
Update: I have since created a tool that will allow you to run testing like this from the comfort of your own web browser. Check out the automated Magento performance testing at MageSpeedTest.com.
Get a Server
Being all the way over in New Zealand pretty much means performance testing Magento from here is out of the question. I fired up an Amazon EC2 small instance for the purposes of testing for a few hours, 20c – I’ve said it once, I’ll say it again, commodity computing is the future . I won’t bore you with a tutorial on starting an EC2 server, there are enough perfectly good guides already online.
You could optionally use a server you already have, or run this from your own computer at the office or home. It would arguably be a fairer test of latency, not running the tests in a production data centre!
Definitely do not run it from the server that is running Magento, that would be a poor test; a) because there would be no latency and b) because the server would be using resources to run the tests, and serve the webstore, that’s not very fair on it!
tar xvzf siege-latest.tar.gz
# if you're on a fresh ubuntu, get this package first
sudo apt-get install build-essential
make && sudo make install
Now you can begin a siege on your store, but first, an important warning…
Continue reading Laying Siege to Magento: Performance testing your Magento webstores