AdSense Manager 3.x is the latest update to the popular WordPress ad management plugin. More than a normal gradual update, version 3.x represents an almost complete rewrite to support a number of changes in the Google AdSense service and the recent explosion in new blog-targeted ad networks. As of writing, AdSense Manager 3.x now also supports Adpinion, AdRoll, AdBrite, Commission Junction, HTML Code, ShoppingAds and WidgetBucks.

The instructions below will guide you through the first steps of configuring Adsense Manager 3.x. If you are upgrading from a previous version of AdSense Manager, you can skip these instructions.

Getting Ready

Before you can do anything else, you will first need to set yourself up with an AdSense account and install the AdSense Manager plugin.

You can also use Adpinion, AdRoll, AdBrite, Commission Junction, HTML Code, ShoppingAds and WidgetBucks. Once you’ve created your account your provider will give you some “Ad Code” to paste into your site. Keep this window open for later: you’ll need to be able to paste this code into AdSense Manager once installed.

2. Download AdSense Manager v3.x

Take the downloaded file, unzip and copy the /adsense-manager/ directory into your WordPress plugins directory at /wp-content/plugins/. After this is done you should have a folder at /wp-content/plugins/adsense-manager/ containing all the plugin’s files. To activate the plugin, simply go to your WordPress dashboard » Plugins and click ‘Activate’.

Upgrading for Previous Versions

If you’re upgrading from a previous 1.x / 2.x version of AdSense Manager simply copy the /adsense-manager/ directory from the downloaded .zip file into /wp-content/plugins/. This will replace the previous version with the new files. AdSense Manager will handle the upgrade of settings/etc. automatically when you next access the WordPress dashboard and show a notice if it succeeds.

Setting Up Adsense Manager

Previously you had to input your Google AdSense ID manually when setting up AdSense Manager, but this is now updated automatically when you import code. If you go to Options » Adsense Manager, you will find the following instructions for importing your first Ad Unit:

2. Create a new ad unit using your network’s ad online management system.
3. Copy the ad code generated (Edit » Copy, from within your browser)
4. Go to Manage » Ad Units and paste the code into the box
5. Click Import to New Ad Unit»

Below here are the settings for Be Nice! a method for supporting development by donating a % of your Ad space and Alternate Ads to raise funds for AdSense Manager. All ads are hand-selected and family friendly, and the income generated in this way allows me to dedicate time that would be otherwise spent on a bar job.

Just enter a % value indicating the proportion of ads you wish to use to support us. If you enter 0 only your own ads will be shown (no hard feelings but please consider donating instead).

Creating Ads

All creating and editing of Ad Units is done on the Manage » Ad Units page in your WordPress Dashboard.

The simplest way to ad new Ad Units to AdSense Manager is by importing Ad Code from your network. To do this simply go to your ad network’s management page, choose your ad settings, and copy the code that is generated. This can be pasted directly into the box at the bottom-left of the Manage » Ad Unit page.

From here you have three options: Save as Code, Import to Defaults, Import to Ad Unit.

Import to Ad Unit

This will be the most commonly used method of importing ad code. By clicking on this option, AdSense Manager will attempt to determine which entwork your ad unit is from and import the settings to create a network-specific unit. This has a number of benefits, including access to network management links and the ability to change defaults for a given network as a group. For example, some networks may require specific HTML wrapped around them.

After clicking import you will see the imported settings: check values and set a name before saving.

Import to Defaults

This imports the ad code and uses the settings to set the defaults for the network. For many networks this will simply be the network ID, but some networks will store default dimensions etc. If you ever want to change the account ID associated with a network (e.g. if you change your Google AdSense account) this is the option you will want to use to update all your ads automatically.

Save as Code

If for some reason importing is not working, or you want to store the ad code as-is, you can choose to import to a plain Ad Code unit. This will not attempt to import, modify or do anything else to the code: it will be output precisely as imported (although, of course, you can edit it later).

AdSense Classic

The simplest way to create Ads in AdSense Manager is by importing Ad Code generated from your ad network (e.g. Google, or Adroll) described above. However, the plugin still supports old-style AdSense Ads if you want to create them from scratch. Simply click on the buttons for ‘AdSense Classic’ in the bottom-right of Manage » Ad Units, and then follow the instructions from AdSense Manager v2.x.

