Menu

Colin Devroe

Photographer. Podcaster. Blogger. Reverse Engineer.

Supporting OS-level Dark Mode preference using only CSS

My blog’s theme is based on Davis by Anders Norén. I’ve been using it for a while, making small tweaks here and there for my images index and other things.

It has a dark theme built-in that I can toggle on and off. But it is an either/or type of thing. I can either have the dark theme on all the time or not.

Since updating to Android 10 I’ve been trying Dark Mode to see if I prefer it. So far it is a bit of a mess, because so many apps simply do not support it yet. Even Google’s own built-in Android apps have yet to fully embrace the OS-level preference. But I’m sure this will change with time.

For my personal blog I’ve long thought about adding a toggle or switch somewhere to allow someone to turn its dark theme on or off themselves. But, for whatever reason I just put it off so long that I never did it. But now, just after Android 10’s release on Pixel phones and on the cusp of iOS 13 being released, both major mobile OSes will soon have an OS-level preference for Dark Mode. I thought this would be a good time to support that preference.

It turns out that many of the latest browser versions have a media query, or CSS’s version of an IF statement, that will allow you to add support for it rather easily.

@media(prefers-color-scheme: dark) {
    /* Do Dark Mode things here */
}

Since Davis already had a .dark-mode body class I was able to take all of those selectors and move them into this media query. This way, if someone toggles that preference at the OS-level, they will automatically get my site’s dark theme. If they toggle it back the other way, my site will adjust. Simple.

I do not think I’m going to go through the trouble of adding a manual switch for viewers. That will end up being a legacy way of handling this in due time. I think people will either turn Dark Mode on or not and if they do they’ll get their preferred version. Even Windows 10 and macOS have these preferences now.

If you’re a Dark Mode person, I hope you like it.

Side note: Anders is spearheading the next official WordPress theme in its next release. If you look at his other themes you’ll see why.

Audio: My armchair analysis of Automattic acquiring Tumblr

Date recorded: August 19, 2019

Yesterday while driving (sorry for the audio quality) I recorded a quick audio bit to distill my thoughts on why Automattic acquired Tumblr.

Short-version: Automattic sees Tumblr as an entry point for new WordPress.com customers – especially youth. For someone to go from idea to full commerce or publishing success via WordPress.com’s current offering could seem cumbersome and not nearly as hip as Tumblr.

Listen to the audio bit for more details. We’ll see if I’m right in 5 years.

Links relevant to this audio bit:

Automattic acquires Tumblr

Matt Mullenweg, on this Tumblog:

When the possibility to join forces became concrete, it felt like a once-in-a-generation opportunity to have two beloved platforms work alongside each other to build a better, more open, more inclusive – and, frankly, more fun web. I knew we had to do it.

Let’s get a few things out of the way immediately. Matt’s team acquired Tumblr for beans. That alone is a big part of this story. Yahoo! paid just over $1B for the platform and Automattic, reportedly, paid somewhere in the $3M area. In the world of acquisitions, this may end up being one of the most profitable acquisitions made by a tech company. Time will tell but I’d be willing to bet that Automattic will profit on this acquisition in a very short period of time.

Second, the tech stack of Tumblr is going to be replaced by WordPress. This is good for a variety of reasons. It ensures Tumblr will very likely be around in some form or another in perpetuity while still retaining its unique posting UI that its community no-doubt loves. I know I love it. I wish I had the same thing for my WordPress blog. Maybe I will get that now?

It also likely means that Tumblr and WordPress users can move back-and-forth between these two platforms much easier. I remember when I switched The Watercolor Gallery, which began as a Tumblog in 2010, to WordPress. It took me weeks to get everything right. Presumably this will no longer be the case.

And lastly, Automattic is an excellent home for Tumblr. They don’t just throw things out like Google, or apparently Verizon. They believe in building things for the long haul, doing them openly (for the most part), and retaining the ethos of the companies they acquire.

Both Flickr and Tumblr have seemingly found good homes.

I’m cdevroe on Tumblr.

Yesterday I submitted a bug report for WordPress’ Gutenberg and this morning the fix was in the 5.1.1 release. WordPress dev community is killing it.

A new interview with Manton Reece of Micro.blog for 2019

Last year, around this time, I published an interview with Manton Reece – founder of Micro.blog (M.b) – about how the platform was growing and what the goals for 2018 were. It was such a great interview and it helped me to understand the direction that M.b was going that I knew I had to interview him again to check in for 2019.

Answering these questions isn’t easy. Manton and I have been volleying back and forth for about 60 days for this interview to come to this point. So before we jump into the interview I just want to take a moment to thank Manton for taking the time to thoughtfully respond to my questions. I hope the entire M.b community enjoys this interview and it helps to give an idea of what is happening there and where the community and platform are headed.

I’ve tried to include links to most everything we mention so that you’re able to find all of the little tidbits. If I missed anything, leave a comment or reply on M.b and I’ll try to track down what you’re looking for.

Now, onto the interview:

Thank you again Manton for taking some time to answer my questions. Last year’s interview was fun so I thought it’d be a good idea to revisit a few of the topics in it and also catch up with you on how Micro.blog is doing and see where it is headed in 2019. Last year you mentioned that most of the growth on the team would come in the form of curators or support. Has the team grown? If so, what does the team look like today and what will it look like in 2019?

Manton: Great to talk to you again! The size of the team has not grown since last year, but I think we’ve done more with the people we have. Jean MacDonald has hosted over 40 episodes of our Micro Monday podcast, and Jon Hays has lead recent improvements to our iOS app and new apps Sunlit and Wavelength. I still expect the growth to be on the curation side and hope that can be a focus of 2019. Where the other big social networks try to use algorithms to solve problems, we think if you want a great community, humans need to be actively involved — featuring content, listening for problems, and thinking about the impact of new features.

Customer support and system administration are the other areas that I’m looking forward to getting help with, but as the platform evolves it’s still valuable for me to be handling most of that myself. I hear from customers every day about what they love and what features are missing. Since we last talked, I’ve also moved my primary blog with thousands of posts from WordPress to Micro.blog hosting, and that has been a great way to prioritize improvements to the hosting part of the platform. Blog hosting is the actual business of Micro.blog and enables us to do everything else we want to do for the social network and community.

From an outsider’s perspective, I don’t know how you’re able to do as much as you do! You are coding Micro.blog, keeping up with the infrastructure software/hardware, dealing with support, paying the bills… the list goes on and on. Then, on top of all that, you’re building a few iOS apps like Sunlit and Wavelength. You also have your own podcast called Timetable and a long-running podcast called Core Intuition. Not to mention your personal blog, help documents for Micro.blog, and keeping up with the community and the Slack channel.

How do you prioritize all of this? Is one project more important than another?

Manton: I think good things can come from trying to do a little too much, but it’s not usually sustainable. Eventually it catches up with you and you have to simplify and wrap up or delegate some tasks. We are in that kind of period right now with Micro.blog. We will continue to do a lot, but some parts of the platform — like the iOS apps — can reach a point of maturity where we work on stability improvements and polishing existing features rather than adding brand new features.

Android is another good example. Many people ask for an official Android app for Micro.blog. Because I don’t have much Android experience myself, I know I would be stretched too thin right now to tackle it, so we are encouraging third-party solutions instead. There’s a new version of Dialog for Android which has full support for the Micro.blog timeline, posting, replying, the Discover sections, and more. I’m really excited about it.

The most important project is the Micro.blog web platform, because without that foundation nothing else is possible. Improving the API and blog hosting will always be something we work on, alongside other priorities that come and go.

I for one am very happy that Dialog exists. I’m also happy that it is pretty good too. What other third-party projects have you come across that more people should know about? And, what haven’t you seen made on top of Micro.blog that you wish existed?

