The obvious and painless solution is to upload the files directly to the server using FTP and then control the blog from within wp-admin. In this case, though I knew the simple solution, I wanted to get to the root of the problem. It turns out that weird permission issues with IIS and WordPress and in some extreme cases such as mine, can be solved with simple but somewhat hidden features to get the desired results.

A Google search revealed that adding a few lines of code to the end of your wp-config.php can solve most issues. As from Firdouss.com guide, try this solution first. Open up your production wp-config.php, find the end of the file and add the following lines at the end. Then save the file, upload to your server and try the process again.

if(is_admin()) {
	add_filter('filesystem_method', create_function('$a', 'return "direct";' ));
	define( 'FS_CHMOD_DIR', 0751 );
}

If that does not solve your problem, you can use WordPress constants to solve your problem. It turns out (thanks to a comment on the Firdouss.com guide) that there are a host of constants that can be added to wp-config that can fix broken upload and install/upgrade problems among other things. That link to the Codex contains a detailed explanation of the constants and what they should be set to. Please refer to that link since it will continue to be updated. In my case, I had to add the following to the end of my wp-config.php file. I could also have modified the above code to return ftpext instead.

define('FS_METHOD', 'ftpext');

Now in my case, there were other permission issues that had to be resolved. Our Plesk install had a borked permission system and in order for uploads to be deleted after they are unzipped and copied (WP need to switch to a move), I had to also CHMOD the files. So I ended up with the following code at the end of wp-config.

if(is_admin()) {
	add_filter('filesystem_method', create_function('$a', 'return "ftpext";' ));
	define( 'FS_CHMOD_DIR', 0755 );
}

Now the uploads/upgrades/installs work fine. YMMV.

As for the weird installation issue, it turns out that when I uploaded the WordPress install files on the server and visited the URI, I got redirected to the following along with a white screen of death with no errors.

http://example.com/index.php/wp-admin/install.php

I needed to change that URI manually to the following for the install to continue. That was all.

http://example.com/wp-admin/install.php

Do you have any other suggestions? Are there any tricks that have helped you get similar issues resolved?

Trend spotting: WordPress Centric Hosting – Over the past two years, a new form of web hosting has cropped up that tries to bridge the gap between all the safety nets WordPress.com offers with the freedom to do whatever you want via the self installed version of WordPress. Examples of these types of companies include Page.ly and WPEngine. I’ve noticed more and more of these types of companies starting to open shop while at the same time, long time players in the web hosting industry are starting to create WordPress centric packages. One thing you need to keep in mind is that a WordPress centric host does not make them better than all of the other options.

How Up To Date Are Their Servers? – During the early part of 2010, there were a number of instances where large, well-known web hosting companies became victims to exploits and attacks thanks to outdated software in use on their servers. Before becoming a customer, ask the web host in question what versions they are using for php, MySQL, phpMyAdmin, etc. A good web host will generally always be using the most recent stable version of software.

Reputation Check – Type into Google the name of the web host you’re interested in followed by the word sucks. You should quickly noticed that every web host sucks. What you should really be paying attention to is not only the severity and amount of problems that users report, but how the company responded to those problems. Every web host is going to encounter its share of problems but it’s how they handle those problems that makes a big difference. An excellent resource for all things web hosting that has been in existence for years is WebHostingTalk.com. If you’re interested in hardware, software, all things related to what it takes to make a web hosting company run, that forum will make your mind explode with detailed discussions.

Human Recommendation – If you start a thread on the WordPress Support forum asking for advice on which web hosting company to go with, chances are you’ll get 3-5 different company names as recommendations. If one of these companies interest you, be sure to ask around to get personal experiences from folks, especially as they relate to customer service and up time. However, similar to the Google Research conundrum, it could turn out that all of your friends have had success with a particular company and you turn out to be the bad apple with a bad experience.

Check And Double Check Policies – It’s imperative that you read the Terms Of Service and Acceptable Use Policies for the host you’re interested in using. While many hosting companies advertise unlimited everything, you’ll find out by looking in the small print within their AUP that if your site goes overboard with CPU, space, or bandwidth resources, you’ll be cut off. Unlimited is a great marketing technique but there are always limitations so take the term unlimited with a grain of salt.

DoS And DDoS Attacks – I found this out the hard way early in 2010 when my own web site, WPTavern.com was hit with a denial of service attack. When I contacted support for AnHosting, they basically told me that I must figured out a way to stop the attacks because after the site gets suspended three times in a row for using too many resources, they would remove my site along with my account. Needless to say, this infuriated me as I’ve been a loyal customer for over two years and they failed to work with me to find a cause along with a resolution. DoS attacks are a common thing these days so please make sure that whatever web host you’re interested in using has a firewall or some type of preventive measures in place to help out instead of abandoning the customer as my previous host did.

Support – Probably one of the most important aspects of choosing a web host is their support system. Look for companies that offer a variety of support solutions such as forums, ticket system, email, and a phone number. I’d choose a web host that has 24/7 support versus week days only. Extra points to those web hosting companies that don’t outsource their support to countries/companies that don’t speak English very well.

