The problem is that most users, who are new to the ways of WordPress, will still use Google to search for themes and will download the first link that provides them with a free theme that catches their fancy. I would go so far as to say that somewhat knowledgeable users might still be tempted to ignore any possible bad effects from these themes; e.g. users continue to flock to sites that provide collections of serial numbers online in spite of being riddled with porn and adware. My opinion is that there are two ways to solve the problem or at least throttle down the preponderance of malicious themes installed on hapless WordPress blogs. Both options come with their pros and cons but one is a resolution closer to home.

• The WordPress application automatically checks installed themes for malicious content and notifies the blogger of the problem, still leaving it up to them to continue installing it or not. This solution is a double edged sword because malicious theme vendors could use the feature to test and hide their malice better. It also smack of “big brother” and is judgmental of a business model that is not explicitly illegal. This test could be run from local code and could have an auto update feature that updates rules from Trac. There are lots of ways to accomplish this.
• Google stops being legally blind and does something (better) about malicious sites. I know that there is a lot of talk about Google search providing worthless results for searches that attract a lot of attention and that they are looking to re-invent themselves. No matter how soon the search engines change their order of doing business, it will be outside of our control and malicious theme vendors will voodoo SEO kung fu are a dime a dozen.

Have you installed a theme without caring whether it contained malicious code or not? Would you pay attention to theme warnings if there was one? Are we going to offer an official Theme Checker?

Organizations like Charity: Water, Children’s Safe Drinking Water, and Water.org are collecting donations to provide wells and water filtration to communities around the world, so wouldn’t it be nice if you could set a fundraising goal on your WordPress blog and share the experience with your readers?

Tracking your fundraising progress on your own blog is incredibly easy thanks to ChipIn. Just register for a free account and create a new event. Once your event has been setup, click the “Create Widgets Now” button. Customize your widget in step 1, select WordPress in step 2, copy the code in step 3, but forget about step 4. Just go to Appearance/Widgets in your WordPress admin panel, drag a text widget to your sidebar, title it or leave the title blank, paste the code into the body of the widget, and click “Save.”

Your visitors will now be able to donate and view your fundraising progress from your sidebar.

We’re curious to read your posts for this year’s Blog Action Day, so please feel free to share them with us.

Hovercards have already been enabled throughout WordPress.com and WordPress.org, and there is an official plugin in the works, but what if you can’t wait for the official plugin to add Hovercards to your WordPress blog?

If your theme has a functions.php file, just add the following line within the file:

wp_enqueue_script( 'gprofiles', 'http://s.gravatar.com/js/gprofiles.js', array( 'jquery' ), 'e', true );

If your theme doesn’t have a functions.php file, or you’d rather not mess with it, use a plain text editor to create a file called hovercards.php with the following content, then use an FTP or SFTP client to upload it to the /wp-content/plugins/ directory, and activate it via the Plugins section of the admin panel.

<?php
/*
Plugin Name: Hovercards
*/
wp_enqueue_script( 'gprofiles', 'http://s.gravatar.com/js/gprofiles.js', array( 'jquery' ), 'e', true );
?>

Credit for the above code goes entirely to Otto and Alex. It is not official and not supported, so you should probably switch over to Gravatar’s official plugin when it’s released, but at least this will hold you over until then.

What do you think of the new Hovercard feature? Will you be adding it to your blog?

Update: The code listed above, while leaner, enables Hovercards everywhere (including the admin panel), which may not be a desired outcome for some users. If you find this to be a tad bit annoying, Otto’s code properly displays Hovercards on the blog side only.

If it’s been a few days since you’ve last edited your blog, chances are that you don’t need to keep any revisions around, and they’re probably just siting in your database taking up space and growing cobwebs. To remove all of your revisions safely without harming your published posts and pages, backup your database, then use either Delete-Revision or Better Delete Revision. If you’re handy with SQL queries, use either phpMyAdmin or the MySQL command line to run the following query (change the table prefix as necessary):

DELETE FROM wp_posts WHERE post_type = "revision"

Update: Thanks to Ozh for pointing out that the above query “just deletes post marked as revisions. If for some reason you associated a revision with a tag or a category that was then removed when the final post was published, you will have extra entries in other tables such as terms.” The proper query to safely remove all of your revisions is as follows (change the table prefix as necessary):

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

If you want to disable the revision system, add the following line to your wp-config.php file:

define('WP_POST_REVISIONS', false );

If you want to specify the number of revisions that WordPress can save, add the following line to your wp-config.php file (change the number to your desired maximum revision count):

define('WP_POST_REVISIONS', 3);

As the revision system is a form of backup, I recommend periodically deleting revisions as opposed to disabling or limiting it.

I ran the above query on my blog for the first time last night and reduced the database size by almost half! How much did you save?

To get started with a native WordPress gallery, you’ll need to create or edit the post or page that you want the gallery to appear in and then click the “Add an Image” button.

You can use this to upload all of your images at full size and WordPress will automatically generate the various sizes (including thumbnails) for you. Now, it’s important to note that once you add an image via this method while writing or editing a post or page, it will be assigned to that specific post or page, which is how WordPress keeps track of the gallery’s content. Once you have uploaded all the desired images, click the “Add an Image” button again, select the “Gallery” tab, choose your desired settings, and click the “Insert Gallery” button at the bottom to add the gallery to your post or page.

If you like getting your hands dirty, there are few more settings that you can tweak by altering the gallery shortcode in the HTML editor tab.

Once you have your gallery setup, there are plenty of good plugins to further enhance it, like jQuery Lightbox For Native Galleries.

What do you use to manage galleries on your blog?  If you use native WordPress galleries, what do you do to enhance them beyond their basic implementation?

There are many ways to backup WordPress, so I’m just going to cover some of the easiest and most complete methods.

First of all, your files are easy to backup. Since WordPress can be downloaded at any time, you only need to worry about files that you’ve customized or uploaded, which should leave only your wp-config.php file and everything under the /wp-content/ directory. You can easily backup these files by accessing your server via FTP or SFTP and downloading them.

Now for the database, which includes all of your content and settings. Just like almost everything in life, there’s the easy way and the hard way.

The easy way: Use a plugin, like WP-DB-Backup or BackWPup. These plugins represent the easiest and most customizable backup options, but they are subject to compatibility with your current version of WordPress and may be blocked by your hosting provider’s security filters.

The hard way: Use phpMyAdmin, which most hosting providers offer in their control panel. Yes, this method is a bit more involved than simply installing a plugin and clicking a magic backup button, but you’ll be able to backup and restore your database on almost any hosting provider without the need to access your blog. This method is particularly handy if you’re moving your blog to a new hosting provider.

Many hosting provider control panels feature their own backup systems, which can vary from provider to provider. For example, cPanel often features a “full backup” option which provides all of your files, databases, and emails in a handy gzip archive. While an ideal method to quickly backup everything, this archive may only be restored by a server administrator on a cPanel system. The previously listed methods will ensure the highest compatibility with most hosting providers.

VaultPress, by Automattic, is a newcomer to the backup scene. It is a paid service, but it provides a hassle-free way to automatically and remotely backup your blog whenever a change is made. If your blog is very important to you, I highly recommend that you try VaultPress now while they’re still offering lower beta rates. I’ve used VaultPress for about two weeks now, so you can certainly expect a review here after I’ve had a month to fully test the service.

Personally, I used SFTP and phpMyAdmin to backup my blog in the past, but now I use VaultPress. How do you backup your blog?

If you love messing with your theme, you can use the official Twitter button generator to generate just a few lines of HTML code that can be inserted into your theme templates, but why not use a plugin to simplify the whole process? I highly recommend Simple Twitter Connect. This plugin, or rather series of plugins, will provide a simple yet customizable way to automatically add the new Twitter button to your posts and pages. You’ll also enjoy a wealth of additional features, including the ability to automatically tweet your posts while publishing, display a list of followers, use your Twitter credentials to login to the admin panel, and allow readers to post comments with their Twitter credentials.

Perhaps Simple Twitter Connect is a little bit more than what you need. In that case, try WP Tweet Button for a simple Twitter button only experience.

If you’re a WordPress.com user, simply visit the Appearance/Extras section of your admin panel and select “Show a Twitter ‘Tweet Button’ on my posts.”

About a month ago I posted about how fast WordPress 3.0 was being downloaded and there was a terrific discussion about the sheer amount of data that was being grabbed to get at the 3.0 version of WordPress.  We even had some comments as to why it was being downloaded at that scale.

Well as of today the download counter reads that it has been downloaded just over 10.3 million times since it was released last month and the counter keeps rolling along!

So what is it that makes the WordPress platform so popular?  What is it that drives people to download it over 10 million times?

