Simply Static turns one

Simply Static is now one year old!1 Yay! Lots of great things have happened over the last year. Simply Static is installed on over 2,000 WordPress sites and has been downloaded more than 16,000 times. The plugin has 33 reviews, all with five stars. I’m encouraged by the fact that the plugin is used as much as it is even though it still doesn’t have many of the features I would want.

One thing I’ve noticed is that the majority of Simply Static’s users are outside of the United States. Or at least the ones I hear from via email and the support forums are. And I would assume that’s fairly representative of the user base. I’m curious if that’s common amongst other WordPress plugins or specific to mine. Regardless, I think it’s great. I’ve spoken with folks from all over the world that I never would have come into contact with otherwise. And I’m humbled by everyone’s English skills. I only speak and write English myself, and so I am grateful for any attempt to communicate in my native tongue.

I’m also thankful for how many people have offered to help with Simply Static. Folks have posted about issues they’ve found, offered patches and translations, and even created a new logo (coming soon!). I am lucky to have so many folks helping with so many different things.

Sadly, Simply Static hasn’t been growing as fast as I’d like. The number of downloads has been increasing at a steady clip, but the number of active installations has flatlined. I had anticipated hitting 2,000 active installs on February 11th. That didn’t happen until May 30th. And then after that it actually decreased below 2,000 for a while. It wasn’t until September that it finally regained 2,000 installs and stayed there.

With 16,000 downloads, this means that only about 15% of the people that download Simply Static keep it installed. I can attribute some of that to people using Simply Static to export a static site and then shutting down WordPress2, effectively using it as an archival tool. That’s a usage I wouldn’t have expected when I started. But a fair bit of those uninstallations must be due to missing features or not being easy enough to use3.

I’m including the downloads vs installs chart, but it’s rather depressing. The red line for installs shows it decreasing back to zero. In reality I’ll hit 3,000 at some point. If my conversion rate stayed the same, that would likely be sometime in February of 2017.


I’ve also not launched a premium version of Simply Static yet. I planned to do that earlier in the year but a couple things derailed that. One is that I felt like Simply Static needed more bug fixes and improvements first. The second is that I got a contract to work on a WordPress site over the summer and that ate up all of the free time I had. I’ve learned that I can’t multitask on projects. If I take on a contract, Simply Static will receive no attention.

I want to launch a premium version of Simply Static by the end of the year, but my backlog of tasks is growing faster than I can work through them. I don’t even have a good idea of how “done” the free version needs to be before working on a premium version. And that makes releasing a premium version by year’s end exceedingly unlikely.

I’m again in need of a backwards plan. I need to figure out what I’m going to ship for the free and premium versions and put dates to it. And… this is exactly the same thing I said a year ago. It’s funny how easy it is to slip back into your old ways. Shipping requires diligence. A lot of it.

1This post was originally entitled “Simply Static turns one today”, for publication on September 22nd. It’s now nearly a month later. Apparently I’m not good at keeping a schedule.
2The active installs figure is calculated based on how many WordPress installations “phone home” to report on things like which plugins are installed. Shutting down WordPress after using Simply Static would make it no longer count as an active installation.
3I am strongly considering adding Freemius Insights just to get a better gauge of why people uninstall.

Simply Static v1.3 Retrospective

The more I work on Simply Static the more I realize just how little I know about WordPress plugins. Last week I learned that when your plugin is getting upgraded via those handy links they give you to upgrade plugins that your plugin gets disabled, all of the files are overwritten, and then your plugin is re-enabled. You might think that the scary part is that your files get overwritten, but no. It’s that your plugin gets disabled. When your plugin gets disabled, it doesn’t get any of WordPress’ handy notifications for things like: hey, we’re upgrading some plugins right now. Maybe yours!

No, you don’t get to hear that. When your plugin is disabled, it’s like it’s in stasis.

So that means, for instance, if you wanted your plugin to add a new database table when someone installed v1.3.0 (hypothetically speaking of course), that your plugin has no way to know that it was upgraded unless you’re checking for being upgraded all the time.

