Tag Archives: Drupal

Drupal: Search for users by eMail address

Posted on by
5

This Drupal tip is probably obvious for 98% of Drupal admins out there – but I’ll post it here for that 2% that have no idea that searching for users by email address is possible/so simple. I used Drupal for over 2 YEARS before I stumbled on how to do this!

To search for a user by email address:
In most themes, you can simply leave the ‘search box’ empty and hit the SEARCH button. This will bring you to a search page with a ‘content’ tab and a ‘users’ tab. Simply enter the email address or partial email address in the search field in the ‘users’ tab, and press search. No need for special wildcard characters. For example, to list all of your users with Hotmail addresses, just type in ‘hotmail.com’.

That’s it!
Happy Christmas everyone and I hope that Santa brings you what we’ve all wished for – much traffic and earnings!

Keep Track of What You Break!

Posted on by
Reply

Do you make a lot of changes to your site?
Do you realize later that you broke something?
Do you pull out your hair because you don’t remember exactly what you changed days or weeks ago?

..yah, me too.

I can’t remember how many times I’ve made a bunch of changes, installed new modules, change my Apache config, deleted modules, etc, then find something broken days or even weeks later. What’s more frustrating is remembering “i know I changed something.. I just can’t remember exactly what!”

There is a easy way to avoid this frustration: Keep a simple “change-log” of everything you do. Create a txt file and keep in a handy location – like on your desktop. Every time you change something, jot it down in the file. For example:

Dec 12 9:50AM - changed Boost-module cache settings to 9-hrs
Dec 11 10:20pm - changed PHP.INI memory_limit = 16M to memory_limit = 32M

It’s simple and free, and I can’t tell you how many times it’s saved my butt.. I also can’t tell you how many times i’ve kicked myself for being lazy and NOT recording something in my changelog file and realizing days later that something is broke and I can’t remember what I did to break it.

Make Kontera Load Faster

Posted on by
4

From the first day I started touting Kontera as a money-maker I have been hearing from other webmasters that they tried Kontera but had to drop it because it slowed-down their webpages as the Kontera tags/ads loaded. I never experienced this issue so i just poo-phoo’d them.

Recently however, imagine my horror when i found that Kontera had started to slow-down my web pages as well! I contacted my Kontera account manager and he mentioned that there are some updated Kontera tags in the works that may help improve performance by not loading until after the content on your page has loaded. I tried the new tags and sure ’nuff, the new tags are indeed teh snappier!

To get the new Kontera tags for your site contact your account manager and he or she will hook you up.

DRUPAL: How To Use dnsBL and RBLs

Posted on by
Reply

Most of my recent yammering about using DNSBLs to block spammers, trolls and other riff-raff has focused on using the DNSBL with Mod_security rules and IPTables firewall which requires either a dedicated server or at least a VPS – leaving all you shared-hosting users out in the cold to fend for yourselves..

But Drupal users in shared-hosting environments rejoice and fear not! You can easily incorporate some of the fun and function of these DNSBLs too! You won’t have the same ability to totally drop their packets but you can block the posts that they make or redirect them to an error page.. Here’s how:

The Drupal TROLL module will not only allow you to block IP’s of users or other IP’s that you add to the block-list, but it will also make-use of DNS Blacklists (DNSBL) to prevent the spammers/trolls, etc from making any posts. They can still read your pages, they just can’t make posts. To use the DNSBL option in TROLL, install as usual, then on the DNS BLACKLIST tab in the configuration page click the “Enable Operation” checkbox and specify how many blacklists the IP must appear on before being “blacklisted” (1 should be plenty).

By default the Troll module uses dnsbl.sorbs.net, bl.spamcop.net, dnsbl.njabl.org, cbl.abuseat.org, & sbl-xbl.spamhaus.org. I would be careful with some of those – particularly spamcop.net and the sbl-xlb.spamhaus.org list. I would change sbl-xbl.spamhaus.org to XBL.spamhaus.org and maybe replace the others with some from my favorite black lists. Remember – be careful. I dont think the Troll module will log when IP’s are blocked so you wont have a good gauge of who is being blocked.