Network Defaults

As mentioned, each network in AdSense Manager has it’s own set of defaults (including the Account ID) that are used as the basis for all adverts on that network. For example you can optionally choose to wrap all ads on a network in specific HTML markup, or you can change the display settings so all AdSense ads are shown on Posts only for example.

Default Settings for a network can be changed by clicking the “Network Defaults” button in the Manage » Ad Units list. As with editing an Ad Unit, when you’re finished click Save changes »

Ad Management

Once you have a few blocks listed, you can manage each block using the buttons provided on the right hand side of the Ad list. Details of each of these are given below:

Clicking Copy generates a copy of the selected Ad, which can then be reconfigured with any necessary changes. This is a good way of setting up a series of similar Ads for example. Note: You can also use Network Settings to configure multiple ads.

The DA (Default Ad) radio button sets which Ad unit will be used by default on your site. When adding AdSense Manager code to your site (or in your posts) you have the option to either specify an ad ID or to show the default. If you opt to show the default Ad on your site, you can then cycle through different Ad configurations by changing the selected Default Ad here.

Positioning Ads

Widgets

If you have the Sidebar Widgets plugin installed, each Ad block will appear on the Widgets configuration page to be positioned as you like. Each Ad will appear with the name of the block in the title.

Drag onto your sidebar and position as you want.

Posts and Pages

You can include Ads into your Posts and Pages using the code below where “name” is the name of the Ad block you have created. New to v3.x is the addition of the shorthand <!--am#name--> format.

[ad#name]

You can also display the default Ad in your posts and pages by omitting #name. Doing this allows you to switch these Ads simply by switching the Default Ad in Manager » Ads.

[ad]

Of course any Ads in posts update automatically when colours or layouts are modified.

Code

You can include Ads in your non-Widget blog adding the code below in your WordPress templates. For example, a good place to add Ads might be sidebar.php.

<?php adsensem_ad('name'); ?>

Again you can display the Default ad by omitting the ‘name’ e.g.

<?php adsensem_ad(); ?>

If you want to avoid errors when you disable AdSense Manager you’ll want to add a function check to the above code. For example:

<?php if(function_exists('adsensem_ad')){ adsensem_ad("name"); } ?>

More

If you have any further questions on using Adsense Manager or have suggestions for modifications, simply leave a comment & I’ll get back to you.

The new widget advertising network from WidgetBucks has been getting popular recently for the higher click through rate and potential earnings. To maintain the amounts advertisers were willing to pay, they recently switched CPM ads for international traffic. Unfortunately this means that non-US & Canada visitors get lower earning non-targeted ads.

Until WidgetBucks targets non-US/Canada traffic better or provides Google-style “alternate ads”, it would be useful to be able to show something else to non-US/CA users in an attempt to maintain relevance.

Fix It

To do this there are 2 options: 1) Full on geolocation through Javascript, 2) Cheat.

As an interim measure I’ve decided to do a number 2, and below is my “solution” to the WidgetBucks problem.

Location vs. Language

Location checking is a potentially script intensive process and the intention here is to keep the script as small as possible (making updating/adding to sites as easy as possible). Although language is by no means a guarantee of location it more often than not should give good results, especially in the US and Canada (where most systems will be set to en-us and en-ca by default if not design). Helpfully, the language setting values also happen to be reasonably easy to access from within Javascript (despite some IE/Firefox differences).

The basic method we’re going to use is to check the browsers language settings on load and, depending on what we detect, display either the standard WidgetBucks ads, or something else. In the example below the “something else” is a WidgetBucks referral unit, but you might want to refer international users to other ad networks, or display a different set of ads altogether (e.g. targetted to a specific language).

Code


<script>

if((mylanguage.toLowerCase()=='en-us') || (mylanguage.toLowerCase()=='en-ca')){
document.write('<div><script src="http://www.widgetbucks.com/script/ads.js?uid=wnJaOtHBcojyRzmd"><\/script></div>');
} else {
document.write('<a href="http://www.widgetbucks.com/home.page?referrer=468034"><img style="border:0" src="http://images.widgetbucks.com/images/referral/adsSuck_468x60.gif" alt="Earn $$ with WidgetBucks!"></a>');
}
</script>


