Menu Sidebar

Catching up in the WordPress Community

I have been releasing plugins and themes since the early days (~1.0) and I’ve been doing professional WordPress development for 6 years, but I only recently realized that I’ve become out of loop with the WP community. There’s so many new sub-groups: premium sellers, WP agencies and a ton of shops.

Looking back (beyond 6 years ago) I fit into a few places, I had some popular themes 1 and a surprisingly popular plugin in Search Everything 2. The community was smaller, the “premium” market was just starting and the explosion of WordPress dominating anything but blogs hadn’t hit yet. I could blame the community growth but I can’t.

I really just shut myself out. I stopped releasing code, stopped blogging and participating. This was because I ended up separating community involvement with work/business, and with me working full-time on a premium WordPress plugin I didn’t want to spend any free time on anything related.

Now that I have a more flexible work schedule, since I only need to hold myself accountable, I’ll be able to “give back”. I plan to contribute back to core 3, putting in more time at Stack Exchange (because it’s not just about WordPress) and being involved in my local WP meetup.

It will also be good business to give back at Sprout Apps and the plan is to make the core apps available for free in WP extend. This alone will help prevent me from sheltering myself away from a community I owe a lot to.


  1. All are no-where to be found now.
  2. Search Everything which I sold to Zemanta earlier this year because I was too busy to support it and they promised to make it better.
  3. Trying to contribute back to core has always been a negative experience for me. The next time around I’m going to take a trac issue that needs work but the debate is already over.
logo vert gradient solid background

Jumping Head First into the Unknown WordPress Project

For the last several years I’ve working hard, head down developing and supporting Smart eCart (formally GBS) 1. Recently I’ve moved away from working full-time on that project but found myself without a clear direction as to what was next.

I contemplating getting back into full-time freelancing web development; for a stretch I was toying with getting a “real job” working for a team that I always wanted to work for; my original plan was go to school to learn iOS development. Instead I decided to keep doing what I’ve been doing, building and supporting a premium WordPress product. However the big difference: I’m on my own this time.

Deciding to build an app wasn’t as difficult as it was to figure out what I should build. At first I was looking to build an e-commerce solution for booking. That idea and many others didn’t last long because I found no real opportunity to break-in with the current solutions already available. I also didn’t want to build something that I’d never use myself.

I ultimately decided on building a WordPress plugin for estimates and invoicing after getting really annoyed with harvest 2. Under the advisement of good a friend I was led think bigger and build more than just an estimate and invoicing app. Instead, I could have the invoicing app as the cornerstone to a whole suite of apps/plugins.

That’s what I’ve been working on. Sprout Apps will start selling Sprout Invoices 1.0 in August and there’s a lot to get done in the next three weeks in order for that to happen. A. Lot.



  1. SeC is a social e-commerce plugin for WordPress. It’s started as a small client project and turned into something huge and successful for everyone involved.
  2. A major payment incident occurred.


I never wanted to write about this topic but after seeing this today I couldn’t help but share my Alzheimer’s experience.

If you watch Seth Rogan’s testimony you’ll briefly hear about his mother-in-law and the complications, conditions and problems they had; my mom had those very same issues, exactly the same. After years of trying my best to take care of her the disease won last year weeks before her 60th birthday. I’m still recovering from seeing how the disease destroys, especially in only a few years.


My experience with contributing to WordPress core has been awful and after years of convincing myself it’s gotten better the results might be the same. Hopefully my feeling of discouragement changes because I really want to be involved.

What I discovered is that in many ways, these jobs are a trap: They pay so little that you cannot accumulate even a couple of hundred dollars to help you make the transition to a better-paying job.

Took a few days to straighten things out but I’m n…

Took a few days to straighten things out but I’m no longer running this blog on a dedicated server and finally recovered a backup that could be used to export the DB. I’ve learned a lot of lessons, the big ones: one, don’t count on software RAID setups; two, always review your backups periodically, something could have gone wrong since you set them up.

Git Submodules with Detached HEAD

This week we at Sprout Venture migrated our largest project to git. Without going into detail about our process we ran into a problem with our superproject’s submodules initialized with detached HEADs; regardless if they’re added with the branch set.

The .gitmodules file would properly show the branch, e.g.

[submodule "wordpress"]
	path = wordpress
	url = git://
	branch = 3.7-branch

But when a branch would be checked out the branch for each submodule wouldn’t be set (or worse at times reset to detached). Not a big deal if the branch has a few submodules but ours has 100s.

I found out about $git submodule foreach and created a little command/script that would recursively loop through all of the projects submodules and checkout the branch according to the branch set in the submodules config file (see above).

git submodule foreach -q --recursive 'branch="$(git config -f <path>.gitmodules submodule.$name.branch)"; git checkout $branch'

Just change to the absolute path of where the .gitmodules file can be found.

Screen Shot 2013-09-12 at 3.56.55 PM

WordPress Clearing All Transients on Upgrade

Nacin just tweeted about a little changeset in WordPress trunk that will delete all transients after an upgrade.

Obviously someone is going to make this “controversial”, there always is with a huge project like this; I’m also not looking forward to the wp-hackers thread on the topic either. Personally, I think it’s a good idea because it’s starts a new conversation about how to properly use transients and what a developer can expect from them. It could lead to some performance improvements on sites that had/have plugins/themes that improperly utilize transients, as suggested by Nacin already.

The problem, which I should preface is untested but conceptually reasonable to bring up, is upgrade/update lag.

I believe a lot of developers, myself included are hooking on init to check for a transient and if not available call an external API (and store it temporarily again). In a current project I’m doing this (technically hooking on admin_init to check on transient data) at least twice, one for an API callback and another to get a json package for an add-on marketplace. That said, immediately after an upgrade these external APIs are going to be hit because transient data isn’t available. This would ultimately delay the load of the next page, which for any user would be either: the welcome page (that the user is redirected to after an auto-upgrade) or the dashboard (redirected to after the DB update page when first visiting the admin after core was updated manually (SVN/Git)).

Consider I do a poor job maintaining these external resources and they’re slow to respond or worse timeout, that would mean a user who just upgraded would be staring at a white screen for the duration that it takes for these external APIs to respond. In the perception this WP user/admin, the burden for this delay wouldn’t be on the plugin authors or external resources it would be on WordPress. Most likely causing people to think ‘is it going to take this long every-time I upgrade?’.

There are a lot of other rabbit holes issues that could be brought up but this is the one I’m concerned about because it affects the perception of how easy an upgrade is.

Do I still think it’s worth clearing out transients after an upgrade? Absolutely. The approach should be different, possibly a background process after the welcome page (or dashboard).

[Update] Anyone know if after an upgrade/update (with these changes) update_plugins and update_themes are fired, since their transients are deleted? This would cause our project (as an example) to need two more immediate external fetches by filtering pre_set_site_transient_update_plugins and pre_set_site_transient_update_themes, excluding the calls to the extend API which I’d expect to always be fast.

Newer Posts
Older Posts

Dan Cameron

I build stuff with WordPress

I'm currently building Sprout Apps to help small businesses and freelancers running WordPress.