If you had the opportunity to talk to a non WordPress user what would you tell them about it to show that it is worth downloading and putting to use for a website?

What is your favorite thing about WordPress?  What is your least favorite thing about it?  What would you add to it?

The experience of this community is the perfect forum to start a dialog like this so I am looking forward to seeing everyone’s thoughts.

My WindowsObserver.com website has 1,100 posts, 9 pages, 4 categories, 2,436 comments, uses 17 widgets, and has 35 active plug-ins. On top of all those elements I use Windows Live Writer to create all of my content and I use a good bit of screenshots and graphics in my posts. As a result I have over 40MB of images (1,100 files) to go along with my 1,100 postings.

Now for the purposes of this story I am not going to get into a comparison of hosting services or the like. The landscape is massive out there and confusing enough. You do not need me adding to it here

I will also make a few other caveats/assumptions:

• This is also based on a self-hosted WordPress site. I am not sure if this works on WordPress.com. If anyone has tried it please comment.
• That you know the basic workings of a WordPress site such as plug-ins, directory structure, etc.
• That you have FTP access to your host and therefore your WordPress files.
• That you have access to your host to create the database and user account details for it. I will talk about phpMyAdmin because that is what my host uses. You may have a different way to access/create your database.
• That you know how to update your websites DNS info with your new host so that people can find it at its new location.
• I will only talk about one WordPress backup plug-in and that is WP-DBManager by Lester Chan. I know and understand there are others out there but this is what I used.

So with all that said here is how I dealt with a move between hosts:

1. I backed up my current sites database using the WP-DBManager plug-in. If you use the defaults for the plug-in the backup will be stored in a sub-directory of the /wp-content/ directory called backup-db.
2. I then launched my FTP software and downloaded the entire site to a temporary folder on my hard drive.  You need to make sure you grab the entire structure of your WordPress site.
3. While the download was happening I went to my new host and created a new MySQL database and user. You could always use the same details as your old host but sometime the prefix for the database name can not be changed. I recommend a fresh database name and password just for good security practices. Make sure you also get the name of the database server. You will need all of this data to get your WordPress site working on the new host.
4. I then created my domain at the new host using their control panel. At this point I did not do anything with DNS. Don’t worry though – creating your domain at the new hosts will do nothing more but prep a directory for you to access and upload your files to.
5. After the files were downloaded from my old host I placed an index.html file in the old sites main directory with a simple message that the site was being relocated. You can be as fancy or in depth as you want.  I then named my WordPress index.php to index.bak so there are no conflicts between the two. This also comes in handy as the DNS shift happens because people will see your site in its new location or the moving page. Once they no longer see the moving page then they will be good to go on the new location/host. It is a great tool for seeing the DNS shift in action.
6. I then updated my wp-config.php file on my local hard drive to reflect the database information for the new host. if you have set up a WordPress site before you know how to do this already.
7. Now it was time to upload all the files to my new host from the local hard drive keeping the exact same directory structure.
8. Once the files were uploaded I updated my registrar’s DNS info for the new host and location of my site.

They say a DNS shift can take up to 48 hours to propagate around the Internet and your mileage may vary for how quick you see the update yourself.  About 30 minutes after I entered the new DNS info at my registrar I flushed my local machines DNS info and was able to see the site at the new address at that point.

To flush your DNS you need to open a command.com window and type in “ipconfig /flushdns” without the quotes. If you then ping your websites URL and see it reply back with the new hosts IP address then you will be able to browse your site at its new location once everything is setup there. If it comes up with the old hosts IP address then there is nothing you can do but wait for the DNS update to get around.

Now for the database move/restoral.  Some hosts restrict the size of files you can upload so you need to be aware of that for your host in these next steps. However, I am going to provide two options for restoring your database. One takes a working knowledge of phpMyAdmin or a similar MySQL database interface – the other makes use of the WP-DBManager plug-in to restore the database and site.  The plug-in method can be used for small size databases as well as large ones.

Restore your database using phpMyAdmin or similar MySQL database interface:

1. I logged into my host and from the control panel I accessed phpMyAdmin logging into the interface using the credentials I created for the sites database.
2. I then went to the Import tab, browsed to the temporary directory on the hard drive where my WordPress site files were stored and went into the /wp-content/backup-db/ directory to find the backup copy of my latest version of the database. Once selected I then left everything at its default settings and clicked the Go button to import the database structure.
3. That is it – the database is now present on your new host in the new database. If your DNS is updated and everything is uploaded you should be able to type your websites address in a browser and it will come up just like it did before the move.

