Commerce Bug 2.5: One Click Layout Graph

Just a quick note that Commerce Bug 2.5 is out, official boring press release-ish announcement here, free upgrade for registered users, and a screencast of the one new feature below.

I know Magento 2 is the new hotness, but Magento 1 sites will be with us for long time. Commerce Bug remains a programmer’s best weapon against the insane complexity of most half-assed Magento implementations that your business development folks foist on you. If you haven’t bought your copy yet, it’s your funeral.

Some Notes on Graph Rendering

Commerce Bug has long had the ability to create a text version of a directed graph of the layout. If you knew about programs like Graphviz, this was a super useful feature for quickly understanding a page’s layout structure.

Unfortunately, lots of developers don’t know about programs like Graphviz, and not all of Commerce Bug’s buyers are developers. Even for folks who do know about Graphviz, the process of copy/pasting the graph text into a file and then rendering that file created friction. Layout graphs were/are a super useful feature, but the initial implementation was lacking.

Tree vs. Graph

The high level solution is obvious — handle rendering the layout in Commerce Bug itself. Coming up with the right implementation for this feature, however, was more difficult that I first imagined.

Magento’s layout is often described as a series of nested block objects. If this were 100% true, a UI/visualization would be simple. Just grab one of the many javascript tree layout implementations and call it a day.

Unfortunately — while Magento’s layout is a series of nested block objects, it’s a self modifying series of nested block objects. This means that

1. Magento creates a tree of block objects, and starts rendering the root block

2. When every block renders, it can potentially create its own blocks

3. When every block renders, it can potentially add, remove and move blocks in the layout

This means every block doesn’t always have a clear parent block, or a single parent block. These are more than theoretical concerns. Either via deliberate developer cleverness, or via the inevitable result of hiring 1,000 monkeys to bang on a keyboard until a store falls out the other end, all of these scenarios are common in production Magento systems.

This means a standard tree UI wouldn’t be an accurate representation of the layout. If this were a corporate driven project like Z-Ray, I’d probably have just shipped the tree UI and called it good enough. However, people don’t buy Commerce Bug because it checks a feature off a list — they buy Commerce Bug because it actually makes working with Magento easier.

This dilemma is what led me to using a directed graph in the first place. The language of a graph allows me to come up with an accurate layout visualization that clarifies Magento’s layout without resorting to oversimplifications or computer lies.

Finding a Graph Renderer

Development being one dilemma sprouting multiple new dilemma, this meant I needed to find a way to render a directed graph in a browser. While graphs are one of the first problems industrialized computer science set out to solve, and there’s lots of code out there that makes sense of graphs, little of that code has made it’s way into a form reasonably and easily consumable by the average web browser.

There’s lots of libraries that model directed graphs (nodes, edges, the relationships between them) without actually providing a visualization layer. Visualization layers do exist, but they tend to be focused on flashy animations or high level views of huge data sets without providing a good UI for analyzing the specifics of the graph. There’s even a few <canvas/> renderers, but performance of these was abysmal, and the UI/UX problem of navigating a large graph still exists.

At the end of the day, the best visualizers were desktop applications like Graphviz, or converting the graph to a neutral format (gif, SVG, PDF, etc.) and using a separate tool to view the graph.

Deciding on a Webservice

Interestingly, possibly ironically, and certainly tangentially, it was Zend’s new Z-Ray extension that provided me with the final bit of convincing that a web service graph renderer was the right approach.

There’s lots of smart people working on Z-Ray, but it’s ultimately a corporate product, and a corporate product will never be able to go as deep as framework specific debugging extensions. Z-Ray may have a great Symfony plugin, but that plugin will never be as good as the native Symfony debugger.

That said — once advantage Z-Ray does have is in-depth platform insights. While it only runs on systems using the Zend Server platform, that deep platform integration gives them insights into what people are actually doing with the platform. This means Z-Ray has Zend Server specific features that no one else can match.

That sort of insight is one of the less talked about benefits of cloud based platforms. Shifting corporate examples, a company like New Relic doesn’t need to ship a perfect monitoring platform out of the gate — they can ship a pretty good monitoring platform and then adjust it as they get real feedback from real users using the system.

Up until now I’ve been very wary of getting into independent application service provider, software as a service, cloud platform development. I’ve always modeled my projects on the desktop software model, in particular the Mac OS software model. Deliver people a set of bits that help them do their job — deliver the right bits and you’re selling cost free widgets. I still believe in that model, but not taking advantage of what a cloud based platform can do is hurting my users, and ultimately hurting my business.

So, in addition to giving my Commerce Bug users the ability to instantly render a layout graph — Commerce Bug 2.5 is me dipping my toe in the cloud computing pool. For now I’m keeping rendering free of any monthly costs, but that may change if hosting costs start becoming a burden.

As always, thank you for reading, and thank you for buying the digital products I create. Those sales directly fund my writing here, and I’m forever grateful for what they do for my career.