Manton: People should keep an eye on Gluon, which is in development now for iOS and Android. I’ve enjoyed reading developer Vincent Ritter’s blog post updates about working on it — the early choices he made on how to build the app and later decisions to update the UI and rewrite portions of it.

Integrating other platforms is another area that is great for third-party apps. For example, IndieWeb-compatible tools like OwnYourGram (for copying Instagram posts to your blog) or IndieBookClub (for posting about books you’re reading or want to read). Having so many third-party apps that can supplement the basic features on Micro.blog means that we can keep the primary experience as streamlined as possible, because the goal is to make blogging easier. I’d love to see more advanced tools for managing posts as well, such as batch editing posts or for import and export.

Switching gears for a moment to Micro.blog’s long term financial sustainability. I know at first there was a funding push related to the Kickstarter campaign, and of course there are those that pay a few dollars per year for the hosted service or other features like cross posting. What does long term sustainability look like for Micro.blog? Does there need to be a lot of growth in the customer base? How else can people like me, who use Micro.blog daily but are not currently paying, help keep Micro.blog funded?

Manton: Kickstarter was perfect to get us started, but paid subscriptions are better long term. I want to build features that are valuable and worth paying for. So we’ll keep making our blog hosting more compelling so that it’s good for people who are just getting started with a new blog, or people who want to migrate from other platforms. We often see people who might have a primary blog on WordPress — and a secondary microblog or photo blog on Micro.blog — decide that it’s simpler to just consolidate everything to Micro.blog, importing their WordPress posts. We don’t expect all the millions of bloggers who host on WordPress to move over to Micro.blog, but even a relatively small number moving to Micro.blog will make the platform more sustainable.

We just rolled out several major new features for blog hosting, including categories and custom themes, so you can have full control over the HTML, CSS, and JavaScript on your site. You don’t need to be a designer or developer to use Micro.blog, but it’s nice to allow some more flexibility for those people who do want to tinker with their site. And now web developers can create custom themes for Micro.blog that can be used by other members of the community.

As for supporting Micro.blog if you aren’t a paying customer, the best way is to tell people about it. All our growth right now is from word of mouth. It’s great when people invite their friends from other social networks, or when they post about why they like Micro.blog on their own blog or talk about it on their podcast. You don’t need to have a large audience to make a big difference.

I’d be remiss to not mention the apparent resurgence of blogging. If not in action then in the collective consciousness. It seems many people are talking and writing about blogging lately. With Medium changing its policies, Tumblr being owned by Oath/Verizon/Aol, Twitter being a hive of villainy, Facebook selling our fears to our captors, and Instagram growing up to be like’s its parent… it seems that blogging is poised to have a huge comeback. Are you doing anything at all to capture that momentum? Or, are you just trying to keep on your roadmap as usual?

Manton: It feels like everything we’ve been working toward for a few years is starting to come together, as more people realize the downsides of these massive, centralized platforms. Whether someone is quitting Facebook tomorrow or a year from now, I want Micro.blog to be a great default choice for reclaiming ownership of your content and getting in the habit of writing or posting photos regularly. When Basecamp recently migrated their long-running blog Signal v. Noise away from Medium, they summed up the change just like we see it: “Traditional blogs might have swung out of favor, as we all discovered the benefits of social media and aggregating platforms, but we think they’re about to swing back in style, as we all discover the real costs and problems brought by such centralization.”

The other part of this is to have a safe, welcoming community. I hate to see people get discouraged from blogging because “no one” is reading, so it helps that we have the Micro.blog timeline and replies where a blog post can start a conversation, or new posts can be featured in the Discover section. I think 2019 is going to be great for blogging. Micro.blog differentiates itself because it offers a solution for both blog hosting and a great community.

Professional blogging; whether that be funded by advertisers, subscribers, fans – is a big business. What are your thoughts on how Micro.blog helps or ignores people or businesses that may want to use the platform to share their content and earn a living from it?

Manton: Micro.blog was designed for people, not “brands”, but there’s no reason it can’t be used for businesses as well. Toward the end of last year I wrote a “12 days of microblogging” blog post series, and on one day highlighted how businesses can use Micro.blog.

Personal blogs can evolve into a revenue source as well, like offering subscriptions or sponsorships. But Micro.blog will never have ads and we aren’t likely to add features specifically for people to make money from their content in the way that Medium is trying to do. We want to focus on helping people discover blog posts, and whether someone monetizes their blog or uses it for occasional self-promotion is up to them. It’s okay if most blogs are personal and non-commercial because that lends itself to authenticity, and there’s great value in just having a space of your own to publish to.

We also think podcasting is only going to get bigger, which is why our first new paid plan was microcast hosting for short-form podcasts. We keep increasing the limits and now you can publish even hour-long episodes to Micro.blog. Like personal blogs, podcasts could be sponsored, or they could be just for fun, or they could indirectly benefit your business, such as supplementing a blog or helping promote something else you’re working on.

I believe you’ve touched on open source regarding Micro.blog in the past. Some of your own projects, like JSON Feed, are open source. Will you be open sourcing Micro.blog or any pieces of it?

Manton: I don’t plan to open source all of Micro.blog in the near future. It’s a complicated project with several components across multiple servers, so it’s not really suitable for just “running yourself” right now. However, I’d love to open source more of it, especially when there’s an immediate benefit to people. For example, for the new custom themes feature, I rewrote all of the themes to use the Hugo blogging engine, and we’ve shared all our changes on GitHub. That’s something people can use right away. Jon Hays also wrote a framework called “Snippets” for the Micro.blog API and Micropub API that we’ll be using in our iOS apps, and we’ve open sourced that as well. I think there is more in our iOS apps (including Wavelength for podcasts and Sunlit for photos) that would be great to open source.

I think I catch myself looking for a search feature on Micro.blog at least twice a week. For instance, I’m big into houseplants lately and I wanted to find some people on M.b that were as well. And I can’t figure out how to do that. Is search coming?

We now have a basic search on the web version of Micro.blog under Discover. This currently searches any post that has been included in Discover. We have plans to add search to the native apps so that it’s easier to access, and expand it so that it searches even more posts on Micro.blog. However, one of the early design goals with Micro.blog was to launch without a full search index, because I didn’t like how Twitter’s search and especially trending topics could be gamed or expose the worst conversations on the platform, even in some cases being a place for more abusive, hateful replies. So we’re going a little slowly with search to make sure that we don’t recreate any of those problems.

I know I’m only scratching the surface for the questions that the community is likely curious about. I hope I did an OK job asking the important ones. Are there any topics I left off that you wish I had asked you about? Or anything you’d like to highlight?

Your questions were great. Thank you! I’d like to mention again what Jean MacDonald has done with our podcast Micro Monday. This podcast didn’t exist when you interviewed me last year, and now we have a great archive of episodes highlighting members of the community — how they got started blogging and what they are interested in, whether that’s related to Micro.blog or something else. It helps people understand Micro.blog while at the same time featuring stories from the community. I’m always inspired hearing what people are up to, and it’s a weekly reminder to me of how important it is that people have a voice on the web with their own blog.


What a fun interview! Until next year…

Signal v Noise exits Medium

DHH:

These days Medium is focused on their membership offering, though. Trying to aggregate writing from many sources and sell a broad subscription on top of that. And it’s a neat model, and it’s wonderful to see Medium try something different. But it’s not for us, and it’s not for Signal v Noise.

SvN was not long for Medium. It never felt at home there. Basecamp (the company, formerly known as 37 Signals) has too strong of a voice and brand design to ever have their blog live inside a platform with such web and brand hostility as Medium.

I think back to 2012 when SvN redesigned, I linked to that redesign then, and how they had carefully considered their typography, graphics (they had a different graphic for each category of posts), layout. Mig Reyes, at the time, wrote:

Instead of poring over other blogs, I spent a week studying books, magazines, and of course, Bringhurst. Capturing the right feel for body text was step one—it sets the tone from here on out.

