Here is a practical example of one can easily connect Magento with some other system. In my case I had Magento plus WordPress integration in which I needed to pull some user data, such as latest users, from WordPress into Magento block.

Stuff like these can easily be done in two easy steps

• Create custom Magento controller. This article shows you how you can create custom controller.
• Use built in PHP function file_get_contents and pass it a full link to controller action that will return html string for given block. Using function like $htmlContent = @file_get_contents($someUrl); if($htmlContent) { echo $htmlContent; } will give you some error proof behaviour. Simple but useful for quick stuff.

That’s it. Later once you get on the milestone track you can easily convert these to AJAX calls.

This will not be the regular WordPress posts and pages. I plan to implement a whole new philosophy into it. I’ll be using an outside /mylibrary folder with full object oriented classes and methods representing models which I’ll be working on. I wrote few lines of code inside the index.php file in the root of WordPress folder to autoload all of my classes and stuff from /mylibrary when needed to avoid include’s ore require’s inside each of my template files.

Most of the stuff inside /mylibrary will call the default built in WordPress functions for manipulating posts and pages, therefore most of /mylibrary stuff will work only inside theLoop of the WordPress template (for now). My idea is to use the Custom Fields functionality, introduced in the newer versions of WordPress, extensively. My idea is to have a special category, let’s say, “user” and a post assigned to each user like “first-lastname” then the page generated by the url “http://somesite.domain/user/first-lastname” with the basic post data plus the custom field data.

All of this data assigned to the “user” post inside the “/user” category will be done transparently to the user. I already made a class that automatically creates a post with basic post daa like title. content, excerpt plus data like tags and custom fields. All I need to do now is to create a page with some form on it and tie my form submit action to execute that class and method I created passing it all the necesery data. This may sound like a lot of work, or even complicated, but hey… few weeks with Magento and WordPress becomes a toy

Anyhow… there are still few things I’m looking around to get the full picture and power of WordPress. One of them is Single post custom template. If you open admin interface in WordPress and go to Edit > Page you can see that you can assign a template foreach page if you like. So my question is, why can’t you do it for Single post? Well, you can, just keep on reading

My idea is to create directory /layouts inside the root of my custom theme. Inside directory /layouts I created two additional folders named /category and /post. Inside directory /category I would like to have special template file foreach of my categories. If my url is like

http://somename.domain/categoryname/postname

then opening http://somename.domain/categoryname/ would open the category template, which by default is archive.php file and I want it to open the /layouts/category/categoryname.php file.

If I were to open the

http://somename.domain/categoryname/postname

I would be directed to single.php file by default and I want it to be pointing to /layouts/post/categoryname.php template file.

So how do I get the defaults to do what I mentioned previously.

All you need to do is to open the functions.php file and place the following code in it. I placed it at the very top of the functions.php file.

<?php

?>

Hope some of you find this useful. You can play around with the add_filter function to make more complex layout routes, just be careful not to get lost

Among few other problems, I had a broken popup page on Compare Products. If you login to backend interface and turn on show hint’s for template, you can easily see from where each part of the page is pooled from. Compare Products is pooled from “app/design/frontend/default/default/template/catalog/product/compare/”. There you can see two files: “sidebar.phtml” and “list.phtml”. The other one is the one that is actually popup. Since my popup error was specific: it opened, but showed none of the compare info, it was logical to have a look inside “list.phtml” file.

What I don’t get it, is why do Magento boys and girls did not use the same helper functions they used in Magento version 1.0.19870.1. My Compare Products popup page get broken because it was calling non existent function. Check the following code.

From version 1.0.19870.1

<?php echo $this->helper('review/product')->getSummaryHtml($_item, 'short') ?>
<?php echo $this->helper('catalog/product')->getPriceHtml($_item) ?>

From version 1.1.2

<?php echo $this->getReviewsSummaryHtml($_item, 'short') ?>
<?php echo $this->getPriceHtml($_item, true) ?>

It’s obvious the function names have change, therefore it’s obvious why template page broke. When dealing with these kind of problems, my approach is to first enable template hints in admin backend, then open the template file where page brakes. If you’re using custom made template, problems will probably be template related.

Performing local update went smoothly as it gets. On my surprise, everything work as it should be. I was convinced I can go and make upgrade to remote development machine. I had no SVN setup to my remote machine so all my code transfer was done trough FTP. Basically if you’re performing your upgrade trough full archive file all you need to do is copy content from archive to your root Magento installation and overwrite everything you’re asked to overwrite. Sound’s easy, doesn’t it? Well it is easy and your upgrade should go clean and without any glitch, that is if you are using built in theme. If you’re using a custom made theme, chances are you’re rune into trouble like i did.

Magento is a very modular system. If you do a little check on default archive for Magento version 1.1.2 (latest, as of time of this writing) you will see it contains 6 383 files across 2 171 folders. This is huge number of files if you ask me. Magento’s philosophy for building themes is somewhat complex. When i say complex i don’t think in terms on hard to learn but in terms of everything is co cut up into meaningful peaces as they say. However, number of this meaningful peaces is huge. This alone is not the problem, although will take some time getting around. Problem is in the PHP code inside those meaningful little peaces.

Let me be specific. If you want to change something in your checkout page, let’s say make it different then it is in the default template then you go and create your theme according to the manual. Then you realize, that if you want to change checkout page you need to change app/design/frontend/default/your_theme/template/checkout/cart.phtml to suite your needs. You do stuff like calling some Magento helper functions, modifying HTML, adding all sort of styles and so on. Magento works by first looking for files within “your_theme” folder. If corresponding file is there it will pick it up, if not it will use it’s own from the default theme. This is very modular if you ask me. However, there is one problem to it. What if someone deleted some helper or some other function you used inside your theme file? Well you would get errors and your online Magento powered shop would fail to work.

When you do upgrade you overwrite files from default theme folder. However, you preserve all the old files inside your custom theme folder. These are the files that worked with Magento version before the upgrade. In order for them to work after the upgrade all the functions called from this template should be existing. I’ve read a response comment on Magento forum where some said “templates for *** have changed significantly”, probably meaning something like “you’ll have to change your theme significantly because of it”.

I’m not here to judge Magento because of this. It’s a great product, it’s free, it has very bright future and so on. I’m just trying to lay out my conclusions. I was pretty surprised when my Magento shop broke after upgrade, when some things started disappearing and so on. On the other hand, it was quite good experience from which I learned a thing or two about Magento. And one advice before and after the upgrade; try to switch your site to default theme and first do a full check to see if everything is working here. If it is, then you’re ready to bug hunt your theme.