Restore your database using the WP-DBManager Plug-in:

In order to use this method your DNS has to be moved so you can access your site at the new host.

1. Browse to your websites address and you should be prompted to create your new site just like when you do a fresh install of WordPress. Type in your sites title and your email address and then go the the next step. You will be provided the temporary password for the admin account.
2. Log into this WordPress install and then activate the WP-DBManager plug-in. Do not worry about activating other ones. Then use this plug-in to restore the copy of your database that should have been uploaded to your new host with all the other files. It will be in that /wp-content/backup-db/ directory.
3. Once that database restores your site will be up and running with plug-ins activated, the same theme, etc.

You will likely still need to tweak a few things like file and folder permissions but if you got the entire directory structure uploaded and restored the entire database your site will be there just like on the old host.

As always, your comments about your own experiencing in this process and the tools you used are always welcome – in fact we look forward to them and the community sharing your unique experience. There is always someone else out there looking for similar info.

WordPress Super Cache does a pretty neat job too at handling heavy traffic, however, there will be a time when the cache in itself will not solve your problems and you will need to make changes to your server setup in order to ensure that your website loads properly and fast.

One of my pet projects on my personal websites has been to scale the site to allow around 70-100 thousand+ users to seamlessly access the site without having to suffer slow load times on a daily basis.

I did tweak my server quite a bit, however, after a point of time I ran out of tweaks and looked at what I could do to scale the system to seamlessly manage more traffic. I did manage to handle traffic to a point by tweaking the servers, but alas the traffic kept increasing and my I ran out of tweaks.

This is when I started to scale the system itself to handle more traffic. Though I am not done fully yet and will do some more changes in near future to scale it further, I thought it best to document my changes so that others could benefit from it. So here is the first part, which includes a tutorial on how you can scale WordPress by using a master-slave (replication) setup for MySQL.

Note: The guide is aimed towards users use standalone WordPress installation on a VPS or dedicated server. Shared hosting providers do not allow users to change system settings, and this implementation will require to make few.

What Is MySQL Replication or Master-Slave Setup?

MySQL replication basically involves an automatic replication of data from one MySQL database server to a different one located on the same machine or another one. In this scenario you can setup a master MySQL database to which data is written, once that happens the data is then automatically replicated across all the slaves you have setup.

Let me give you a practical example; you have database A where inserts/updates happen, now in a master-slave setup this will be your master server. With replication, you keep the master database as is, however, you add new slave databases which will constantly check back with the master database for updates and then automatically replicate it to themselves without you having to run manual SQL update/insert statements.

So when you insert new data into the master database, the slave database will be notified and will automatically copy the new data over to itself, this replication happens quickly enough that you may not even notice it. If you are not yet clear about what this means, you can visit the MySQL manual for replication.

How Does MySQL Replication Help?

In a production environment of a website database reads constitute a major chunk of the total database accesses. So for example, if 1000 users visit your website, there might be somewhere around 1000 or more hits to the database, depending on how your site works. The latency to respond to those requests will be higher when compared to a site which gets lesser traffic since all those 1000+ hits have to be processed by a single database.

With MySQL replication you can distribute the reads between the master itself and several slaves, so the latency to respond back to requests will be much lower since the load is distributed among several servers.

In addition to that, since you are replicating data, you will also have backups in several places, which you can then use as failovers if your main database has any problem.

How Can You Replicate MySQL Data In A Master-Slave Environment?

Replicating data from a master to one or more slaves is very easy, all it takes is a few configuration changes. A master server will have to be configured only once, and so will a slave. However, you might have to repeat certain steps on the master server in order to grant privileges to multiple slaves to access the data on it.

I would rather prefer not to go into the steps required to create a master slave environment, as an excellent one already exists on HowtoForge: How To Set Up Database Replication In MySQL.

In my setup I have used a Master-Slave environment, but you can also use a Master-Master environment, I would not go into that, but you can always look it up on the internet.

How do I use a MySQL Master-Slave Setup with WordPress?

After you have created a master-slave setup you have multiple resources, but how do you really tell WordPress to actually read from multiple databases?

Don’t worry you do not have to scratch your head and hire programmers to do it. There is a solution in the form of HyperDB which is written by the WordPress team, and is actively used in WordPress MU and on WordPress.com(?).

