Rogue Wolves

I've decided to try out the FeedBurner StandardStats feature to keep an eye on various site statistics such as referrers, geographic location of visitors, browsers used, etc.

Note: This is something the Drupal logs could do a much better job at. A nice dashboard similar to what StandardStats gives you with pretty graphs, etc.

The FeedBurner instructions to integrate StandardStats into your site didn't work well for me. There are Drupal specific instructions, but they fail to mention which template file you should put the code into. Here is the code FeedBurner suggests:

<script src="http://feeds.feedburner.com/~s/YOURFEEDNAME?i=http://www.example.com<?php print $node_url ?>" type="text/javascript" charset="utf-8"></script>

You will need to change YOURFEEDNAME and www.example.com to your site specific info. After some reading I found that $node_url is only available in Node.tpl.php and not in Page.tpl.php so the code must go into Node.tpl.php. At first I thought it was working but then I noticed that for anonymous users (the majority of site visitors) the script was not showing up in the html. After a bit of head scratching I realized this must be a cache issue. Now how to clear the Drupal cache? I thought there used to be a button on one of the admin screens to do this? I can't seem to find it (if it ever existed) so I had to clear the cache the manual way: I truncated the cache_page table in mysql. Bingo! Things were working now.

Note: Drupal really should have an admin feature to clear the cache.

After some more testing I noticed a problem with this technique. Using the Node.tpl.php will cause the FeedBurner script to be repeated for every node that is on the page. For node view/edit pages there is only one node so this is not an issue, but for the front page or a node list page (term pages, etc) the script will be included for each node. This means that if a user visits the front page of your site in FeedBurner StandardStats will report the user visited every node listed on the front page. Needless to say this will skew your stats. I'd rather be more accurate and know that they visited the front page.

To fix this behaviour I decided to not put the script in Node.tpl.php. Instead I put code in Page.tpl.php so there is only one notification to FeedBurner StandardStats: whether the user is on the front page or on a particular node page. Since the $node_url variable is only applicable to Node.tpl.php I needed a new technique to report the node url. My first attempt was to add this code to the Page.tpl.php:

<script src="http://feeds.feedburner.com/~s/YOURFEEDNAME?i=http://www.example.com/<?php print $node->path ?>" type="text/javascript" charset="utf-8"></script>

This script worked for logged in users, but mysteriously $node->path always returned blank for anonymous users. After some digging on Drupal.org, I found this bug report about $node->path returning null for anonymous users. They have a good work around: Use url("node/$node->nid") instead of $node->path

My working script is as follows:

<script src="http://feeds.feedburner.com/~s/YOURFEEDNAME?i=http://www.example.com<?php if ($node->nid != "") print url("node/$node->nid"); ?>" type="text/javascript" charset="utf-8"></script>

The if ($node->nid != "") will only append the node url if we are currently on a node page. This isn't a perfect solution, since this will only return a specific node url or your root url (ex: www.example.com). A better solution would always return the actual URL being visited whether it is a search page, term page, node page, etc. Consider that a future enhancement...

I also wanted to mention Dave Ried's new FeedBurner Module. I have not yet tried it out but it sounds like it has great promise and will eliminate the need to do much of this kind of stuff manually:

Integrates Drupal with the services provided by FeedBurner. Currently this module provides the means to redirect requests for your site's feeds to user-specified/created FeedBurner feeds. Special user agents, like FeedBurner and Feed Validator (this can be customized) are still allowed access to the direct feeds so there is no need for any special .htaccess hacking.

Update: Here is a link to another way you can integrate FeedBurner StandardStats.

I've decided to use CVS to maintain my Drupal sites rather than manually downloading Drupal updates and upgrading by copying the updates into your drupal folder. Manually updating is time consuming. In order to do it correctly you shouldn't just copy the new files overtop of your existing install since this could leave old files in your folder that are no longer used and can cause problems or security holes. To do it right you need to rebuild your Drupal folder and then copy in your settings, themes, etc. Then you may also need to go and download all your modules again for the new version. It turns into a chore quickly. A much better way is to use CVS to handle all the grunt work.

Drupal like many open source projects uses CVS to maintain it's development and release code. CVS is a version control system that helps developers keep track of their code and all the changes that have occured. Also, like many open source projects the CVS repositories that store this code are open for anonymous access (read only). This means anyone can download the latest code directly from the CVS repository that hosts it. By using CVS you get all the nifty features of a version control system such as updates to out of date files/folders and removal of files no longer in the repository. This is exactly the functionality I want in order to eliminate the need to manually perform these actions...

I recently decided to play around with FeedBurner and get some useful stats on my RSS feed. If you ever wanted to know how many people subscribe to your feed, what they use, and track hits then you should check out FeedBurner. Plus it's free! (you can pay for a pro account that gives you even more ways of slicing and dicing your stats)

Instructions for integrating FeedBurner into Drupal

In order to use FeedBurner you need to tell FeedBurner where your RSS feed exists and then you need to direct all of your site visitors to subscribe not to your Drupal feed but rather to the feed that FeedBurner will create for you. This way all your feed traffic will pass through FeedBurner so they can calculate all those fancy stats.

There are several ways to integrate this. Here are a few:

1. You could setup FeedBurner to point directly to your Drupal feed and then modify your site theme so that the RSS links point to the FeedBurner RSS url. Plus you'd also want to modify the RSS url for autodiscovery (the feature that lets your browser or feed reader detect that an RSS feed is present on the current webpage). To change the autodiscovery feature you can follow this thread on Drupal.org. Now when someone subscribes to your site they will use your FeedBurner RSS feed so you can track stats.
2. The above option has a big problem. Those subscribers that have already subscribed to your RSS feed will still be grabbing your feed from Drupal rather than from FeedBurner. So all your current subscribers will be ignored in the FeedBurner stats. Blah. To get around this you can modify your .htaccess file and redirect your traffic to your drupal rss feed to the feedburner rss feed! Aha! It's fixed! Um, not quite... If you do this you will break FeedBurner because it also uses your drupal rss feed! So you'd be redirecting feed burner back to itself! Frustrated yet? So in order for this to work you need Feedburner to have a special "hidden" url to get to your RSS feed (that doesn't get redirected). This allows FeedBurner to get to your drupal feed and subscribers to your Drupal feed to get redirected to the FeedBurner feed. Then you could do the other hacks in option 1 to make sure new subscribers use your FeedBurner feed too.
3. You SMRT people out there may have picked up on something. Why do we need to do all that stuff in Option 1 if we are already redirecting our Drupal feed url to FeedBurner? Good call! Simple answer? You don't! So this option is the simplified way to integrate FeedBurner. It involves creating a special "hidden" url so FeedBurner can get to your Drupal RSS feed and some rewrite rules in your .htaccess file to redirect all traffic to your drupal feed to your FeedBurner feed. That's it! This will take care of new subscribers to your feed and current subscribers with minimal fuss. This option also lets you have control over your feed since all feed requests goes through your site.

More details inside...

Last week I finally bit the bullet and upgraded my Drupal site to 4.7. I know! I know! It's been out for a while why did I wait to update to the new goodness? Comment Spam and lots of it. I was waiting for the spam module to be updated for 4.7 and I was planning on doing the update as soon as it was ready but life happened so last week was the first chance I had.

To figure out a good upgrade strategy I found Matt Westgate of Lullabot posted a great video on upgrading your Drupal install to 4.7. Also the Drupal website has a good hand book devoted to upgrading from previous versions.

In particular my upgrade steps were:

1. Backup mysql database
2. Log in a User 1 (the first user that you created for your drupal site is the administrator)
3. Disable all contributed modules and custom themes
4. Backup your whole 4.6 directory on your web server
5. Remove 4.6 files and directories on your web server(this avoids having leftover files from 4.6 when you copy the 4.7 directory)
6. Copy 4.7 files and directories to your web server
7. Copy your files directory from the backup of your 4.6 directory into the 4.7 directory
8. Copy your config.php file from the backup of your 4.6 directory into the 4.7 directory (It's stored in the Sites directory
9. Copy your .htaccess (and robots.txt if you had one) from the backup of your 4.6 directory into the 4.7 directory
10. Open your browser to www.yoursite.com/update.php (substitute www.yoursite.com with your url)
11. Follow the directions on that page to update your db (you backed up your db right??)
12. Now you are done the heavy lifting. You can download and install updates of any contributed modules you need/want from drupal.org (don't forget to enable them)
13. Copy in any custom themes to the 4.7 theme directory and enable them
14. The menu system has had an overhaul from 4.6 so you most likely will have to go in and tweak your menus a bit
15. Don't forget to look over and change your Access Control settings after the update and after you install all the contributed modules
16. If you use Cron for periodic Drupal tasks don't forget to edit the appropriate cron file in the scripts folder of your 4.7 directory

Wheh! I think that's pretty much it. Hopefully your upgrade will go nice and smooth. Oh if you had an XTemplate theme you will need to install the XTemplate theme engine as Drupal has now switched over completely to phpTemplate. (If you have no idea what that means then you are probably okay).

My upgrade went fairly smoothly. I have a mirror install of this site on my laptop so I was able to do some upgrade tests before taking the plunge and worked out most of the snags. My personal site however had a snag that had me scratching my head for a bit. Anonymous users couldn't see any content posted but rather saw the first message drupal displays when you install a brand new site. Hmm. Strange. I searched Drupal.org and found this post from a user that had the exact same problem. He wasn't alone it seems a few others were having the same issue and one of the posters said they fixed the issue by installing the Simple.Access module.

Note:You can download the 4.7 version here.

Anyways, this made a light bulb go off in my head as to what was happening and I posted this comment to the thread on Drupal.org:

Good upgrade but keep getting first user screen

I had this same problem and figured out that it was because I was using a module that sets access control on nodes (in my case it was organic groups) but when I upgraded I no longer needed this module so I didn't bother upgrading/enabling it. But if you aren't going to use the module you need to clear the node access information on the nodes otherwise nodes will not be visible to anonymous users...hence the start screen that is showing.

This is my guess as to what's happening but I'm not sure as I haven't dug too deeply into it. Someone else could verify this.

To fix this issue: I installed the Simple.Access module and then enabled it (as the module specifies) and then disabled it using the admin/access/simple_access/setup page. Disabling the module will clear all the node access information so all the nodes are visible again.

Since I no longer desired the node access control this worked well for me.

Hope this helps!

So if anyone else is in this situation hopefully this will help them out.

By the way, if you notice any problem with this site please let me know. Thanks! And sorry if my RSS feed has been duplicating the last few days. Hopefully it's resolved now. It seemed to be a glitch from updating.

If you are interested to know some of the differences from 4.6 to 4.7 click here.