Another thing I ran into is that MySQL doesn’t like having hyphens in table names. Normally this wouldn’t be an issue, except that I was prepending my plugin slug to the table name so that it would be unique. My plugin slug was ‘simply-static’. So, with the release of v1.3.0, I changed the plugin slug to ‘simply_static’. Go underscores!

That worked fine until it didn’t.

My plugin slug was also used as the key to store all of the settings for the plugin. Changing the slug meant that I’d need to migrate all of the settings from the old key to the new key. No problem, I thought. I’ll do the migration when I’m checking if my plugin is being upgraded.

You can imagine how well that went.

Since the plugin wasn’t properly checking for upgrades, none of the settings got transferred over, and worse yet there weren’t any default settings either, so the plugin got into a super weird state until you deactivated and reactivated it.

I feel like I should’ve caught these issues in testing, and I did test upgrading the plugin, except that it turns out that since I didn’t know how WordPress was actually upgrading plugins that I wasn’t testing it in the way I should have.

All of the above happened to coincide with me getting sick and with the repo having some issues of it’s own. So that meant that my plugin was completely unusable for the better part of a week for any unfortunate soul that happened to upgrade.

As far as lessons learned, I learned that there is definitely some lackluster WordPress documentation on how to handle plugin upgrades. I also learned that I need a test plan. Even aside from the upgrading debacle, there was an issue where URLs weren’t being replaced. A single click on any link on my test site would’ve exposed that issue.

Onward and upward, I guess.

New Year, New Goals

I’m proud of what I accomplished in 2015. After taking on the Ship by September Challenge I launched my first WordPress plugin: Simply Static. I’d done some work with WordPress before, using it for my personal websites. I’d also done some consulting work with modifying and creating WordPress themes. But plugins were new to me. I hadn’t created or customized one before. I hadn’t even looked through the code for a plugin. But, with some research on the Googles, I was able to successfully create my first plugin, submit it for inclusion on the WordPress plugin directory, and have it accepted within 24 hours.

After I released the plugin I started keeping track of the downloads, and more importantly, the number of active installs (the number of WordPress sites that the plugin is actually installed on). Initially that was to make sure that the plugin was successful and worth continuing to spend time on. At this point though, it’s pretty clear the plugin is successful, and continuing to track the metrics is just for my own personal enjoyment. Speaking of which, on December 23rd Simply Static hit 1,000 active installs — almost exactly 3 months after launching. At the current rate I anticipate hitting 2,000 active installs on February 11th. Unfortunately only reports active installs to one significant digit, so my estimations for how Simply Static is progressing are going to become increasingly less accurate.


Towards the end of last year I started putting together a plan for what I wanted to accomplish in 2016. I decided that I wanted to do one major release per month, with bug fix releases sprinkled in where necessary. January’s release was going to be an upgrade to the export log feature. February’s release was going to be to AJAX-ify the static archive generation so that it didn’t cause a PHP timeout. And in March I wanted to begin on a premium version of Simply Static.

I was able to accomplish January’s release by mid-month due to some unanticipated extra time in my schedule. However, at about the same time I learned that Simply Static had a major shortcoming. I knew that Simply Static could take a while to create a static archive, and if it took too long, PHP would cut it off before it completed successfully. What I didn’t know was that it could time out after generating as few as 100 pages. I was angry/alarmed when I found this out. One hundred pages is a small site by any measure. You would easily hit that with a year or two of consistent blogging. A limit of 100 pages was completely unacceptable to me.

Once I learned that the limit could be as low as a mere 100 pages I started rearranging my schedule. Everything I had planned for February got pushed off to March, except for fixing the timeout issue. I’m glad I created a plan for the first few months of 2016, but sometimes circumstances change and you have to change with them.

Don’t make promises

Don’t make promises you can’t keep.