If you care this much about your site/blog you cannot be holed up in some constrained content silo like Medium. Medium is an excellent (perhaps currently the best) web-based writing tool but the platform is more than just that. It promised exposure which is why many blogs like SvN gave it a try. But that was definitely the wrong reason to go there.

Nice pick up for WordPress of course but in reality SvN could have found a home on any platform they had full control over. I like the new design too.

Since Gutenberg has a very nice date picker I’ve now been able to deactivate the plugin I wrote in 2016 for replacing WordPress’s original post scheduler. I’ll keep the code on Github for Classic Editor users.

Matt Haughey on the mobile WordPress app

Matt Haughey vents his frustrations with WordPress:

Over the past week I’ve written a bunch of posts while out and about using the iOS WordPress app, often with photos of things I was seeing. But unless I was on WiFi or had 5 bars of LTE connectivity, I would get a Posting Failed, Retry? message. The wild thing is even after hitting retry a bunch, it would still fail. And then if I flicked over to my draft posts folder, the post wasn’t there. If I didn’t keep retrying and instead clicked anywhere in the app, the post would disappear completely.

Like Haughey, I too am frustrated with the WordPress mobile app (I’m on Android, and I have the same issues). I’ve actually removed WordPress from my phone because I can’t use it. It simply doesn’t work well at all. If I even try do post my photo posts with it crashes over and over and over and over. Which is why you’ve seen a lot less photos from me.

The Android apps I use every day

From the time I switched to Android in late-2017 (more here) I’ve been installing and uninstalling apps and services from my phone – trying to find the right mix for me. I expect the apps, preferences, and everything about my mobile experience to continue to change but lately it seems to have settled a little. So I thought I’d share what I’m currently using day-to-day.

My current Android home screen.

Pocket Casts – I have a 25-minute commute to and from work every day so having a podcast app that I like is very important to me. I’m so glad that Pocket Casts exists because Google’s default podcast app, called Google Play Music (for now) is not very good.

Pocket Casts’ Up Next feature is very well done, in that I can create my own playlist using the currently downloaded episodes, or cherry picked episodes, from any podcast I want. I set aside a moment once or twice per week to curate that list and Pocket Casts does the rest.

It also looks very nice in split-screen mode with the other app I use daily while driving Waze.

Waze – I had heard about Waze for years before I tried it in earnest. When I first downloaded it on iOS and tried it I thought it looked like a game. (And, yes, I suppose it is.) But, it turns out to be very useful in many ways. Like Google Maps it can give you directions from A to B, but that isn’t really what Waze is made for. Waze is made to make your morning commute faster and safer. The Waze-using community can report problems like traffic, accidents, police, etc. and anyone behind them can be warned in advance of these things. It has made a huge difference in my morning commute and helped tremendously in longer trips like our trip to Kentucky earlier this year.

Clip Stack – This little utility saves clipboard history and allows you to manage your clipboard. An app like this, on any platform, comes in handy more often than you’d think.

JW Library – My Bible and research/study app for all things biblical. Not only does it have tons of different Bible translations it also allows for notes, highlighting, video/audio, and more. The app has continued to improve since it debuted a few years ago.

Lose It! – I’m on a diet for the rest of my life so I use Lose It! to track my calories every single day. The app is updated often and is improving a lot each time.

Snapseed – It takes a little while to get used to this photo editing app. But I love that I can save my own “Looks” (or sets of photo edits). I use it on my Pixel 2 XL and also on my iPad. Nearly every photo you’ve seen from me since December 2017 has gone through Snapseed.

Flamingo – Unfortunately, if you don’t already have this app you can no longer get it. Flamingo is a sane Twitter app that records your place on the timeline and shows tweets reverse chronologically.

Spotify – I love Spotify. After trying Apple Music for a few months I can say that Spotify’s playlists just absolutely blow Apple’s offering out of the water. There is no comparison. I can understand why iOS users would use Apple Music due to how it is built into everything – but there is no reason to use it otherwise. Spotify is just better.

LaunchBoard – I use this app to quickly launch any app that isn’t on my home screen full time. You tap it, tap the first letter of the app you want, and launch the app. Think of it like using Spotlight on iOS. Same number of gestures too.

WordPress – Short status updates and some of my photo posts are created, and sometimes drafted sometimes published, using the WordPress app. It was unusable on Dreamhost but now that my site is hosted on Digital Ocean the app works great. Something I didn’t realize was that I can use this app without activating the bulky JetPack plugin. So I’ve done that and my site is much happier as a result. In fact, I’ve reduced my site’s footprint dramatically recently and I couldn’t be happier.

Chrome – One of the main reasons I switched to Android was being able to have a desktop and mobile browser of my choice. So I’m able to use Chrome (or any other browser) as my default. I also use Micro.blog via Chrome since that is the only way I can currently.

Messages – Pixel’s default SMS manager is called Messages. It works fine for what I use it for. I’m not looking forward to the updates coming to “Chat” that I’m reading about. These updates feel like HTML email – they are fun, but I don’t need those things. SMS works just fine for me. I wouldn’t mind, however, end-to-end encryption of all messages.

Voice Recorder – I record my audio bits using Voice Recorder. I haven’t be publishing many lately but I’ve been recording them still. This is a great way to capture content and ideas.


A few more apps that I have installed on Android that, while I may not use every single day, are great apps to have:

Wikipedia – I read a lot of information on Wikipedia. Mostly on my iPad. Having an app dedicated to it is very nice to save pages for reading later, doing research on multiple topics, etc.

Inoreader – I generally do not read RSS subscriptions on my phone unless I’m killing time. But, when I do I like having Inoreader on my phone. Feedly would work fine too.

Notable mentions are Microsoft Teams and Slack, Google Pay, Twitter app (for Moments when something happens), Dark Sky (though, I’ve been using this less lately since Google updates me on the weather), Google Photo Scanner, Trello.


Also, an app I use daily but that I didn’t have to install is the Camera. The Camera app is actually quite good for my use.

Any Android apps that I should check out that are not on my list?

An interview with Manton Reece of Micro.blog

I have fond memories of the very early days of WordPress (when it had just been forked from b2/cafelog), of Twitter, of Brightkite, of App.net, of Mastodon… just to name a few. The early days of any platform or so important to what they will become. They are the most fun to watch.

The early days of any platform can be frustrating too. Services sometimes go down, features aren’t released as quickly as you’d like, and small bugs can hamper your workflow.

I liken it to watching art be created. It can be a bit messy, it can sometimes confuse you, but when you see the final product you have the privilege of knowing how the platform got to that final state.

Yesterday I volleyed back and forth via email with Manton Reece, the founder and creator of Micro.blog. Micro.blog is in that same relatively early stage where new features are released with regularity, where the community is growing steadily, and where the users have the strongest voice.

He kindly answered a few questions. But here are a few highlights that I plucked from his answers:

  • Micro.blog is both an aggregator of blog posts and a blog/site hosting platform
  • Features on Micro.blog are rolled out slowly on purpose, to be sure they won’t disrupt the principles behind the service. And they often come from what users are already doing on the platform.
  • Native support for audio and podcasts are already part of the plan
  • Many users that use the hosting feature use their Micro.blog-powered site as their primary web site
  • Community support members for curation, help, etc. will be the primary area the team will grow, outweighing engineering

Here is the interview and his responses in their entirety.

First, thank you for making Micro.blog. For me personally it is surfacing some excellent independent microbloggers that I wouldn’t have found otherwise. Now that Micro.blog is open to the public, is there anything that you see happening on the platform, either now or during the beta period, that has surprised or delighted you?