One thing to notice is that you’ll need to escape the / on the script tag (i.e. add an extra \ to make it <\/script>) in order for it to work. But the rest of the script strings and the other ad can be entered as normal. You should be able to put anything you want in the alternate ad space but remember the quotes/etc. (consult a Javascript resource guide for instructions).

With your ad set up as above, you should be able to limit your CPM ads to a bare minimum and hopefully maximise the return on your ad space!

Caveats

Users outside the US/Canada who (like me) have their browsers (inexplicably) set to en-us or en-ca will still see the untargeted CPM ads. This is because although the script above will think they are in the correct area, WidgetBucks geolocation is a little bit smarter. This means that would will still get a number of CPM ad impressions, although it will be hopefully considerably reduced.

Another potential problem is for users in the US/Canada who’s first language is not English (the most obvious group being French Canadians). If the browser is set to fr-ca then they will not be shown the WidgetBucks ads, although they would be eligible for the targeted widgets. Unfortunately I’m from the UK and have little knowledge of how French Canadians set their browser-language settings, so any feedback/suggestions would be much appreciated – of course you could just add ‘fr-ca’ as an additional option into the script code.

As with everything else, please leave your comments & feedback for improving the code.

Users of the AdSense Manager for WordPress may be interested in an update from Kaspars Dambis which brings Google’s new Rounded Corners and Ad Slot Ids. These features will all be rolled into the updated AdSense Manager v3.0 coming shortly, but in the meantime Kaspar has provided a download of the updated plugin.

AdSense Manager v3.0 should be along in the next week, so if there are any other updates you would like to see let me know!

To keep hosting costs on this site down (following the loss of Ad income) the following WordPress plugins are now unsupported:

AdSense Manager, Blog Juice, Blogtimes with Icons, IM Online, Infocon Widget, Quick SMS and Update Manager.

All the above are now hosted on WordPress Extend.

The one exception to this is Throttle
which currently remains at home here while I complete the FAQ files.

A new version of AdSense Manager is now on limited release as Beta. This new version includes the most requested new features:

• Referral Units (Text & Image)
  Referral units can be added by entering the CPA code (and format for Image referrals). These can be taken from the Google AdSense code generator manually. For an easier way to do this, see Code Converter below.
• Copy Ad to New Ad
  Allows you to make duplicates of previously created ads to modify slightly
• Direct Code Ads
  If you prefer to manage your Ads using Google’s online service you can use this method to save pure code into the AdSense Manager system.
• Code Converter
  To make it easy to import settings into configurable Ad units, you can use the Code Convert (found in the Direct Code Ads section) to transfer code into a manageable Ad unit.

If you’re happy with Beta software (it may break) please download, test and submit your bug reports. If everything goes well the full release will be coming over the coming weeks!

Thanks for all your support & feedback.

Most mobile providers provide a method for sending SMS messages to handset by email, although many do not publicise this capability. Messages sent to these specially formatted email addresses are forwarded directly to your mobile device. In effect this service gives you free SMS messaging from PC to mobile phone.

It can take time to get this information direct from your mobile provider, so I’ve compiled a database of all known SMS Email addresses used by the major international networks.

To get your own personal SMS Email address, use the automated form to generate your own personal address.

Ever find yourself wanting to copy emails from one Outlook account to another? Say maybe someone moves on to another job and you want to keep a record of what’s been done, or your company is reorganised and departmental emails need to be seperated up.

If you’ve ever tried to do this in Outlook 2003 you’ll have been banging your head against a wall trying to figure it out. It may be that newer version of Office provide this function automatically (I don’t know, I use OO.org) but many offices do not upgrade to the latest Office software regularly. For that reason, here’s a step by step guide to save you half an hour of your life.

Getting the To Account Ready

First up, we’re assuming you have the email account you’re copying the emails to already set up and ready to take them. This account is going to be labeled to, the account you’re copying the emails from will be labeled from.

Secondly, it is going to look as though we’re doing this backward. But you need to do this the “wrong” way around otherwise it gets a lot more complicated. Seriously.