Just download HyperDB and follow the instructions to setup the different databases you have created. Once that is done, HyperDB will internally take care of distributing the load across multiple MySQL servers.

HyperDB is not like a regular plugin so you will need to follow the installation instructions and also make changes to the DB settings to specify the different MySQL servers you have. Once you have made the changes, your WordPress install will load faster than when it did with a single MySQL database.

That’s it, with two simple steps you now have multiple databases serving your website. This will definitely ease out the load on your servers and will also allow you to easily scale by adding more slaves to your setup.

In my scenario the cost of scaling added only around $20 per box a month, since I threw in servers with minimal configuration as they were only DB servers and did not take up much resources to read data. If I need to scale more I could throw in few more boxes and handle more traffic easily.

Just an afterthought, it does make a difference if your slave servers are on the same network as the master or if they are on an outside network, as far as possible try and add boxes on an internal network itself.

Did you find this guide interesting? Do you think this will help you scale your system? Do let me know through your comments. Oh and also do tell me if you have used any other method to scale your system or would prefer to do it differently.

As a developer when you start out coding, you have a certain number of things a function will require in order for it to work, some may be optional too, so you set out to create a method signature similar to the one below.

function do_something($var1, $var2, $var3, $var4 = false, $var5 = '')  {

//process business logic here

}

Now, say you release your plugin or theme and get more feedback on features and other improvements. If the features or improvements suggested require you to change the method signature to incorporate new variables and you use default values, you are in a bit of a spot.

So what is the best way to avoid such situations? In my opinion, if you use a function which accepts variables, it could easily scale to accept more parameters without breaking anything by accepting an array as a single parameter. The array would have to be built up either internally in the code somewhere or externally through the user.

So you could rewrite the above logic as below:

function do_something($args = array()) {

$myvar = (array_key_exists('mykey', $args)) ? $args['mykey'] : get_default_value('mykey');

//process business logic here

}

Now, you would not expect a user to pass an array while using your non-widget based plugin in their themes, so you would have to provide users with an options page which will allow them to set the values they want to be passed to the function, and then build a Facade function internally which will then read all the option values and pass it on to the main function to be processed.

I hear people saying that they can fetch the options from WordPress inside the function itself and there is not need for this Facade, however, in my experience of over 11 years in the software industry, I have learnt one important thing, never mix anything with business logic.

If a function is supposed to perform a task, let it perform only that and nothing else, that way you can reuse the function elsewhere without having to constantly rewrite it to adapt to different things.

I have seen several plugins which make use of arrays and several which do not. I would definitely be interested to learn on how you approach this, the comments form is open.

Update: From the comments below, many users mistook me. I never said that users cannot use wp_parse_args. However, being an OOPS developer, I stick with my above post and say that you should keep business logic separate from processing logic, no matter whether it is WordPress or any other platform, that is the basic fundamental I learnt in OOPS, and I do believe OOPS is the best fundamental and way to go forward. I expect arguments on that.

A few days ago Jeff posted some links on steps to move from the Blogger platform to WordPress and now Amit Agarwal from Digital Inspiration has written a comprehensive guide on moving from a WordPress.com domain to a WordPress.org domain.

You will find lots of posts which are similar to this one, but I found this guide to be comprehensive and to the point, so if you are planning to move to your own domain now or in the near future, don’t forget to bookmark the article.

How to Migrate your Blog from WordPress.com to a Personal Domain

A shortcode is a WordPress-specific code that lets you do nifty things with very little effort. Shortcodes can embed files or create objects that would normally require lots of complicated, ugly code in just one line. Shortcode = shortcut.

Many WordPress plug-ins make use of short codes to easily make a call to a plug-ins functionality.  This can make maintaining your WordPress based site very easy but what happens if you decide to shift from one plug-in to another and that specific short code is not used in the new plug-in?

