Lee Bolding’s comment in the Magento certification discussion on Linkedin was too spot on to not repost:

…Certification would even the playing field a little – I see large agencies, with big clients and deep pockets, with no technical Magento skills, yet (somehow) they’re Enterprise partners. I see small outfits – just a few guys – with wizard Magento skills, but no exposure to either (Magento) Enterprise or larger clients. The end result is that large enterprise clients lose confidence, believing that the larger, non-skilled agencies are “the best of the best” (they MUST be, they’re partners!) whilst the smaller companies (with the wizards) fight to survive because they’re deemed to be unskilled (otherwise, they’d be partners).

Lee is right. Since I’ve talked with him a few times, I’m hoping that he is grouping Elias under that smaller “wizard” company label. We endeavor to do good work. We build complex extensions for Magento. And, quite frankly, we get hammered as a business on our bottom line. No joke. The thought of leaving Magento all together crosses my mind at least once a week. This consideration is fueled by conversations with agencies who make a killing off of other webwork that is, well, easy when compared to Magento.

Our best client in 2009 was an agency. They love us. They now hate Magento. So they stopped selling ecommerce projects to their clients because it was a pain in their butt. Building “regular” websites was more profitable. This is becoming increasingly common as developers forego the Magento learning curve in favor of easier wins.

Or is it a US thing? Magento isn’t as big here in the states as it is in Europe. A client told me that he estimates that there are maybe half a dozen firms in the US who are highly specialized experts in Magento. I know a Mage firm who bought a skype number for the UK and gets 2-3 calls/day from what seem to be higher end clients in Europe. Our module sales are stronger in France than in our own country, which might not be a bad thing since the dollar’s value seems to be deteriorating. We’re currently considering adding another storefront to our module store that is Europe specific to see what impact it has on sales across the pond.

Right now Magento feels like a mediocre hand in poker. Do you bluff your way through it or fold and cut your loses? Would forking over $5k to Varien to slap a professional partner sticker on the site draw in good clients who value Mage services enough to pay handsomely for them? I like Varien. I’m impressed after my conversations with Tim Schultz. I think Roy Rubin is brilliant. But can they create an ecosystem that provides a return on the investments from developers in the community? Jury is still out.

A discussion about Magento certification popped up on Linkedin this week. My intended comment quickly evolved into a blog post:

The issue at hand is rooted in supply/demand. There is latent, unmet demand for Magento services. Our firm is not certified (yet). However, last night I went to bed with 0 emails in my inbox. This morning I woke up with 4 new requests for help with Magento projects. This happens to us daily. There are simply not enough hands on deck to meet demand.

Uncovering the Root Issue

For many Magento development firms, services rendered end up as a net loss. Magento is complex and demands a highly specialized skill set. Clients want someone to fix their problems within a predictable timeframe and budget. But the reality is that projects are more involved once you dig in and uncover what is going on in the code or what is really expected from the customer. So the developer either burns hours estimating upfront or tacks on extra hours without compensation to fulfill a fixed commitment that was misestimated. In the end, he could have made more money building Wordpress sites for local restaurants and dry-cleaners.

At the positional intersection of both store owner and developer is one thing: risk mitigation. Store owners want to know that their store will get done properly and within budget while developers want to know that they’ll be profitable and appreciated in their work. Both sides are deathly afraid of the opposite experience.

Enter Certification

Magento certification should be aimed squarely at risk mitigation.  Most current programs get off balance by offering some sort of training + certification exam combo to provide enablement. Services are more profitable when associated with a product; and training services wrapped around certification are probably no exception. However, this approach ignores the chief value proposition for the developer, who is ultimately the paying customer. Remember, he simply wants to lower risk by attracting higher quality clients and charging more money for essentially the same services already being offered. He usually doesn’t want more training.

