<config>
    <frontend>
        <events>
            ...
        </events>
    <frontend>
    <adminhtml>
        <events>
            ...
        </events>
    <adminhtml>
    <global>
        <events>
            ...
        </events>
    <global>
</config>

It is pretty self-explanatory, but here’s how it works: Events are firing off all the time. If you are needing to observe an event, but only when it happens on the frontend, then you would put your observer in the ‘‘ section. That same event might also be fired off in the admin, but your module won’t observe that event from the admin if you have it in ‘‘. If you want the event to be observed no matter where it happens (admin or frontend), you would then put your observer in the ‘‘ section.

I was trying to observe an event that should be fired off when an order is edited in the admin. I wasn’t able to log anything in my observer at all, and I couldn’t figure out why. Turns out it was because I had the event observer in the ‘‘ section. I changed it to ‘‘ and then it worked just fine.

<config>
    ...
    <stores>
        <admin>
            <design>
                <package>
                    <name>default</name>
                </package>
                <theme>
                    <default>prattski</default>
                </theme>
            </design>
        </admin>
    </stores>
</config>

Then I made my own adminhtml theme folder (app/design/adminhtml/default/prattski/) and put the template files in their proper spot.

No dice.

I was working with 1.4.1.1, so I figured I would just copy my module over to one of my 1.4.0.1 installations and sure enough, it worked perfectly. So, I’m not yet sure what the change was, or how to get it to work in 1.4.1 (or if it is just a fluke). So if you know the details about the change, if there is one, please let me know. Otherwise, if I figure it out, I will update this post.

This order contains (grouped) items and therefore cannot be edited through the admin interface at this time, if you wish to continue editing the (grouped) items will be removed, the order will be canceled and a new order will be placed.

Now here’s the interesting part that we discovered: If you add one simple line to app/code/core/Mage/Adminhtml/etc/config.xml, you can kind of get it to work. Search that file for ‘available_product_types’. Within that tag, you’ll find simple and virtual tags. Add ‘‘, ‘‘, and/or ‘‘ there and save the file.

Now, refresh the order in the admin. When you click edit, you will no longer receive the same warning, and the products will come over to the duplicated order. Interesting!

This begs the question: Why doesn’t Magento have any other product types enabled for editing products besides simple and virtual? I wonder if there is good reason behind it. Perhaps adding ‘‘ above makes it look like it works, but behind the scenes, something is getting messed up?

I have tried this with all three product types. Here is what I discovered:

Grouped Products: It seems to work perfectly. The products come over, and there doesn’t seem to be any difference in the original order and the duplicated order.

Configurable & Bundled Products: It works, but only partially. The products get transferred to the new order, but the options do not. The price is accurate, but you are missing the selections made by the user.

Unfortunately, this post is not a solution, but merely a sharing of a discovery. I wish I had a solid solution to offer. Configurable, Grouped, and Bundled products are pretty common among the numerous Magento websites that I have seen and developed. Why Magento hasn’t yet made editing orders with these product types is a huge question for a lot of Magento users out there. I can only assume that Magento hasn’t implemented it yet for a good reason. Hopefully they will add this functionality soon.

As always, I would never suggest editing core files directly. If you want to experiment making these changes other than just a quick experiment, then create a proper module to do so.

I currently run up a tail -f var/log/system.log & in Terminal to monitor files, which works pretty good. That is my preferred method at this point. I know that I could also use the Console app, but quite honestly, there’s no organization there, and there’s loads of other log files that I don’t care about.

I think it would be awesome to have a native Mac app that allows you to ‘subscribe’ or ‘unsubscribe’ from any log files of your choosing, almost like a feed reader (like NetNewsWire). Here are some features that I think would be really great:

