Idea: Github Integration with Magento Connect

There has been some discussion about Magento Connect lately, so I wanted to help keep the momentum going with a suggestion of my own.

The current system that Magento uses isn’t horrible, but it isn’t great either. One thing I would like to see is some kind of integration with Github. Many of use use github to store our extensions because we like open source and enjoy providing them to the community. Honestly, keeping an extension updated on Magento Connect is a tedious process, especially if we already keep it all updated on Github.

One example of this is modman. It is an incredibly easy-to-use system, and it pulls all the needed files from github and installs them in the proper locations with a simple command. Through the use of the Github api, you could access the readme for the module description, see when it was last updated, see how many active issues there are, etc. Perhaps there could be a specific file that could be added to every repo that would tell Magento Connect the information it needed, similar to the way modman does it, but with additional information.

I think this would be great, and the goal ultimately would be for an extension writer to be able to add their github repo of their extension once, and then from there it’s just a matter of keeping the repo up-to-date, and all changes made to the repo master branch would update Magento Connect dynamically.

Supporter of the idea or have additional thoughts on this? I’d love to hear your comments.

Posted in Git, Magento | 8 Comments

Prattski_SimpleDevToolbar – Improvements

When I first initially released the Prattski_SimpleDevToolbar, one thing I overlooked was the ability to enable/disable it. I have now added the ability to do that, as well as added the ability to make it only viewable by specified IP addresses.

The changes are now up on Github where you can download the Prattski_SimpleDevToolbar extension.

Posted in Magento | Comments Off on Prattski_SimpleDevToolbar – Improvements

Magento Extension: Prattski_SimpleDevToolbar

Yes, this is yet another developer toolbar. There’s plenty of them out there, but I wanted to make my own. Being able to see all the tons of information available for each page is nice, but I often don’t need all that information. I mainly just wanted a quick and easy tool to do the things I wind up going to the admin to do and taking 3+ steps to do it.

The challenge I created for myself had 3 requirements:

  • Be available in the admin and frontend
  • Require no templates at all
  • Do the few tasks I wanted it to do

I was able to accomplish all 3. A big thing I dislike about many of the other dev toolbars is that they often require you to put code in header templates, or modify other templates. I find this annoying for a tool like a dev toolbar because it makes it more annoying to install into projects that already have those templates modified. With the method I used, you can install it into ANY Magento site without conflicting with anything. And, the same code doesn’t have to be repeated to be displayed both in the admin and the frontend.

This extension provides quick access to the following:

  • Toggle Logging
  • Toggle frontend template path hints
  • Toggle profiler
  • Toggle all cache types
  • Flush cache if cache is enabled
  • Mark all unread admin notifications as read

I have this extension up on Github, so you are free to check it out, post bugs, post feature requests (but remember, this is a ‘simple’ dev toolbar, I don’t want to make it all crazy packed with things – but I am open to new ideas), contribute, etc. I hope you find it useful.

Posted in Magento | 3 Comments

New Magento Developers Meetup in Austin, TX

I moved to the Austin, TX area nearly 3 months ago, and upon arrival, I started checking out to see what was around for Magento-related groups. I found one and have attended twice, but the group wasn’t quite what I was hoping for, which was more of a developer focused group. About half the group typically has little to no development experience with Magento, so when it comes to discussion topics, it can difficult for everyone to be on the same page, especially with topics surrounding development.

The leader of that group is a great guy, and he and I talked about my thoughts on this, and we both agreed it that it was a good idea for me to start up a new Magento Developers Meetup in Austin, focused on developers. So, I have done just that! Announcing the Austin Magento Developers Meetup. The first meeting will be held on Thursday, September 27th at 7pm. If you are a developer in Austin, please come and check it out.

My hopes for the group are to have a group discussion about any variety of Magento development topics, as well as a time where we can all work on Magento together and learn from one another. I hope to see you there!

Posted in Magento, Meetup | 1 Comment

Wrote My First Magento 2 Module

It has been exciting to take a peek at the Magento 2 code now and then, and to view the changelog as new things are being added or modified. I figured it was about time to get a copy installed and create a module to start to learn the differences.

I have a simple developer toolbar module that I wrote that adds the bar to the top of the page, both in the admin and on the front end, that allows you to toggle logging, template path hints, profiler, cache, flush cache if on, and mark all unread admin notifications as read (if there are any). The module uses no template files at all and is all self-contained, so no matter what your design is, it always works.

Calling Models/Blocks/Helpers
The first noticeable difference is the way you call models, helpers, blocks, etc. No more shortcut, xpath-y style of calling things. You need to use the full class name now. Here are a few examples:

// Magento 1.x
// Magento 2

No More app/etc/modules/Your_Module.xml
That’s right, there are no more separate xml files for each module in app/etc/modules. Instead, you simply add the xml tags into the module’s config.xml file. At it’s most simple form, that simply means adding the active and codePool tags into your config.xml:


No More Declaration of Module’s Models/Blocks/Helpers
In Magento 1.x, if you wanted to have your own model files for instance, you needed to declare that in your config.xml with code like this:


There is no longer any need for this due to the using of full classnames when calling models for instance. This really simplifies things and helps remove some room for error when writing modules.

Many Events Have Changed
The other difference is that the event that I was observing was no longer an event. I was extremely surprised to find that there was a different event that provided a LOT more flexibility and a LOT more options for doing cool things with it. I initially was frustrated when I found out that my observer wasn’t firing, but was thrilled to find out that Magento only made a way better option. So, as you begin to experiment and port your modules over to Magento 2, be slow to get frustrated. A lot has changed, and so far from my experience, it has been for the better!

I will continue to post more as I experiment with Magento 2.

Posted in Magento | 6 Comments

Magento Dev Best Practices: Module Readme Files

