As part of a computer setup, there are some essential programs one needs to have installed. Personally, here is my suite of programs that I install on a clean machine.

First and foremost, there is an awesome site called Ninite that helps setup Windows machines. From Ninite, I always install the following.

• Web Browsers
  • Chrome
  • Opera
  • Firefox
• Utilities: WinDirStat (helps find large files)
• Messaging
  • Skype
  • Thunderbird (free email client, alt. to MS Outlook)
• Media
  • iTunes (music/video)
  • VLC (video player, plays everything)
  • Audacity (audio editing)
  • Spotify (better radio than iTunes)
  • QuickTime
• Runtimes *REQUIRED
  • Java
  • .NET
  • Silverlight
  • Air
  • Shockwave
• Compression: 7-zip (helps find large files)
• Imaging
  • GIMP (optional, if you do not have PhotoShop)
  • Inkscape (optional, if you do not have Illustrator)
• Documents
  • OpenOffice (optional, free alternative to MS Office)
  • Reader
• Online Storage
  • Dropbox
  • Google Drive
  • SkyDrive
• Developer Tools
  • Python (optional)
  • Filezilla (FTP/sFTP)
  • Notepad++ (Powerful Editor)
  • JDK (optional)
  • PuTTY (required for Git, etc.)
  • Eclipse (optional IDE)

Once you select all of these, you simply click "Get Installer," then run the installer, and go get some Starbucks for Brian Gardner's sake or a Mountain Dew for my sake. Simply walk away and do something else for a bit.

After these install, I also install the following softwares manually:

• Adobe Creative Suite/Cloud Master Collection (par excellence design tool)
• Latest Version of Internet Explorer
• Safari for Windows
• XAMPP: Local Apache & PHP server for rapid development.
• MySQL Workbench: If you are used to MS SQL Server, then this will make you feel more at home.
• Git for Windows (Download): For running Git from the command line.
• TortoiseSVN: WordPress Core Trac Patches & use with Assembla SVN (free private SVN repos)
• TortoiseGit: Use with Github & Bitbucket (free private Git repos)
• Atlassian Source Tree: Windows GUI for Git (works with Github and Bitbucket)
• Bitvise Tunnelier: SSH & FTP Client, better than PuTTY IMHO
• NodeJS: Use with CSSLint, JSLint, Grunt, etc.
• Git Credentials: Stores credentials so I don't have to enter them over and over again.
• Screen Capturing Software: Jing and/or TinyGrab2
• Cyberduck: Awesome FTP client for Amazon S3
• Sublime Text: Premium Editor ($70)
• phpStorm: Premium Editor ($99)

Did I miss anything from a Windows perspective?

Many times, I extend plugins with additional functionality or customize plugins with specific needs of the theme or the site. You may do the same, but where does this code need to go? Should it go in functions.php or should it reside in its own plugin?

Before I answer this question, let's consider these questions.

1. How do you handle troubleshooting on plugin updates if the theme or site breaks?
2. Since the original functionality exists in a theme, what happens to that functionality if the user switches themes? Or, in other words, is this customization truly theme specific?
3. What happens to the code if the extended plugin is deactivated?

Depending on how you answer these questions, I would say whether the extension should be in either it's own plugin or in the theme's functions.php though one could easily argue that regardless, it is plugin territory, especially in light of Thomas Griffin's Plugin Activation class.

For example, there are times when plugins release an update and this update either breaks your theme or breaks your extension. The former is going to happen periodically with some plugins, but if the latter happens and your extended code resides in functions.php, then your theme may break. Regardless, it becomes an effort to determine where the breakdown occurs: is it the theme or the extension? So, if it resides in functions.php, we go and comment the extension to see if it was the problem.

However, if the extension lives within a plugin, then it is just a simple test by deactivating the plugin to determine whether it was the problem. Also, having it reside in a plugin keeps the functions.php file cleaner.

Now, if you extend a plugin that contains a shortcode, like Display Posts Shortcode. So for example, let's say we add an attribute to the display posts shortcode.

Now should this be made into a plugin or not? In my opinion, it should. Many would argue by default this should reside in a plugin simply because now you are immediately impacting content. If a user or the client were to switch themes, then in places that use the [ display-posts] shortcode, only the shortcode appears without the modification.
To make it into a plugin, we just need to add the file header. Below you will see the file header and the plugin header comments, which WordPress reads and uses for the plugins page.

Yet, this brings up another issue. How do I deactivate my plugin if the extended plugin was deactivated? We will discuss this in the next post on Tuesday.

