Tag Archives: email

Dumb

Last year I wrote about my decision to remove email apps from my mobile devices. Today I took the next logical step and got rid of my smartphone altogether.

I was giddy when I got an iPhone in 2008. Having email and the web (and later, stuff like Twitter) on a mobile device was the coolest thing ever. But it’s become clear over the last year that the benefits of this connectivity are, for me personally, clearly outweighed by the drawbacks. The smartphone keeps me connected to the internet; I work on the internet; therefore the smartphone keeps me connected to work. And when I’m not at my computer, dwelling on work-related issues is both pointless (because I can’t fix them until I’m at a computer) and annoying (because duh). Even if there were a way for me to carve out a totally-non-work-related part of my online life, I’m not sure I want to have it in my pocket, where I’m always tempted to fiddle with it.

To make the transition a bit more fun, I got myself a legitimately nice dumbphone, the Nokia 515 (which I had to order from a shady-seeming importer, because it’s not supposed to be available in the US). I’m having a good time setting it up. It’s been a few years since I had to migrate my contacts manually, so I’ve built up lots of cruft. The only people I moved over to the new device are those I really like (and might want to call) and those I really don’t like (and want to screen). The camera on the Nokia is pretty good for a dumbphone, but totally lame compared to my Moto X. Using multi-tap to type is hilariously awful, but T9 is better than I remembered. It’s retro-fun.

Using this phone is going to introduce friction into my routine. Messages will be harder to type; appointments will be trickier to look up; addresses will be impossible to locate; and so on. But when I look around a subway car or a restaurant or a playground and see dozens of people gazing vacantly into the easy gleen of their smartphone screens, I remember that friction can be good sometimes.

2013

Another installment in my year-end reflections.

In my 2012 post, I laid out a couple of things to think about during the upcoming year. I feel like I did a pretty decent job with at least one of them: turning off. This summer, my family and I rented a cottage and vegged out for a month and a half. I intended it to be a semi-working vacation, but it ended up being a barely-working vacation, and it was awesome. I also made some changes in the second half of the year that made me more mindful of getting sucked into work while on the go: I stopped using email on my phone, I got myself an OFF Pocket, and I’ve generally stopped carrying my phone so much. I started riding bike for fun around the city, and got back into a decent running routine (about 800 miles on the year). So, I feel like things are a bit more relaxed than a year ago.

Work-wise, I haven’t branched out as much as I’d hoped. I’ve got a few big deadlines in the next month or so, after which I plan to come up with an interesting project or two to shake out some of the cobwebs. If anyone is planning to do something really cool, let me know 😀

I continue to feel less and less connected to my old academic self. This is something I don’t talk about much, either online or in person, though I was recently persuaded by a friend that others might benefit from hearing about it. In the upcoming year, I hope to write more about this issue and other more varied topics than what I allowed myself in 2013.

Out with the old. Happy new year!

No email, no cry

In the spirit of a recent post by my friend Evan Solomon, I thought I’d write briefly about a decision I made this summer: No more email on my mobile devices. A few months ago, I removed the Email shortcut from my home screen; today, I switched to a new phone, and I don’t plan to configure the email app at all.

The reasoning behind this decision is similar to Evan’s. Very rarely do I get an email whose subject is truly urgent, in the sense that it requires immediate action. Those few that I do receive are almost always related to work – someone’s production site has gone down, say. But, in nearly all cases, it’s a problem I can only solve if I’m at a regular computer. And if I’m using my phone, it’s likely that I’m not currently at a computer, and I probably can’t be at one immediately. So there’s little to be gained from getting the message while I’m on the go. Urgent messages that are not work-related – such as family emergencies – wouldn’t come through email anyway, so I’m not missing anything in that case either.

Like Evan, I find myself able to concentrate better on the people around me when I’m not thinking about the device in my pocket. This is doubly true because of the nature of the non-urgent email I usually get. Many emails are bug reports, and reading about bug reports when I’m not in a position to do anything about them is both highly distracting (mental debugging!) and usually frustrating. Some emails are requests: for favors, for work proposals, etc. This kind of email too is distracting in an unpleasant way, as I find myself silently drafting a response on the spot. Even the few emails I receive that are genuinely pleasant take me out of the moment, and again, don’t really admit of a proper response while I’m on the go (I refuse to write anything longer than a text or a tweet on a phone).

Weaning myself from the mother’s milk of mobile mail was a quick and painless process. A day or two in, and already I could see that I was more engaged with the things around me. When I’m at the playground with my kid, I’m paying attention to him. When I’m on the train, I’m reading a book. And when I’m standing in line or in some other kind of situation where email typically fills the void, I’m often just feeling bored. And feeling bored is a very welcome change from a head clouded by frustration and software bugs.

