I know I know I know! API is coming in the next 2-3 weeks. It’s a necessity, because there is an iPhone app in development for this exciting project. Fortunately, I’ve been building the site with CodeIgniter, which means that with a little refactoring, building an API will be a relatively painless experience.

Truly, the API is there; MVC architecture kind of forces that. All I have to do is clean it up and expose it. Slick, huh?

This morning I once again encountered the single shortcoming in the otherwise impressive “Backup and Migrate” module. I use this module so that I can dev on my local machine and push my changes out to my sandbox site for the client to approve easily and quickly. The tiniest improvement in this module would make it even that much simpler.

Here’s what happens. When I “Restore” from a Backup and Migrate backup, my temporary path is overwritten with the one in the backup. This makes sense of course, but means that before I can restore again, or do any uploads, I much manually reset the path. Bleh. It would be fantastic if before restoring, B&M module sequestered this piece of information from the existing DB, then placed it back after the update. I expect this would require the ability to save something in the filesystem (since the DB is being overwritten) or in an untouched table on the DB. Probably a simple workaround is possible…has anyone else solved this issue?

Update: The info is stored in the DB, table variable, key file_directory_temp. I think I’m going to try to write a routine that grabs this and saves it to session or something, then replaces it.

Well, today I learned something new, but it took some doing, so I’m hoping I can save someone else time and effort through the magic of Google search. Here’s the backstory: Mad Science Department got brought in a few months ago to help patch up and update an existing eCommerce site. We added true credit card processing, helped the client through the Labyrinth that is Authorize.net (which is a whole separate post, provided there’s enough Run in my beaker), and patched some security holes. In the process, we had the host apply a stock SSL. All smooth and cool, right?

This morning we got a note from the client’s local folk, saying that the client cannot access the site admin (under SSL) from a mobile device! Oh no! So after recreating the issue on my handy dandy iPhone, I contacted the host, who assured me that the SSL was working properly. Well, that’s a weight off my shoulders, but why isn’t it working for mobile? Host’s support didn’t know, suggested it had something to do with the phone. Hrumph.

So I checked the cert and tracked down the issuer. This is where a nice young man called Jeff comes in. He explained to me that the various SSLs actually use different types of encryption, and therefore some certificates which are perfectly good for web use simply cannot encrypt data over mobile networks (GSM,G3,etc.). In order to add this level of encryption, my client would have to upgrade to a higher premium, which would allow for more diverse and stronger coverage. Now I know.

I don’t usually give shout outs in my Lab Notes, but Jeff from Comodo was very helpful, so thanks.

Which is why I freaked out a little when I received this message in my Facebook stream. Then I followed through to some of hte other posts on the subject and realized that this was the self-same bug that had been identified Auguest 12 and patched with WordPress version 2.8.4.

We Mad Scientists are a competitive bunch. We don’t like other Mad Scientists hacking into our stuff and messing with it, so as a rule, we apply security patches as soon as we are aware of them! If you or your agency is a maintained client of Mad Science Department, you probably have little to worry about. If you do see a “security upgrade” warning in your admin panel, it’s probably a good idea to let us know, but nine times out of ten, we’re already upgrading all the installations we maintain.

This kind of attack brings up other issues as well. It’s important to make sure that you are backing up your databases and file system regularly, so that you don’t lose too much in the event of a successful attack. Your host may even provide tools to automate this on a cPanel. If you are a user (not a developer) handling your own WordPress installation, be vigilant and make sure you update as needed! Those warnings and messages in the backend are there for a reason! If you have a developer helping you, they’ll know the difference between feature updates (nice to have, but sometimes buggy) and critical security updates. Don’t be afraid to ask how necessary a given update is!

The events of today have led me to believe that PayPal accounts should remain open and viable, even if the retailer decides not to use them as their primary gateway, for the simple fact that it provides and good backup plan! It takes mere moments in a package like Magento eCommerce (Mad Science Department’s favorite eCommerce package, if you haven’t figured that out by now!) to switch PayPal on, thus allowing purchasing to continue!

If you are considering the choice between PayPal as a permanent solution and a true merchant account, there are a number of factors to consider.

In the early stages of launching an online store a decision needs to be made: how will customers’ payments be processed? This needs to be determined before the site is developed as different payment options may require radically different forms of implementation. But how do you choose? Is price the single most important factor? What are the other factors?

-John Conde

This article may help you sort through the pros and cons of each option, but I would still suggest keeping a PayPal account around, for those unforeseeable instances!

I’ve published Magento in a few different environments, some for development (testing), others for production (live!).

Geeks will want to know that having root (full administrative control of the server) certainly helps, but is not required. Mostly, the joy of root in this situation is that it makes creating backups (via tar) and updating (which means doing some chmod dances) much simpler. Obviously, if you have an SSH user, you can do these things as well. However, if you can live with having your files 777, it’s really not that big of a deal. Magento is big, so backing up via FTP will take a long time, but it’s hardly impossible.