What we need is a streamlined certification exam like Google offers. You charge me $50-$100 and I’ll happily pay to get 3 developers through a certification exam. But anything over $500/certification that also requires me to lose bandwidth while developers sit in training does not currently make business sense. That is, unless so many other developers get certified that I lose out on business or enough upside exists to justify the cost of certification (which I believe might end up becoming the case based on my conversations with Varien/Magento, inc.). But for now supply/demand seems to be in favor of the developer. If only we could all just figure out how to operate profitably.

Over the past year, we have been learning some valuable lessons regarding communication. As we’re all involved with the web, communication without “connecting” with the intended party isn’t really communicating at all. We’ve been working to apply this into as many areas as possible within the communication avenues that exist between our team members and clients each day. As an example, we’ve started documenting project requirements (mostly business-uses) via screencasts to communicate within a project.

Josh (Colter) recommended we start using the tools at Screencast.com and Jing. I started today, and am very pleasantly surprised at the ease of these screencast tools. Though I haven’t unraveled all of the features these both bring, I was able to download the software from Jing to record screencasts, as well as the uploader desktop tool from Screencast.com. Within minutes I had created a screencast, uploaded it, and shared it within a project for others to see with nearly perfect quality.

We’ll plan to begin using these for all of our modules, installation overviews, knowledge base support, and other areas to help communicate (and educate) our customers effectively.

Should any of you have another streamlined process or even general thoughts on using multi-media within the work you do, please do share. All is welcome.

Last week we quietly launched an Elias module store. Now you can purchase 8 different modules to enhance, extend & enjoy your Magento storefront. Keep an eye on the module store as we add several more modules over the next few weeks. And let us know if you need a module for your store that hasn’t been built yet.

Considering the woes that can come with installing a SSL certificate. Yesterday, we ran into an issue with a client that I wanted to note, just in case anyone else may benefit from the scenario and solution.

Scenario

We had the Magento integrated with SVN and have a post-commit hook that auto-deploys into our root directory on the server. We originally had the httpdocs folder and the httpsdocs folder mirroring each other so that the httpsdocs folder would handle SSL (https) requests and the httpdocs would handle all other non-SSL requests.

As we were installing our SSL certificate, we changed the base_url and the secure_base_url to the appropriate (specific) URLs in place of the {{unsecure_url}} and {{secure_url}} generic values. All of a sudden, as soon as SSL installation was complete, the frontend would no longer transition from the “shopping cart” (url: http://cart.crankbrothers.com/checkout/cart/) into the “checkout” (url: https://cart.crankbrothers.com/checkout/onepage/). The checkout URL would redirect back into the shopping cart.

Solution

We realized that the sub-domain and shared docroot setup (httpdocs and httpsdocs, together) could be creating the issue. Thus, we simplified our setup (cheers Eric Dennis) to make httpdocts the separate docroot for both HTTP and HTTPS requests.

Game, set, match. Problem solved. By the way, you should check out Crank Brothers for a working example

Hope this helps save time for someone else!

Hi All,

Figured I’d share a quick Magento snippet (There are several I’d like to share each day. For some reason this particular one seemed quick enough to post).

Want to change the number of products that display in the Magento Category listing?

You’ll need to modify these two files:

• app/design/frontend/default/YourThemeName/layout/catalog.xml (default theme line 198)
• app/design/frontend/default/YourThemeName/layout/catalogsearch.xml (default theme line 61)

See the screenshot for the variable columnCount()? In order to change that, go to the following file and add in this snippet:

• app/design/frontend/default/YourThemeName/layout/catalog.xml (default theme line 198)

<action method="setColumnCount"><columns>3</columns></action> <!-- set your own number -->

And also this snippet:

• app/design/frontend/default/YourThemeName/layout/catalogsearch.xml (default theme line 61)

<action method="setColumnCount"><columns>3</columns></action> <!-- set your own number and insert <em>inside</em> the "search_result_list" block tags-->

Tonight I was setting up a staging environment for a client of ours so they would have the ability to “visually” interact with the recent data migration our team has performed (OSCommerce to Magento, in case anyone was wondering).

Here’s the error I was receiving:

ERROR 1064 (42000) at line 382: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'USING BTREE,
KEY `FK_ATTRIBUTE_VARCHAR_ENTITY` (`entity_id`),
KEY `FK_CATALO' at line 9

The reason behind this is that there is an inconsistency in the way the export syntax was being handled as I imported into the staging environment (which evidently has a different MySQL version running). Thus, the staging site was expecting different syntax for the following:

--
-- Table structure for table `catalog_category_entity_varchar`
--
DROP TABLE IF EXISTS `catalog_category_entity_varchar`;
CREATE TABLE `catalog_category_entity_varchar` (
`value_id` int(11) NOT NULL AUTO_INCREMENT,
`entity_type_id` smallint(5) unsigned NOT NULL DEFAULT '0',
`attribute_id` smallint(5) unsigned NOT NULL DEFAULT '0',
`store_id` smallint(5) unsigned NOT NULL DEFAULT '0',
`entity_id` int(10) unsigned NOT NULL DEFAULT '0',
`value` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`value_id`),
UNIQUE KEY `IDX_BASE` (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`) USING BTREE,
KEY `FK_ATTRIBUTE_VARCHAR_ENTITY` (`entity_id`),
KEY `FK_CATALOG_CATEGORY_ENTITY_VARCHAR_ATTRIBUTE` (`attribute_id`),
KEY `FK_CATALOG_CATEGORY_ENTITY_VARCHAR_STORE` (`store_id`)
) ENGINE=InnoDB AUTO_INCREMENT=697 DEFAULT CHARSET=utf8;