Redundancy – If the companies website and services go down, do they have a fail-over system in place? Is your data mirrored to that fail-over system? Does it have the same security precautions as their first system? This is not overly important as their are a number of options available specifically for WordPress users to create redundancy of their data.

Communication – This is one area in which I see web hosting companies screwing up the most. You’d figure that by now, they would understand that communication with their customers is paramount but most of them still don’t get it. Ask the web host you’re interested in whether or not you’ll be contacted if maintenance is required on the box your site resides on. Also ask where all such service interruptions and other announcements will be published. Nothing like publishing a post in WordPress only to hit the button and see a site not found error.

Payment Options – Make sure you understand any money back guarantee that is offered. I recommend staying away from purchasing web hosting for more than one year at a time unless the money back guarantee specifically states that refunds can be pro-rated. Preferably at 1, 3, or 6 month periods at the most. This way, you’re not locked into a specific host. You’ll regret it when you’re halfway through your contract and the web host experiences severe technical difficulties that last a week or more but you can’t move to a new web host because you’ll lose money from not fulfilling the other half of the contract. It may seem like you’ll save tons of money by purchasing 3-5 years worth of hosting, but realize this is a very high risk you’d be taking.

SSH And SFTP – SSH stands for Secure Shell. It’s a Unix-based command interface and protocol for securely getting access to a remote computer. It is widely used by network administrators to control Web and other kinds of servers remotely. SSH is actually a suite of three utilities – slogin, ssh, and scp – that are secure versions of the earlier UNIX utilities, rlogin, rsh, and rcp. SSH commands are encrypted and secure in several ways. Both ends of the client/server connection are authenticated using a digital certificate, and passwords are protected by being encrypted.

SFTP on the other hand is the secure version of the FTP protocol. SFTP, or secure FTP, is a program that uses SSH to transfer files. Unlike standard FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted in the clear over the network. It is functionally similar to FTP, but because it uses a different protocol, you can’t use a standard FTP client to talk to an SFTP server, nor can you connect to an FTP server with a client that supports only SFTP.

Sandboxing – Probably the most important question you can ask to a shared hosting company is how they secure/sandbox the user account space. By default *nix systems don’t protect user home directories. Also, how do they secure/sandbox the php processes. By default, php has to run with apache privileges and any code that runs on the server, regardless of user, runs in the same security context. Sandboxing the PHP code to a specific user account is important on a shared host so that user1 can’t write some code that hijacks user2?s site.

Conclusion:

While this isn’t the all encompassing guide to choosing a great web host to put your WordPress powered web site on, it does provide food for thought. This is just a short list of things to consider but in reality, having a great experience with a webhosting company is almost like winning the lottery because it’s so rare. In my experience with WPTavern.com, I experienced 2 great years with my previous host and then it turned into a nightmare in just a matter of two weeks forcing me to move. In fact, I moved twice in one week due to the problems I was having with migrating my site. Ultimately, it comes down to gathering as much information as possible in order to make an informed decision as to whether a particular webhost is right for you. Price should not be the only determining factor for hosting your site, especially if you plan on taking things seriously.

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?

Allows visitors to save posts from your site – When you add the Site Memory button to your site, visitors can automatically save posts, pages, and content defined by you to their Evernote your visitors can save posts and pages to Evernote as clips. You have total control of what Evernote saves, the save location of the clip, and how the clips are tagged.

Easy Access to Favorites – When visitors return to your website and click on the Site Memory button they are presented with everything that they have ever clipped from your website.

The two items above translate to a better experience for your users as well as repeat visits from users who reference your website on their Evernote notebooks. The two items below translate increased engagement into cash.

Make Some Moolah – Evernote employs a freemium model that provides the software and service free, if users wish to access additional features they have the option to upgrade to the premium version. This is where you make the money. For every referred user that upgrades to the premium account you will receive the first $10 Evernote collects.

Free Advertising – The Evernote team promotes the most popular sites via social media every couple of weeks.

Does this sound like something you would like to implement on your sites? If so follow the instructions below to help you set up Evernote Site Memory on your website.

How to Setup Evernote Site Memory

The first thing you need to do is visit the Evernote Site Memory page. You might also want to sign up for the affiliate program so that you have the code handy when we get to that step.

1. Choose the button design you wish to use.

2. This is the part where you get to customize what is clipped by Site Memory. The best thing you can do is use the Inspect Element feature in Chrome or Firebug in Firefox to find which element contains the actual content you wish to include. There’s no need to include your website’s masthead, sidebar, and other irrelevant elements.

Example of Inspect Element feature in Chrome to determine the Div that contains the content which should be clipped.

When choosing the div for the content to clip keep in mind that you probably don’t want to include the comments section and any other elements that may make up the end of each post.

4. The next step allows you set your website’s name that will be displayed in the Site Memory window after a visitor clicks on the button.

You can also include a name for the Notebook in Evernote that will be used to store clips from your website. Take this opportunity to think about a keyword or term that you would like your website to be associated with.

If you signed up for the affiliate program, enter the referral code in the referral code text box.

A. If you are happy with the preview you are good to go.

5. Select the code provided and right-click to open the menu.

6. Click Copy to save the code to the clipboard.