So, think about it. What value do you get from reading email on your phone? And what does it cost?

Project Reclaim and the email dilemma

One of the main 2011 goals for Project Reclaim is to get my email out of Gmail. Heavy reliance on Gmail raises a number of red flags. For one thing, email is central to my business and personal life online, and provides the best archive of my online past (get the important stuff first). For another, Gmail is ad-supported, in a way that has rankled since Gmail went public: it “reads” your email and serves ads based on what it finds. No one really talks about it anymore, but it still kind of bugs me – so I want to move to a non-free system (paying is better than getting something for free).

It’s taken me a while to make the move, though, for two main reasons.

  1. Email is tricky. Good, free mail server software is easy to find. But it’s not necessarily easy to set up and maintain. If the outgoing server isn’t configured correctly, your messages will get marked as spam. If you haven’t got constantly monitored spam filters on your incoming mail, you’ll be inundated with garbage. And the issues of backups and reliability, while certainly important in the case of (say) self-hosted websites, are many times more important with email: if the server goes down, emails may get altogether lost in the ether.

    I’ve set up and configured email servers before, and it hasn’t been very fun. When deciding how to solve the Gmail conundrum, I needed to take this fact into consideration. I started to do a bit of research on paid email hosting, and found good reviews of Rackspace’s hosted email service. The service is pretty affordable, and I knew from years of Slicehost use (now owned by Rackspace) that customer service and support would be good.

  2. I needed a good address. I own a lot of domain names, but most of them are lame, and none lent themselves very neatly to an email address. For instance, when your domain name is boonebgorges.com, what’s the email account name? ‘boone’? The cool factor there is pretty low. And I am a cool guy, so that’s important.

    Some of the obvious domains are taken. boone.com is wasted on dry-erase boards. gorges.com could never be wrested from the clutches of “one of the oldest family owned Volvo franchises in the United States”. But there was hope – or should I say había esperanza – that I might get the fairly unused gorg.es. In fact, my brother and I had been working on that project for a couple of years, but it was only a few months ago that the owner finally relented, and the domain name was transferred to the Gorges boys.

So, about two months ago, I made the switch. For now, I just set it up as another account in Thunderbird (more on my Thunderbird setup). I created a generic “Archive” directory on my gorg.es account (to mimic Gmail’s All Mail) and pointed my ‘Y’ shortcut to that directory. I’m using K-9 Mail on my Android phone, which I set up to save the entire Archive directory, so I’d have good local email search on my phone. Little by little, I’m moving over my email correspondence to the new, awesome address. Bye bye, Gmail!

Building a baby photo site with WordPress

My wife and I just had our first baby, which is the occassion for much nachas and, by extension, picture sharing. Facebook is, for better or for worse (emphasis on the latter), the de facto place for such sharing to happen. For a number of reasons – a desire to be somewhat selective about who sees my family pictures, my Project Reclaim sensibilities, the fact that I don’t have a Facebook account and generally think that Facebook is an evil company – I don’t want to use FB for this purpose. As in the case of my Twitpic-like photoblog, I figured I could use WordPress to set something up that was nearly as seamless as Facebook, or Google+, or Flickr, or whatever.

The criteria

There were a few things I wanted out of the baby site.

  1. Easy (or zero) login for users
  2. Control over who has access
  3. Optional email notification for new content
  4. Easy, javascripty gallery browsing