As a rule of thumb, one can either

• (1) head over to the MySQL Developer Documentation for syntax reference
• (2) or simply check out a recent Magento export from the server they are trying to import into and determine how the “USING BTREE” statement was handled. Likewise, I simply removed the following:

<p style="text-align: left; ">UNIQUE KEY `IDX_BASE` (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`) USING BTREE,

and replaced it with this:

<p style="text-align: left; ">UNIQUE KEY `IDX_BASE` USING BTREE (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`),

Hope this helps someone who is experiencing the same error and spending way too much time trying to understand the incompatible syntax.

With the redesign of the Ei Site, we wanted to take advantage of certain features native to WordPress, one of which was Custom Fields.

We wanted a simple way to display our client list using Custom Fields. Using built-in WordPress functions, it is pretty simple to pull information from Custom Fields. With Custom Field structure like this:

Name: client
Value: Name|Work_Done|Description|URL

You can use the get_post_meta() function to loop through all of the ‘client’ fields and pull the value for each and display to your page.

ORIGINAL CODE:

<?php
	$allOptions = get_post_meta($post->ID, 'client', false);
	if($allOptions) {

		foreach ($allOptions as $option) {
			$fullValue = explode ("|", $option);
			$name = $fullValue[0];
			$work = $fullValue[1];
			$text = $fullValue[2];
			$url = $fullValue[3];
		}  

	}
?>

The problem comes if you want to control the way the output is displayed. The get_post_meta() function does not provide a SORT property. So in order to control the order of display, we simply added an additional component to the VALUE field, a ’sort order’.

Name: client
Value: Sort|Name|Work_Done|Description|URL

Rather than just display the information in the initial foreach() loop, we stored the data into a new array, based on the SORT item for use later.

NEW CODE:

<?php
	$client_array = array();
	$allOptions = get_post_meta($post->ID, 'client', false);
	if($allOptions) {
		foreach ($allOptions as $option) {
			$fullValue = explode ("|", $option);
			$order = $fullValue[0];
			$client_array[$order] = $option;
		}
	}
	rsort($client_array, SORT_NUMERIC);
?>

With the data now stored in an sorted array, we can now loop through the new array and display the information in any order we want.

Who: Anyone who works with Magento (especially clients who are running a store) and could benefit from a more in-depth understanding of Magento best practices.
What: SVN and Magento (a sweet relationship)
Why: Because whether you are a client or a developer, your life can be made easier by using SVN and reaping its benefits

