The next edition in our ever continuing development for the perfect banner manager is out. While we still have a few more features on the road map, we’re proud to announce we now have true multi-store support, but not just basic multi -store, but true EAV multi -store, like Magento users are familiar with in the catalog. We still have to update all the screenshots and demo store, but here’s a few from the latest version.

NOTE: You should never have to override a layout file. All layout updates should be done in the local.xml. for more information on layout updates. Check out http://neoware.com.au/magento/inserting-and-editing-layout-blocks

When (most) code files are stored in Magento, they are loaded by the Mage PHP Autoloader, and as such must follow a strict naming convention, this does make it very easy to find a file given only it’s class name however.

We’ll take a standard Magento core file for this example.

Mage_Widget_Model_Widget

Because the Widget Module was added later on in the life of Magento, it serves as a very good example of a module.

Firstly, if you know which code pool it’s located in we can start from there, but because we’re starting for scratch, let’s find the code pool from configuration.

Lets start in app/etc/modules/Mage_Widget.xml

Note: a lot of the Magento core modules, have a single activation file, Mage_All.xml.

Firstly, we can see in that file, under the codePool it’s letting us know it’s in the core folder.

app/code/core/Mage/Widget/Model/Widget.php

This is case sensitive, so if you’re developing under a windows environment, make sure you are strict, or once it’s run under a Linux environment everything will break.

All the underscores are converted to slashes, with the last word always being followed by .php, and the file path is complete, very simple and very effective.

Magento is a configuration based framework. So knowing how all the config.xml files go together is pretty important. In a module, there are 2 major configuration files, with many more optional ones.

Recommended Reading:

Module Activation File:

The Activation file is the file that activates the modules, and tells Magento, where to look for the module, as well as dependencies.

The Activation files are all put in app/etc/modules/

Technically, it doesn’t matter what you call this file because all files in this folder are parsed, but the naming convention is Namespace_Modulename.xml. Inside the file however, does matter.

<config>

<modules>

<Namespace_Modulename>

<active>true</active>

<codePool>community</codePool>

<depends>

<Mage_Catalog/>

</depends>

</Namespace_Modulename>

</modules>

</config>

active:[true, false] this actives or de-activates the module. Note: this is the only place that you can truly deactivate the module. In the backend, under Configuration => Advanced => Advanced => “disable module output” will NOT disable the module. It merely stops that module from outputting any html to the page. This is the way to disable a module from showing without breaking functionality, but in most cases, when you need a module disabled, you will have to find the module activation file.

codePool: [local, community, core] note the capital P here, codepool as a variable will not work it must be codePool. This is the root folder Magento will look for this module in. The code pools are loaded in order: core, community, local. Any overrides you wish to do with modules should be done in local.

depends: [ (Any other Module Namespace_Name)] this is the list of dependant modules that must be active and loaded before this module can function. Magento does checking on this variable so make sure your module includes all the relevant dependancies.

Module config.xml

The next most important configuration xml files in Magento are the module etc/config.xml files.

Once the Module is activated, we can then start building out our module.

app/code/community/Namespace/Modulename/etc/config.xml

We start with a declaration of which module this will match the module activation file exactly, then state your version number.

<config>

<modules>

<Namespace_Modulename>

<version>1.0.0</version>

</Namespace_Modulename>

</modules>

<global>

<models>

<modulename>Namespace_Modulename_Models</modulename>

</models>

<blocks>

<modulename>Namespace_Modulename_Blocks</modulename>

</blocks>

<helpers>

<modulename>Namespace_Modulename_Helpers</modulename>

</helpers>

</global>

</config>

global: [models, blocks, helpers, resources, index, events, eav_attributes*]this is all the configuration that defines the global specs of the module. There are a few areas in magento that override each other, but this is the global config.

*eav_attributes can be defined in configuration, but it is more commonly accepted to put them in your resrouces setup script.

global : models: [modulehandle => classname] Here is where you are defining where Magento is to look to find you code for all your models. Because of the autoloader in Magento, you’re both defining a path and a Class name, by doing this, for Magento to load this class, it must be in the correct path name for the autoloader to find it.

global : blocks: [modulehandle => classname] Here is where you are defining where Magento is to look to find you code for all your blocks. Because of the autoloader in Magento, you’re both defining a path and a Class name, by doing this, for Magento to load this class, it must be in the correct path name for the autoloader to find it.

global : helpers: [modulehandle => classname] Here is where you are defining where Magento is to look to find you code for all your helpers. Because of the autoloader in Magento, you’re both defining a path and a Class name, by doing this, for Magento to load this class, it must be in the correct path name for the autoloader to find it. Note: with helpers, the default helper will always be Data.php