Thanks for being part of the Micro.blog community! I’ve loved how people not only embrace the platform, but in many cases get back to writing at an old blog that they had accidentally neglected, or get inspired to start up a new microblog at their own domain name. So many beautiful photos have been posted, which we like to highlight in the Discover section, and the tone of conversations has remained thoughtful and respectful even as the platform has grown.

I’m also happy to see that many Micro.blog users have warmed up to some of the early decisions we made to not copy every feature from other popular social networks. For example, not showing follower counts or worrying about how many likes a post has received.

People seem to really enjoy the new emoji-based topics we introduced recently, to collect posts about books or music or sports. Little experiments like these are a reaction to what the community is already doing. The best thing we can do is build features that support what people are posting about — to encourage the kind of posts that make Micro.blog a nice place to be — and then see which of those features resonates.

Have you been surprised at all by the number of photos that people are posting? Or, did you always think that Micro.blog would be a great place for people to share photos? And, do you think you’ll see audio or video shared more on Micro.blog in the future?

I’ve always thought photo-blogging would be a perfect fit for Micro.blog, and we’ve tried to build good support for it in the iOS app, such as having built-in photo filters. Many people are frustrated with Twitter and Instagram and want to post photos to their own web site again. But I was still happily surprised to see so many photos. There was also some help from the community, such as Doug Lane running a 7-day photo challenge.

Our plan was to start with photos, with good photo hosting, and then expand to natively support audio and podcasts. After that, video. I think video can quickly become kind of overwhelming and busy when shown in a timeline — especially with auto-playing video, which we don’t want to do. So I’m comfortable expanding this support fairly slowly to make sure we get it right.

I see Micro.blog as two parts: 1. A community of syndicated microblog posts that are populated by people’s independent web sites using RSS or JSON feeds. And, 2. A blogging platform that allows you to create a simple blog (with an emphasis on microblogging). Is this the right way to look at Micro.blog now and into the future? And if so, why tackle both problems rather than simply #1?

That’s the right way to think about it. What I found while developing Micro.blog is that just building a more open social network-like platform wasn’t enough. If we wanted to encourage people to blog more, we needed to make blogging itself much easier. The best way to do that is to also offer to host someone’s blog for them directly on Micro.blog.

Blogs hosted on Micro.blog started with an emphasis on microblogging, but they have improved significantly since we initially launched, and now offer many features competitive with other dedicated blog hosts. There are Micro.blog users who have their full web site hosted by Micro.blog because it’s just more convenient.

This second part of Micro.blog is also very important to grow the service as a business. I want to run Micro.blog for decades to come. The only way to do that — to pay for all the servers and other supporting services — is for Micro.blog to be profitable. Since we never want to show ads, offering paid plans such as blog hosting is a great way to go.

Would you be willing to share any interesting stats? Some that I’d personally be interested in tracking would be the most number of posts in an hour, the greatest number of signups in a day, stats like that.

And as a follow-up: As the platform (meaning the software, hardware, underlying services, backup routines, databases, etc.) become more complex surely you’ll need to expand from being the two-person team Micro.blog is currently. What position do you think the next full or part-time team member of Micro.blog will fill?

I don’t currently have many stats to share. We have been so busy improving the platform that we haven’t built anything to track things like spikes in the number of posts. There is a 500-user limit on new registrations per day. When we opened it up to the public, the limit was just 100 which was reached pretty quickly as people would share a link to their friends.

There are so many areas that we could use a larger team for, like system administration and planning how to scale the platform. As you noted, the first person to join Micro.blog was Jean MacDonald, our community manager. I hope that the community will continue to grow such that we’ll need additional curators to help manage features like the Discover section.

Facebook recently announced they were hiring 10,000 moderators, and I know Twitter has a large staff as well. I expect one mistake that these larger social networks made early on was hiring too many programmers, and not enough curators. For Micro.blog we always want people who can interact with the community and stay ahead of any issues.

Discover has already seen a few iterations. First, it was a simple list of users. Then it expanded to include photos posted by the community. After that, a human-curated list of posts was added. And now, hashtag-like emoji’s allow you to find posts on topics like books, music, and football. Did I miss anything? This must be a fun part of Micro.blog to tweak and see how the community responds. I know I’ve found it to be very fun to have open a few times during the day. Can you share a little about how posts end up in the Discover tab? Who is making those selections and what are the next steps?

I feel like the current iteration of Discover is by far the best yet. There were a couple problems with just featuring a list of users. You can only feature so many users, so we randomly selected users to show from the featured list. Those users would get a lot of attention but unless we continually update the list, it might not be enough people to fill your timeline with interesting posts if you just pick a few people to follow. The list got stale quickly as new people were joining the platform.

Now, throughout the day we skim through posts and replies and put them in Discover. This is a better reflection of the activity on the platform. It’s not all posts, but it’s a good snapshot of the kind of things people are posting about. It looks good and isn’t overwhelming. It’s a great way to find new users who just joined Micro.blog, too.

Emoji topics are a little different. Whenever Micro.blog sees a new post, it checks it for emoji and adds it to a collection. If an inappropriate post shows up, we can just remove it from the collection without effecting anything else about that post or user on Micro.blog. There are a limited number of emoji, which keeps everything simple. I don’t think it will get out of control like Twitter hashtag search results often do.

One aspect I’ve always loved about microblogging was that it could be consumed and participated with in realtime. A few examples that come to mind are backchannels for live TV events like awards shows, or for conferences and meetups, etc. Is this something the Micro.blog team thinks about much? Are there any apps, features, or other considerations that would be made specifically to foster realtime interactions for things like this?

I agree this is a natural fit for indie microblogging. Something like live sports might not appeal to everyone, so it would be useful for both tuning into those feeds or filtering them out. Over the weekend, we put the football emoji in the Discover section for people who were posting about the NFL playoffs, as a simple experiment for making current topics more discoverable.

There are myriad other things we could talk about like Pins, third-party applications, indieweb building blocks like Webmention, and the all new Micro.blog logo and app icon. Is there anything you’d wish to highlight? If so, please do. And lastly, what is something you wished I asked but didn’t that maybe you’d like to make sure people reading this interview know (feel free to allow this to be nothing)?

The third-party ecosystem and larger IndieWeb community are both really important. There are several third-party apps for Micro.blog in development now, for iOS and Android. When I was designing the Micro.blog API, I based it on JSON Feed, Micropub, and other common APIs so that third-party Micro.blog apps could also be adapted for other platforms. And likewise, Micro.blog benefits from many existing IndieWeb tools and open source software like WordPress. The more we can push forward the user experience for indie microblogging, making blogging more approachable, the stronger the open web will be.

Thanks Colin! It was great to have a chance to share some of our thoughts behind Micro.blog.

Thanks to Manton for taking the time to write thoughtful responses. If you haven’t yet given Micro.blog a try head on over to there and give it a whirl. You could very well make an impact on the type of place it becomes.

You can follow Manton on Micro.blog at @manton. And I’m @cdevroe.

Facebook will drop the patent clause for React license

Matt Mullenweg:

I am surprised and excited to see the news that Facebook is going to drop the patent clause that I wrote about last week. They’ve announced that with React 16 the license will just be regular MIT with no patent addition. I applaud Facebook for making this move, and I hope that patent clause use is re-examined across all their open source projects.

Interesting outcome. Here is more context.

Matt Mullenweg on Automattic’s use of React

Matt Mullenweg:

I’m here to say that the Gutenberg team is going to take a step back and rewrite Gutenberg using a different library. It will likely delay Gutenberg at least a few weeks, and may push the release into next year.

Automattic will also use whatever we choose for Gutenberg to rewrite Calypso — that will take a lot longer, and Automattic still has no issue with the patents clause, but the long-term consistency with core is worth more than a short-term hit to Automattic’s business from a rewrite.

This is a big blow to React. The framework will still be massively popular and adopted but the number of developers in a thriving ecosystem like Automattic’s products – like WordPress – that now have to move onto something else is a big blow. Automattic’s continued use of React would have meant thousands of jobs for a long number of years.