When I started, I was pretty sure that I’d be able to get all of these things pretty easily, using existing WordPress plugins. I was both right and wrong about this: plugins exist for all of these purposes, but none of them were very easy to implement. As a result, I ended up building several pieces from scratch. I’ll go through each of the criteria, talk a bit more about what I was looking for, and then say something about how it was achieved. By doing this, and sharing the code (spoiler alert: https://github.com/boonebgorges/Hard-G/tree/master/wp-content), I’m hoping that I can help others with similar sensibilities to get started on their own sites.

Non-sucky registration and login

I love WordPress, and I understand the important reasoning behind the decisions that led to the design, but WP’s user registration system sucks. I didn’t want just anyone to be able to create and activate an account. I didn’t want users to have to click an activation link. I didn’t want users to have randomly generated passwords that would need changing later on. And I wanted users to have the option of logging in a non-WP way.

Several of these problems could be solved by using Facebook logins. I’m not willing to give my photos over to the horrific FB leviathan, but I’m happy to piggyback on their login APIs if it will save my family and friends a few headaches. I wanted my users to have the option of clicking a single button that would give my site the ability to provision them based on their persistent Facebook login.

I started by looking at some popular Facebook Connect plugins from the wordpress.org plugin repository. I didn’t really like them. Most were linked to the Comments section of blog posts, while I wanted to use the logins for overall site access. Most were dependent on Javascript for logins, while I wanted to handle logins on the server side. Most used an outdated version of FB’s API (or at least of the PHP API classes that FB offers). And, to be blunt, most were too much of a mess, having been retrofitted many times over, and as a result next to impossible to extend. I tried modifying one or two of the more popular FB-WP plugins to do what I wanted, but I ended up writing so much garbage spaghetti code that I decided to cut my losses and start from scratch.

So I boned up a bit on the FB API, and wrote a small plugin that I call Wally Login. Together with the registration page template from my custom theme (a child of TwentyEleven), it does a couple of key things.

Your choice

Your choice

  • Rudimentary access control · If a non-logged-in user tries to visit any page on the site (other than the registration page), he is redirected to the Register page.
  • FB login integration · If a user clicks the “Log me in using Facebook” link, they’re directed to the FB authorization page for my website (which is registered as a Facebook app). There, they’re asked to approve the app – a one-time process – and are then returned to my site. Based on the display name, email address, etc that I get from FB, I create a WP user corresponding to the FB account. On future visits, approved users who are logged into Facebook will be automatically logged into my WP site whenever they visit it (an important point, because FB cookies are persistent over browser sessions, while WP logins, by default, are not). As a result, in the best-case scenario, a user will authorize their FB account with my site one time, and will never again have to think about authorization on Wally’s page.
  • A customized WP registration process · If users opt not to go the FB route, they can create a WP account directly on the site. I wanted to avoid sending users to an unthemed wp-login.php or wp-signup.php page, so I cribbed a few lines of code from BuddyPress and made my own registration and login dialogs. Wally’s site is part of a larger WP network, but I wanted to bypass WPMS’s built-in registration stuff (which requires users to activate their accounts, and is thus generally too hard for newbies to grok). My custom registration therefore creates the user directly (with wp_insert_user()), using a password that he provides, and skips the activation email. (By bypassing account activation, I’m removing an important spam prevention tool. More on that in the next section.)
  • Customized email notifications · Because I’m not using the built-in registration process, I needed to write my own email notifications for account applications and approvals.

If you decide to use my code, keep in mind that it’s not particulary beautiful. I wrote it for my own use, which means that it will take a bit of elbow grease to get it to work on your own site. In particular, if I were writing something for more general distribution, I would not be so reliant on a theme template as I am here. But if you’re looking to create a site like mine, this code is a great place to start – especially the FB integration stuff, which has made the registration and login process about as smooth as it can get.

Access control

The final important thing that the Wally Login plugin does is to provide me (the site admin) with control over who has access to the site. There are a couple ways I could have approached this issue. One is to whitelist users ahead of time. The problem with this is that I’m bound to forget some names, get email addresses wrong, and run into other problems that stem from my unfortunate lack of omniscience. Another strategy is the invitation code. When unique to the individual, this method suffers from the same drawbacks of the whitelist; when non-unique (ie when everyone uses the same invitation code) it takes away much of the security, as the code can be passed around quite easily; either way, invitation codes are clunky, easily misplaced, and all too often mistyped.

Thanks for applying

Thanks for applying

As a result, I ended up going with a third option: an application and approval process. Here’s the idea, conceptually. Anyone who wants can create an account on my site (either through Facebook or natively; see the previous section). However, the account does not actually allow access to the site unless the account is also approved by the administrators. Thus, after the initial application, two emails are sent: one to the applicant saying “thanks for applying, please be patient”, and one to me saying “there’s a new applicant, please approve them”. Then I go to my approval interface and click the Approve button (if I want), which marks the user as approved in my database and sends them an email saying “You’re in!”

Here’s a brief description of how it works technically. All applicants have a WP account created for them. Every new account is marked, at the time of creation, with user_status = ‘2’, and I make sure that no page other than Register can be viewed by an account with user_status = ‘2’. In this way, I am turning the idea of activation around a bit – natively, WP makes the user do the activation, but in my case I do it. The admin tool I use to activate users is my Unconfirmed plugin, designed for a slightly different purpose but quite at home here. (For technical reasons, Unconfirmed needs users to have activation keys; thus Wally Login also generates some dummy keys during the user creation process so that Unconfirmed will work right.) Unconfirmed, in turn, does the work of flipping user_status to 0 upon approval.

Taken together, Wally Login and Unconfirmed (with custom WP registration, FB integration, user approval by admin, etc) has given me a comfortable level of access control, without making the process unduly difficult for my users.

Email notification for new content

One of the biggest drawbacks of creating a standalone picture site instead of using an all-purpose social network (in practice, this means Facebook) is that the standalone site is likely to be forgotten. FB collects all of your network’s activity into a single stream; it’s highly unlikely, on the other hand, that Wally’s site will become part of anyone’s daily routine, so that they stop by to check for new content. For that reason, good email notification of new content is essential to making the site work.

Dead simple email subscription

Dead simple email subscription

I first tried using the popular Subscribe2 to handle these notifications. But I ran into a bunch of problems. For one thing, I didn’t like that S2’s subscription management happened in the Dashboard – I want to keep my users on the front end. S2’s category-based subscription is too complicated for my site, where people are either going to want to subscribe to all posts or to none at all. And the widget that comes with S2, for display on the front-end of the site, is pretty much atrocious. (Sorry. The rest of the plugin is nice. But that widget sucks.) At first I tried solving these problems just by building my own widget for S2, one that would tell the user whether he was currently subscribed, and show an Unsubscribe/Subscribe button, as appropriate. But, given the structure of S2’s data (which is somewhat arcane, and in any case far too complicated for my purposes), it ended up being a lot harder than it should have been.

So – wait for it – I wrote something from scratch. It is dead simple. Two parts: (1) a widget, which does exactly what I describe in the foregoing paragraph; and (2) hooks into publish_post to send an email to all subscribed users (along with some gentle checks to make sure dupes are not sent). This plugin has no admin UI and no options, because I don’t need any of those things.

Pretty galleries

Since the main point of the site would be to look at lots of pictures, it was quite important to have an easy, pretty way to do so. By “easy” I mean, primarily, navigable by keyboard; by “pretty”, I mean, primarily, bigger than the content area of a typical blog post. Less important, but still desirable, was the admin interface: I wanted it to be easy to upload lots of pictures at once, to add captions and other metadata if necessary, and to turn it all into a gallery that would look good on the front end.

Pretty, easy

Pretty, easy

You know the drill: I tried a couple of the more popular free plugins, but all of them were annoying in one way or another, and each one was way overengineered for my meager needs. I was especially disappointed by the back-end admin for the popular gallery plugins, which I found lugubrious, unintuitive, and impossible to extend. After some consideration, I decided that I actually preferred WP’s native Add Media interface for uploading photos and adding metadata, and that I was perfectly happy with the way that WP’s gallery shortcode displayed content on the front end, at least when viewing thumbnails.

So the only thing I really needed was to implement the javascript that would allow for keyboard navigation and lightboxing of gallery photos. Thanks in part to his extremely uncreative and literal plugin naming schema, I found Viper007Bond’s jQuery Lightbox For Native Galleries plugin. It does almost exactly what I want, right out of the box.

I did make a few minor mods, though. First, the plugin is a bit greedy in the way that it filters the output of get_attachment_link(), which was either breaking things (as in the case of comment_post_redirect on attachment posts) or making it hard to display links to the attachment page instead of the raw attachment file. The former problem I solved with a filter; for the latter problem, I was a bit lazy, so I modded the plugin itself in addition to adding an explicit ‘lightbox’ class to attachment links. This combination of hacks makes it work perfectly for my purposes.

Odds and ends

A little bonus

A little bonus

With my absolute requirements met, I was able to add a few other goodies to the site. My theme is a child of Twenty Eleven, which I’m pretty much using as-is. But I’ve added a few fun bits. First, on each attachment page, I added Download links, so that users could download images of various resolutions for printing or editing. I messed with the WP Admin Bar so that users coming from Facebook wouldn’t see Log Out and some other inappropriate links. And under each thumbnail in Gallery view, I’ve added Download/Comments links, so that users could bypass the jQuery lightbox and go straight to the attachment permalink if they wanted.

It took some work, but I think I’ve ended up with a site that is nice to use and easy to maintain, without resorting to the extreme discomfort associated with Facebook. Hooray!

New WordPress plugin: Unconfirmed

If you’ve ever been responsible for supporting an installation of WordPress Multisite with open registration, you know that the activation process can be a significant source of headaches. Sometimes activation emails get caught by spam filters. Sometimes they are overlooked and deleted by unwitting users. And, to complicate matters, WP’s safeguards prevent folks from re-registering with the same username or email address. This can result in a lot of support requests that are not particularly easy to handle. Aside from reaching manually into the database for an activation key, there’s not much the admin can do to help the would-be member of the site.

The Unconfirmed Dashboard panel

The Unconfirmed Dashboard panel

My new WordPress plugin Unconfirmed eases this problem a bit, by providing WPMS admins with a new set of tools for managing unactivated registrations. (By naming it “Unconfirmed”, I fully expect that the plugin will join some great movies and books in the pantheon of Important Cultural Objects.) Unconfirmed adds a new panel to your Network Admin Dashboard (under the Users menu). When you visit the Unconfirmed panel, it gives you a list of all pending registrations on your system. The list is easily sortable by registration date, username, email address, and activation key. For each unactivated registration, there are two actions that the admin can perform. “Resend Activation Email” does exactly what it says: it sends an exact duplicate of the original activation email, as created by the WordPress core activation notification functions. “Activate” allows admins to activate a pending registration manually, which will trigger the activation success email to the user.

At the moment, Unconfirmed is compatible with WordPress Multisite (aka Network mode) only. In the future, I may expand the plugin to work with non-MS installations of WP. Unconfirmed works with BuddyPress, too. The plugin was developed for use on the CUNY Academic Commons.

Download Unconfirmed from the wordpress.org repo or follow its development on Github.

Making the Thunderbird interface more Gmail-y

As part of Project Reclaim, I’m gearing up to move my email off of Gmail and onto my own server. Email is, and long has been, central to my life online – it’s my main point of contact for so many personal and professional connections, and my email archives are the closest thing I’ve got to a record of my online activity. So I’m keen to make the move as smooth as I can.

For that reason, I’m handling the transition in stages. The first stage involves transitioning email client software away from the Gmail website.

Choosing a client

I’ve chosen Thunderbird as my alternative, for a couple reasons.

  1. It’s open-source.
  2. It’s highly extensible and customizable.
  3. It works across platforms. That’s important, because I’ll be migrating away from OSX.

Choosing Thunderbird is not without its sacrifices. For one thing, moving to an OS-native application, rather than an app that runs in a browser window like Gmail does, means that I’ll no longer be able to count on having a consistent UI and feature set between different devices. In some cases, this is not a huge loss. The UI for Gmail on my Android phone is really quite different from the normal web version, and it’s never bothered me very much. My biggest worry, though, is that I’ll have multiple workstations – a primary work machine and a netbook, for example – with different email setups. I’m hoping to mitigate the problem by coming up with some idiot-proof backup and syncing methods for the fairly small number of files that comprise Thunderbird’s configuration. (This’ll be necessary for other software transitions as well, like my gradual move to Vim. It’d be quite easy with Dropbox and some strategically-placed symbolic links, but I’m trying to break the Dropbox habit too 🙂 )

It’s a considerable comfort that, now that I have a smart phone (and am thus no longer reliant on public or borrowed computers for email access), the vast, vast majority of my email use is centered on a handful of devices, all of which I own. The last time I checked my email on a device other than my own was probably three years ago. Weird, now that I think of it.

The other sacrifice is related to UX. I happen to like Gmail’s interface. In particular, I’ve grown quite used to Gmail’s thoughtful keyboard shortcuts, which make it possible to do nearly navigation without touching the mouse. Coming up with a reasonable facsimile of these shortcuts in Thunderbird would be the biggest part of my configuration process.

Keyboard Shortcuts

Thunderbird has pretty good keyboard shortcuts out of the box. I didn’t feel like learning a whole new system, though, so I wanted a way to map Gmail-style shortcuts onto Thunderbird. There used to be a Thunderbird extension to do just that, called GmailUI. But the GmailUI website suggests that the extension is only compatible with Thunderbird versions 0.8-2.0 (Thunderbird’s currently in 3.1), which would explain why the extension doesn’t show up in a search on tho Mozilla repo (the “Expression Search” plugin does come up, which is a fork of a part of GmailUI that I’ll talk about in a minute – but it doesn’t do keyboard shortcuts).

So I looked for a more general method for customizing Thunderbird’s keyboard shortcuts, and found it with Keyconfig. It’s pretty straightforward to remap keystrokes using Keyconfig (Tools > Keyconfig), though it can be a bit of a pain because many of the standard Gmail shortcuts (like j and k for up/down navigation) are already in use by Thunderbird, so that changing one shortcut often means making two. You might find it helpful to borrow my configuration, which I’ve pasted below. Add these lines to your user.js config file (create if it doesn’t exist):

[code language=”javascript”]
user_pref(“keyconfig.main.key_killThread”, “][I][“);
user_pref(“keyconfig.main.key_markJunk”, “meta shift][J][“);
user_pref(“keyconfig.main.key_markReadByDate”, “meta shift][D][“);
user_pref(“keyconfig.main.key_markThreadAsRead”, “meta shift][R][“);
user_pref(“keyconfig.main.key_newMessage”, “meta shift][M][“);
user_pref(“keyconfig.main.key_newMessage2”, “meta shift][N][“);
user_pref(“keyconfig.main.key_nextMsg”, “][J][“);
user_pref(“keyconfig.main.key_previousMsg”, “][K][“);
user_pref(“keyconfig.main.key_reply”, “][R][“);
user_pref(“keyconfig.main.key_replyall”, “shift][R][“);
user_pref(“keyconfig.main.key_toggleMessagePane”, “][V][“);
user_pref(“keyconfig.main.xxx_key74_SwitchPaneFocus(event);”, “][D][“);
[/code]

Briefly, this does the following. First, it maps some familiar keystroke combos from Gmail to Thunderbird: j and k to up and down, and r and R to Reply and Reply To All. Second, because two-stroke codes from Gmail (like gi for Go To > Inbox) don’t seem to be supported natively by Thunderbird, I’ve mapped D to SwitchPaneFocus, which lets me get back and forth between the folders pane, the message list pane, and the single message pane, for easier navigation. As I get more comfortable with it, I might write my own extension that ports over some of the other most convenient Gmail shortcuts, but for now this covers a good 80% of what I might regularly use.

The other big shortcut missing from Thunderbird is y, which is the Archive command in Gmail. For that purpose, I installed Nostalgy, which allows you to move messages with keyboard shortcuts. I don’t think I’ve set this up in 100% the right way, but here’s how I’ve approximated Gmail’s y using Nostalgy. First, at Tools > Nostalgy > Keys, I’ve set ‘Save message’ to ‘shift Y’ and ‘Save as suggested’ to ‘Y’. ‘Save as suggested’ seems to work on a session basis; it suggests the folders that you’ve used since the last time you started Thunderbird. Thus, every time I start Thunderbird, the first time I want to archive a message, I use the more verbose shift-Y. A dialog at the bottom of the window suggests places where I might put the message; I select Gmail’s All Mail folder. Then, the next time I want to archive a message, I can use y by itself to go to the suggested (i.e. the last-used) location. Since I just throw all of my email into All Mail – no complex tagging or organization – this is all I need.

Bonus! Offline Access and New Email Throttling

Moving to a non-web-based email client is not all bad. For one thing, moving to a local application means that my email – archives and all – are available offline. I know that Google Gears and some of the new HTML5 goodies mitigate the issue somewhat with respect to Gmail, but offline access for a webapp is always going to be something of a hack.

On a related note, one thing that I have always hated about using Gmail is how it weaves together the process of checking for new email and accessing old email. I like to check for new mail at specified intervals only (once every few hours); anything more than that is extremely distracting. In Gmail, this meant closing the browser tab. Yet, fairly frequently, I find that I need to access an older email from my archive in order to do a specific task. In Gmail, this meant checking my new email as well. Now that I’ve moved to Thunderbird, I can access my archive without checking for new mail – the way it ought to be!

Setting it up this way was not straightforward. There are a few things you’ve got to do:

  1. In Tools > Account Settings > Server Settings, configure the ‘Check for new messages at startup’ and ‘Check for new messages every x minutes’ however you’d like. I have them both disabled, so that email can only be checked manually.
  2. Here’s the tricky part: Gmail, in its futuristic wisdom, uses a special protocol called IDLE to push new email to remote clients – bypassing the settings from step (1). (This took me half a day to figure out.) Disable this feature at Tools > Account Settings > Server Settings > Advanced > ‘Use IDLE command if the server supports it’.

I’m planning to spend a few weeks improving and getting used to this setup before starting the migration to self-hosted email.

Wildcard email whitelists in WordPress and BuddyPress

Cross-posted on the CUNY Academic Commons Development Blog

WordPress (and before that WPMU) has long had a feature that allows admins to set a whitelist of email domains for registration (Limited Email Registration). On the Commons, we need to account for a lot of different domains, some of which are actually dynamic – but they are all of the form *.cuny.edu. WP doesn’t support this kind of wildcards, but we’ve got it working through a series of customizations.

These first two functions form the heart of the process. The first one hooks to the end of the BP registration process, looks for email domain errors, and then sends the request to the second function, which does some regex to check against the wildcard domains you’ve specified. This is BP-specific, but I think you could make it work with WPMS just by changing the hook name.


function cac_signup_email_filter( $result ) {
	global $limited_email_domains;

if ( !is_array( $limited_email_domains ) )
		$limited_email_domains = get_site_option( 'limited_email_domains' );

$valid_email_domain_check = cac_wildcard_email_domain_check( $result['user_email'] );

if( $valid_email_domain_check ) {
		if ( isset( $result['errors']->errors['user_email'] ) )
			unset( $result['errors']->errors['user_email'] );
	}

return $result;
}
add_filter( 'bp_core_validate_user_signup', 'cac_signup_email_filter', 8 );

function cac_wildcard_email_domain_check( $user_email ) {
	global $limited_email_domains;

if ( !is_array( $limited_email_domains ) )
		$limited_email_domains = get_site_option( 'limited_email_domains' );

if ( is_array( $limited_email_domains ) && empty( $limited_email_domains ) == false ) { 
		$valid_email_domain_check = false;
		$emaildomain = substr( $user_email, 1 + strpos( $user_email, '@' ) );
		foreach ($limited_email_domains as $limited_email_domain) {
			$limited_email_domain = str_replace( '.', '.', $limited_email_domain);        // Escape your .s
			$limited_email_domain = str_replace('*', '[-_.a-zA-Z0-9]+', $limited_email_domain);     // replace * with REGEX for 1+ occurrence of anything
			$limited_email_domain = "/^" . $limited_email_domain . "/";   // bracket the email with the necessary pattern markings
			$valid_email_domain_check = ( $valid_email_domain_check or preg_match( $limited_email_domain, $emaildomain ) );
		}
	}

return $valid_email_domain_check;
}

Before WP 3.0, this was enough to make it work. The latest WP does increased sanitization on the input of the limited_email_domains field, however, which makes it reject lines like *.cuny.edu. The following functions add an additional field to the ms-options.php panel that saves the limited domains without doing WP’s core checks. (Beware: bypassing WP’s checks like this means that there are no safeguards in place for well-formedness. Be careful about what you type in the field, or strange things may happen.)


function cac_save_limited_email_domains() {
	if ( $_POST['cac_limited_email_domains'] != '' ) {
		$limited_email_domains = str_replace( ' ', "n", $_POST['cac_limited_email_domains'] );
		$limited_email_domains = split( "n", stripslashes( $limited_email_domains ) );

$limited_email = array();
		foreach ( (array) $limited_email_domains as $domain ) {
				$domain = trim( $domain );
			//if ( ! preg_match( '/(--|..)/', $domain ) && preg_match( '|^([a-zA-Z0-9-.])+$|', $domain ) )
				$limited_email[] = trim( $domain );
		}
		update_site_option( 'limited_email_domains', $limited_email );
	} else {
		update_site_option( 'limited_email_domains', '' );
	}
}
add_action( 'update_wpmu_options', 'cac_save_limited_email_domains' );

function cac_limited_email_domains_markup() {
	?>

<h3><?php _e( 'Limited Email Domains That Actually Work' ); ?></h3>

<table class="form-table">
	<tr valign="top">
		<th scope="row"><label for="cac_limited_email_domains"><?php _e( 'Limited Email Registrations' ) ?></label></th>
		<td>
			<?php $limited_email_domains = get_site_option( 'limited_email_domains' );
			$limited_email_domains = str_replace( ' ', "n", $limited_email_domains ); ?>
			<textarea name="cac_limited_email_domains" id="limited_email_domains" cols="45" rows="5">
			<br />
			<?php _e( 'If you want to limit site registrations to certain domains. One domain per line.' ) ?>
		</td>
	</tr>
	</table>

<?php
}
add_action( 'wpmu_options', 'cac_limited_email_domains_markup' );

New BuddyPress plugin: BuddyPress Group Email Subscription

Email Options on settings page

Email Options on settings page

I’m quite happy to announce the release of a more-or-less stable (we hope!) version of BuddyPress Group Email Subscription, a BuddyPress plugin that allows for fine-grained, user-controllable email subscription to group content in BuddyPress.

This plugin is different from some of my others in that it was truly a group endeavor. The base of the plugin was written by David Cartwright, with a little bit of code from me. A nearly complete rewrite of the front-end and most of the guts of the plugin was undertaken by Deryk Wenaus. I wrote the daily and weekly digest functionality, along with some of the settings pages and various bugfixes throughout. The current codebase of the plugin is probably 60% Deryk, 30% me, and 10% David.

It was my first time working on a truly collaborative software development project like this, and it was a real pleasure working with both of these gentlemen. Thanks, guys.

Get BuddyPress Group Email Subscription here.

Adding an “email to members” checkbox to the BuddyPress group activity stream

During the recent upgrade from BuddyPress 1.1.x to BuddyPress 1.2.x, and the subsequent move away from group wires to interactive group activity streams, one thing that some users on the CUNY Academic Commons missed was the “Notify members by email” checkbox of the old wire.

This morning I wrote a bit of code to add that kind of functionality to group activity streams. There are three functions, each of which goes in your plugins/bp-custom.php file.

First, adding the checkbox to the activity box. Notice that it only shows up when you’re on a group page.

[code language=’php’]

function cac_email_activity_checkbox() {
if ( !bp_is_groups_component() )
return;
?>


Second, handling the data when it gets to the server and sending the emails. Obviously, you’ll want to change the text of the email to match your own site and your own preferences. The line “remove_action( ‘bp_activity_after_save’ , ‘ass_group_notification_activity’ , 50 );” is there to prevent an email notification from being sent if you’re using the Group Activity Notification plugin, a big official release of which is coming soon 🙂

[code language=’php’]

function cac_email_activity_handler( $activity ) {
global $bp;

if ( $_POST[‘mailme’] == ‘mailme’ ) {

$subject = sprintf(‘[CUNY Academic Commons] New update in the group “%s”‘, $bp->groups->current_group->name );

$message = strip_tags($activity->action);
$message .= ‘

‘;
$message .= strip_tags($activity->content);

$message .= ‘

——-
‘;

$message .= sprintf(‘You recieved this message because you are a member of the group “%s” on the CUNY Academic Commons. Visit the group: %s’, $bp->groups->current_group->name, $bp->root_domain . ‘/’ . $bp->groups->current_group->slug . ‘/’ . $bp->groups->current_group->slug . ‘/’ );

//print_r($message);

if ( bp_group_has_members( ‘exclude_admins_mods=0&per_page=10000’ ) ) {
global $members_template;
foreach( $members_template->members as $m ) {
wp_mail( $m->user_email, $subject, $message );
}
}
}

remove_action( ‘bp_activity_after_save’ , ‘ass_group_notification_activity’ , 50 );
}
add_action( ‘bp_activity_after_save’, ‘cac_email_activity_handler’, 1 );
[/code]

Finally, you’ll need some Javascript to make the AJAX activity submission work correctly. This is really just a copy of what’s in the bp-default JS file, with a few added lines to make it work.

[code language=’php’]
function cac_email_activity_js() {
if ( !bp_is_groups_component() )
return;
?>

var jq = jQuery;
jq(document).ready( function() {
jq(“input#aw-whats-new-submit”).unbind(‘click’);
/* New posts */
jq(“input#aw-whats-new-submit”).click( function() {
var button = jq(this);
var form = button.parent().parent().parent().parent();

form.children().each( function() {
if ( jq.nodeName(this, “textarea”) || jq.nodeName(this, “input”) )
jq(this).attr( ‘disabled’, ‘disabled’ );
});

jq( ‘form#’ + form.attr(‘id’) + ‘ span.ajax-loader’ ).show();

/* Remove any errors */
jq(‘div.error’).remove();
button.attr(‘disabled’,’disabled’);

/* Default POST values */
var object = ”;
var item_id = jq(“#whats-new-post-in”).val();
var content = jq(“textarea#whats-new”).val();
var mailme = jq(“#cac_activity_mail:checked”).val();

/* Set object for non-profile posts */
if ( item_id > 0 ) {
object = jq(“#whats-new-post-object”).val();
}

jq.post( ajaxurl, {
action: ‘post_update’,
‘cookie’: encodeURIComponent(document.cookie),
‘_wpnonce_post_update’: jq(“input#_wpnonce_post_update”).val(),
‘content’: content,
‘object’: object,
‘mailme’: mailme,
‘item_id’: item_id
},
function(response)
{
jq( ‘form#’ + form.attr(‘id’) + ‘ span.ajax-loader’ ).hide();

form.children().each( function() {
if ( jq.nodeName(this, “textarea”) || jq.nodeName(this, “input”) )
jq(this).attr( ‘disabled’, ” );
});

/* Check for errors and append if found. */
if ( response[0] + response[1] == ‘-1’ ) {
form.prepend( response.substr( 2, response.length ) );
jq( ‘form#’ + form.attr(‘id’) + ‘ div.error’).hide().fadeIn( 200 );
button.attr(“disabled”, ”);
} else {
if ( 0 == jq(“ul.activity-list”).length ) {
jq(“div.error”).slideUp(100).remove();
jq(“div#message”).slideUp(100).remove();
jq(“div.activity”).append( ‘

    ‘ );
    }

    jq(“ul.activity-list”).prepend(response);
    jq(“ul.activity-list li:first”).addClass(‘new-update’);
    jq(“li.new-update”).hide().slideDown( 300 );
    jq(“li.new-update”).removeClass( ‘new-update’ );
    jq(“textarea#whats-new”).val(”);
    jq(“#cac_activity_mail”).removeAttr(‘checked’);

    /* Re-enable the submit button after 8 seconds. */
    setTimeout( function() { button.attr(“disabled”, ”); }, 8000 );
    }
    });

    return false;
    });
    });