Module Rewrites

Note: Most module rewrites aren’t actually required, with many situations able to be solved with events in Magento, to use events to extend functionality.

This is Magento’s take on the Standard Factory Methods that you see in many other frameworks. Because Magento is so heavy based on configuration, even the class factories refer to the configuration before loading. This means, that every module in Magento can be extended or completely overwritten with ease, without breaking functionality.

Module rewrites are all configuration based.

<global>

<models>

<catalog>

<rewrite>

<product>Namespace_Modulename_Models_Product_Override</product>

<rewrite>

</catalog>

</models>

<global>

When Magento reads its configuration files, every module is parsed into one (very big) configuration file, and pushed through to the appropriate code handlers.

Events

With PHP not natively supporting events, Magento has coded an events system that runs in the Framework, this is configuration based, unlike most event driven systems. To register an event observer with the system, you need to specify it in your configuration file.

To find which event you need to use as a handle, you need to find it in code, which to be honest can be very time consuming. There are some default events that occur on several load points, however I don’t have a list for you here, with many occurring in the abstract layer (meaning that any class that extends from those classes also trigger those events).

There are a few rules about observers though, the model that you specify in the configuration, just has to be a normal model (however the convention is to have one observer class named observer), and can contain any function, as long as it has a parameter type declaration within the function, like below.

function onCatalogAfterIsSalable(Varien_Event_Observer $observer){

$productToEdit = $observer->getProduct();

$productToEdit->setName($productToEdit->getName() + “ Is Awesome”);

}

Any Change that’s done here is persisted on that entity that was passed to it, so when you’re done there’s no need to return anything.

There are several important pieces of information to know about layout blocks before you can properly use and understand them, firstly, check out how to resolve the Magento Block from the Block Type.

Blocks

If we take a peek at a layout file in Magento, you’ll notice it’s very similar to the structure of a HTML layout, with different parts of the website grouped together and children being added afterward. This snippet is taken from the page.xml in Magento 1.6.1 focusing on the “default” handle, for more information on handles

Magento layout is made of Blocks. Not Pages. By that I mean, when you hit a page in a Magento store, Magento doesn’t go looking for a page as such. Instead, it loads the layout xmls, combines them, and finds your route. In that route, it contains the blocks shouldn’t be loaded, and which should be, which Magento then loads.

There are a few major attributes to each block

Type: This determines the code* being run for the template to use. To understand exactly which file is being loaded here, you must first understand the module naming convention and module config.xml.

Name: This is a unique identifier for this instance of this block type. I.e. if the block was going on the left hand side and was a random products display, you might called it “content-left-random-products”

Template: This will be the file everyone with HTML experience will understand. This is the output for the block. However, there are certain overriding rules that Magento has in place that need to be understood before any modifications are done to these files.

Before and After: This is a very convenient way of positioning a block. You simply put in the name of the block you want this block to come after (or before) and it’ll position it accordingly. For positioning the block before or after everything use – as the name.

Eg: say you want to position something at the start of the content block.

<reference name=”content”>

<block type=”core/text” name=”sometext” before=”-“>

</block>

</reference>

*note: Magento has a way of defining modules and their blocks. Read

Blocks are a two part system, there’s the code block, and the template. From that Code file, it prepares the data, and includes the template to be parsed. All information available in the template comes from the code block.

There are two types of blocks in Magento, Layout Blocks and Output Blocks.

Structural Blocks

Structural Blocks are blocks that hold a position in the layout xml. Each block is assigned at minimum, a type and a unique name. Structural blocks may or may not be outputting themselves, but they will output child elements. These blocks appear in the Skeleton Html Template. We take this image from the Magento Design Guide

For the core/text_list, it does nothing but render its children. These blocks are generally used as Structural blocks in default Magento themes.

Note: Not all blocks render all their children. This is dependent on the template file it uses, and whether the “getChildHtml” function is called.

Content Blocks

Content blocks are blocks that are outputting something that isn’t a child block. For content blocks to render child blocks they need to implement the “getChildHtml” function, which in turn renders the child block, and if that child implements the “getChildHtml” function and has child blocks, they’ll cascade and be rendered too.

References

Magento’s layout system is something to be respected. Not only can we add blocks via the default layout files, but we can add our own, or remove default functionality all in one file. A proper Magento design should only ever use one xml. This is due to references.

Note: Magento themselves do not stick to this convention in both their default and modern themes, but this is correct syntax.

When a reference is used, like the example above, it will treat the code inside the local.xml as if it were inside the left block in the page.xml, and add the “randomproducts” block.