Grandchild themes? Really? Yes, they are possible but not popular with many lead developers arguing against this practice. Justin Tadlock, for example, writes an excellent post against the argument of creating grandchild themes, which PostStatus concurs with an apt statement: Grandchild themes solve "a problem to a bad architecture." While I am not sure that it is "a bad architecture" per se, but more a bad practice that creates a bad architecture.

Are grandchild themes possible? Yes. Are they maintainable? Yes with some great difficulty though not scalable. Is there ever an instance where it should be used? Possibly. The only scenario I can conceive is as part of an internal multi-site/sub-sub-site but besides this rare occasion, at the moment I cannot think of any that would justify the use of a grandchild theme over developing via branches.

So, let's look at these four: theme frameworks, parent themes, child themes, and grandchild themes a bit more closely.

Theme Frameworks

Justin Tadlock defines a theme framework as...

a set of conventions to use for developing WordPress [parent] themes.

Yet, I would differentiate between a a framework from a theme framework using the former in its more pure scope meaning "a reusable set of libraries, functions, classes for a system" or as Justin defines it "a set of conventions." A theme framework, on the other hand, is a parent theme that implements a framework. A framework displays nothing on the front-end or the back-end. In WordPress terms, a framework does not include or require to contain a functions.php or a style.css, as Hybrid Core. If I carry this to other themes or theme frameworks, I believe that "themes" like Genesis are theme frameworks as their primary purpose is to be extended and serve as a framework, yet there is a front-end and a back-end that is ready to be used and customized out-of-the box.

In other words, a theme framework is a parent theme or an advanced parent theme, as some call theme. Genesis, a theme framework, is an advanced parent theme.

Parent Themes

A theme is a completely new front-end layout of a WordPress site. While theme frameworks are always parent themes, not all parent themes are theme frameworks. Just like how all squares are rectangles ut not all rectangles are squares. Suares are a specific subset of rectangles.

Parent themes can be a fork of a theme framework as part of its core, and a parent theme can be a theme that sits on a framework within itself. Simply, parent themes use the WordPress installation and adds various forms of presentations and formats.

Child Themes

A Child Themes is:

a theme that inherits the functionality of another theme, called the parent theme. Child themes allow you to modify, or add to the functionality of that parent theme. A child theme is the safest and easiest way to modify an existing theme, whether you want to make a few tiny changes or extensive changes. Instead of modifying the theme files directly, you can create a child theme and override within.

As Justin later notes, child themes solve the problem of safe upgradability, which is imperative. For example, if you update and customize Twenty Eleven or Twenty Twelve, every time WordPress upgrades, you get in danger of losing all or some your theme customizations. However, if you use a child theme of those, then you can easily update without thinking twice. This is one reason why the upgrades of Genesis go so smoothly!

Child themes are typically done as a WordPress theme, and there are two plugins which assist you in making child themes:

1. Child Themify (Downloads: [plugin_info slug="child-themify" data="downloaded"]): [plugin_info slug="child-themify" data="short_description"]
2. Orbisius Child Theme Creator (Downloads: [plugin_info slug="child-themify" data="downloaded"]): [plugin_info slug="child-themify" data="short_description"]

Grandchild Themes

By default, WordPress cannot create a grandchild theme even though Smashing Magazine wrongly states this. However, Mark Barnes and AppThemes write a great tutorials on how to create a grandchild theme.

So why do some people believe they need to have grandchild themes? Theme shops like StudioPress focus on creating child themes that modify Genesis, the parent theme framework, with a few different functions, etc. Recently, Genesis has been updating some of these themes (e.g., Lifestyle, Outreach). However, in these updates, many have a new slug which forces people to properly upgrade a site manually. However, Lifestyle (among others), for example, did upgrade with the same folder slug. So having a site created based on this child theme that implemented a grandchild theme workflow would make maintenance, err upgrading, easier. However, in my opinion, this complicates the workflow, harms the client (who would just click upgrade without thinking through the ramifications and implications as would some novice developers), and is a lazy approach to keeping up code on a site. Furthermore, the upgrade in a Genesis child theme is never security as that is 100% addressed in the advanced parent theme. Instead, these upgrades are purely aesthetic.

In the comments of Mark Barnes's article, Eric Mann gives a great rationale and better workflow to editing a child theme than using grandchild themes stating:

If you are using a child theme for a system like Genesis, then you should fork it rather than try to hack your presentation into a plugin. Throw the current version of the child theme into Git or SVN, then create a dev branch to contain your customizations. If (and this is a big “if” since most won’t) the child theme is update, you can create a diff between the original and the new version using your VCS and apply the diff to your branch.