As usual, Mullenweg sees the longterm angle, and weighs that against the core principles upon which his company was founded, and I believe he’s taking the right path.

Side note: I still see so many developers that deal with WordPress day-to-day that haven’t yet started learning JavaScript in earnest. Mullenweg himself has urged the WordPress community for the last several years to invest in learning JavaScript. So, if you haven’t already… jump in.

Mobile blogging goals (audio)

Recorded September 10, 2017

Starting with this audio bit I’m making a few changes.

I’m ditching the episode numbers. My audio bits are not a podcast, they aren’t really episodes, and keeping track of the numbers is just more work. I will, however, denote in the title that this is an audio post.

I’m also switching to the audio format that comes directly out of Voice Memos on the iPhone rather than doing the work of converting the file to MP3. If you have any issues listening to this audio file please let me know.

Enjoy the listen!

Links

Download Audio File

JSON Feed WordPress plugin

Manton Reece just released the JSON Feed WordPress plugin into the WordPress directory. Making it mad easy to install and support the new spec.

WP Admin → Plugins → Add New, then search for “jsonfeed”.

I’ve updated to this version in the directory so that all future updates come from there as well.

Attending NEPA WordPress Meetup for March 2017

Last night was the NEPA WordPress Meetup for March 2017. It was a panel discussion regarding how agencies use WordPress with Jack Reager of Black Out Design (our gracious host, thanks Jack and team), Liam Dempsey and Lauren Pittenger of LBDesign in the Philadelphia-area, and your’s truly of Condron Media.

As these types of events typically do, the discussion meandered through many different topics including the reasons our agencies have decided to use WordPress as our platform for many of our projects, about how someone can get started using WordPress, about JavaScript and how it is the language that is currently eating the web, and even a bit about baking bread somehow.

One question that was posited by Phil Erb, our moderator for the evening, was what do the agencies or individuals get out of the WordPress community. Most of the answers were focused on what each individual gleans from WordPress-related events. If you’ve read my blog at all you know that I’m a strong advocate for attending events and that I think they have immense value. It was good to see all of the panelists agree on this point. I hope it spurs some in the audience to attend even more events and certainly more events out of the area and bring that energy and knowledge back to our nook in the mountains here in Pennsylvania.

It was a great meetup in a great space. Very glad to have been part of it.

Thanks to Phil and Stephanie for organizing the event, to Jack and his team for opening up their new space to us (they should be proud of the space they’ve created there, it is lovely), to Liam and Lauren for driving a few hours through fog and lastly to Liam for sharing his Duke’s pizza with me.

Post filtering fixes at Homebrew Website Club

Last night Tucker Hottes, Den Temple and I held the first Homebrew Website Club at The Keys in Scranton, PA. I really appreciate that HWC will force me to set aside some time to work on my personal site since it is often neglected for more pressing projects.

During HWC I began trying to fix my crufty URLs for post format filtering on WordPress. Unless I’m missing something, it doesn’t appear that WordPress has “standard” post format filtering out of the box. It can filter by every other post format – statuses, audio, images – but doesn’t for standard posts. I’m almost sure I am missing something. If anyone knows how to do this more elegantly please let me me know. However, I’ve added this functionality myself months ago and now those URLs are cruft free. You can see them in my sidebar.

To do this isn’t trivial. Here are the steps you need to follow:

I’m glad HWC gave me the time to finally fix this as it had been bothering me for a few months. Looking forward to the next HWC where I’ll tackle a few more Indieweb things I’ve been meaning to bolt on.

Angelina Simms on the Philly Burbs WordPress group

Angelina Simms published her experience at WordCamp US this year. Note this bit about the Philly Burbs WordPress group:

Too often, we are surrounded by people who act like they are concerned about your well-being out of self-interest and totally disappear if you don’t fit into their grand scheme of things. That is definitely not the case when it comes to hanging with WordPress people, especially within the burbsWP community.

Related.

Attending the Philly Burbs WordPress meetup

img_3873

Do you know the visible signs of a strong community? If you’ve ever attended a Philly Burbs WordPress meetup then you definitely do.

Last night my new coworker Tucker Hottes and I drove the 2.5 hours to Pheonixville, PA for this month’s WordPress meetup in the Philly Burbs meetup group. What we saw during the evening was the clear, visible signs of a healthy, vibrant, and active community.

Those signs were:

  • Conversation – People were talking to one another from the jump. They greeted one another when a new person arrived. And even if they had already found their own seat, they got up and moved to have a conversation with someone else.
  • Inclusivity – No one. No one feels like an outsider at one of these meetups. Race, gender, or distance from the area (like us) doesn’t matter. Everyone feels very welcome.
  • Questions – Lots of questions and answers. And people really trying to help one another.
  • Lingering – After the event was over people stuck around, got more food, chatted more. In fact, if it wasn’t for the long ride home I would have stayed longer.

I’ve attended this meetup before as a presenter in West Chester. And I felt welcome then too and I could feel the strength of the community then as well. This is a well run group and I highly recommend attending one of their meetups if you can.

Oh, if you’re wondering why I’m willing to drive 2.5 hours just for a WordPress meetup. Read this.

FADE INTO A WORDPRESS LOGO

INTERIOR, COFFEE SHOP, HOUSTON, TEXAS

Matt Mullenweg, founder of WordPress, wearing a WordPress tshirt, brainstorms over a latte.

MULLENWEG, internal dialogue: “How can I get WordPress in front of the Wix customer base for free?”

MULLENWEG: *opens WordPress on his Mac*

….

MULLENWEG: Publishes: “The Wix Mobile App, a WordPress Joint” to his WordPress-powered blog. For free.

Twitter explodes.

INTERIOR, POSH APARTMENT, ISRAEL

Tal Kol, Engineer at Wix, spits his tea all over his computer’s display.

KOL: *opens Medium.com*

KOL: *continues to wait for Medium.com to load gallons of JavaScript*

KOL: Publishes: How I Found Myself Accused of Stealing Code from WordPress

CUT TO: INSIDE A MOVING UBER

Mullenweg cracks a smile while looking at his mobile phone.

CUT TO: IMAGES OF BOTH COMPANY’S SLACK CHATS EXPLODING

INTERIOR, APARTMENT BEDROOM, NEW YORK CITY

Avishai Abrahami, CEO of Wix.com, is stomach-down, in bed, sound asleep.

BZZZZ

BZZZZ

Avishai Abrahami’s mobile phone is vibrating on the nightstand.

BZZZZ

Avishai Abrahami reaches for his phone. His eyes nearly pop out of their sockets.

ABRAHAMI: Sits down at his computer. *opens Wix content management system* …. errr, *opens WordPress Admin*

ABRAHAMI: Publishes: Dear Matt Mullenweg: an open letter from Wix.com’s CEO Avishai Abrahami on Wix’s WordPress-powered blog.

CUT TO: EXTERIOR, PUBLIC PARK, HOUSTON TEXAS

Matt Mullenweg is seen frolicking through fields of green grass.

THE END

Hacking rather than waiting

Yesterday afternoon Sarah Pressler retweeted Jono Young’s request for a plugin that would add a submenu to the WordPress’ Admin with the current pages for the site under the Pages menu. This would reduce the number of clicks to get to the page editor.

I was waiting for an upload to finish and I thought, given the code I have laying around from other projects, I’d be able to supply Jono with something passable for what he needed. Though it is far from what I would recommend using, it is a start.

Here is what I did:

  • I used get_pages to get a list of WordPress pages the were published.
  • While looping through each page I used add_submenu_page to add the page titles under the Pages menu
  • I used JavaScript to replace the HREF attribute on the links to link to the page editor