Let me give you an example.  I used to use the WordPress Adsense Manager Plug-in on WindowsObserver.com to place my Google Adsense ads.  It allowed me to build the ad and then use a short code to place it on a page or in a blog post.  That short code looked something like this [ ad#post-top ]. 

I made the decision to go to a different ad source and the Adsense Manager plug-in was not compatible for me anymore. So what I decided to do initially was to just allow the Google Adsense ads to run on all of my old posts (at least 600 or so) and then run the new ad code on subsequent pages.

A couple of weeks ago I decided to do something about the old ad code and went in search of a tool to do this.  That is when I found the Real-Time Find and Replace Plug-in written by Marios Alexandrou.

The premise of this plug-in is very simple. It searches for text you enter in the settings and dynamically replaces it as the page is generated in a users browser utilizing the alternate text that you provide.

Here is now simple it is to use:

Once you have installed the plug-in you will find the menu item for it under the Tools menu in your WordPress Admin panel:

Clicking on that brings up the main settings page:

Here you click the Add link and insert the text you want the plug-in to find and then insert the text you want put in its place in the Replace text box. Click Update to save your settings. 

There it is – ready and able to find and replace any text you choose on the run. I used it to replace short codes but you could use it to replace anything you want to on your pages.

Final note about this plug-in: According to this plug-ins page at the WordPress.org Plug-in Directory it is only compatible up to version 2.8 however, I am running it on version 2.9.1 without any problem.

I would be very interested in hearing what plug-ins you use to find and replace text for your site/database.

I did a bit of digging around, however I did not find any conclusive answers to what was wrong. However, I did find a solution at this forum post, and after including an additional snippet it started working fine.

If you are facing a problem with the is_home() function, you can use the wp_reset_query(); function before you use the conditional checks to fix the issue.

I am still looking into the internal code as to why this is happening, will update the post once I find an answer to this problem.

Two instances where this is ideal are:

• When loading an inline frame with Thickbox or Colorbox.
• When parsing AJAX requests in an external PHP file.

To further give justification for this technique, I had a major plugin conflict with another plugin. My Ajax Edit Comments plugin had failed to work for one of my clients.

After doing some troubleshooting, I determined it was a plugin conflict with “xyz” plugin. When I looked at the conflicting plugin’s code, I was able to pinpoint the problem to one patch of code, but failed to determine a fix.

The conflicting plugin was causing my nonces to fail, as well as my AJAX processor to fail (since that uses nonces as well).

Since my plugin’s editing options are all in a Colorbox inline frame (where I manually load the WordPress environment), I figured I would only load the plugins I needed (mine in this case).

Okay, enough chat! Let’s get started.

To call this technique a “hack” is a huge compliment. I wouldn’t recommend this for widespread use.

The Technique

If you look at your wp-settings.php file, there is a conditional right before it loads your active plugins.

It checks to see if the constant WP_INSTALLING is defined. If it is, WordPress doesn’t load any plugins.

So the trick to “trick” WordPress is to define the constant, and then manually load the WordPress environment.
After that, we can load any plugins desired.

Here’s some code:

<?php
header('Content-Type: text/html');
define('WP_INSTALLING', true);
//Adjust the dirnames to match the path to your wp-load file.
$root = dirname(dirname(dirname(dirname(dirname(__FILE__)))));
if (file_exists($root.'/wp-load.php')) {
		// WP 2.6
		require_once($root.'/wp-load.php');
} else {
		// Before 2.6
		require_once($root.'/wp-config.php');
}
$plugin = 'your-plugin-directory/your-plugin-file.php';
// Validate plugin filename
if ( !validate_file($plugin) && '.php' == substr($plugin, -4) && file_exists(WP_PLUGIN_DIR . '/' . $plugin)) {
	include_once(WP_PLUGIN_DIR . '/' . $plugin);
}
unset($plugin);
?>

You’ll see from the snippet above that we define the constant WP_INSTALLING, and then load the WordPress environment.

After WordPress has loaded, we load the plugin file we need.

If you need more than one plugin loaded, you can use a simple foreach statement.

$current_plugins = get_option( 'active_plugins' );
if ( is_array($current_plugins)) {
	foreach ( $current_plugins as $plugin ) {
        // $plugin looks like: your-plugin-dir/your-plugin-file.php
        switch($plugin) {
        	case: 'yourplugin':
            case: 'anotherplugin':
            	break;
             default:
             	continue;
        }
		if ( !validate_file($plugin) && '.php' == substr($plugin, -4) && file_exists(WP_PLUGIN_DIR . '/' . $plugin)) {
			include_once(WP_PLUGIN_DIR . '/' . $plugin);
		}
	}
	unset($plugin);
}
unset($current_plugins);

I would advise that you use this technique only in standalone files where needed, as I’m not sure of the long-term side-effects that might occur if the WP_INSTALLING constant is always defined.