Handling the Crontab for Drupal in a Multisite Configuration

When running Drupal in a multisite configuration, handling the crontabs for each domain can be a hassle to maintain, especially if you are running a large install, with many, many clients, clients and domains coming and going and the like.

This can be pretty easily managed with a file simple lines of PHP. The goal of this code is to create a file that will look in the "sites" directory and see the entire list of domains and subdomains, skipping, of course, the "all" and "default" directories. Also, when PHP parses thru a directory it lists "." and ".." as directory names, so those must be filtered out as well.

The PHP to accomplish this is quite simple, look at the code below:

<?php
$dont_run[0] = ".";
$dont_run[1] = "..";
$dont_run[2] = "all";
$dont_run[3] = "default";
$path = "./sites/";
$dir_handle = @opendir($path) or die("Unable to open $path");
while ($file = readdir($dir_handle))
{
 if(!in_array($file,$dont_run))
 {
  system("wget -O - -q -t 1 http://".$file."/cron.php",$ret_val);
 }
}
closedir($dir_handle);
?>

Looking at the above code, you will see you can list any additional domains you want filtered out by simply adding the the $dont_run array. it will open the sites directory, list thru each subfolder, if the name isn't found in the $dont_run array, it then does a wget on the cron.php for that domain.

In my testing this script works great on two different installations, the only possible issue I see is if some hosts limit access to the system() command.

Google Ad Manager

For the last few months I have been using Google Ad Manager to manage my Google AdSense ad spaces across my web sites and it's been very nice. I like the sleaker code of Ad Manager and the increased control of placements and slots, but until recently I have not used it for third party ads, even though I knew it had the capability...or, that it was actually it's main selling point.

Using Ad Manager keeps most of the information about the ad space out of the client side code, which is nice. AdSense, in the beginning had everything client side...font colors, background colors, size, publisher number and more. They later upgraded code to contain less, and then Ad Manager has virtually nothing. The only thing it still has is the one thing I wish they'd store client side, that being the publisher number.

That aside, the Ad Manager makes it easy to manage even third party ads. Set up an advertiser record (client) and a line item (each ad for that client) and assign each of those ads to existing ad slots. When setting up the line item you select what type of ad it is, select geographical targeting and how to display it and it will begin appearing in those ad slots.

When configuring the unit you can enter how much you are receiving by CPC or CPM, or if it's a "house" ad (such as you'd use for affiliate ads) and it will show it accordingly. It can also be set up to show AdSense ads as back fill for spaces you no longer have inventory for.

You can host images on their system, set up custom HTML or JavaScript code, set them with date or impression ranges, and even target the ads by country, browser, browser language, operating system, bandwidth and time of day. Pretty amazing functionality in that regard.

Also, it's hosted by Google, so it's no maintenance, space or resources on your part, and the code calling ads is JavaScript so it does, by nature, eliminate crawlers from executing it and bloating your stats unnaturally.

I've been very happy with Ad Manager thus far, and have used it for mostly affiliate ads, such as eBay Partner Network and Amazon.com ads, but it is so much more functional than that.

If you have a need for an ad server to manage your advertisement publishing efforts, check it out.

I am so glad to see this being covered, Google Scams!

As a frequent visitor of the Google AdSense support forum, we see, every day, people coming in complaining that Google has ripped them off. Saying they paid $2.00 (or so, prices vary) for some CD full of AdSense ready web site they can just deploy and start making money with. Then, 7 days later they see a $79 charge (again, prices vary) from a company that isn't Google.

These services are not Google, they are scammers using the Google's good name and ripping people off. The additional $79 would be a monthly charge that is approved by the user (usually unknown to them) via the fine print terms and conditions of their $2.00 CD purchase. This is justified as a fee for ongoing support of the product.

Yesterday Fox News finally covered the story in a local news broadcast letting people know about the scam. It's growing in popularity quickly, and I have seen Google take some down as they have the chance, but they pop right back up under a new name, multiplying quicker than they can be caught.

I am just glad the news media is actually covering something that may help people, finally.

Google's Not-So-New Idea

Yesterday Google announced "Web Elements", which, in a nutshell is the brilliant and innovative concept of syndicating news content from their database to your web site.

Oooooooo, what a unique idea, it's only as old as, I dunno, RSS feeds.

RSS feeds do have a couple drawbacks, those being that you need to have either a feed reader to read them easily or have some technical knowledge to parse them out and show them on your web site. Both drawbacks of which can be easily remedied by any number of free solutions found all over the internet. The upside of RSS is that if you do have the technical know-how you can integrate them seamlessly into your web site's content.

With this new fangled whiz-bang "Elements" thing the only real new part of it is that you can tie it in to your Google AdSense account if you so choose. Other than that it's basically a little news block that has a predefined look and feel which far too much resembles a blatant advertisement.

I love Google AdSense, big fan, but at least with AdSense you can set colors and styles to match your own web site with these new web elements, ya get what ya get and they stand out like the proverbial turd in a punch bowl.

I like the idea of the interactive interface of the "next" and "previous" buttons, the layout of the news and the little highlight image is nice so they do look attractive, but by the looks of it, it'll only be attractive if your web site has a white background with light blue accent colors.

Running Drupal as a Multisite with cPanel

In recent weeks I have been working with a friend setting up a web site/web service as a business idea. We decided on Drupal as a base for the project due to it's apparent adaptability to multisite configuration, meaning, one code base can run multiple web sites. First we tried it on the DirectAdmin control panel, as it's my personal choice. It turns out DirectAdmin has some limitations when running subdomains that disallowed it from working in our desired setup.

So, off to cPanel we go...

I haven't looked at cPanel is years, it's come a long way, and has good addon domain handling as well as very functional subdomain handling, and it's user interface has become vastly more usable, though it still has too much crap on top with all the useful links available after scrolling.

The trick for multisite handling is that you need to assign all your domains and subdomains to point to the same web root. When registering a new subdomain, point it to the default "public_html" directory of your web root. When registering an addon domain, you must declare it as a "parked" domain. As a parked domain you have no ability within cPanel to use it for email, however, so one would need to go to the registrar and direct the email to Google Apps or some such service.

That takes care of the domain pointers. Now it's handling them inside of the Drupal system. Drupal has a root/sites/ directory. Inside that directory you need to creat a directory for each domain and subdomain you will be running. So your install will look like this (assuming "public_html" is your web root, some hosts use "htmldocs" or any other name):

/public_html/
/public_html/sites/
/public_html/sites/default
/public_html/sites/domain1.com
/public_html/sites/domain2.com
/public_html/sites/subdomain.domain1.com

etc.

Each of those directories will be used when Drupal is hit with a request from the related domain. The trick to a multisite configuration is to never, ever use default for anything! Always, even from the very first domain, use a domain folder. The sites/default folder has a file in it named "default.settings.php". This file should be copied to each domain folder and renamed settings.php and made writable for installation, also make sure you have a unique database for each site to keep each site separate.

You can use one database a use a prefix, but that would be a HUGE database if you are running many sites, using a unique database helps keep sites independent, and database sizes more manageable.

Any domain or subdomain that is requested from a domain folder that hasn't been set up will be prompted to install it. The install works the same for any domain or subdomain, just enter the proper database info for each one.

These are just a few tips I have learned in the past few weeks to make running a multisite configuration of Drupal easy.