That last step is the hacky part in my opinion. add_submenu_page() asks for a function name to call to build the page for the menu item when it is clicked. In other words, for each item on the Admin menu there is a corresponding function that will show you the page that it results in. But I didn’t want to create a new page, I wanted the link to go to the page editor.

I dug around for five minutes or so and I didn’t see an apparent way to change the links for the page titles (though I’m sure there is a better way if I had the time to continue looking) and so after the page loads I use JavaScript to replace the attributes with links to the page editor.

Nowhere near perfect but, in a pinch, it is one step closer to what Jono wanted. Hopefully he or someone else can build upon and it make something a little more reliable and less hacky.

You can see the source on Github.

You’ve been granted h-entry

This morning I took a few minutes to add microformats to the HTML of my blog. I had done so in the past when my site was using a completely different theme and hadn’t taken the time to add them back in. Shame on me. I should have done it much sooner since it took less than 20 minutes and now I think my blog will be a little easier to read for things like webmentions.

This post isn’t to be used as a guide in adding microformats to your WordPress theme. I’m simply writing this down as a way to walk myself through my own task of doing so. But if you read it and feel inspired to add microformats to your own site then I’ve done my job.

In short, the following classes must be added to your index pages (index.php, archive.php, search.php, etc.) and your single post page (single.php) to support the h-entry microformat.

  • h-entry
    • p-name
    • p-author
    • u-url
    • p-summary or e-content
    • dt-published

There are other classes in the spec, and I recommend supporting which ever ones make sense for your site, but if you only had these class names added your HTML, it would be much easier to parse for the little robots that are running around on the web trying to eat your code.

Many WordPress templates wrap posts in an article tag and add classes to it using post_class function. This function adds numerous classes to help you specify things like post-formats, post-types, etc. Supporting h-entry couldn’t be easier since the post_class function allows you to add any classes you’d like on your own. Like this:

Next, you’ll want to add the p-name and u-url classes to the link that goes to your blog post from the index. That should be easy enough. Mine looks like this but your’s will likely look a bit different. In my case the A tag’s contents contains the post’s name, and the HREF of the A tag is the post’s URL. So I can add both classes to the one element.

We’re almost there. The next class I needed was dt-published – or the datetime that the post was published. This one may prove to be a bit harder to wrap your head around but here is how I did it.

I used HTML’s time element so that I could take advantage of the datetime attribute. Exactly as the microformats wiki suggests. get_the_date in WordPress accepts PHP’s date formatting arguments (all those weird letters up there) so it didn’t take too long to figure out how to format the datetime correctly. Essentially, I’m formatting the date for machines in the attribute and humans in the contents.

Finally the contents of the post must be marked up. On my indexes I only show an excerpt of the post and on the single page’s I show the entire entry’s contents. So I use p-summary on index and the e-content class on the single post page. This is how my index page’s markup looks.

For my particular use I also needed to mark up statuses or what might be called “notes” on the indieweb wiki. In retrospect “notes” is a far better term since what I post as statuses are more often than not more a note than a status. But, oh well? I think I’m stuck with it for now. For statuses I simply mark up the entire content as both p-name and e-content as suggested by the microformats wiki.

Here are a few examples of each post format, in HTML, that I use on my site.

Status:

Image:

Post on Index:

I hope to improve this markup a bit over the coming weeks to support more microformats. But for now I think this will help to make my site’s HTML a bit more readable to our little bot friends.

 

A date picker to schedule posts in WordPress

On Sunday mornings I make some coffee, sit down at my computer, and choose 7 images to publish to my blog throughout the week. After I’ve chosen and edited the images I schedule them in WordPress to be published each morning at around 9:00am. I can then go about my week knowing that each day there will be a new image automatically published to my site.

There was a problem though. I think in days not dates. Like, “what image should I post on Wednesday?” instead of “what image should I post on the 12th?”. So when I used WordPress’ default date selector for scheduling the post I found myself wishing that I could see what day each date was.

So I searched the plugin directory but I didn’t find anything (more on this in a second). I was surprised. So, I quickly cobbled together a plugin of my own which I’ve open sourced on Github this morning. And, while I’m not finished with it, it works. I can see which day each date of the week is and that helps me. So now my Sunday morning’s will be a bit happier.

It turns out there is a plugin for this, which Sal Ferrarello linked me to in the BurbsWP Slack, called Publish Date DatePicker. I don’t think I found it because I searched terms like “scheduled posts” and “date picker” with a space in the name. Oh well. Now I have my own and I plan on improving upon it slightly before I roll it together as a release.

Update: To make sure you have the latest version of this plugin visit the releases page on Github.

Migrating Subscriptions from one Stripe account to another

One of my recent client programming projects (hire me here) was to help a company migrate all customers, cards, plans, and subscriptions from one Stripe account to another as a result of an acquisition. I hadn’t needed to do anything like this in the past and I ended up fumbling my way through a few of the steps. So, I thought it worth the effort to jot down the process.

Here is a graphic of the overall process with notes to follow below.

Stripe Migration

I made some notes along the way during this project. Using the numbers above, here is the process step-by-step and some things you’ll want to keep in mind before you begin.

  1. Send an email to support@stripe.com to request Customer and Card migration from Account A to Account B.
    • Remember that both accounts need to be activated
    • Stripe cannot transfer live accounts into test accounts (a shame)
  2. Stripe transfers Customer and Card information from Account A to Account B
    • Stripe cannot “schedule” this transfer for an exact date or time
    • Stripe can run the migration more than once should new Customers be added
    • Customer IDs are retained from one account to another
    • Card IDs cannot be retained
    • Stripe will not migrate Plans or Subscriptions
  3. Transfer Plans from Account A to Account B
    • Retain all plan information (recommended)
    • The most crucial piece to keep the same is plan_id
    • You may want to make adjustments to “Statement Description” at this time if the business name has changed
  4. Transfer Active Subscriptions from Account A to Account B
    • There is no need to transfer cancelled or inactive accounts
    • During the transfer, request Subscription on Account A to cancel at period end
    • Create a new Subscription on Account B based on plan_id, using billing_cycle_anchor will allow the Subscription on Account B to begin the moment the Subscription on Account A is cancelled
  5. (not in graphic) Verify all Plan and Subscription information has been moved

Whether you’re using Stripe’s excellent API to migrate your Plans and Subscriptions or doing it manually via their admin the process is basically the same. The customer I was working with had nearly 5,000 customers and over 1,000 active Subscriptions on 4 Plans. So writing a script to do this saved huge amounts of time.


Aside: How do you calculate whether or not it is worth building a script to do this or doing it yourself via Stripe’s admin? Well, the pessimistic view would be something like this comic from the always excellent XKCD re: automation. However, the more practical approach is this comic from XKCD titled Is It Worth The Time?


How did I write the code? Depending on your exact needs and your familiarity in different languages you may want to find a completely different approach to the one I took. However, I’m a PHP guy, this is what I did.

I started by doing a search on Github for “Stripe Migration” (always worth starting here) which led me to this set of simple scripts from Nyalex for migrating Plans and Subscriptions on Stripe from one account to another. This likely saved me 5 to 10 hours of development. (Thanks Nyalex!) I then reached out to him on Twitter to let him know I was about to use his script. We had a nice conversation that helped me to get my head around how his scripts worked.

My modifications to Nyalex’s script were fairly minimal but vital. Since he hadn’t used the scripts in some time they fell out-of-date with Stripe’s latest API version. So I had to make some subtle updates to account for those. Also, the client was using Easy Digital Downloads, a WordPress ecommerce plugin, as their backend so I had to write a few SQL queries to update the Subscription IDs in EDD’s customer table as the process ran. I plan on writing a Pull Request for Nyalex so that I can help keep his set of scripts up-to-date for future uses.

There were, of course, a few hiccups when running the scripts.