• Ability to subscribe/unsubscribe easily to any log files on your system
• Easily clear the log display (just like command + k in Terminal) or delete everything in the log file
• Set filters that look for specific matches (using regex). If a match is found, the app would notify you in some way (Growl, dock bounce, etc.)
• Nice display of log entries (subtle zebra stripe perhaps? Color-coded, or color icons to easily distinguish between errors, warnings, debug, etc.)
• On the logs that you aren’t currently viewing, show the number of unread log entries for all other logs that you’ve subscribed to – just like a feed reader
• Ability to organize logs in folders, and rename them (without actually renaming the actual file)
• Perhaps some sort of integration with IDE’s, like Eclipse, Aptana, Netbeans, etc. that would allow you to click on a particular error if there is a file and line number in the log, and it would take you to the error in the file
• Ability perhaps to also monitor log files on servers (if proper credentials were given to access them)

If you think that this would be a good idea, and something you would be really interested in having, please leave a comment. Also, if you have any additional ideas that would make this app even more useful, post a comment for that too.

If you would be at all interested in making an app like this, while I do not know cocoa or mac app development, I would love to help in anyway I could.

When you build a module, it typically goes in app/code/local/YourName/YourModule/. Magento’s modules live in app/code/core/Mage/ModuleName/. Your modules should basically follow the same exact format. So, as of Magento 1.4.1.1, you have 57 different modules to look at as examples. For most things that you want to be able to do, there is probably a great example somewhere in the core modules for you to learn from and re-factor for your own needs.

If you are going to build modules, then learn how Magento does it and build them properly! I am tired of seeing modules that require a file in itself to be writable (because they didn’t want to take the time to figure out how to set/get configuration from the database), or “modules” that are nothing more than files to be put in the app/code/local/Mage/ directory to directly override core files, or modules that have such jacked up file/folder structure that you can’t even tell what’s going on.

Honestly, there is no better method that I have learned Magento development from than looking through the core modules. You will not regret spending time doing that if you wish to be a better Magento developer.

I will probably have more posts on this eventually, so forgive the lack of information in this post. I just wanted to get the word out there at least that I am extremely impressed with Nginx. It is blazing fast. Just today I ran an import of just over 26,000 customer records, and it completed it (importing 5 records at a time) in under 30 minutes. That’s fast!

So you may want to check it out if you are interested in a much, much faster server environment for Magento (and for anything else for that matter).

I just started up a new Magento project, and the design/skin files that I received from the client were littered with .svn files. I hadn’t noticed that at first, so I ended up committing them. Here’s what I used to remove them all:

find . -type d -name '.svn' -exec git rm -rf {} \;

mysqldump -u [user] --password=[password] databasetodupe | mysql -u [user] --password=[password] newdatabase

I did some Googling around and came across someone that seemed to have a similar issue, though not with Magento. So I figured I’d give it a shot. Well, it worked. The unfortunate part is that, being not all too familiar with how all this configuration stuff works, I don’t know why it works (if you know why, please let me know).

The Solution

Open up your php.ini file (mine was in /etc/). Look for the following line:

pdo_mysql.default_socket=/var/mysql/mysql.sock

If that line exists for you, try changing it to:

pdo_mysql.default_socket=/tmp/mysql.sock

Restart apache after saving, and that’s all I had to do. One thing to keep in mind though is that I am using the stock php (with 10.6), and I’m using mysql installed with homebrew.

$form = new Varien_Data_Form(array(
    'id'        => 'edit_form',
    'action'    => $this->getUrl('*/*/save', array('id' => $this->getRequest()->getParam('id'))),
    'method'    => 'post',
));

After looking at it with co-worker of mine, the answer to the problem was quite easy. Form encryption type. In order to upload files, you need to have ‘multipart/form-data’, so adding one extra line to the form parameters did the trick:

$form = new Varien_Data_Form(array(
    'id'        => 'edit_form',
    'action'    => $this->getUrl('*/*/save', array('id' => $this->getRequest()->getParam('id'))),
    'method'    => 'post',
    'enctype'	=> 'multipart/form-data',
));

So, if you have any modules that deal with uploading files, be sure to add the encryption type to your form.