In my last post I mentioned that my conversion rate of downloads to active installs for my WordPress plugin, Simply Static, was a little over 20%. And while that seemed good, I didn’t have anything to compare it to. I also said that the topic of my next post might discuss average WordPress plugin conversion rates. Mentioning that I might talk about it made me feel constrained, like I had to talk about it. Turns out, it’s hard to find out what the average conversion rate for WordPress plugins is without collecting a little lot of data over time. I didn’t have a chance to do that, so I couldn’t write about it, and as a result I didn’t write anything.

So I learned a lesson: don’t make promises you can’t keep. Or, don’t say what you are going to write next unless you’ve already written it.

In other news, my plugin has reached 600 active installations and has 10 five-star reviews. The conversion rate for my plugin is sitting at about 35%. I’m very happy with the progress it’s making.

Unfortunately my development work on the plugin has slowed. I haven’t released a new version in over a month where previously I’d released a new version at least once a week. I attribute this to several things. One, after I released the plugin I got this feeling of being done . Like there was nothing else to do. I knew this wasn’t true, of course. But my feeling of urgency in completing the plugin was gone.

I realize now that my problem was in not setting more deadlines for myself. When I was originally building the plugin I was doing it for Amy Hoy’s Ship by September challenge. And so I had a deadline. I would release the plugin by mid-September. And I did that. But without further deadlines, progress stalled. Without deadlines it was too easy to push things off until later.

Another issue is that I felt like I was drowning in bug reports. I was getting new bug reports every week. And they felt like a burden. Something that I needed to do before I worked on anything else. How could I work on enhancements when there were bugs to be fixed? However, not all bug reports are created equal. Some bugs are far more urgent or far more likely to affect people than others. So I need to find a better way to assess how impactful they are and how and when I should fix them.