Action – method

The Action Tag is a way or running code from the block type, after it’s instantiated. Any method that is available to the block class, can be run in layout xml. For all the developers out there, the variables passed into these functions, are passed, wrapped in any tag.

Some basic, and very useful functions that will be available on every type of Magento recognised block are:

<action method=”unsetChild”> <name>poll</name></action>

Remove

The remove xml is a way of removing (completely) the position or the block in question. Instead of unsetting the child block from the parent block (yet still keeping it in RAM), you will stop the block from being instantiated. When you remove a block, you prevent all subsequent children of that block from being instantiated. This is mainly used if you’re optimising your theme for speed, but it should be used with caution.

Note: once a block has been removed it cannot be re-added further on down the code. (you call remove in the default handle, and all other handles will not have access to that block).

<remove name=”left”/>

Layout / Template overrides and when they should be used.

Layout overrides are a way of overriding the core files. If you place an xml with the same name in your layout folder for your theme, you will override the default files. If the designer truly understands layout xml, this should never have to be implemented. Do not use this if at all possible, as soon as you go to update Magento, you will be sure to have your theme break.

Template overrides however are a necessity to a fully customised Magento store.

To find out more about theme overrides check out

The all-important local.xml

The theme local.xml (app/design/frontend/YOUR PACKAGE/YOUR THEME/layout/local.xml) is the final word on what gets rendered. Again, a good Magento Designer should only ever use one layout file, the local.xml. Except for extraordinary circumstances, all other overrides are considered incorrect, when Magento is upgraded, these will most likely break the site, if overridden completely. The local xml should contain a lot of references, and this is where the before and after tags come into play. The following example, we’ll insert the random products module after everything in the content module. This is where we make our edits and additions to the layout xml.

Routing in Magento lets you extend Magento in a way that seamlessly integrates in with the Magento system. When routes are setup correctly, a user of your module can access your modules information by typing in something like http://www.thewebsite.com/yourmodule/.

Whether you’re building a blogging extension or something a lot more complex, a lot of the time, users need direct access to a view that you’re creating.

Routes

In Magento, there are a few rules to routing and controllers, but once they’re setup, it’s very expandable with minimal effort.

use:[(string) standard, admin]: This is the type of route that you’re wanting. If admin, this is prepare the admin layout and provide an area for you to insert your content. If standard, magento prepares the frontend layout and then loads your content.

args: module[(string)(Module Name)]: This is the Module name that you’re routing to, this should be the same name that is declared in the declaration/activation xml (the xml located in app/etc/modules) for your module.

args: frontName[(string frontname)] : The frontname is where your route starts, by convention this name should be the same as your module handle (in the example above this is called “modulename”)

The front name is the variable that you should pay the most attention to. Once this is set, your module will be accessible from the browser (provided the controllers are in place to catch the request)

*note: if you don’t have url rewriting turned on this will always result in a 404, in this case try using http://www.thewebsite.com.au/index.php/modulefrontname/. If it still doesn’t load then, and your configuration is correct, remember to flush your config cache in the backend. (System => Cache Management)

And if we take a peek inside a controller they have to follow a convention inside as well. Note: this class is named slightly differently to normal (it’s missing the “controllers” part in the class name) this file is loaded differently from the autoloading modules and blocks.

anotherAction is simply a redirect for the index action, when “*” are used in the route path, it means “current”. In this particular redirect it’s stating “current module”, “current controller”, “index action”. This is only an internal pointer, and won’t work in the browser. Don’t be shy about using the redirect directive, if you end up in a redirect loop, it will escape out and tell you after 100 redirects.

It’s important to note here, that the layout will only load if you’ve instructed it to do so, any controller actions that need to fit in to the rest of the magento store, need to call $this->loadLayout() and $this->renderLayout();

Setting up Admin Controllers

Overriding controllers is an important part of extending functionality. Thankfully, with Magento (the latest versions, anyway) this is a breeze.

In this example, we’ll override the Mage_Adminhtml controllers so that we can have our module, coming up in the admin like:

Fatal error: Call to a member function getLabel() on a non-object in /home/mystore/public_html/store/app/code/core/Mage/XmlConnect/Helper/Theme.php on line 143”

ok, so we had the same problem on a few of our client's websites. After a bit of poking around, we figured out, that some Magento installations (especially ones that have been upgraded from an older version of Magento, have this folder:

\media\xmlconnect\themes

rename or delete this folder and it'll work fine.

It's searching for themes because the folder exists, in ours we found 2 themes, test_white and test_black. (Obviously not a default one) once we deleted this folder (or renamed it) it'll generate the missing files for you.