1. Log in under the account you’re copying the emails to
2. In the folder list (on the right hand side) right click on the name of the account at the top where it says: Mailbox – Last Name, First Name
3. Select “Sharing…”
4. Click Add and select the name of the account you’re copying the emails from
5. Once added, select the name in the list and select “Owner” from the Permission Level list.
6. Click OK to close this box.

Setting up the From Account

The account you are copying the emails to is now set up to receive them. If the permissions are set up correctly the from account can copy folders to the to account.

1. Log in under the account you’re copying the emails from
2. On the top menu bar, click Tools, then Email Accounts…
3. View or change existing email accounts should be selected. Click next.
4. On the next window “Microsoft Exchange Server” should be selected. Click Change…
5. On the next window click More Settings…
6. On the next window click the tab named Advanced
7. Next to where it says “Open these additional mailboxes…” click Add
8. Enter the name of the to mailbox in the format Last Name, First Name
9. Click OK to return to the previous menu.
10. Click Next, then Finish to exit.

The to email account should now appear in your folder list on the left hand side of the screen. If you click on it you should be able to see the Inbox although you may not be able to see any other folders – that doesn’t matter (it’s the reason we’re doing it the “wrong” way around).

Moving Your Emails

To copy the folders from the from mailbox to the to one just drag them across from one account to the other. It should move them (i.e. removing the originals) automatically although you may need to do this seperately.

Because you can’t drag the Inbox folder across itself, you’ll need to copy the messages out of the folder seperately. Simply select the folder on your from account and drag them across.

If you can’t see the Sent Items in the to mailbox you will not be able to drag the emails straight across. In this case create an extra folder on the to account – named Sent Items for example – and copy the emails into there. Once you log back in as the to user you can move them across to Sent Items as normal.

If you have any problems following this guide drop a note and we can figure it out!

The new plugin download interface, hooked into wp-plugins.org adds extra incentive for plugin developers to use SVN.

There are a number of detailed SVN guides available, as well as an entire online book. But for casual plugin developers wanting to get the benefits of using the system most of the information is over detailed or not specific to the wp-plugins.org system. This tutorial covers adding and updating plugins through the wp-plugins.org SVN.

Creating a New Repository

Before uploading code you need to create the repository for it on the SVN (Subversion) server. Thankfully, this is done for you by the WordPress sytem. To set up a new repository for your plugin simple follow the steps below:

• On the WordPress » Extend site, click Add your plugin
• Enter your details into the fields provided:
  • Name is the name of your plugin. You will probably want to specify the standardised name here, e.g. im-online rather than IM Online to make sure it matches your main plugin file. It’s not important but it could save some confusion.
  • Description is a short outline of what your plugin is and does.
  • Homepage is the URL of the plugins own page on your site. This is option but is useful for admins to check the suitability of the plugin. You can specify a different page or location later if you don’t do it here.
• Click Request »

Once this is done your plugin will be checked by the admins and the repository space will be created on the wp-plugins.org SVN. An email will be sent to your registered WordPress account email (click “View Your Profile” at the top to check which email you have registered with the system).

Accessing Your Repository

There are a number of methods available for accessing a Subversion repository from GUI based applications to command line. However, regardless of the software used the processes for interacting with the SVN are the same.

Before you get started you’ll need to get your hands on some software. The wp-plugins Wiki lists recommended SVN software for Mac OS X and Windows.

For KDE I would personally recommend KDESVN which is available through Ubuntu’s repositories. It has a bizarre interface but it works effectively and features shell integration. You can also gain read-only access through KDE’s file system.

With the software installed you can now connect to your plugin’s repository the location given in the confirmation email. This follows the standard form:

http://svn.wp-plugins.org/plugin-name/

Once connected you should be presented with three folders: branches, tags and trunk.

SVN Concepts

There are a few basic concepts you need to get your head around to use SVN for plugin development. The different folders branches, tags, and the trunk, along with the development process using update and commit.

Repository Folders

Trunk is where you do the major development for your plugin. Your trunk repository should contain the latest, greatest, in development code. Your editing takes place here with updates being added to this location regularly.