Quick Summary:

1. High-level explanation of SVN
2. Who should use SVN
3. Why it should be used
4. Specific things to watch out for with Magento
5. Bonus: optional tools

1. A high-level explanation SVN

“SVN” (aka “Subversion”) changes and improves the development process. It is an “enhancement” to “CVS” which allows developers to maintain local, staging, and production environments. This is a best proactive for most software development (and Magento) projects. SVN relates to “Git” (though some prefer one more than the other) and is free to use.

Simply put, SVN is a tool that keeps a revision history of code over a period of time. You keep project code located within the repository and pull a copy of the entire code with one simple command (a total of about 6 seconds). In addition, any updates to the code are committed to the repository, which allows anyone who is “linked” to the repository to sync their code with the latest changes via one click of a button. A simultaneous, multi-user environment is thus organized for development and proper administration.

Just to reiterate – there are an incredible number of benefits to SVN… too many to mention here.

2. Who should use SVN

Everyone who works with Magento should use SVN. As a rule of thumb, SVN should be used in any significant software development project (unless you use Git).

3. Why SVN should be used

SVN allows multiple developers to build simultaneously in an organized fashion with a detailed history of the progress. This ensures that the live storefront (production environment) is always intricately cared for (read open for business). Every developer has experienced early on in their career the inevitable mistake of removing a file via FTP, only left to realize that file is lost in space and no longer retrievable. But large cocktails are no longer necessary to cope with such an event thanks to SVN. The developer’s life becomes easier; and the client’s business is safer. When used properly, SVN ensures reliability, integrity, speed, and fall-back recovery.

4. Specific things to watch out for with Magento

In our experience, there are a few specifics to watch out for when using SVN with Magento. Without getting too technical, here are a few things we’ve learned along the way:

+ You need to watch out for the caching within Magento. Utilizing SVN:Ignore is the key to allowing the local environment to cache correctly. I would recommend setting SVN to “ignore” for the following (at least) when maintaining separate environments:

• app/etc/local.xml (or use SVN lock instead for this)
• media/catalog/product/cache
• var/

+ If you use Beanstalk then you can streamline SVN managing with the “Deployment” tool within BeanstalkApp’s repository storage.

+ Use a test script. We’ve learned the hard way to stick to a quality test script as we merge different branches into the main SVN repository (used for production). Maintain a staging environment and use the test script from every angle prior to going “live” to production with the new changes.

+ For phases of a project, it helps to create a “branch” for each phase and a staging environment for each branch (assuming the project is large enough to call for it). This makes it easier to rollback and merge updates.

+ We prefer to keep the entire Magento directory maintained via a SVN repo. We do this so that we can upgrade, modify, and perform other changes locally prior to streamlining the changes to the staging and production environments.

5. Bonus: optional tools

At Elias, we fancy apps that make our lives easier. We invest a lot of time researching and trying out new apps to see how well they fit our business. So far we have found a few SVN tools that are worth mentioning. (Note: these may be Apple-specific. Forgive us):

• VersionsApp: A high-quality desktop application that allows one to manage repositories locally for streamlined management of code.
• BeanstalkApp: A sweet as online SVN storage service to host repositories full of code, revisions, and a great interface for management.
• Coda App: A quality code editor that integrates with SVN
• TextMate: Another quality code editor with SVN integration
• MAMP: A personal Mac server with Apache, Mysql and PHP
• VirtualHostX: A virtual hosting utility that works well with MAMP
• VirtualBox: A sweet virtualization product to run multiple operating systems
• Spoon.net: A browser-compatibility testing tool we’re just becoming familiar with

Those of you who are already familiar with SVN know that there is obviously much more to rave about. This post is intended to be a simplified “business use-case” for SVN and explanation of why it is a Magento best practice. We welcome you to chime in with other suggestions for us all to benefit from!