The other way which you can use instead-of Troll or in addition-to Troll is one of my other favorite Drupal Modules, Bad Behavior. The newer version of BadBehavior includes httpBL support from ProjectHoneyPot which will catch/stop a lot of spammers and trolls. The Drupal BadBehavior module is no longer officially supported by the Author, but the community has been doing a good job at patching it and keeping it current. To get the newer versions of BadBehavior to work with Druapal and also enable httpBL support read-through this page at Drupal: Updated For BadBehavior 2.1. If all the posts in that thread are too much to follow, I have the fully-patched (with updated whitelists) version and I’d be happy to ZIP/gZIP it up and send to anyone that needs it.

Keeping Spammers Away

Posted on by
2

I’ve spent a lot of late nights over the last two weeks fine-tuning my anti-spam, anti-troll, and anti-script kiddies setup. I’ve also spent a bit of time optimizing all of my MySQL databases and Apache memory usage, but that almost seemed easy compared to keeping the trolls and spammers away.

Over the last week I have also slowly re-enabled the use of RBL’s via MOD_SECURITY to catch the IP’s of known spammers, open SOCKS proxies, TOR nodes, etc then pass the IP address to the firewall to block them (semi) permanently. I had disabled the use of RBL’s and DNSBL’s a while back due to performance issues but I finally worked those problems out (DNS lookup & firewall problems).

The overall setup now looks something like this:
Layered Security
The funny thing is that even with all the fancy firewalls, mod_security, RBL, DNSBL’s and user-agent filtering, good-old Akismet and Bad-Behavior still catch things that all the others missed.

Drupal: Change From Private File System to Public File System

Posted on by
2

When first setting up a new Drupal site one of the things you have to choose is the type of File System access to use – either “Private” or “Public”.   Of course you don’t have much information to help you make this life-altering decision other than what the Drupal File System configuration page tells you:

Choose the Public download method unless you wish to enforce fine-grained access controls over file downloads. Changing the download method will modify all download paths and may cause unexpected problems on an existing site.

If you are (or, were) a n00b like me, naturally you would choose the method which would would allow you to enforce fine-grained access controls over file downloads, aka the private filesystem option.

The only trouble with choosing to use the Private file system is that it will prevent you from activating options like “Optimize CSS files” and “Optimize Javascript files”. (That’s why both of these optimization options are grayed-out in your performance settings!) Using the private file system will also prevent you from using performance-enhancing modules like Javascript Aggregator. And, unless you are actually making use of those fine-grained access controls over file-downloads, you don’t even need your file system to be ‘private’.

So you may ask yourself, “why can’t I change from a private file system to public?” And the answer is the scary warning that you see on the Drupal File System settings page:
Changing this location will modify all download paths and may cause unexpected problems on an existing site

I stared at that warning-message for 5 years and finally decided to do some extensive research to see what would happen if I changed from my private file system to a public file system. After 10 minutes of Googl’ing and 5 minutes of reading, I learned it’s really not that big of a deal to change the file system type – so I gathered my courage, made my backups and made the change from a private to a public file system.

The change is simple: on your admin/settings/file-system page, just click from “private” to public and check through all of your pages – particularity pages with uploaded files or images. Of course, make a complete backup first, but if you see a bunch of broken pages and panic, it’s simple to just click back from public to private and it will put everything back the way it was.

I made this change on 3 sites of mine. On two sites, nothing happened, and everything worked perfectly. On one site, many of my uploaded images were returning “not found” – this is because just as the warning promised, some of the download paths had changed. Fixing the broken download paths was quick and painless.

Fixing the “not found” broken image paths:
Using Firebug or by looking at your page-source, find the broken image-path. In my case it was “/sysroot/files”. Then, find the correct/actual location of your images. In my case it was just “/files”. Now that you know the new path you can update all of your pages/nodes with two simple SQL updates.

The first update will fix any node bodies, and would look something like this:
update node_revisions set body = replace(body, '/sysroot/files', '/files')

The second, will fix any node-teasers, and will look like this:
update node_revisions set teaser = replace(teaser, "/sysroot/files", "/files")

If you have files/images in your comments, the update would look like this:
update comments set comment = replace(comment, '/sysroot/files', '/files')

That’s it! It took me less than 5 minutes to make the change from a private file system to a public file system and fix any damage. Of course, your mileage may vary, so be sure you have a good backup of your database before you change anything.