Tags contain snapshots of your code, frozen in time. For this reason you commonly use tags to mark releases – e.g. a tag called 1.1 for that release. Once the tag is created (see later) you can then continue to develop the trunk code knowing a stable, permanent and more importantly working is available for download. For this reason it is not a good idea to edit or modify tags once created – to do this create a branch.

Branches are effectively tags which continue to be developed. These are useful when you need to develop two or more versions of your code in parallel, for example one version compatible with WordPress v1.x and another for WordPress v2.x You won’t be using these in normal WordPress plugin development so until then you can forget all about them!

Update & Commit

Update and Commit are the two central processes in version management. Updating, often called “checking out” is the process of updating your local copy to match what is in the repositories. Commit, often called “checking in” is the process of uploading your changes to the repository.

During commit SVN will report changes and conflicts between your local copy and the remote version stored on the SVN server. If you are developing a plugin alone and there are not likely to be contributions uploaded during your update and commit cycle it’s quite possible you’ll never see this happening. If you are developing a larger project, you may want to read up on version control.

This is only a basic introduction to SVN concepts. More information is available in Version Control with Subversion a free online SVN book from O’Reilly.

Preparing Files for Upload

Now we know what we’re doing, we’re going to set up our repository. If you’ve been developing your plugin off-line you will have a set of plugin files in a directory on your system. You can upload these files to your SVN as they are, but there are a couple of additional files you will want to add for GPL compliance and WordPress plugin download compatibility.

First of all, download a copy of the the GPL license and save this in the folder with your plugin. You may want to have a read of it first to check that you agree to the terms, but remember than GPL compliance is a requirement for hosting on wp-plugins SVN.

Next, if you want to make use of the plugin download system you’ll need to add another file, named readme.txt to your plugins directory. This file contains information about your plugin to be displayed to visitors. An example file is available, along with a validator to check before upload.

With these files in place, you’re now ready to upload your files to SVN for the first time.

First Upload

The first step is to check-out (or “update”) the trunk folder of your repository to the local folder containing the plugin files. This links your local folder to the remote repository. When you do this your SVN software will read the directory and may indicate which files are not currently in the repository (which should be all of them). Using your SVN interface simply add each file (or directory) to the SVN.

Because you currently have the repository checked out, the changes you have made will not be reflected on the remote server. In order to apply the changes, simply commit the directory back to the repository – you may also want to add a comment to indicate the changes made. Your files are now in the SVN (and can be downloaded).

Updating & Developing Code

Revision control with SVN follows the same basic process of checking in/out and making changes to files. In between these steps there are various checks (e.g. diff) which you can do to compare changes made by yourself to versions submitted by other people. However, because this article is mainly concerned with solo plugin development we won’t be covering that here. More information about resolving conflicts is available from the SVN book.

Check Out (Update)

Before developing your plugins you want to check out the current version from your repository. If you are developing your plugin single-handedly on a local installation this may seem like an unnecessary step – and in many ways it is. It is only necessary if you believe that someone else could have updated the files in the repository (e.g. applied a patch) since you last updated the files and you want to take those changes into account.

Note, if you elect not to check out the code you will receive a warning if there are any conflicts when you come to re-upload. At this point you can resolve them as neccessary.

Make Changes

Now you can edit your files and fix your plugin as you like – this part of development will be no different to developing software without SVN. Remember, if you’re using tagged releases you can check in your plugin code at any time (whether it works or not) allowing you to access it from anywhere you are.

You may also want to keep your readme.txt up to date as you go. Installation instructions which do not match the release can be a big headache for users.

Check In (Commit)

You’ve done your fixing and now you’re ready to upload the latest version of the code. This is simple a case of checking in (committing) the changes from your local files to the repository. Most GUI systems allow you to do this in one go, applying the change to an entire folder.

The system should check the files and identify which (if any) have changed. These files should be flagged to allow you to confirm that you want to apply the changes to the remote repository. If there are any conflicts your system should notify you of these now and allow you to fix them (either manually or by dropping one set of changes).

You can also add a comment at this point to indicate the changes you have made. This is useful on multi-developer projects for keeping track of who is doing what and when. You may also want to add comments so you can see when different changes were made – for example if you want to work back through previous modifications.