My preferred environment is a LAMP (Linux/Apache/MySQL/PHP) stack where I have root. I’ve deployed several development models and a few production models this way, and they worked like a dream. I have deployed Magento on MAMP (the app), MAMP (MacOSX/Apache/MySQL/PHP compiled, not the app) and WAMP (WindowsXP or Windows Server 2008/Apache/MySQL/PHP for various tests and development. This was less satisfactory, but worked. The MAMP application really didn’t like it, and required a bit of tweaking to get it going, but I don’t see MAMP as a viable production option anyway. (I’ve never had reason to try MAMP Pro.) Most recently I installed it in a shared LAMP server with a Plesk control panel. There were a few minor challenges here, but I was able to work with tech support at the host to get them resolved quickly.

For the average non-geek, it’s probably helpful to know that a LAMP stack is an extremely common shared hosting environment. Because it is inexpensive to set up and stable (low maintenance) almost every hosting company offers this package, and it is quite often their lowest priced option! So getting Magento to run on your site should not be a difficult task for a developer familiar with Magento.

I’ll admit that the first couple of instances of Magento I installed, I was very disappointed in how SLOW it seemed. It was as though the big giant toolbox was just too darn heavy and slowed everything down. Adding new products was a chore and surfing the site was a less-than-ideal situation. But then I discovered a few little tricks to speed things up. If you are installing Magento for the first time, you might find this information helpful.

Because Magento compiles each pages from dozes of files on each page call, performance with Magento has to do with both the environment its hosted on and with caching options. As I noted before, you want caching off during development. But once that puppy is ready for production, turning caching back on will dramatically improve time to serve pages. There are also options to cache javascript and css, like Fooman Speedster, which make things even faster. Of course, the mySQL query speed is going to matter, but the Mage engine seems to do a pretty good job of compiling requests. There is a developer option available to display the performance stats for each page draw in the page footer which can be helpful to tweak and optimize certain things. there is much to learn and try when tweaking for performance, and a good place to start learning is here: Magento performance and optimization group .

After receiving a scary email from ZenCart yesterday, I’m even more inclined to choose Magento for an out-of-the-box good solution that is very customizable. If properly done, it can be customized heavily and stay upgradable. I’m looking forward to my next installation, which should be happening in the next month!

PS: Some readers found this information daunting. This is why Magento works best when implemented by someone with development experience. At the Mad Science Department, we enjoy developing Magento solutions and handling all the scary bits so that our client agencies don’t have to! We are kind of…um…Mad that way.

I’ll admit that my experience with osCommerce and ZenCart is limited. In the cases where I was required to work with them, I was stepping into an orphaned project and had to pick up where another developer had left off. It was hateful. The “design” of the back-end made me embarrassed to hand it over to the client, and the client was generally extremely confused as to how to work with the cart once they had it. I did the best I could with it, but it was far from fun. (I often say that ZenCart totally harshes my Zen.)

So I started researching, and I attended a wonderful little talk about the Magento community by one Paul Reinheimer during PHP Appalacia. I decided to give it a try on my next project, and I was immediately impressed with the look of the Magento product, the clean interface (back- and front-end). Let’s face it, most clients are very visually oriented, at least initially, and this looked professional. I’ve since implemented this cart a number of times, some for realz and some for testing. Some were pretty much out of the box, others were heavily modified in some way. I’ve built a couple of simple modules (add-ons) and am in the process of building a more complex one.

Starting from the top: Setup is easy, once you are sure you have all the prerequisites on your server. Shared environments can be tricky, and it’s it’s good to have root in this situation, because the downloader (my preferred method of installation after trying the various options) needs the entire directory to be open to the world (chmod 777). I’m not real comfortable with leaving all of my files world open, so I usually open them, do the install or upgrade, and close them back down. If you are running under suexec, this is a bit simpler, but still can be tricky if you haven’t set the ownership permissions correctly. After all this server stuff is settled though, setup is push a button, wait, input some parameters and push another button and you are golden.

I don’t recommend installing the “demo database” unless you are just testing things out. Start with a clean database. OH! And if you plan to do a development machine setup and then migrate to a production server, be prepared: just doing a mySQL dump will give you some pretty ugly results. Be sure to follow the process here.

Adding existing modules, themes, etc. Is pretty simple, but often requires more steps than you would initially expect. You might have to set the new template as the default then go through existing pages/catalog entries and make sure they haven’t been custom defaulted to the old template, for example. It’s very handy to have caching OFF for this part of the setup, as it makes it really tricky when you are being served a cached document and going “BUT I CHANGED THAT!!!”.

If you have a background in themeing for other carts, WordPress, etc. forget everything you know. Magento themes work in an entirely different manner and really take some getting used to. I think this is what turns most people off when they start working with it. PERSEVERE, because once you wrap your head around the way that the XML defined template structure works, you will probably love it. But first, you will hate it a lot. (This is where my love hate relationship comes from. I always have to resettle my head into Magento space when I’ve been away from it for a while.) The flexibility here is amazing, especially since once you understand the XML structure, you can use it to redefine layout on any individual page, set of pages, etc. through the browser accessible back-end!

Building modules is pretty straight up Zend school of design. If you are familiar with the Zend framework, the Mage framework shouldn’t cause you much trouble. If you aren’t all that familiar with the Zend framework (I wasn’t when I started with Magento) Mage can help you get a foot in that door. This part is really for developers, not Web Designers. You need to know more PHP than “include()” and “echo()”.

Overall, the back-end is easy to use, once it is understood. Before I meet with my client for training, I usually backup anything I’ve done with the database. Then I walk my client through each section in the back-end and encourage them to play around and try new things, assuring them that everything they do will be erased after our training. It is extremely robust and can scare some clients. I tell them to focus on the catalog and orders sections and leave the rest to me. As they become more confident, they will often start trying bits in the other sections.

I don’t think that Magento is one of those “free” programs that anyone can download, install, and configure appropriately, but I do think that it is a good option for most end-users who have access to a qualified developer to set it up and walk them through it. There is a frustrating learning curve, but like most good learning curves, it is worth the climb. The community is reasonably helpful, and rather passionate. Of course, Mad Science Dept works with other carts on request, and if the client has only one or two items to sell, we may even write up a very simple tiny cart instead of using one of the very robust Open Source or Commercial options out there.