development

Having been away from the WordPress scene since version 2.x days (I think the last time I launched a WordPress website was around 2009), I recently had reason to develop some WordPress plugins, and I wanted to ask some questions about the WordPress coding standards and API that I hope will help enlighten me (and, maybe, other PHP developers coming from other frameworks/platforms to WordPress).

Here are some questions I've had while working on my first WordPress plugin (coming purely from the development side—I'm deliberately ignoring any mention of WordPress's UI, as I don't want to inspire any trolling along the lines of 'WordPress vs. [Another CMS]'):

After reading A successful Git branching model [nvie.com], which I consider one of the best graphical/textual depictions of the ideal Git model for development teams (and most large projects), I simply wanted to adapt a similar (but way less complex) model for some of my smaller sites and multisite Drupal installs.

Since I'm (almost always) the only developer, and I develop locally, I don't want the complexity of working on many branches at once (master, hotfixes, develop, release, staging, etc...), but I do want to have a clean separation between what I'm working on and the actual live master branch that I deploy to the server.

So, I've adopted a simple 'feature branch model' for my smaller projects:

• master - the live/production code. Only touch when merging in a feature or simply fixing little bugs or really pressing problems.
• [issue-number]-feature-branches - Where I work on stuff.

Graphically:

Any time I work on something more complicated than a simple styling tweak, or a fix for a WSOD or something like that, I simply create a feature branch (usually with an issue number that matches up to my internal tracking system). Something like 374-add-node-wizard:

Android's back button is a problem. A big problem.

Others have already identified this in a broad sense, but I wanted to give a few concrete examples of why I (as a guy who wants to simply port a couple apps from the iOS platform to Android) think the back button (especially) is a bad idea.

Disorientation

Mobile phones, and tablets especially, require a lot of UX work in the area of interface orientation. For my extremely-basic CNL app, I've spent hours tweaking little interface elements that change when the interface is rotated from portrait to landscape.

The tendency in iOS is to use a 'back' button with the label of the previous function/screen in a given app in a navigation bar at the top of the current screen. This allows a user to freely move about inside an app, and is pretty much consistent across all apps. Additionally, this 'universal back button' is always at the top left of the screen—just like a web browser.

Email is such a pain (I should know, as I'm currently working on a site that's sending 10-20,000 emails per day to 40,000+ users. Spam prevention, SPF records, bounce handling, abuse reports, deliverability, send rates, etc. are all huge hassles that must be dealt with when handling more than a few hundred emails a day.

For testing, I often like throwing in a quick bit of code to send me or someone else a simple email with a few bits of information when something happens on the site, or to test email addresses or formatting. Therefore I like having a quick one-line function call to send an email. In Drupal 6, there was a handy drupal_mail_send() function that would use some default settings and allow you to quickly shoot off a simple email (not translated, not pluggable, etc., but easy to implement).

Drupal 7 did away with that function, and instead, the simplest way to send an email in Drupal 7 requires some 20+ lines of code. Not fun when I'm trying to set up a few quick one-off emails that just need a 'from', 'to', 'subject', and 'message'. For these emails, I don't care about message translation, mail altering, etc. I just want an email shot off as quickly and simply as possible.

Drupal 7. Is it ready?

That seems to be the general question in the air over the past few weeks discussed by many in the community. There's a problem with this question, though... I think many people look at their particular use cases, determine Drupal 7 to not (yet) be a good fit, then declare all things Drupal 7 to be lacking.

Really, though, are things so bad? I've seen hundreds of sites on Drupal Gardens that are beautiful and functional. I've upgraded two of my simpler Drupal 6 sites to Drupal 7. I've built a total of fifteen Drupal 7 sites—some serving more than 10,000 visitors a day, others serving a hundred or two (and almost all on shared hosting!)—and am working on three others. So, for me, the question 'Is Drupal 7 ready for prime-time?' doesn't make sense. It's already there (I haven't started a new project on Drupal 6 for six months now).

Sure, there are a few rough edges in Drupal 7, and some of the APIs can be confusing and/or complex, mostly because of incomplete or missing documentation... but those things are easy to fix, and require more developers to start using the APIs and fleshing out the APIs.

The second app developed by Midwestern Mac is Catholic News Live, or CNL for short. This app, which is the iPhone/iPod Touch/iPad/Android interface for the content aggregated by the Catholic News Live website, showcases a simple list and map layout on mobile phones and tablets, as well as Drupal's great flexibility.

The Catholic News Live website uses the Drupal distribution Managing News, which allows the site administrator to add news feeds that are automatically imported on a set schedule from websites all around the world. Each story is geotagged with a location (if proper locational keywords exist in the article), and then stories have latitude and longitude values for map display.

The iOS app takes these stories and allows users to not only view and read them in a simple list, but also share any story via any popular social media service (making use of the popular ShareKit for this purpose). Stories can also be displayed in a map view using the iOS MKMapView.

The Android app has similar features to the iOS app, but uses Android's built-in sharing service and the Android MapView.