Now comes the most difficult part of all, adding the code to your site. For some this may be as easy as pasting the code in a specific spot, but for some it will require tweaking CSS/HTML so for the sake of brevity we’ll stick to the basics.

Warning – Before proceeding, please backup your template files.

1. Open your theme’s single.php template file.

Note: I would probably stick to using the Site Memory button on single posts only. No need to add it to archive or index templates, unless the archive and index views on your website include the entire article and not an excerpt.

2. Find the best location (usually below the title or at the end of the post) for the Site Memory button, paste it into the template and save the changes.

To confirm that the button is working open one of your posts and try clipping the article to your Evernote notebook.

Notice how the information you entered in the Button Creator appears in the Clip to Evernote window. Clip from Your Site and the Notebook that is created. Again, when deciding what to use for these items consider sticking to keywords that help brand your site.

When the clip is saved to Evernote make sure to click on the View in Evernote link so that you can see what was included in the clip.

As you can see from the example above it’s worth taking the time to see how your clip turns out when the Clip button is used. I thought that by specifying a specific DIV I would segregate the content and only include information from the post, but the opposite happened. It looks like the entire site was included in the clip so it will take some tweaking and knowledge about your theme’s HTML and CSS to get the right DIV to ensure only information pertaining to the article is included.

Once you’ve got it down for the single posts then you have the option to use the Site Memory button on pages as well.

If you’re looking to customize the Site Memory button beyond the options available above you can visit the Developer page to get the inside scoop in all of the features available and how to implement them. If you don’t want to mess with your website’s template and are looking for a WordPress plugin to simplify the process, Evernote states that they are working on something to simplify the process.

Are you concerned about Site Memory slowing down your website? Don’t be, the buttons are static and the developer’s page even offers a minified JavaScript library that can be used instead.

Do you think you’ll use Evernote Site Memory on your WordPress blogs? Why? Why Not?

As you can see in the image above, the search results page lists the post date for the article followed by the description.

Do not confuse the intent here, if you are running a news site or writing about topics whose value is short lived then the adequate thing to do is to continue using dates. However if your traffic from search engines is suffering from users who refuse to visit an old article (and your topics are timeless) then you might want to consider removing the post date from your articles.

So how would you go about removing dates in WordPress?

Google is smart about locating dates on posts so you have to be aware of all the dates present on your WordPress site. Based on discussions on the web it appears that Google uses the post date when listed on a page and when the post date is missing, Google uses dates in comments and even within the post itself. So removing dates will take some cunning.

In order to remove the post date from the posts on your WordPress site you will have to remove the post date from your theme’s template file. In terms of indexing the post date, it appears that Google uses the post date from the single post and not the archive, so for the sake of users and simplicity we are only going to remove the post date from the “single.php” template file.

WARNING! Before proceeding with the modification of any template files, please make sure that you back up your files.

Remove date from single posts