Is it more work? Yes. Is it an ugly hack using a plugin? No. Work with what you have, but don’t advocate a system like this that introduces a third level of moving parts into the theme’s presentation

Eric previously gives these reasons against Grandchild themes:

1. Arbitrary limitation would need to be imposed on theming.
2. A difficult, near impossible troubleshooting workflow
3. Multiple developers, multiple development patterns
4. Theme distribution of a grandchild theme is untenable

Conclusion

Personally, I don't believe grandchild themes will ever be implemented or supported in WordPress core, and rightly so. I believe that developers should seriously consider the relationships between their theme frameworks and child themes and possibily create a workflow that resembles a true framework, multiple advanced parent themes, allowing their customers to implement with child themes. However, with theme shops like Genesis or Thesis, this is more difficult as the advanced parent themes generate a lot of revenue. So, besides being a change within a development model, it would be a change in revenue and business models for them. And both models work well and address different user/client needs. I think StudioPress has created an excellent model which Nathan Rice, the lead developer behind Genesis, writes:

I was convinced that users would have a hard time with the Genesis concept, but to my surprise, we've evidently stumbled on something that users really love. My guess is that grandchild themes, or any attempt to synthesize that concept, would disturb the balance of an otherwise extremely popular methodology.

Have you ever used grandchild themes? Ever heard of them? Think they are a good idea? bad idea?

I love working with Gary Jones (@garyj) of Gamajo Tech. Every time I talk with him, discuss any thing development related, I learn something. In a recent "conversation," he said:

I'm not keen on Core Functionality plugins—it's still one plugin that has many roles, all of which could (and therefore should) be separated out.

To me, this single comment caused me to think and analyze the role of the Core Functionality plugin. As I thought about my site and client sites I have created, I think he's identified a major weakness of a Core Functionality plugin.

As such, I believe it has two essential limitations:

1. Difficult Post-Development Workflow
2. Potentially, Poor Post-Deployment User/Client Experience

In development, as a developer my goal is to develop as quickly as possible for two reasons: more projects and better client experience. In doing this, it is great to place all the site's functionality into a single plugin that serves as a glorified functions.php file. To me, it also leads to less code bloat with the ability not to have to place functions and classes (e.g., Metaboxes) in each plugin wrapped in a conditional.

if ( function_exists( 'foo' ) ) {
function foo( $param ) {
echo $param;
}
}


So, using a single core functionality made it easy to rinse and repeat. However, using only a single core functionality plugin or a site-specific plugin, while having its advantages, can be problematic. As Gary specifically illustrated to me, generalizing his example, let's say you have a core functionality plugin (or a functions.php file run rampant) that contains several different custom post types and functionality extensions. Then something breaks with a single, specific custom post type or functionality extension that is developed within the core functionality plugin. This can cause a domino affect of issues within the site, maybe even the dreaded white screen of death.

One cannot simply disable the core functionality plugin in production/live site and begin to fix the issue in their staging or local development environments. Disabling the core functionality plugin essentially would remove some of their content (based on custom post types in the core functionality plugin) from visibility (not that it would be removed from the database), or even break the entire site. Instead, with a set of smaller plugins, only the specific plugin causing the issue needs to be disabled.

(Note: No developer would ever assure that their code will always work on the site forever as clients enable other plugins that may cause conflicts, change the code, current plugins become upgraded or even deprecated, and WordPress core is ever changing, growing, developing, and improving.)

As a result of using only a single core functionality plugin, the client now has a problem in identifying the issue and re-mediating the issue forcing them to hire someone else to fix the problem immediately.

@wp_smith Great post. The other missing point: smaller plugins make it easier for future devs to find code.

— Gary Jones (@GaryJ) February 12, 2014

Then, as Gary notes, the client is paying more because the developer has to take extra time to troubleshoot the code and find the issue, which is frustrating for developers.

Instead, not using only a single core functionality plugin, the client has options. This becomes very client-centric, which leads to loyal clients and more work. The client then can determine whether they need that functionality on their site (and I have seen clients rightly choose this may times over). Or, they can decide when they could fix it within their timeline and their cash flow. Simply, it creates a better post-production client experience.

Please do not get me wrong. I believe that the core functionality, site-specific plugin has its place, especially in extending a theme, a child theme, skinning a theme/child theme, or in creating a grandchild theme.

What are your thoughts? Do you see any other limitations or disadvantages?