The first (and probably the most "brute force") way is to put it in the local codepool:

app/code/local/Path/To/File/To/Override.php

Magento's autoloader loads the codepools (located at app/code) in the following order

local

community

core

So any files with the same path in the local code pool will be loaded before the files in the core. When Magento is upgraded, you'll need to make your changes to your local override if the core file is updated.

First thing you do is check the error log only to find that the error is a “0x000000ff”, which in laymans terms is a memory error. Which doesn’t give you a lot to go on. After a bit more digging (by turning off all of my installed PHP modules, I’ve found that it was my pdo_mysql extension, which Magento uses regularly.

The first thing you should do is check that your PHP binary is compatible with the extensions you’ve got. If you have no idea, go and replace your whole PHP install and re-associate the handler for it.

To do that firstly go get yourself the thread safe version of PHP from http://windows.php.net/download/ (unless you’re really needing non thread safe, in that case you’re a little on your own).

For all of you that have ever tried to code for joomla, you’ll know that information is either very abundant, for simple questions, or non-exisitant, for anything more complex. If you’re anything like me, you find yourself scurrying through pages and pages of search results, only to say “stuff it” and go file by file through the source code to find what argument you’re meant to be passing into some rarely used Joomla Function.

One such API is JTable. And although Joomla give you a nice littleHow To: JTable I still find myself having to var_dump() the results to find out how it’s returned and with so many questions. Ok let’s continue from the How To Guide.

Awesome! I love Blueberry Pie. But that’s beside the point. We go back our object, so we can access this easily with $row->id or $row->recipe_name That’s all good, but what about multiple rows? Well. That’s the problem. Everything about the JTable Class only deals with one row, as soon as multiple rows are involved, you have to use:

So maybe they missed a little in that How To Guide. A good example is at http://docs.joomla.org/JTable/bind. After the data’s bound to the JTable object, before we can save, we just have to make sure that we can save, a quick check(), lets us know.

The update $updateNulls variable is the option to update the database value to a NULL, when the Object has a NULL in the data. When set to false (by default), the variables that are NULL aren’t updated.

This should help out a little when it comes to JTable. I’ll cover the creation of those tables in the future, but for now. This is Tony signing off.

of course you could do this in one line but remember that you're loading a whole entity here so if you need to use any other data from the attribute set, it's probably not optimal to run this every time

When establishing the form object, you’ll need to set 2 variables on instantiation, the ‘method’ and ‘enctype’. For anyone familiar with html forms, this should be second nature. This sets the form to post the data in a “post” method, and tells the browser that there’s going to be data in the format of a file being transferred. It’ll look for that data in the “file” input type within the form.

Once it’s submitted you’ll need to save the file. In this example, I’ve written a function to upload an image to the media directory [This hasn’t been tested, so anyone that wants to poke holes and correct it, let me know and I’ll correct it]:

//this allows the uploader to rename files if it has to. Essentially, if you’re uploading an image, //where you could run into a conflict, this should be true. But if you’re uploading a pdf for // instance, you’ll want to replace that pdf next time it’s uploaded. $uploader->setAllowRenameFiles(true);

I came across a link to a talk that about Magento 2 the other day. It was dated back in October last year. But what they have to say is still very relevant. You can find it here. (http://www.youtube.com/watch?v=SbAHSZiml7g)

Aside from the obvious rundown of the Magento 2 rollout plan (or lack of); they also went into great detail about what they're looking at doing for the new version, including several coding restructures. From a user point of view the initial version 2.0 is going to be identical to the in functionality to their Magento 1 counterpart, I assume it's going to look a bit prettier.

The theming in Magento 1.0 provides a lot of functionality, so I’m not sure if I totally agree with simplifying the theming, but it would certainly make it a lot clearer for a novice user, which is what they’re aiming at doing. They’re replacing the package system with a single field. I’m not sure about the specifics of this yet, but they also mentioned that you can have unlimited fall-back themes. I’m really interested in how they’re going to implement this, but at this preliminary stage, in the theme.xml it looks like they’ve added a lot more settings for developers.

Inline layout editor. Those 3 words are either going to excite you, or send chills of horror down your spine. If you’ve used Magento before, as a novice user, you may have found it really difficult to change the page without going into layout file editing; and even then, most users (even some developers we’ve seen), modify these files incorrectly. The inline layout editor will enable user to “drag and drop” block elements on the frontend and easily change the layout of the site. Like all things “what you see is what you get” (WYSIWYG) if it’s done correctly, we’re going to see advanced functionality and nice, neat, clean files on the output. But most Web developers know the horror of output they get from, even good, WYSIWYG editors; most of the time it results in turning off the editor and putting in straight HTML.

Responsive Base Theme

A big challenge to most web developers recently is tackling the ever expanding mobile computing era. From tablets, to smart phones, to TVs, we’re seeing more and more resolutions pop up out of the blue. And that means your beautifully designed website that works just fine on the desktop, is almost unreadable on your tablet, and even worse on your mobile. This is where the responsive base theme comes in. By default, Magento plan to make their theme adaptable. As you change the resolution, it changes the way that it displays. In my opinion, this is a good thing. I know that sounds obvious. But it’s a bit like what Google’s done to every other search engine. Set the bar really high. It’s going to make it harder for Magento theming companies (like ourselves) to them every view, and make sure it all works, but from the user point of view, and the store owner point of view it’s only going to bring more stores in line with the latest in web technology, which ultimately pushes the industry forward.

Simplified Config with valid XML

If you’ve ever coded a module, or used Magento as a developer, you would’ve experienced the large learning curve associated with it. This learning curve is mainly due to the amount of configuration that is able to be set within Magento modules. In Magento 1.0 you set everything in configuration, including the folder structure, database connection, admin menus, access control, entities, installation resources, the list goes on for a while, so I won’t list is all here. Although it provides a lot of functionality, you do end up writing a lot of boiler plate configuration.

After a quick look into a module in Magento 2, they’ve:

Removed the module activation file (normally found in app/etc/modules/ and combined it into the module’s config xml. Less files = better.Removed the functionality to set the folder structure for blocks, models and helpers. I’m happy with this. I’ve been coding with Magento for over 2 years now, and not once have I ever needed to set these to something different.In the Video they were saying that on average it’s 20% less code. And that they’re making this a valid xml file. Do I hear a sigh of relief? Finally we can validate the file against an XML schema, before hours of frustrating diagnostics that usually result in lost hair and over-consumption of coffee.

The introduction of bootstrapping entry point code

A feature that I think is well overdue. Global entry point code or Bootstrapping code, enables different parts of Magento to act as one. The idea is that no matter if you're running the cron.php or you've got a symlink multistore setup, booting all runs through the same code. This enables a store to be disabled on the front end, cron, and any xmlrpc or soap services to be disabled as well. Again, well overdue. This isn't particularly revolutionary but its worth noting as a major feature add.

The removing of several core modules

Adminhtml is no more. It's been a long time. Its for the best. And we'll get you a new one. Ever since the controller override functionality that was introduced quite a few versions ago now, the Adminhtml module has been legacy code that's stuck around, and because of the timeframe that Magento have put on the rollout of version 2, we're seeing lots of code changes, most notably, dataflow (replaced with an import/export module), OSCommerce and the compiler. They've made it clear that they're expecting the community to create extensions to replace this functionality and that it won't be in the core code. Fair. To be honest I think there's a lot of functionality that Magento has included by default that really could be excluded, but hey. Who's complaining, right?

The API is something I have to say is, by the sound of it, going to be impressive. They haven't confirmed all of these extras just yet, but RESTful services based on model declaration were mentioned. So all you have to focus on is creating and declaring your module correctly and Magento will automatically make a WSDL and allow access to your module via the API. Pretty neat huh? Although the most interesting part of that talk was when they mentioned automatically making a legacy version when you update your module. Not quite sure how this is going to work yet, I’m sure there are more rules to come to enable this feature (like not altering the database in any major way, or having a conversion from one to the other, but its certainly something to keep your eye on.

Development on Magento 2 right now

Thinking of developing for Magento 2? Just. Don't. From what the team were saying, there are a lot of changes happening in the transfer of prototype to jQuery, particularly on the front end area. Together with a changing core code base, its really not a good idea to start developing anything at this point. Just wait until an alpha's released, but more preferably the beta. The team have indicated that there is going to be a long beta phase, so that gives all the developers plenty of time to convert your modules over when you can. Another big change coming from Magento for Magento 2.0 is the openness we’re seeing when it comes to the development process. Right now, if you’re a developer, you can find it on git hub (https://github.com/magento/magento2) and they’ve said they’re open to git pull requests. They've even been nice about the tools they're creating to assist in the transfer, so fingers crossed it won't be as bad as we think, but only time will tell.

The next version of nBlog has been released, fixing some of the bugs pointed out by the Magento Community, it now operates a lot more seamlessly with a single store setup, and is supported by PHP versions upto 4.3.27.

Neotheme has had a facelift and a new support portal, with live chat incroperated. Into our website and via our support portal (http://support.neotheme.com). Along with the switchover to neotheme.com, comes our developed new look.