1. Open the single.php file located in the theme directory in WordPress (usually server//wordpress/wp-content/themes/your theme name).

2. Locate the following line of code and remove it (or comment it out) from the template;

<?php the_time(); ?>

Note: The code used by the theme developer may vary from theme to theme and location so make sure you look for the <?php the_time within the single.php template to be sure.

3. Save the changes and refresh your website to see the modification. If the changes don’t appear right away make sure to clear the cache if you are using a plugin like WP-Supercache.

Remove date from comments

In order to make sure that Google cannot find a date on your blog post we will also need to remove the dates associated with comments. This can be a bit frustrating for users who want to follow a comment thread so it is entirely up to you.

1. Open the comments.php file located in the theme directory in WordPress (usually server//wordpress/wp-content/themes/your theme name).

2. Locate the following line of code and remove it (or comment it out) from the template;

<?php comment_date() ?>

Note: The code used by the theme developer may vary from theme to theme and location so make sure you look for the <?php the_time within the comments.php template to be sure.

3. Save the changes and refresh your website to see the modification. If the changes don’t appear right away make sure to clear the cache if you are using a plugin like WP-Supercache.

When removing these PHP functions make sure that you take into account the formatting of your posts and comments to ensure that the removal of this element doesn’t interfere with your theme’s design or break the code.

After these changes are made you will need to wait a couple of hours or days in order for Google’s index to reflect those changes. The variance in time is due to your site’s crawl rate so if your site is very popular and is crawled frequently you may see the update in hours. If your site still appears in the search results with the date, make sure you visit the page and search for the date, remember even dates within the content (originally published on [date]) will be used by Google to stamp a date on the site.

Other solutions for the removal of comments and post dates

If you use a commenting system like Disqus or IntenseDebate that is based on JavaScript then there is no concern for the removal of the date from the comments template. If you are using an older version of WordPress or you feel a bit adventurous you could download the Date Exclusion SEO Plugin from the WordPress plugin directory, just keep in mind that the plugin hasn’t been updated in over 500 days and it’s officially compatible up to 2.71.

Will You Remove Dates from Your Posts?

I’ve mentioned some of the Pro’s related to removal of post and comment dates on your blog:

• Users searching for content on search engines are more likely to click on your link compared to others with older dates.
• Visitors arriving from search engines will not discriminate the age of the content and will instead focus on the content itself, which should increase readership, time on site, etc.

Of course, as with anything as radical as this there can be some repercussions:

• If you employ this “hack” and you run a news site, visitors will arrive, but will quickly realize that the content is dated and leave the site.
• Some users like to know when an article was published and may get frustrated if there is no publish date.
• If you decide to stay away from Disqus or IntenseDebate to manange your comments and remove the dates from the comments, users may be confused and frustrated because they can’t follow a comment thread or identify when it a particular comment was posted. In which case they respond by leaving the site or by leaving a nice comment.

If the content on your blog is timeless and you could increase the amount of traffic coming to your blog from search engines, would you remove the post and comment dates?

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.”

Multisite is the most talked about new feature in WordPress 3.0 – the WordPress team has folded the functionality of WordPress Multiuser into the main WordPress project. So how do you use it?

This tutorial assumes your are comfortable using FTP clients such as Filezilla and doing basic edits of WordPress files.

1. Download WordPress 3.0 release candidate. You can find it here.

2. Edit wp-config in your favorite text editor and add the following line:

define(‘WP_ALLOW_MULTISITE’, true);

(I’d suggest adding it just above the line “// ** MySQL settings – You can get this info from your web host ** //”)

3. Install WordPress normally

NOTE: If you’ve already installed WordPress 3.0, just edit wp-config and add that line of code, there’s no need to re-install.

4. Under Tools on the sidebar, you’ll now have an “Network” option. Click it.

5. Here you’ll setup your “Network” – a Network is all the blogs or sites you’ll have under your WordPress install (if you’re migrating back to WordPress from WordPress Multiuser this might be confusing. In WordPress Multiuser the term for network was “site” and the term for site was “blog.” Explanation here).

If your host supports it, you’ll have the option here to choose between subdomains and subdirectories.

Example of a subdomain: site1.yourdomain.com
Example of a subdirectory: yourdomain.com/site1

Fill out your Network Title and Admin E-mail Address and press install.

6. You’ll be greeted with your next list of steps: creating a blogs.dir directory, editing wp-config.php, and .htaccess. WP recommends, as do I, backing up wp-config.php and .htaccess files before proceeding.

After completing the steps, you’ll need to log back into WordPress.

7. On your next login, you’ll notice a new menu: “Super Admin.”

8. Click “Sites” under this option to create a new site. Fill out the forms accordingly.

9. After creating a new site, click Users. You’ll see a new user was created for the new site.

10. You can control all sites on your network through the Super Admin menu, but for right now you might find it easier to administer individual sites through their own admin menus. You can access them as you would a normal wordpress site. In the example above, it would be: http://mydomain.net/malta/wp-admin

This is a quick introduction to using the plugin. Showing ads only to search engine visitors is extremely simple – Who Sees Ads can do much, much more. Check out the links at the end of this article for more information.

NOTE: Although the plugin says it’s for WordPress 2.5, it works fine with WordPress 2.92. I haven’t been able to test it with 3.0 yet because I don’t have any 3.0 test sites indexed in any search engines yet. Anyone else know if it works with 3.0?

If you don’t want to do this with a plugin, you can do it with some simple PHP, see here.

1. Install and activate Who Sees Ads.

NOTE: If you use WordPress Firewall (and I recommend you do), you’ll need to deactivate it while you install, activate, and configure this plugin.

2. Click “Who Sees Ads” under “Settings” on the dashboard.

3. Under “Edit Contexts” type a name for your context, preferably something descriptive like “Search Engines Only.”

4. Drag the “if Visitor comes from a search engine then Display” box from the “Possible Rules” box to the “Active Rules” box.

5. Paste the code for your ad (from Adsense or wherever) into the “Ad Code” box.

6. Under “Edit Context” select the context your just created. Code for your new context should appear. You can now copy and paste this into posts or into your theme templates.

That’s all you need to do to get this very simple configuration to work – but wouldn’t it be nice if you could drop that PHP code into a widget? You can, but you’ll need another plugin for that.

7. Install and activate Samsarin PHP Widget – this plugin allows you to add widgets to your sidebar that can execute PHP code.

8. Go to “Widgets” under “Appearance” on the dashboard.

9. Drag an instance of Samsarin PHP Widget to your sidebar and position it where you want the ads to appear.

10. Paste the code from step 6 in the widget.

Don’t forget to turn WordPress Firewall back on if you turned it off.

For a look at some other things you can do with this plugin:

9 Ways to Make Your WordPress Blog “Smart”

Hiding Advertisements For Single Posts

And of course visit the plugin homepage for even more documentation and ideas!

While on the blog’s front-end, WordPress makes it super-easy with its conditional tags.

I’m not going to go over the conditional tags here, but here are a few you can take advantage of:

• is_home()
• is_front_page()
• is_single()
• is_page()
• And much more.

While being selective on the front-end is relatively straightforward, the admin-panel is another monster.

Sure, there’s the is_admin() conditional, but what if you only want to run a script in a certain section within the admin panel?

One technique is to use the PHP reserved variable called $_GET.

Say you have a plugin options page with a URL of:

http://www.mydomain.com/wp-admin/options-general.php?page=my-plugin-file.php

You can use the $_GET variable to capture the page and run a conditional to determine if the page is yours.

<?php
if (isset($_GET['page'])) { 
    if ($_GET['page'] == "my-plugin-file.php") {
        /*load your scripts here */
    }
}
?>

If there are no variables to capture, you may have to use the reserved variable $_SERVER to capture the page name. From there, you would use a conditional or a switch statement.

<?php
switch (basename($_SERVER['SCRIPT_FILENAME'])) {
    case "edit-comments.php":
               /*load scripts here*/
        break;
    case "upload.php":
               /*load other scripts here*/
        break;
    default:
        break;
}
?>

A Real-World Example

For a WordPress plugin I modified (WP Grins Lite – I’m not the original author), I wanted to include the JavaScript file only on specific pages.

In the admin panel, I wanted the script to load when adding/editing posts and pages, and when editing a comment.

On a post, I wanted the script to load only on posts and pages. To make things interesting, I also wanted to only load the script if comments were open.

<?php
function add_scripts(){
    global $post;
    if (is_admin()) {
        switch (basename($_SERVER['SCRIPT_FILENAME'])) {
            case "post.php":
            case "post-new.php":
            case "page.php":
            case "page-new":
            case "comment.php":
                break;
            default:
                return;
        }
    } else if ((!is_single() && !is_page()) || 'closed' == $post->comment_status) {
        return;
    } 
    wp_enqueue_script('wp_grins_lite', plugins_url('wp-grins-lite') . '/js/wp-grins.js', array("jquery"), 1.0); 
    wp_localize_script( 'wp_grins_lite', 'wpgrinslite', $this->get_js_vars());
}
?>

And there you have it. Page detection in a nutshell.

This article is an excerpt from Ronald Huereca’s e-book entitled WordPress and Ajax (used with permission).

Localizing a plugin or theme is relatively straightforward, but JavaScript presents its own difficulties since we can’t easily call the PHP functions necessary (which is one reason authors embed JavaScript in PHP files).

Since embedding JavaScript in PHP files is never a good technique, we use localization to save the day.

With JavaScript localization, you can use PHP magic to build your localized strings, and then use JavaScript to read/parse those strings. What you do with them is only limited to your imagination.

Furthermore, if you display anything with JavaScript, chances are your users will want the strings to be localized.

Fortunately, WordPress provides the ultra-handy wp_localize_script function.

wp_localize_script

The wp_localize_script takes three arguments:

• handle
• object_name
• l10n

Handle

The handle argument will be the same handle you use for your script name.
For example, if you have a handle of my_script, you would use the same name when calling the wp_localize_script function.

Object_name

The object_name argument is a string that tells WordPress to create a JavaScript object using the name you specify.

It’s important that the string you pass is as unique as possible in order to minimize naming conflicts with other scripts.

For the upcoming example, our object name will be my_unique_name.

l10n

The l10n argument is an array of strings you would like to localize.
Within this array, you will want to take advantage of the __ function.

wp_localize_script Example

For the purpose of this example, let’s create a function called localize_vars and have it return an array.

<?php
function localize_vars() {
    return array(
        'SiteUrl' => get_bloginfo('url'),
        'OtherText' => __('my text', "my_localization_name")
    );
} //End localize_vars
?>

Please note the use of the __() function. It takes in the text we want to localize, and our localization name. This will be the same name you use if you take advantage of localization within WordPress.

The variable SiteURL gives us the http path to our WordPress site, which comes in handy in certain situations.

From another area in our code, we call the localize_vars function:

<?php 
wp_enqueue_script('my_script', plugins_url('your-plugin-name') .'/my_script.js', array('jquery'), '1.0.0');
wp_localize_script( 'my_script', 'my_unique_name', localize_vars());
?>

WordPress then conveniently adds localization JavaScript immediately before our main script is included. Viewing the page source will reveal:

/* <![CDATA[ */
    my_unique_name = {
        SiteUrl: "http://www.mydomain.com",
        OtherText: "my localized text"
    }
/* ]]> */
</script>
<script type='text/javascript' src='http://www.mydomain.com/wp-content/plugins/my_plugin/my_script.js?ver=1.0.0'></script>

With the localize example, you can use PHP magic to add just about anything to your localization object. Hence, no need to ever embed JavaScript within a PHP file.

Now you can call your localized JavaScript variables from your my_script.js file. Here’s an example of an alert:

alert(my_unique_name.SiteUrl);
alert(my_unique_name.OtherText);

It’s really as easy as that. You can now localize JavaScript strings.

Other Localization Techniques

While the wp_localize_script function does great work, it has one inherent flaw: each localized string is on a new line. For plugins that require a lot of localized strings, the size of the page source can easily balloon to unacceptable levels.

To remedy this, we can use two additional localization techniques: one uses JSON, and the other is a custom function.

The JSON Technique

The JSON Technique uses WordPress’ built-in JSON class in order to parse our localized variables.

We would use the same localize_vars function, but would modify the way we queue our scripts.

First, let’s create a helper function that will instantiate the JSON class and spit out our localized variables to screen.

<?php
function js_localize($name, $vars) {
    ?>
    <script type='text/javascript'>
    /* <![CDATA[ */
    var <?php echo $name; ?> = 
    <?php 
    require_once(ABSPATH . '/wp-includes/class-json.php');
        $wp_json = new Services_JSON();
        echo stripslashes($wp_json->encodeUnsafe($vars)); 
    ?>;
    /* ]]> */
    </script>
<?php
}
?>

The js_localize function takes in a $name (our object name) and an array of our localized variables ($vars).

The function then instantiates the JSON class and encodes the variables for output.

Here’s how the code would look when queueing up your scripts:

<?php 
js_localize('my_unique_name', localize_vars());
wp_enqueue_script('my_script', plugins_url('your-plugin-name') . '/my_script.js', array('jquery'), '1.0.0');
?>

Please note that the js_localize function is run before the script is queued.

While this technique does eliminate the newlines and creates cleaner source code, it does have one major flaw. It doesn’t work for all languages.

For example, the Turkish language causes the above technique to crash and burn.

However, if you don’t plan on having additional languages and want localization purely for the ability to access the JavaScript variables, then I would recommend this technique.

A Custom Function

For those wanting to eliminate the newlines caused by wp_localize_scripts, and still have the ability to handle complex languages, then a custom function will have to suffice.

We’ll use the same exact code to queue our scripts, but the js_localize function will change a bit.

My technique is to iterate through the localized variables, save them to an array, and output the array to screen.

<?php
function js_localize($name, $vars) {
    $data = "var $name = {";
    $arr = array();
    foreach ($vars as $key => $value) {
        $arr[count($arr)] = $key . " : '" . esc_js($value) . "'";
    }
    $data .= implode(",",$arr);
    $data .= "};";
    echo "<script type='text/javascript'>\n";
    echo "/* <![CDATA[ */\n";
    echo $data;
    echo "\n/* ]]> */\n";
    echo "</script>\n";
}
?>

It might not be the most poetic thing you’ve ever seen, but it works pretty well, even for those complex languages.

Localization Conclusion

Within this article you learned the how and the why of JavaScript localization.

The benefits of localizing your JavaScript are:

• No need to embed JavaScript and PHP.
• Can capture PHP variables without having to load the WordPress environment.
• Can enable others to translate your JavaScript strings.

You also learned three different techniques to achieve localization.

• Using wp_localize_script – Recommended for general use.
• Using JSON – Recommended for non-complex localization and performance.
• Using a Custom Function – Recommended for complex localization and performance.

This article is an excerpt from Ronald Huereca’s e-book entitled WordPress and Ajax (used with permission).

Before that, it was every plugin or theme author for himself. If you wanted to add in a script, it was hard-coded in.

As you might imagine, this presented a ton of problems. Scripts were loaded twice, out of order, or even when they weren’t needed at all.

Furthermore, some themes and plugins had the JavaScript embedded within the plugin’s or theme’s PHP file just to capture a few PHP variables. Not good! In order to add scripts properly to JavaScript, you must always keep your PHP and JavaScript separate. And by separate, I mean separate files. There’s just no excuse anymore (I’ll get into this in Part 2 of this series).

The wp_enqueue_script function is the first step in loading your scripts properly. Not only can you add your script, but you can also specify the dependencies (e.g., jQuery), and the version number.

This prevents duplicate JavaScript files from loading, which is always a good thing.

So How Does wp_enqueue_script Work?

Aside from the excellent documentation from WordPress, you’ll find my regurgitated version below (gross, I know).

The function wp_enqueue_script takes in five arguments, with the last four being optional.

<?php wp_enqueue_script('handle', 'src', 'deps', 'ver', 'in_footer'); ?>

The handle argument is a string that names your script, or references someone else’s.

For example, you can add the jQuery script to any page by calling:

<?php wp_enqueue_script('jquery'); ?>

Likewise, if you have previously registered your script (using wp_register_script), you can call your script by calling:

<?php wp_enqueue_script('my_script'); ?>

Src

The src argument is asking for the URL of the file. If you supply the src of the script, the wp_enqueue_script function automatically registers your script for others to use (no need to use wp_register_script).

An example of it in use is:

<?php wp_enqueue_script('my_script', WP_CONTENT_URL . 'plugins/my_plugin/my_script.js'); ?>

Themers would use:

<?php wp_enqueue_script('my_script', WP_CONTENT_URL . 'themes/my_theme/my_script.js'); ?>

Deps

The deps argument is an array of dependencies. For example, if your script requires jQuery or other JavaScript files, it’ll load these files before your plugin’s JavaScript file.

Here’s an example:

<?php
wp_enqueue_script('my_script', WP_CONTENT_URL . 'plugins/my_plugin/my_script.js', array('jquery', 'another_script'));
?>

See that array up there (it’s pretty, I know)? That’s what’s calling your dependencies.

jQuery is built into WordPress by default, so calling it via dependency is no problem as long as you queue it via wp_enqueue_script.

The another_script dependency assumes you have already used wp_enqueue_script to assign it a handle and a src.

The outcome in this scenario is that jQuery and another_script will load before my_script.

Ver

The ver argument is simply the version of the JavaScript file for caching purposes. If you are supplying your own script, it’s a good idea to supply a version.

The version is string based and looks like this:

<?php
wp_enqueue_script('my_script', WP_CONTENT_URL . 'plugins/my_plugin/my_script.js', array('jquery', 'another_script'), '1.0.0');
?>

As you update your JavaScript file, update the ver argument. If you don’t, you’ll inevitably run into caching issues with WordPress.

In_footer

The in_footer argument (since WP 2.8) determines if the script will load in the header or footer (header is the default).

To load your script in the footer, simply pass it a 1 (or true).

<?php
wp_enqueue_script('my_script', WP_CONTENT_URL . 'plugins/my_plugin/my_script.js', array('jquery', 'another_script'), '1.0.0', true);
?>

Great care should be used when setting the scripts to load in the footer as some themes do not have this functionality built in (the theme must make use of the wp_footer function call).

Naming Your Handler

One last thing (err, warning?) to take note of is naming your handler for wp_enqueue_script. If you are using a third-party script (say, Colorbox), use common sense in naming the handler. There’s no reason to name it “lightbox” or “mybox”. The handler name should be obvious, right?

The same goes for the built-in scripts with WordPress.

For example, the handler ‘jquery’ is built-in. Do you want to supply your own version of jQuery?

How about ruin everybody’s day and give it a handler of ‘jquery.js’? The result will inevitably be two jQuery instances loading on the same page and causing mayhem with other scripts.

Instead, use the function wp_deregister_script to remove the WordPress reference and supply your own.

<?php
wp_deregister_script(array('jquery'));
wp_enqueue_script('jquery', 'your-jquery-path.js');
?>

With this technique, however, you should have a pretty darn good reason for not including the default scripts. After all, you’ll essentially be running a piece of software that may not be fully tested and/or compatible with WordPress.

Great, I have wp_enqueue_script down. Now what?

You have to call wp_enqueue_script from the appropriate hook in WordPress.

Fortunately, WordPress has two such action hooks you can tap into: admin_print_scripts and wp_print_scripts.

The admin_print_scripts hook allows you to add scripts in the admin panel, while the wp_print_scripts hook allows you to add scripts everywhere else.

Adding your wp_enqueue_script code is as simple as adding an action inside your plugin or theme code.

An example of the code being used inside of a class constructor is:

<?php
add_action('admin_print_scripts', array(&$this, 'add_admin_scripts'));
?>

And for those not using a class (classes help avoid conflicts with other plugins):

<?php
add_action('admin_print_scripts', 'add_admin_scripts');
?>

For the above example, we have a callback method of add_admin_scripts. An example of it in use is:

<?php
function add_admin_scripts() {
    wp_enqueue_script('jquery');
}
?>

Conclusion

Here are the steps you should follow in order to add scripts to a WordPress theme or plugin:

• Add the appropriate action to your WordPress theme or plugin (themers will want to use functions.php).
• Determine your script dependencies.
• Code your wp_enqueue_script calls appropriately.

This article is an excerpt from Ronald Huereca’s e-book entitled WordPress and Ajax (used with permission).

As before, I’ll emphasize a few things:

1. Your WordPress security is only as good as the security on your local computer. If you’re not running good antivirus and anti-malware software or are using an insecure wireless connection, none of this will matter.
2. Likewise, if you’re not keeping your WordPress install updated, none of this will matter.
3. I should have at least mentioned this in my previous security article but didn’t: your WordPress security is also only as good as your web server’s security. Since the audience for these tutorials is beginners, I’m going to assume that you don’t have a lot of control over your host’s security settings. So I’m not going to say anything else about this other than to look for a reputable host with experience hosting WordPress.
4. Make sure you’re using a strong password. See step 2 of my previous tutorial.
5. I’m going to assume you already know how to install WordPress plugins.

NOTE: I’m writing this guide for WordPress 2.92, the current stable release. All of these plugins seem to work with WordPress 3.0, but I haven’t thoroughly tested them.

WP Security Scan

Let’s start by checking for the biggest security holes first, using the plugin WP Security Scan.

After you install you should see a new “Security” section on the left column of your dashboard:

Let’s click “Scanner” and check our file permissions, the most crucial of security settings in WordPress. Chances are everything will be shaded green, and everything’s ok. However, if anything’s not set correctly it will be highlighted in red. Changing file permissions is beyond the scope of this tutorial – contact your web host if you need to change anything.

Next, let’s change our database prefix. This is a “security through obscurity” technique. What we want to do is make your WordPress database harder to exploit by using a database prefix other than the default one – this way any sort of generic, automated attack on the database will likely fail because the hacker will be using the wrong database prefix.

BEFORE ATTEMPTING THIS MAKE SURE YOU BACKUP. I can’t stress this enough. I wrote a tutorial on backing up your WordPress tutorial. Even if you don’t use the plugin I describe there, make sure you’ve got a good backup before proceeding.

If you followed my last security tutorial and changed your database prefix during install, you can skip this step.

Otherwise, click “Database” on the Security section. You’ll see something like this:

If you see something other than “wp_” in the field labeled “Change the current” field, then you can skip the next step.

Change “wp_” to something else. It’s highly recommended that you still keep the _ for database readability in the future, however.

Click “Start Renaming”

If this fails, you’ll either have to change the database prefix manually or not at all. Manual changes of the prefix table are beyond the scope of this tutorial.

Secure WordPress

Next, let’s install Secure WordPress. After you install it click “Secure WP” in the settings column of the left column of the dashboard. Most of the defaults should be fine, except one: if you’re not planning on using Windows Live Writer, check the box next to that option and click “Save Changes.”

WordPress Firewall

The steps above will help prevent attacks by hiding information about your WordPress install from attackers, making sure the correct file permissions are set, and plugging a few potential security holes. Next we’ll install some plugins that actually stop attacks on your blog.

WordPress Firewall is a handy plugin for preventing a variety of attacks. This one is especially important if you weren’t able to change your database prefix. It’s quite simple – just install it. There should be no need to change the default settings. Important: WordPress Firewall has only been tested up to WordPress 2.8. It has not been tested with WordPress 2.92 or WordPress 3.0 beta 2.

Bad queries

Block Bad Queries, like Firewall, prevents hackers from performing certain common dangerous actions on your site. This one you just install and activate – there are no settings to change.

Chap Secure Login

If you’re not using SSL to login (once again, beyond the scope of this tutorial), you can use Chap Secure Login to encrypt your password. This is especially recommended if you use a lot of different computers to access WordPress, or frequently use public wireless Internet connections. Chap is another remarkably simple plugin – just install it and activate it and you’re ready to go. Note: you’ll get a warning the first time you login after installing. According the plugin developers, this is to be expected.

Login Lockdown

Finally, we’ll want to protect against brute force or dictionary attacks. In an out of the box WordPress installation, users can attempt and fail to login an infinite number of times. This means someone could try thousands of password combinations until they got the right one. Login Lockdown will ban users from IP addresses that have tried and failed to login too many times.

Install the plugin and click “Login Lockdown” in the “Settings” section. You should get an options menu that looks like this:

If you have a hard time typing your password correctly, you might want to set the “Max Login Retriess” a little higher.

I also recommend using the “Mask Login Errors” option. Normally, if a user types an incorrect username WordPress will return an invalid user name error. But if the user types a correct username but an incorrect password, WordPress will return an invalid password error. This gives someone trying to crack your password an extra hint as to whether they at least have the right username. If you use the “Mask Login Errors” option, WordPress will return a generic “username or password is incorrect” error instead.

Ask Apache

Many people swear by AskApache Password Protect. However, I have not been able to get it to work with my host. Your mileage may vary. If I understand it correctly, this plugin adds an additional password to the /wp-admin directory. If you allow open registrations and have lot of users logging in, you might not want to use this plugin.

Conclusion

There’s still much more you can do, such as using .htaccess to protect directories, moving core WordPress files, and monitoring for exploits. Those are things we’ll have to cover in the future. If you have need to harden things further now, please see the Hardening WordPress Codex entry. Remember no (usable) site will ever be completely secure, but if you’ve installed the plugins above your chances of getting hacked will be greatly reduced.

This tutorial assumes you already know how to install plugins.

This tutorial should be forward-compatible with WordPress 3.0

1. Install WP-DB-Backup by Austin Matzko

2. Mouse over Tools so that the down arrow appears

3. Click the down arrow

4. Click Backup

5. You’ll see something like this:

On the left are the default database tables included with WordPress. All of these are included every time you backup. The only thing you have to decide here is whether to exclude spam comments from being backed up (I recommend this) and whether to exclude post revisions (I recommend excluding these too, unless you have a specific reason for keeping revisions).

On the right is a list of additional database tables, most of which were probably created by plugins. There’s also a table called that will end with the name “commentmeta” – this can be used by plugins.

If your plugins have created a lot of data that you would like to save, or you’ve spent a lot of time configuring particular plugins, you’ll want to backup these tables. Otherwise, you can keep your database backups smaller by not checking them.

7. Next we see the Backup Option. There are three choices here:

A. Save to the server

This will save a backup of your database as a file on your web server. I don’t recommend this.

B. Download to your computer.

This will create a database backup file that you can save to your local computer.

C. Email backup to:

This allows you to send a copy of the backup to any e-mail address you’d like.

8. Let’s go ahead and download a copy to our hard drives now.

Check options you want in the Tables section then click “Backup now!”

You should see a progress bar, and when that’s done your browser will prompt you to save the file. You can save this file wherever you’d like.

9. There’s another section called “Scheduled Backup.” This is where this program gets really great.

Here we can schedule a backup to be e-mailed to a particular e-mail address however often we’d like. I recommend checking selecting “Once Daily.”

10. On the right, you’ll see that list of optional tables again. Check the ones you want to backup every time the backup runs.

11. Enter the e-mail address you want the backups delivered to in the “Email backup to:” field.

12. Click “Schedule backup.”

13. You should now get a backup file as an e-mail attachment every day. You should save these attachments to your local computer. If you’re using Gmail or another web mail host that has a lot of storage space, you might want to leave your databases on their server as an additional off-site backup. Be aware that that’s an additional security risk – if your e-mail account is ever compromised, the would have access to all of your database backups.