Once the files have been committed you can exit the repository, content in the knowledge your files are safe.

Tagging for Download

Testing

Once you have developed your plugin to the point where you feel ready to release a new version, check it. Below is a list of recommended steps for testing a plugin release:

• Test the plugin on your local installation.
• Test again on your remote setup.
• Test the plugin with all other plugins disabled.
• Test the plugin with all your other plugins enabled.
• Install on a pristine WordPress install.

Tagging

Now the plugin is ready to go you are ready to tag. Basically, tagging means taking a copy of the current trunk code and freezing it for release purposes. Again the process for doing this will differ from one SVN interface to another, but the basic steps are:

1. Copy /trunk to /tags/x.x where x.x is the version number of your release (e.g. 1.2)

That’s it.

The release is now “tagged” and available for download. However, if you want this latest tag to appear in the WordPress plugin download system you need to let it know the tag is available and is the latest version.

If you haven’t done this already, you need to go back to the readme.txt file you created earlier and find the line, near the beginning, where it lists the Stable tag. Next to this you need to add the name of the tag which you have just created and re-save the file.

Once complete simply check-in the readme.txt file again using your SVN software.

Downloading Plugins

Once the files are in the SVN there will be a short delay before they show up in the plugin download interface.

If you have tagged a “latest release” and marked this in the readme.txt file in the trunk, the download interface will point to this latest tag. However, all other tags can be accessed using the standard file format, with x.x reflecting the tag name:

plugin-name.x.x.zip

If you opt not to use tagged releases, the download file format will instead point to the trunk:

plugin-name.zip

Note that this second download location, pointing to trunk, is always available to use if you want a permanent download URL which will continue to work throughout release. Note that if you do this you will want to keep trunk as a working copy to avoid unnecessary bug reports.

Finally…

Stick with it. While SVN can seem an overly complicated system for basic plugin development, if you learn the basics above it should fit easily into your development cycle. You’ll also gain a set of skills useful not just for WordPress development, but for any open-source project.

Any suggestions, comments and improvements are always welcome.

While getting started using the new wp-plugins.org SVN I was looking for a quick way to download the contents of an SVN to local disk. This can be useful when doing research on methods employed by other plugins or for getting a local development copy where SVN access is unavailable. Under KDE you can normally access any remote location using the standard URL format. For example, an SVN (using the svn://) protocol would normally be accessed using the URL style svn://svn.wp-plugins.org.

Many SVNs, e.g. svn://svn.kde.org can be accessed as expected. However, this is reliant on the server providing an svn:// protocol access which some do not – notably the wordpress.org SVN which instead provides access to the SVN through http:// only.

In these cases you need a method for accessing svn:// via http:// ..and surprise, surprise, KDE can do that. As Sabin Iacob noted, it’s possible in KDE to provide separate file and transport protocol within a single URL. Doing this allows the filesystem to connect through one (transport protocol) and act on the result as if it were the other (file protocol).

For example, using Konqueror (or any KDE app) to connect the WordPress SVN enter the following URL to browse the WordPress repository as if it were a standard directory:

svn+http://svn.wp-plugins.org/

Of course, this is not just restricted to use on the WordPress SVN, or indeed SVN alone. This capability is useful in any situation where you need to bypass the protocol restrictions of the server yet still use the result as if it had come from a standard setup.

If you have suggestions of other uses share in the comments!

Note

When working with SVN files directly (e.g. for the purposes of developing) it is always preferable to go through the standard check-out, modify, check-in process to allow the system to keep track of changes properly. However, some times you may want to just take a copy of remote files for personal use. Pick your use-case carefully.

Adsense Manager is “Yet Another Adsense Plugin” which helps you manage the Adsense ads on your WordPress site. Unlike other Adsense plugins however, Adsense Manager generates the code automatically for you. Now you can create, edit and position Ads all from within your WordPress admin panel. On WordPress Widgets enabled blogs you can also drag the Ads around your Sidebar to position them as you like.

The plugin is currently fairly young (compared to some of my plugins) but it should be fairly stable and bug free. Feedback and suggestions for improvements are always welcome.

More information is available here…