In the previous post, Extending or Modifying a Plugin, in this two part series, I wrote about modifying by extending an existing plugin using a plugin. This left us with the following question:

How do I deactivate my plugin if the extended plugin was deactivated?

This snippet will allow you to deactivate your extended plugin when the extended plugin deactivates.

Picking up from the previous post, in the example below, there is a code snippet to customize Display Posts Shortcode. So, if the client decides to deactivate Display Posts Shortcode, then this plugin will deactivate itself automagically.

Yes, it is strange that I am hooking into the updated_option hook. One would think that this could be done with the deactivated_plugin hook, but it cannot since at the time of this post either the documentation (ticket #27189) is wrong or the action occurs at the wrong place (ticket #27189, see also #20241).

Full Extended Plugin

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.