First, the client’s server would time out if I tried to process all 4,800 accounts at once. Each account creates several Stripe API calls (about 7) so even with Stripe’s limit of 100 accounts at-a-time that is still a hefty 700 API calls. So understandably I had to find the right number that the server’s setup could handle without choking. I also slimmed down the number of API calls slightly from the default. I did this by creating some mock API calls for the cancel and create Subscription calls and let the script run a few times until I found the right number. For this particular client it was 20 accounts at a time being processed. Which meant the script ran over 200 times to complete the process. Because I was purposefully doing this manually, rather than setting up the script to run end-over-end, this process took a little over an hour.

Second, prior to creating those mock calls I accidentally duplicated a few subscriptions for 23 accounts and needed to go back and manually cancel them all before re-running the script. I recommend not doing this. Again, it is a drawback that Stripe cannot migrate live Accounts as Test accounts so that you can do test runs on this sort of thing but it is understandable.

And, lastly, I didn’t properly create a log file for all of the transfers as they were done so I had to manually save the output of Nyalex’s script to a text file. I think I’d like to update the scripts to create a log file of old subscription ID, customer email address, and new subscription ID at the very least. This would have saved me a lot of time and would give me a “back up” of sorts should any customers have been missed. Also, since the scripts only attempt to migrate active Subscriptions it would have been nice to extend the scripts to log inactive Customers too just as a double-check that those Customers were looked at.

Overall this was an interesting project to take on and I’m hoping that my knowledge from this project will get reused in the future. If you need to migrate from one Stripe account to another please reach out.

How I converted from Custom Post Types to Post Formats

It wasn’t too ugly. But it wasn’t exactly a cool swim either. I thought I would jot down why and how I moved from using a Custom Post Type for each type of post that I publish here — status, photo, audio, and normal post — to Post Formats.

First, why move to Post Formats from Custom Post Types? For my use, Post Formats make much more sense than creating my own Custom Post Types with their own taxonomies. In November 2011 Matt Mullenweg described Post Formats in this way when releasing WordPress 3.1:

our new Post Formats support which makes it easy for themes to create portable tumblelogs with different styling for different types of posts

I remember my reaction to Post Formats at the time. It did seem like a great way to allow those that liked Tumblr’s simple post format style, that of being able to quickly share an image or quote rather than a full blog post, using WordPress. But in reality, as Post Formats matured over subsequent releases I believe their utility has gone far beyond just that of competing with another platform’s ease of styling as Matt’s original description laid out. I think this bit from the WordPress Codex describes their value better:

The standardization of this list provides both compatibility between numerous themes and an avenue for external blogging tools to access this feature in a consistent fashion.

This is the important bit. Standardization. My Custom Post Type for statuses, while similar to the status Post Format, wasn’t standardized and wouldn’t be compatible if I switched themes, used the WordPress iOS application, or tried to use them with the thousands and thousands of plugins that support Post Formats. So they looked like statuses but they didn’t have the advantage of WordPress’ built-in status format.

If you have a site like mine where I’m attempting to share from my site first then onto the social networks (POSSE), you will likely need the very same Post Formats that I do. And so will everyone else. To standardize these specific formats allows them to become much more powerful than simply styling them in a theme.

This important bit about standardization was the WordPress development team’s exact stated purpose for the feature. In fact, the implementation of Post Formats didn’t even start out as feature. It was simply to be “a standard” to be documented in the Codex. Andrew Nacin just prior to WordPress 3.1’s release wrote:

There was no code. It was simply going to outline a standard: a name for a custom taxonomy, and a standardized set of formats.

I urge you to read the post he wrote at the time. Fascinating look back to just 5 years ago.

So, this is why I ditched my own Custom Post Types. Since I was converting my site from Barley (which used Content Types in a similar way to Custom Post Types) I ended up coming with that overall “baggage” of customizing each type for my need. When, in reality, the core team had already figured out the subtle nuances between the formats that I was going to use and have already standardized their use, their API, and (optionally) their display.

How did I convert all of my posts into blog posts and then change their format?

One of the advantages to using WordPress at all is that there are myriad developers out there attempting to solve the same issues you will likely come across. In this way you’re able to find their solution and either use it outright (and hopefully support them financially or in some other way) or stand on the shoulders of their code and customize it for your needs. So when I decided that I wanted to make this switch the first thing I looked for was a plugin that would help me change my Custom Post Types into blog posts en masse.

John James Jacoby is the lead developer of a plugin called Post Type Switcher. Essentially this plugin makes it very easy to change many Post Types into a blog post in a matter of a few minutes. Once installed and activated you’re able to “bulk edit” all posts listed in your Admin to change their Post Type. Since I only had a few hundred status updates, a few dozen photos, and very few audio bits that I’ve published so far moving these was easy. From there, I bulk edited those posts to change their Post Format to the appropriate ones. It took about a half-an-hour and a few dozen clicks.

Yes, I could have written a quick script to do it. It would be fairly simple to loop through all Custom Post Types and run wp_update_post to switch the post_type. And I thought about that. But why reinvent the wheel? JJJ’s plugin worked beautifully for my needs. However, if I had thousands and thousands of posts to convert, I likely would have avoided the mouse at all costs and written that script.

Once the posts were converted into blog posts and their format adjusted I was able to remove all of the Custom Post Type code that I had written, their associated archive and single files and a bunch of query adjustments too. Switching to Post Formats simplified my theme’s code fairly dramatically.

I have run into a bit of an issue though. And one that I’m still wrestling with.

I wanted a way for viewers of the site to filter the Post Formats separately. So if they wanted to read my latest blog posts or sort through my statuses they could do so. WordPress has a way to do this out-of-the-box (almost). You can filter blog post types by using /type/post-format-name-here*. However, the one Post Format that cannot be filtered, as far as I’ve been able to tell, are normal blog posts (which WordPress calls “Standard”). For some reason, it does not mark these posts with a format but rather leaves those null. So /type/standard does not return your posts it simply results in a 404.

Others have discovered this same caveat to Post Formats and have written about it. Here is a Stack Overflow thread from 2012, as an example. The solution suggested there was similarly suggested in April 2011 (before 3.1 was released) by “levin” on their blog. At the end of their post they wrote: “I hope there have a better solution in future WordPress release”.

As far as I can tell, there hasn’t been. I’ve tried several different URL hacks and rewrites and so forth to see if somehow WordPress could filter out just the Standard Post Format out-of-the-box and I haven’t been able to force it to do so. I plan on digging into this a bit more but for now I’ve used a solution similar to levin’s from 2011 to filter my posts. It is a crufty URL for now too. Because hopefully the ugliness of the URL will spur me on and motivate me to create a more elegant solution. When I do I’ll share it on my blog.

*I think having /type in this URL is a bit confusing at this isn’t a custom post type. It should likely be /format?

 

How I create a combo feed using WordPress

When my site was on Barley I had something we called a “combo feed”. A combo feed combined all content types (what we called custom post types) into my main RSS feed. This allowed someone to subscribe to a single feed and get all of the blog posts, statuses, photos, and audio bits that I publish. Optionally, they could choose to subscribe to each of them individually, effectively allowing them to opt-out of the ones they’d rather not see. A good example of why someone may do this would be if they followed me on Twitter they may not want to subscribe to my status updates.

I wanted to have this functionality on WordPress too and I thought I’d share how I did it for anyone else that may find it useful. If you see anything I’m doing wrong please let me know.

When I register my custom post types I enable the post type archive. This turns on the /feed URL for each of them. See my statuses feed as an example. According to the Codex page for register_post_type I could also turn on rewrite for ‘feed’. But since I turn on the archive this is done automatically. Here is a slightly modified version of the code I use:

Now that I know there will be feeds for each custom post type, it’d be nice to list them in the HEAD of the HTML document so that they are discoverable by feed readers. For example, Feedly (the feed reader I use) lists all of the feeds available to subscribe to. I’d like that list to include all of my feeds and not just my combo feed. WordPress has a function to “add theme support” for several things and one of them is adding feed links to your site automatically. Which is nice since I may add or subtract feeds over time and this way all of the currently available feeds will be discoverable without me changing anything. Here is the documentation for this function, but here is what it looks like in my functions.php file:

The final step is to combine all of the custom post types that I want into my main feed. This is done by modifying the request for the main feed to include the other post types. WordPress calls this “filtering”. When a request for my feed comes from a feed reader I “filter” the request to include the default blog posts and the custom post types that I want.

This function first checks to be sure the request coming in is for a feed. Specifically the main feed. It does this by checking if the request is for a feed and that the request does not include a custom post type. Next, I set the post_type array on the request to include all public post types that are not built in (meaning, not out-of-the-box from WordPress such as post and page) using get_post_types. Lastly, I add the default ‘post’ type so that my blog posts are included in the request as well.

For my use I include all public custom post types because I do not have any that I do not want to include in my main theme. You could just as easily create the array yourself to include any custom post types that you’d like. But then you’d have to manually update that array when you add or remove custom post types.

I’m happy with the result. I hope you subscribe.

Presenting at the NEPA WordPress Meetup

Tonight I had the privilege of presenting at our local NEPA WordPress Meetup. We were also privileged to host the event at our space in Carbondale, PA.

My presentation was entitled The History & Future of Inline Editing. I’m sure there will be a video posted online as soon as it is ready.

 

A case for something, anything more simple than WordPress

There is a growing sentiment that WordPress – though incredibly well supported and ubiquitous – is simply far too complex for some projects and for some customers.

Obviously, I think so too. That’s why my company is building Barley.

Here are a few other notable people that seem to believe the same thing, that while WordPress is a powerful tool and it is providing their livelihood currently, it is time for more simple solutions. More choices.

Jason Schuller, of Press75 (a premium WordPress theme shop for 8 years), on his personal blog:

In my case, I’ve become increasingly passionate about creating minimalist/simple website solutions for which WordPress isn’t quite suitable as a platform in its current state and direction. As WordPress continues to change, the passion I once had for my WordPress theme business continues to become more of a chore than anything else.

John O’Nolan, in his pitch for Ghost (a competitor to WordPress’s blogging features which was successfully funded on Kickstarter with almost $300,000 more than its goal):

The WordPress motto is “decisions, not options” – and yet there are still too many options, too many settings, too many things which you have an unnecessary level of control over in the administrative user interface. Things like admin colour schemes, quickpress, press this, post-via-email, remote publishing, inline theme editing, media editing and multi-everything. Things that many people have never even used.

There are a lot of web sites. Billions, perhaps. And each of those sites have different needs. Some sites are blogs, others are small business web sites, others are photo galleries, others are one pagers of information, and some are pages that let you buy things. There shouldn’t just be one tool to build all of these.

There also isn’t one, single, clearcut answer to “What should I use besides WordPress?” because, in reality, you should choose a tool that works best for the project-at-hand. For some web sites WordPress is the clear and obvious choice. For others, such as small business sites, event sites, professional profiles, and others – perhaps Barley is a good choice. And for those of you that prefer to write in Markdown perhaps Ghost or Dropplets might be fun to use.

As a web developer you should have a few different tools in your bag so that when you need to reach for one you grab the right one for the job.

Meeting up in Philly

The Philadelphia WordPress and Weblogger meetups are over, for April. Eliza, Chris, and I drove down to Philadelphia (it takes us about two and half hours), and enjoyed the company of many bloggers in the Philly area.

First, we met up with Andrea and Tom. This happened to be Tom’s first Meetup also. It would seem that Meetups are an old hat to Andrea, since she is involved not only with the WordPress and Weblogger Meetups, but because she also frequents the Philly Webstandards Meetups as well.

Mike, a freelance developer and Nintendo DS player, was the next to arrive. Mike’s hill-top view, like Andrea’s, into “the standards movement” was refreshing. Hopefully they, and their entire team, will keep up the good work they are doing on that front. Mike is a Ruby on Rails convert, so he is also involved with that group in the Philly area.

Ellen, who brought Pineapple stuffing (which I found delicious) and lover of cats, showed up next. Ellen’s perspective into the attidude, demeanor, and personality of cats really made me think twice about our cats. Ellen described her blogging purposes as “fooling around”, which is why I think many bloggers do their writing. In some ways, it is definitely the purpose for most of my posts here on my site. I find my personal blog a very personal outlet for ideas and thoughts that wouldn’t, and perhaps shouldn’t, otherwise have any public view.

Scott McNulty, system administrator and fellow Macintosh enthusiast came with his smile on. He did not hold me accountable for my Drew Carrey comment, to which I will forever be in his debt. By far, the funniest guy in the group, Scott even made Ellen’s Pineapple Stuffing recipe hilarious.

Ben, fitting name for a bloke in Philly, came in fresh from the Philly Pillow Fight (his photos from the fight). Ben has a firm hold on what he likes musically, so he and Chris had a nice discussion regarding that. Here are some photos that Ben took while at the Meetup.

Amardeep, also known as Deep (the best name on the planet bar none), wandered in from the nearly 75 degree Philadelphia air. All of us wished that we had more time to talk to Deep, though the amount of people and the amount of time that we had together didn’t add up. Deep teaches Literature, and so his site is driven towards his thoughts on that specific topic.

Marisa of Apartment 2024, showed up beaming. I doubt she’ll ever live down the fact that her site comes up first for “Does Papaya make you poop?” on most search engines. We all have our vices Marisa. She also writes for the Philly Metro blog, which has the purpose of advocating local blogging. It will be decades until we see a Clifford Metro blog, this much I can assure you.

Tony, whose specific job title eludes me right now, works for TV Guide in Phildelphia. I didn’t realize they were based there, but you learn something new everyday. Again, another gentlemen that I wish I had more time to talk to, he writes his personal blog for the very same reason we all do, as a place to jot down thoughts. Recently Tony wrote an article called Bon mot du jour, in which he states that he isn’t always as eloquent as he’d like to be. I can fully attest to that, being that I’m often caught saying something that sounds like someone ten years my junior.

Stephanie, of Patrick Murphy 06, walked in next. I didn’t get any time to speak with her, but she’s on the front lines of blogging about politics in the Philadelphia area. Seems like their doing a fairly good job too.

Leah (spelling, sorry) and Duran came in last. Slackers. 🙂 After talking to Duran for a little while I learned about his hatred for Active Directory, or those that manage it improperly to be sure. I’m with ya Duran. Leah, another person I only literally got to say “Hi” to, was very excited to get some help with her backyard. Go help her out if you can.

Final thoughts

All in all the trip was definitely worth getting to my first Meetup. I had fully expected to see Owen, who ended up having a medical situation, and I hope he recovers quickly from that. Jason Santa Maria, Rob Weychert, and Joshua Lane of Pixelworthy were supposed to show up too. I hope their teeth are ok.

It was enjoyable, if only for a few hours, to spend some time with people that hold the same importance on this thing called blogging that I personally do. I look forward to doing it again one day, and I’m even considering starting up a Meetup closer to home.

Philadelphia Meetups

Also known as: Colin’s first try at this meetup thing.

This Saturday, at around 2pm EST, Eliza, Chris and I are heading down to Philadelphia for the April Philadelphia WordPress Meetup, organized by Owen Winkler.

Shortly thereafter, since it would appear that the WordPress meetup will only last about an hour, we’ll attend the April Philadelphia Webloggers meetup.

Having never been to a meetup, I can’t say as I have any expectations as to what will happen. I’m simply going as a trial to see what all the hoopla is about.

If you will be in the Philadelphia area, and can attend either meetup (which happen to be at the exact same venue), then please stop in and say hello.