The third thing is that I got Fallout 4, and I spent a lot of time playing that :(

What it comes down to is that I forgot the lessons of JFS. I didn’t set a deadline. I didn’t create a backwards plan. I didn’t ruthlessly cut scope.

It’s funny how easy it is to fall back into your old ways.

I have a release for Simply Static later this week to fix some bugs. After that, I’m creating the backwards plan. And then, onwards!

(I won’t make the mistake of saying that the next blog post will include this backwards plan.)

100 active installs

I’ve hit my first milestone for Simply Static: the plugin is now being used on more than 100 WordPress installs.

I was curious to see how my plugin was doing over time and I wanted the ability to predict when I’d hit certain milestones, so I put together a spreadsheet to track downloads and active installs. You can get the number of downloads per day from, but they only ever show active installs for the current day, so my data there is a bit spotty. I used the FORECAST function to fill in the blanks and get a rough approximation of active installs over time.


My conversion rate of downloads to active installs has remained fairly constant at a little over 20%. That seems good, but as I mentioned a couple posts back I have nothing to compare it to. Perhaps that’ll be the topic of my next post.

Why I created Simply Static

Simply Static received its first review yesterday; 5-stars! I’d be lying if I said I wasn’t excited. Though, in reading the review, I’m not sure I would have given myself 5 stars. Here’s what they said (emphasis mine):

Easy, simple, works. After file generation you need to hand copy some folders that could be miss because not linked inside the html generated by WP, like Revolution slider folders. Also you need to add file with retina extension that are normally generated by your template (e.g. [email protected]).

After reading the review I was feeling frustrated that he still had to copy over files to get everything to work. What good is a static site generator that doesn’t generate all of the files you need for your static site? No good at all.

Before I created Simply Static, I had a Ruby on Rails webapp. I needed a way to create a couple pages (Terms of Use, Privacy Policy) and maintain a blog for it.

Being that it was Rails, I could have easily built in the functionality to create pages and blog posts. But those weren’t the primary feature of my app. Adding those to Rails felt like adding unnecessary cruft. And I didn’t want to maintain HTML files by hand. What I wanted was WordPress, generating exactly the pages I needed.

If you’ve ever tried to use WordPress side-by-side with something like Ruby on Rails, you quickly find that your easiest option is to set it up on a subdomain. Which I didn’t want. I wanted everything on a single domain. A slightly more complicated option is to point specific paths at WordPress, e.g. everything at /blog/ goes to WordPress. That worked, but for arbitrary pages (e.g. /privacy) you have to hard-code each of those. Not ideal, but a little bit closer to what I wanted.

However, my fear in using WordPress on the same machine as my webapp is that WordPress is a fantastic target for hackers, and I didn’t want a compromise of WordPress to affect my webapp. In an ideal scenario, I wanted to use WordPress to create the content but publish static pages for my webapp to serve. WordPress would remain safely locked away somewhere but I’d still get the pages and blog posts that I wanted.

And so I began my search for a static site generator for WordPress.

Surprisingly, I found three static site generator plugins for WordPress. Finding them was difficult though. One of them (the one that works the best) hasn’t been updated in over 3 years and is virtually impossible to find on the WordPress plugin search engine unless you type in the name exactly. In fact, I only found it because someone mentioned it on a Hacker News thread.

After trying the plugins out, I ran into issues with each of them. The user interface on all of them was, well, not very user-friendly. And then each of them had some critical flaw with creating the static archive. It wouldn’t copy all of the files over. Or it wouldn’t replace all of the URLs for the WordPress installation with the destination URL. Or it would copy over extra files from the theme that didn’t need to be there.

In the end I used one of them that worked well enough for my situation. But I was left feeling that there was plenty of room for competition in WordPress plugins for creating static sites.

Eventually I shuttered my Rails app and went looking for my next project. I decided to take on the task of creating Simply Static. My experiences with the other plugins presented me with my two main goals. One, copy over every file needed (and nothing that isn’t needed) to create an exact static copy of the WordPress site. Two, create something simple enough that you can be up and running in a matter of minutes.

And this is why I get frustrated when my plugin when doesn’t copy all over all of the files that it should. Creating a perfect static copy of a WordPress site is the primary goal.

The first week

Simply Static has been available for a little over a week now. It’s sitting at 164 downloads and 30+ active installs. I have no idea if those numbers are good. What’s an ideal ratio of downloads to active installs? You don’t want everyone who downloads your plugin to turn around and uninstall it. But I’m sure some amount of tire-kicking is normal.

Downloads chart as of 2015-10-02

The day after I posted my plugin a friendly gentleman sent me my first bug report. He had installed the plugin on a few sites and some of the files (fonts and images and such) weren’t copying over. He was able to work around the issue by manually copying over the missing files. But that’s a suboptimal experience, and I doubted that he was the only person with the issue.

So I decided to do some research of my own. I tried out my plugin out on some WordPress sites I’d previously built to see if I could recreate the bug. Turns out I could! My plugin was failing at it’s core mission: creating static copies of websites.

So now I’m working on a new method of identifying links and files that need static copies. The current version looks for anything with the full URL in it ( and ignores relative URLs (/images/shiny.gif). The new version will go through all elements in the HTML DOM and extract the URLs from attributes. And I’ll do something similar for URLs in style blocks/attributes and stylesheets. Look for that to release in the next couple of weeks.

P.S. Speaking of releases and bugs, Simply Static is on github now. If you use the plugin and find a bug, kindly report it there. Or email it to me. I like mail.

Up and running

As of this morning I’ve officially launched my first WordPress plugin: Simply Static.

To be honest, it’s launching a bit sooner than I’d anticipated. I put in the request late Sunday night, and at that point there were 80 plugins in the queue. 30 of which were awaiting their initial review. I was expecting that it would take them a week to get to my submission. Instead, at noon the next day my submission was approved.

I had been planning to use that week to get a basic marketing page up for Simply Static. That didn’t happen. But hey, the lack of a marketing page doesn’t prevent people from using the plugin. Just f#%&ing ship, right? So I posted my plugin anyway.

Speaking of which, if you are using Simply Static, I’d really like to hear from you. Yes, you. Hit me up at

Now that my plugin has launched, my todo list involves a lot of writing. I mapped out some very clear use cases for the plugin when I created it, but they’re not written down anywhere. So I want to create a tutorial or three, and then there’s also the marketing page I’d mentioned.

I also want to keep updating the blog as I go — a sort of Captain’s Log of my adventure with entrepreneurship. We’ll see if I can stick to it!