Menu

Colin Devroe

Reverse Engineer. Blogger.

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:

<article id="post-<?php the_ID(); ?>" <?php post_class( 'h-entry' ); ?>>

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.

<h3><a class="p-name u-url" title="Permalink to <?php the_title_attribute(); ?>" href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h3>

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.

<time class="dt-published" datetime="<?php echo get_the_date('Y-m-d H:i:s'); ?>"><?php echo get_the_date('F jS, Y'); ?></time>

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.

echo '<div class="p-summary">';
the_excerpt();
echo '</div>';

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:

<article id="post-3964" class="h-entry post-3964 post type-post status-publish format-status hentry category-uncategorized post_format-post-format-status">                    
 <div class="p-name e-content">
  <p>Scheduled my image posts for the week. I wanted a change so I chose mostly older photos from different locations.</p>
 </div>
 <time class="dt-published" datetime="2016-10-09 08:55:20"><a class="status-date" href="http://cdevroe.com/2016/10/09/3964/" title="Permalink to this status update">8:55am on October 9th, 2016</a></time>
</article>

Image:

<article id="post-3894" class="h-entry post-3894 post type-post status-publish format-image hentry category-uncategorized tag-airplane tag-flying tag-rc tag-scott-township post_format-post-format-image">
 <div class="p-name e-content">
  <p><img class="alignnone size-full wp-image-3895" src="http://cdevroe.com/wp-content/uploads/2016/10/IMG_4998.jpg" alt="img_4998" srcset="http://cdevroe.com/wp-content/uploads/2016/10/IMG_4998.jpg 1000w, http://cdevroe.com/wp-content/uploads/2016/10/IMG_4998-300x200.jpg 300w, http://cdevroe.com/wp-content/uploads/2016/10/IMG_4998-768x512.jpg 768w" sizes="(max-width: 1000px) 100vw, 1000px" /></p>
  <p>Coming in for a landing, Scott Township, PA &#8211; September 2016</p>
 </div>
 <p class="text-uppercase text-muted"><a class="u-url" title="Permalink to Coming in for a landing, Scott Township, PA &#8211; September 2016" href="http://cdevroe.com/2016/10/09/coming-in-for-a-landing-scott-township-pa-september-2016/">October 9th, 2016</a></p>
</article>

Post on Index:

<article id="post-3945" class="h-entry post-3945 post type-post status-publish format-standard hentry category-uncategorized tag-git tag-github tag-subscriptions tag-youtube">
 <h3><a class="p-name u-url" title="Permalink to Tracking my YouTube subscriptions over time" href="http://cdevroe.com/2016/10/08/tracking-my-youtube-subscriptions-over-time/">Tracking my YouTube subscriptions over time</a></h3>
 <p class="text-uppercase text-muted"><time class="dt-published" datetime="2016-10-08 13:02:22">October 8th, 2016</time></p>
 <div class="p-summary">
  <p>As I wrote late last month, I&#8217;m using YouTube a lot, and so I&#8217;d like to track my subscriptions over time. Git is the best tool for this sort of thing so I quickly jotted my YouTube subscriptions down and put them on Github. To retrieve your own subscriptions you can use YouTube&#8217;s Subscription Manager. [&hellip;]</p>
 </div>
 <p class="text-primary"><a title="Permalink to Tracking my YouTube subscriptions over time" href="http://cdevroe.com/2016/10/08/tracking-my-youtube-subscriptions-over-time/">Read more...</a></p>
</article>

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:

add_action( 'init','custom_post_type_register' );
function custom_post_type_register() {

    $args = array(
        'label' => __( 'Audio' ),
        'singular_label' => __( 'Audio Item' ),
        'public' => true,
        'show_ui' => true,
        'capability_type' => 'post',
        'hierarchical' => true,
        'has_archive' => true,
        'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt', 'custom-fields', 'revisions', 'page-attributes' ),
        'rewrite' => array( 'slug' => 'audio', 'with_front' => false ),
       );

    register_post_type( 'audio' , $args );
}

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:

add_theme_support( 'automatic-feed-links' );

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.

// Combine Custom Post Types into main feed
function combine_cpt_into_feed($the_request) {
    if ( isset($the_request['feed']) && !isset($the_request['post_type']) ) :
        $the_request['post_type'] = get_post_types($args = array(
	  		'public'   => true,
	  		'_builtin' => false
		));
    array_push($the_request['post_type'],'post');
    endif;
    return $the_request;
}
add_filter('request', 'combine_cpt_into_feed');

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.