This is the third post in a series about Magento development best practices, and it is about readme files. How often have you opened up a module’s directory and all you see is folders? That is the case the majority of the time. The only way you can possibly know what a module does is by finding the original download (where they may have included a pdf or something), or perhaps if you are a developer, your company has a wiki or something for the project where the module was documented. You could also look through the code to figure it out if you are a developer, but that can take time. Chances are, there’s no or little documentation where you need it.

This is really a bummer and it stinks for the Magento community that this is so common. In my opinion, the best place for documentation is to keep it right in the root of the module itself. I think it’s best to make it a txt file or something that can be easily opened in an IDE and easily modified. A pdf looks nice, but is not ideal for continued updates to the documentation if the module is ever updated.

My practice is to create the readme.txt file in the module root right after I create the module directory. I then make sure to continually keep it updated as I progress with the development of the module. That way it’s always up-to-date, and it’s not a pain to take the time to write it all after I’ve written the entire module, as well as you won’t forget about certain points or aspects of it either.

Readme files contain not only information about what the module does and how it functions, it also includes how to use it from every possible perspective (frontend, backend, how to use it’s methods/helpers if needed, etc.)

I encourage all of you to make a regular practice of this. I guarantee it will help you, your team, and anyone else who ever uses your modules.

Posted in Best Practices, Magento | 2 Comments

Magento Dev Best Practices: Code Commenting

This is the second post in a series about Magento development best practices, and it is about code commenting. High up on the top list of shortcuts developers take is failing to properly comment code. And, the excuse, nearly every time, has something to do with being under a deadline and not having time.

You may save a couple minutes here and there, but ultimately you may cause many more minutes, hours, or even days by not properly commenting your code. I believe it should be the habit of every developer to make your file comment right when you create your file, make your class comment right when create a class, make your function comment right when you make a function, and comment about functionality within as you go. If you do it as you go, you won’t forget to do it later, and you won’t forget about what functionality might be doing. You’ll never have to spend the painful time to go throughout your entire module you just wrote and comment everything.

Properly commented code has the following benefits (and plenty more):

  • Makes it easy for you to understand/remember what your code is doing should you need to modify it later
  • Makes it easy for someone else to understand what your code is doing if they need to modify it
  • Looks great and shows professionalism
  • If you do it using a standard like PHPDoc, you can easily make documentation automatically from your code
  • Assists in IDE code completion

The standards I follow for myself and I encourage teams that I am a part of do do as well in terms of Magento module development:

  • Commend EVERY file, even if it’s an xml file, template file, etc. Every file has my modules file doc block at the top. Very important is the @author tag so we know who’s worked on the file
  • Every class has a doc block title and description if necessary
  • Every function has a doc block describing what it does
  • Within functions, template files, etc., there are many comments explaining what is going on and why certain things are happening to make it very clear and understandable
Posted in Best Practices, Magento | 3 Comments

Magento Dev Best Practices: Team Coding Style Unity

I recently led a discussion at the Austin Magento Meetup group on Magento Development Best Practices, so I figured I would start a small series of posts about it. To start it off, I’d like to start with team coding style unity.

Unless you are the sole developer on a project, this is an important topic. I find it incredibly annoying to open up a file that is formatted completely differently than I do it. I know it is easy with an IDE to reformat it, but having to do it over and over again (thus causing your teammates who have different styles than you to have to reformat it back) is very annoying.

I highly suggest getting the entire team onboard and adopting a specific standard. Since Magento is built with PHP, my suggestion is to adopt and follow the Zend Code Style Standards. It is already all documented and well thought out, so you wouldn’t have to create your own document for it all and keep it maintained. To make it even more enticing, Magento follows these standards for the most part anyway.

Getting your team united in code style will not only make the team development experience more enjoyable, it will also promote the creation of good quality code (as long as you are using a good standard!).

Posted in Best Practices, Magento | 2 Comments

Magento: Programmatically Modify Attribute Configuration

Today I was asked programmatically modify a product attribute so that it was no longer searchable, and make a different attribute searchable instead. I wrote up the code and put it on our database updater module to run as an upgrade script, but you could put it anywhere you want. To modify an attribute, you can do the following:

// Method 1
$model = Mage::getModel('catalog/resource_eav_attribute');
$model->loadByCode(4, 'color');
if ($model) {
// Method 2
$attributeId = Mage::getResourceModel('eav/entity_attribute')->getIdByCode('catalog_product','color');
if ($attributeId) {
    $attribute = Mage::getModel('catalog/resource_eav_attribute')->load($attributeId);

You can see I used the setIsSearchable() magic method to set the the ‘is_searchable’ for the color attribute to 0, which is “No”. You can change whatever you want and then save it and you are good to go.

If you want to know what options you can change, load up the attribute, and log/output $attribute->getData(). It will show you all the current settings.

Posted in Magento | 3 Comments

Magento: More Flexibility For Your Layout Updates

I’ve been working on a project with a lot of requirements for certain templates or javascript to be added based on a lot of different conditionals and situations that the standard layout xml files do not really allow for. Fortunately, there are events and methods that you can use to add in xml on the fly without the need for layout xml files, allowing the ability to add in logic as to what and if something should be added or not.

First thing you are going to want to do is create an event observer to observe the ‘controller_action_layout_generate_xml_before’ event. That event will provide you with the layout object. By accessing the Update object from the layout, we can easily add in our own update:

$layout = $observer->getLayout();
    <reference name="content">
        <block type="module/block" name="" template="your/template.phtml" />

If you wanted that block only to be added if the customer is not logged in, you could wrap the code in a conditional. You could get quite creative with this in implementing all sorts of cool functionality as we have done on our project. I hope this provides the tool to get you started!

Posted in Magento | 2 Comments