According to WordPress, those who have previously been subscribed by email should continue to receive email notifications of new posts as before. WordPress.com followers will only see new posts in the Reader. You will not receive email updates unless you subscribe to receive those on the new site. Some older subscribers may have missed one or two recent posts in the transition this week, so feel free to take a moment to catch up.
Others subscribed via RSS may potentially need to update their RSS feeds to reflect the change.
If you’re worried that you’re not getting the content in the preferred format, please feel free to resubscribe to the new blog/site or resubscribe to the appropriate RSS feeds on the new site.
If you have any issues/problems in this transition that you can’t seem to remedy directly, please email me directly; I’m happy to help.
The concept of IndieWeb is something slightly different to many people and it’s ever evolving and changing, just like the internet itself.
Trying to define it is somewhat akin to trying to define America: while it has a relatively well-defined geographic border and place in time, its people, laws, philosophies, and principles, while typically very similar, can vary and change over time. What it is can be different for everyone both within it as well as outside of it. It can be different things to different people based on their place, time, and even mood. In the end maybe it’s just an idea.
A basic definition of IndieWeb
In broadest terms I would define being part of the IndieWeb as owning your own domain name and hosting some sort of website as a means of identifying yourself and attempting to communicate with others on the internet.
At its simplest, one could say they have an IndieWeb site by buying their own domain name (in my case: boffosocko.com) and connecting it to a free and flexible service like Tumblr.com or WordPress.com. Because you’ve got the ability to export your data from these services and move it to a new host or new content management system, you have a lot more freedom of choice and flexibility in what you’re doing with your content and identity and how you can interact online. By owning your domain and the ability to map your URLs, when you move, you can see and feel the benefits for yourself, but your content can still be found at the same web addresses you’ve set up instead of disappearing from the web.
If you wished, you could even purchase a new domain name and very inexpensively keep the old domain name and have it automatically forward people from your old links to all the appropriate links on your new one.
By comparison, owning your own domain name and redirecting it to your Facebook page doesn’t quite make you IndieWeb because if you moved to a different service your content might be able to go with you by export, but all of the URLs that used to point to it are now all dead and broken because they were under the control of another company that is trying to lock you into their service.
Some more nuanced definition
Going back to the analogy of America, the proverbial constitution for the IndieWeb is generally laid out on its principles page. If you like, the pre-amble to this “constitution” is declared on the IndieWeb wiki’s front page and on its why page.
Some people may choose to host the business card equivalent of a website with simply their name and contact information. Others may choose to use it as the central hub of their entire online presence and identity. In the end, what you do with your website and how you choose to use it should be up to you. What if you wanted to use your website like Twitter for short status updates or sharing links? What if you wanted to use it like Facebook to share content and photos with your friends and family? What if you want to host audio or video like Soundcloud, YouTube, or Vimeo allow?
The corporate social media revolution was a lovely and useful evolution of what the blogosphere was already doing. Thousands of companies made it incredibly easy for billions of people to be on the internet and interact with each other. But why let a corporation own and monetize your data and your ability to interact with others? More importantly, why allow them to limit what you can do? Maybe I want to post status updates of more than 280 characters? Maybe I want the ability to edit or update a post? Maybe I want more privacy? Maybe I don’t want advertising? Why should I be stuck with only the functionality that Twitter, Facebook, Instagram, Google+, LinkedIn and thousands of others allow me to have? Why should I be limited in communicating with people who are stuck on a particular service? (Would you use your phone to only call friends who use AT&T?) Why should I have hundreds of social accounts and an online identity shattered like just so many horcruxes when I could have one that I can fully control?
By decentralizing things to the level of owning a domain and having a simple website with control of my URLs, I can move to cheaper or more innovative web hosts or service providers. I can move to more innovative content manage systems that allow me to do more and communicate better or more broadly with others online. As a side effect of empowering myself, I can help create more competition and innovation in the space to do things I might not otherwise be capable of doing solely by myself.
Almost all of the people behind the IndieWeb movement believe in using some basic web standards as a central building block. Standards help provide some sort of guidance to allow sites to be easier to build and provide a simpler way for them to communicate and interact with each other.
Of course, because you have control of your own site, you can do anything you wish with it. (In our America analogy we could consider standards to be like speech. Then how might we define free speech in the IndieWeb?) Perhaps a group of people who want some sort of new functionality will agree on a limited set of new standards or protocols? They can build and iterate and gradually create new standards that others can follow so that the infrastructure advances and new capabilities emerge. Generally the simpler and easier these standards are to implement, the more adoption they will typically garner. Often simple standards are easier to innovate on and allow people to come up with new ways of using them that weren’t originally intended.
This type of growth can be seen in the relatively new W3C recommendation for the Webmention specification which grew out of the IndieWeb movement. Services like Facebook and Twitter have a functionality called @mentions, but they only work within their own walled gardens; they definitely don’t interoperate–you can’t @mention someone on Facebook with your Twitter account. Why not?! Why not have a simple standard that will allow one website to @mention another–not only across domain names but across multiple web servers and even content management systems? This is precisely what the Webmention standard allows. I can @mention you from my domain running WordPress and you can still receive it using your own domain running Drupal (or whatever software you choose). People within the IndieWeb community realized there was a need for such functionality, and so, over the span of several years, they slowly evolved it and turned it into a web standard that anyone (including Facebook and Twitter) could use. While it may have been initially meant as a simple notifications protocol, people have combined it with another set of web standards known as Microformats to enable cross-site conversations and a variety of other wonderous functionalities.
Some people in the IndieWeb might define it as all of the previous ideas we’ve discussed as well as the ability to support conversations via Webmentions. Some might also define an IndieWeb site as one that has the ability to support Micropub, which is a standard that allows websites to be able to accept data from a growing variety of applications that will allow you to more easily post different types of content to your site from articles and photos to what you’re drinking or reading.
Still others might want their own definition of IndieWeb to support the functionality of WebSub, MicroSub, IndieAuth, or even all of the above. Each small, free-standing piece expands the capabilities of what your personal website can do and how you can interact online. But since it’s your website and under your control, you have the power to pick and choose what and how you would like it to be able to do.
So what is the IndieWeb really?
Perhaps after exploring the concept a bit, most may not necessarily be able to define it concretely. Instead they might say–to quote United States Supreme Court Justice Potter Stewart—“But I know it when I see it […]”.
The IndieWeb can be many different things. It is:
an independent network of websites;
a set of broad-based web standards;
a set of principles;
a group of people;
a support network;
an inclusive community;
a Utopian dream of what the decentralized, open Internet could be.
In some sense it is all of these things and many more.
Here are my answers to Alan’s list of questions about my domain:
What is your domain name and what is the story, meaning behind your choice of that as a name?
I’ve spent 20+ years working in the entertainment industry in one way or another and was enamored of it long before that. Boffo and socko are slanguage from the trade magazine Variety essentially meaning “fantastically, stupendously outstanding; beyond awesome”, and used together are redundant. I was shocked that the domain name was available so I bought it on a whim expecting I’d do something useful with it in the future. Ultimately who wouldn’t want to be Boffo, Socko, or even both?
In my youth I think I watched Muppets Take Manhattan about 1,000 times and apparently always thought Kermit was cool when he said “Boffo Lenny! Socko Lenny!”
What was your understanding, experience with domains before you got one? Where were you publishing online before having one of your own?
Over the ages I’d had several websites of one stripe or another going back to the early/mid-90’s when I was in college and everyone was learning about and using the web together. Many of my domains had a ~ in them which was common at the time. I primarily used them to promote work I was doing in school or with various groups. Later I remember spending a lot of time setting up WordPress and Drupal sites, often for friends, but didn’t actually do much with my own. For me it was an entry point into working with coding and simply playing with new technology.
I didn’t actually begin putting a lot of material online until the social media revolution began in 2006/2007. In 2008, I purchased a handful of domain names, many of which I’m still maintaining now. Ultimately I began posting more of my own material, photos, and observations online in a now defunct Posterous account in early 2010. Before it got shut down I had moved back to WordPress which gave me a lot more freedom and flexibility.
What was a compelling feature, reason, motivation for you to get and use a domain? When you started what did you think you would put there?
When I bought my first handful of domains, it was primarily to begin to own and brand my own identity online. I wasn’t sure what exactly I was going to do with them, but I was posting so much content to Facebook and Twitter I thought I ought to be posting it all (especially the longer form, and in my mind, more valuable content) to a site I owned and controlled and then syndicating the content to those other sites instead. Initially microblogging, bookmarking, posting checkins, and sharing photos made it easier to being writing and producing other things.
What kinds of sites have you set up on your domain since then? How are you using them? Please share URLs!
Most of my domains are personal and personal education related, though I do have a few for separate business/work purposes.
collect bookmarks of interesting things I see online or want to read in the future;
post about what I’m reading, watching, or listening to;
post what I’m eating, drinking, or places I’ve checked into, photos of things around me;
post podcasts and microcasts from time to time;
draft and synthesize big pieces of the above to write reviews or longer pieces (from articles to books) and publish them for others to read.
Generally I do everything others would do on any one of hundreds of other social media websites (and I’ve got all those too, though I use them far less), but I’m doing it in a centralized place that I own and control and don’t have to worry about it or certain pieces of functionality disappearing in the future.
In large part, I use my website like a modern day commonplace book. It’s where I post most of what I’m thinking and writing on a regular basis and it’s easily searchable as an off-board memory. I’m thrilled to have been able to inspire others to do much the same, often to the extent that many have copied my Brief Philosophy word-for-word to their “About” pages.
Almost everything I do online starts on my own domain now, and, when appropriate, I syndicate content to other places to make it easier for friends, family, colleagues, and others to read that content in other channels and communicate with me.
https://chrisaldrich.withknown.com — This is a WithKnown-based website that I used when I initially got started in the IndieWeb movement. It was built with IndieWeb and POSSE functionality in mind and was dead simple to use with a nice interface.
http://stream.boffosocko.com — Eventually I realized it wasn’t difficult to set up and maintain my own WithKnown site, and it gave me additional control. I made it a subdomain of my primary website. I’ve slowly been using it less and less as I’ve been able to do more and more with my WordPress website. Now I primarily use it for experiments as well as for quick mobile replies to sites like Twitter.
What helped you or would have helped you more when you started using your domain? What do you still struggle with?
Having more examples of things that are possible with a domain and having potential mentors to support me in what I was attempting to do. I wish I had come across the IndieWeb movement and their supportive community far earlier. I wish some of the functionality and web standards that exist now had been around earlier.
I still struggle with writing the code I’d like to have to create particular pieces of functionality. I wish I was a better UX/UI/design person to create some of the look and feel pieces I wish I had. Since I don’t (yet), I’m trying to help others maintain and promote pieces of their projects, which I use regularly.
I still wish I had a better/more robust feed reader more tightly integrated into my website. I wish there was better/easier micropub support for various applications so that I could more easily capture and publish content on my website.
What kind of future plans to you have for your domain?
I’d like to continue evolving the ability to manage and triage my reading workflows on my own site.
I’d like to be able to use it to more easily and prettily collect things I’m highlighting and annotating on the web in a way that allows me to unconditionally own all the relevant data without relying on third parties.
Eventually I’d like to be able to use it to publish books or produce and distribute video directly.
I’m also continuing to document my experiments with my domain so that others can see what I’ve done, borrow it, modify it, or more easily change it to suit their needs. I also do this so that my future (forgetful) self will be able to remember what I did and why and either add to or change it more easily.
Tomorrow I’m positive I’ll see someone using their own website to do something cool or awesome that I wish I had thought to do. Then I hope I won’t have to work too hard to make it happen for myself. These itches never seem to stop because, on your own domain, nearly anything is possible.
What would you say to other educators about the value, reason why to have a domain of your own? What will it take them to get going with their own domain?
Collecting, learning, analyzing, and creating have been central to academic purposes since the beginning of time. Every day I’m able to do these things more quickly and easily in conjunction with using my own domain. With new tools and standards I’m also able to much more easily carry on two-way dialogues with a broader community on the internet.
I hope that one day we’re able to all self-publish and improve our own content to the point that we won’t need to rely on others as much for many of the moving parts. Until then things continue to gradually improve, so why not join in so that the improvement accelerates? Who knows? Perhaps that thing you would do with your domain becomes the tipping point for millions of others to do so as well?
To get going it only takes some desire. There are hundreds of free or nearly free services you can utilize to get things rolling. If you need help or a mentor, I’m happy to serve as that to get you going. If you’d like a community and even more help, come join the IndieWeb chat room. You can also look for a local (or virtual) Homebrew Website Club; a WordPress Meetup or Camp, or Drupal Meetup or Camp; or any one of dozens of other groups or communities that can help you get moving.
One of my favorite parts of the Post Kinds plugin isn’t just that it provides me the flexibility to add a huge variety of post types to my website or the semantic HTML and microformats it provides to help my site dovetail into the IndieWeb. It’s that it allows me to quickly and easily provide very rich reply contexts to my posts so that I more easily know what I’ve bookmarked, liked, favorited, read, or replied to online. In some sense it helps guard against some of the problem of context collapse found in many social media sites on the internet. As my friend and foodie extraordinaireJeremy Cherfashas said, “a reply without context is like an egg without salt.”
For a long time I had been wanting a bit more control of how the Post Kinds plugin presented some of the data it allows.1,2 After one inputs a URL, the plugin uses several methods to scrape the related web page and returns a lot of metadata about it including the title, a summary, the site name, tags, a featured image, publication date and time, the author and author’s website among others. The data returned depends on how the page is marked up and is generally based on available microformats or open graph protocol data when they’re provided.
The plugin has a setting to “Embed Sites into your Response” on its settings page, and this is generally okay, but it relies on sites to have some sort of oEmbed set up predefined. For bigger sites like YouTube and WordPress, this is generally alright, but it’s not always the case that any data is provided by the external site. Even in YouTube’s case you’ll only display the video with no other meta-data about it. As a result I leave it turned off.
Let’s take a quick look at what some of these default outputs for the reply context with a short comment underneath them look like.
With the embed option turned off the plugin will return a “Summary” of the parsed website page. This too is generally well supported in 90% of websites in my experience. But the data it returns is (smartly) filtered using wp_kses for security so that a malicious page couldn’t inject random html or code into your page. This means that useful functionality is often being stripped out of the “Summary/Quote” field in the reply context. I’d prefer to have the ability to have text with links, video, and audio to appear in-line in these contexts so that there’s a better representation of the actual post I’m reacting to.
The question then, is how can I make this happen?
In older versions of the plugin there was a setting for this feature, but it wasn’t well documented and most people didn’t know what the setting was or what it meant. For simpler UI and support it was ultimately stripped out although the raw code for it was left in. In fact, it’s literally the first short block of code within the plugin’s main code! It looks like this:
To enable the ability to manually add arbitrary html, links, audio, video, etc. you can go to your main administrative user interface in WordPress and go to Plugins >> Edit and then choose the Post Kinds option in the drop down selector in the top right hand corner and click select. Search for the code listed above (it should be right at the top, underneath the title and details for the plugin) and change the single word false to true. Next scroll down the page and click the Update File button.
Now you should be able to manually change any of the fields within the Response Properties metabox and they’d display in full HTML as you’d expect them to. (Caveat: because you’ve disabled a small layer of security, you should keep a close eye on what data appears in your “Summary/Quote” field and make sure you’re not allowing your site or your readers to be led astray or hacked. In my case, I’m almost always modifying it by hand, so it’s not a big issue. Your mileage may vary depending on what you’re posting.)
But wait… What happens when I update the plugin? Won’t the update overwrite the change? Yes, you’re absolutely correct. You’ll have to remember to go back and make this change any time the plugin updates. To prevent this, you could instead modify your wp-config.php file in the root folder of your WordPress install. To do this add the following lines of code to the bottom of this file:
/** Sets up initial variable for the Post Kinds plugin to not filter the Summary/Quote field */
if ( ! defined( 'POST_KINDS_KSES' ) )
define(' POST_KIND_KSES', true );
Next save the file and upload it to your WordPress install. Now you should be all set.
The Post Kinds plugin, essentially an extended version of WordPress’s core Post Formats functionality, allows one to make a variety of types of posts on one’s website that mirrors the functionality provided in a huge variety of social media platforms. This is useful if you’re owning all of your own data and syndicating it out to social silos, but it’s also great for providing others better user interface for reading and consuming what you’re posting.
I’ve documented and written about it quite a bit in the past and am obviously a big fan. In addition to most of the default post types (notes, favorites, likes, bookmarks, reads, listens, etc.), my personal site also supports follows, eat, drink, wishes, acquisitions, exercise, and chickens! Wait a second… CHICKENS?!?
One of the nice benefits of the plugin is that it’s fantastically modular and extensible. As an exercise a few months back I thought I would take a shot at adding chicken post support to my website. Several years ago in the IndieWeb, partly as an educational exercise and partly for fun, several people thought it would be nice to add a post type of “chicken” to their sites. What would it look like? What would it entail? How might it evolve? Since then interest in chicken related posts has naturally waned, but it does bring up some interesting ideas about potential new pieces of functionality that one might want to have on their personal websites.
While I currently support many post types, I’ve discovered recently that I have a variety of notes and checkins that relate to items I’ve purchased or acquired. I thought it might be worthwhile to better keep track on my own website of things I acquired in a more explicit way to make posting them and searching for them a lot easier. But how could I do this myself and potentially contribute it back to a broader base of other users? I started with a bit of research on how others have done this in the past and tried to document a lot of it on the Indieweb wiki. I eventually asked David Shanske to reserve the idea of acquisitions within the Post Kinds plugin, which he did, but I wondered how I might have done some of that work myself.
So below, as an example, I thought I’d write up how I’ve managed to add Chicken posts to my website. To a great extent, I’m using data fields and pieces already built into the main plugin, but in doing this and experimenting around a bit I thought I could continue to refine chicken posts until they did what I wanted, after which, I could do a pull request to the main plugin and add support for others who might want it. Hopefully the code below will give people a better idea about how the internals of the plugin work so that if they want to add their own pieces to their sites or contribute back to the plugin, things might be a tad easier.
Pieces for a new Post Kind in WordPress
Adding a new Post Kind primarily consists of three broad pieces which I’ll address below. The modularity of the plugin makes adding most of the internals for a new kind far simpler than one might imagine.
Adding Taxonomy Support
New kinds in general will require a small handful of properties which include:
a name (as well as its singular, plural, and verb forms);
a format, so that the plugin can map the new post kind to a particular Post Format type within WordPress core so that themes which use these can be properly set when needed. Format options include: aside, image, video, quote, link, gallery, status, audio, and chat. Some post kinds may not have an obvious mapping, in which case the value can be left as empty;
a generic description for display within the admin user interface as well as for the archive pages for the type which are auto-generated;
a description-url, typically this is a link to the IndieWeb wiki that has examples and details for the particular post kind. If there isn’t one, you could easily create it and self-document your new use case. It could even be empty if necessary;
A show setting with a value of true or false to tell the plugin to default to showing the kind in the Post Kinds “Kinds” metabox so that the new kind will show up and be choose-able from within the interface when creating new posts.
Code to include these pieces of data will need to be added to the /includes/class-kind-taxonomy.php folder/file path within the plugin so that the plugin knows where it needs to be found.
As an example, here’s what the code looks like for the bookmark kind:
'bookmark' => array(
'singular_name' => __( 'Bookmark', 'indieweb-post-kinds' ), // Name for one instance of the kind
'name' => __( 'Bookmarks', 'indieweb-post-kinds' ), // General name for the kind plural
'verb' => __( 'Bookmarked', 'indieweb-post-kinds' ), // The string for the verb or action (liked this)
'property' => 'bookmark-of', // microformats 2 property
'format' => 'link', // Post Format that maps to this
'description' => __( 'storing a link/bookmark for personal use or sharing with others', 'indieweb-post-kinds' ),
'description-url' => 'http://indieweb.org/bookmark',
'show' => true, // Show in Settings
For direct comparison, and as an explicit example for my chicken post kind, here’s the block of code I inserted within the class-kind-taxonomy.php file immediately below the section for the acquisition type:
'chicken' => array(
'singular_name' => __( 'Chicken', 'indieweb-post-kinds' ), // Name for one instance of the kind
'name' => __( 'Chickens', 'indieweb-post-kinds' ), // General name for the kind plural
'verb' => __( 'Chickened', 'indieweb-post-kinds' ), // The string for the verb or action (liked this)
'property' => 'chicken-of', // microformats 2 property
'format' => 'image', // Post Format that maps to this
'description' => __( 'Owning all the chickens. Welcome to my chicken feed.', 'indieweb-post-kinds' ),
'description-url' => 'https://indieweb.org/chicken',
'show' => true, // Show in Settings
You’ll probably notice that beyond the simple cut and paste, I haven’t really changed much. Syntax aside, most of these pieces are relatively obvious and very straightforward, but I’ll add some commentary about a few parts and what they do which may not be as obvious to the beginner. When creating your own you can copy and paste this same block into the code at the bottom of the list of other types, but you’ll want to change only the data that appears within the single quotes on each of the nine lines for the various settings.
For those not familiar with microformats you may be asking yourself what snippet to add for the property setting. The best bet is to take a look at the microformats wiki or look for possible examples of people doing the same type of post you’re doing and copy their recommended microformat. For extremely new and likely experimental edge cases, chances are that you’ll need to choose your own experimental microformat name. In these instances you can use prior microformats as examples and potentially follow the format. In my case I knew about the bookmark-of, like-of, favorite-of, and the experimental read-of, listen-of, and watch-of microformats, so I followed the pattern and chose chicken-of for my experimental chicken posts. One could also potentially ask for recommendations within either the microformats IRC/chat channel or the IndieWeb chat. If you create a new and experimental one, take a few moments to document your use case in the IndieWeb and/or Microformats wikis for others who come after you. Keep in mind that if you change the property name at a later date you will need to go into your database and change the wp_postmeta database meta_key field from mf2_property1 to mft_property2 so that WordPress will know where the appropriate data is stored to be able to display it.
The show setting is fairly straightforward, but may not be as obvious to some. It has either a value of true or false. If the value is false, the new post kind won’t be displayed in the radio button options within the admin UI for creating new posts. If the value is true, then it will be available. The Post Kinds plugin has a number of reserved post kinds which aren’t displayed by default on most sites–primarily because they do not have appropriate views or data fields defined–but they could be enabled by changing the show flag from false to true. Most often we recommend you only show those kinds that you’re actively using.
Additional examples of the dozen or more standard post kinds can be found within the code to provide some additional potential clarity on what types of data each of them are expecting.
I debated a while on making the verb ‘chickened out’ instead of ‘chickened,’ but I chickened out thinking that it would make my posts something wholly different. Obviously you can now make your own choice.
With this chunk of code saved into the plugin, it is now generally aware of the new post kind and can save the appropriate data for this new kind of post.
Now you’ll want to add some code to the plugin to tell the plugin how it should display the data it’s saving for your posts. The easiest way to do this is to copy and paste the code from one of the many default views already in the plugin and just change a few small pieces of data to match your post kind. This code can be created as a new file with your new matching post kind name (the one at the top of your code snippet above that appears on line 1 before the word ‘array’) in one of two places. If you put it in the views folder in the plugin, you may need to re-add it later on if the plugin updates. Otherwise you can add the code into a file which can be placed into a folder named kind_views in either the folder for your theme (or your child theme, if you have one.) We recommend placing it in your child theme, so if the parent theme updates, your code won’t accidentally be lost.
There are a variety of views for many post kinds available to stand as examples, so you can look at any of these and tweak them as you wish to get the output you desire. For more complicated output displays it might certainly help to have some PHP coding skills. For my chicken post kind I simply copied and pasted the code for the bookmark kind view and pasted it into a file named kind-chicken.php following the naming convention of the other files.
Below is a copy of the code I added for the chicken post kind which is nearly identical to the bookmark view with exception of changing the name of the template, adding u-chicken-of and changing the get_before_kind to chicken instead of bookmark. Note that because the chicken-of microformat is wrapped on a URL, it has the u- prefix, otherwise if it were on plain text it would have been p-chicken-of using the standard microformat h-, u-, p-, and e- syntax.
I also put both the u-chicken-of and the u-bookmark-of microformats in the view so that sites using the post type discovery algorithm that don’t recognize the chicken-of microformat won’t choke on the proverbial chicken bone, but will default back to thinking this post is of the bookmark type. I suspect that I could also have left the u-bookmark-of off and many would have defaulted to thinking this post was a simple note as well. You can make your own choice as to which you prefer as a default.
Finally, you’ll want to include the appropriate svg icon within the plugin so that it will display on the post (if the appropriate settings are chosen within the plugin’s settings interface: either “icon” or “icon and text”), and within the Kinds metabox in the post editor.
You’ll want to have one icon named kindname.svg in the svgs folder and another named kinds.svg in the plugin’s root folder. The kinds.svg is a special ‘master’ svg of all of the kinds icons bundled together. If it helps in matching the icon set, all of the current kind icons are made with Font Awesome icons which have the appropriate licensing for distribution.
In my chicken example, I opted for the feather icon since Font Awesome didn’t have an actual chicken available.
Naturally some people may want to display particular exotic kinds which might not extend to the broader public. A chicken post type certainly falls under this umbrella as I wouldn’t expect that other than for novelty, obsessive IndieWeb post kinds completeness, or for a very small handful of specialized farming, juggling, or comedy websites that anyone else in their right mind would really want to be doing a lot of posting about chickens on their site.
David Shanske, the plugin’s creator, has made it possible to create a sub-plugin of sorts so that one can add one-off support to these types using a variety of filters and functions. This could be useful so that updates to the plugin don’t overwrite one’s work and require adding the pieces outlined above back in again. Sadly, this is a tad beyond my present abilities, so I won’t address it further at the moment other than to say that it’s possible and perhaps someone might document it for others to use a similar template in the future.
Try it yourself
Now that you’ve got the basics, it should be relatively easy to add many of your own new post kinds.
If you want a simple exercise, you should be able to go into the code and manually change the show flags for the eat and drink kinds from their default false to true to enable posting food to create a food diary on your website. (These have a reasonable default view and icons already built in.)
With slightly more work you can change the show flag on the follow kind and copy a view based on the bookmark view to make a follow view to make follow posts. (Here’s a link to my version.) Similarly other hidden kinds like wishes and acquisitions can be enabled easily as well. These also have default icons already built in, but just need a view defined to show their data.
If you want a slightly larger challenge that uses all of the above, why not attempt adding the appropriate machinery to create a want post?
Though David has often said before that he wouldn’t build in support for multi-kinds, some people may still want them or think they need them. If you’re exceptionally clever, you might be able to create your own explicit multi-kind by mixing up the details above and creating a kind that mixes a variety of the details and creates a view that would allow the specific multi-kind you desire. Caveat emptor on this approach if you should take it.
Share your ideas
Now that you’ve got the general method, what kinds are you going to deploy in the future? What have you already created? Feel free to reply with your ideas and thoughts below in the comment section or send us a webmention from your own site with what you’ve done. Maybe consider doing a pull request on the plugin itself to add the functionality for others?