Purpose of this page is to document discussions/brainstorming regarding Indieweb WordPress Themes and Plugins to operate together, initiatives to get Indieweb elements into Core and WordPress building blocks. Interoperability should exist regardless of the author and future development, as well as advice/suggested practices.
There are several projects to improve both the level and ease of supporting IndieWeb formats & protocols in WordPress.
Brainstorming/discussion at https://github.com/indieweb/wordpress-indieweb/issues/47
Ease of installation and management
- Johannes Ernst demonstrated at Indie Web Camp 2014 how to install Wordpress with several preactivated indie web plugins with a single command on IndieBox. Updates, backups, restores etc are also single commands on IndieBox.
- A barebones theme that has microformats2 - point the designers/developers that want to build a theme to use that.
- gRegor is considering doing this with the HTML5blank.com theme.
- Some common defaults that non-technical users could try out, like Twenty Fourteen with microformats2 support added
- GWG worked on a fork of _s(Underscores) for Indieweb, which is the stripped down starter theme on which the default Wordpress themes are based. It can be found at mf2_s. Also working on trying to get MF2 changes into _s itself.
Problem: Right now there's too much context-setting pre-amble before there's anything like a "Hey, choose from one of these themes."
Goal: Improve the variety and number of available WordPress themes that support IndieWeb out of the box. Many of the common IndieWeb functionalities have been implemented, but theme support is one of the last remaining major bottlenecks for helping the WordPress implementation of IndieWeb gain broader support from generations 2+.
General strategy: Compile and simplify a list of popular candidate themes and expand support for those which seem most worthwhile to increase the list of options.
Perhaps in small groups we could choose a new theme every three months or so to dogfood and iterate on?
Separate themes out into "These work, go ahead and use them", and "We're testing these out", and "Here's some we could improve"
It's been suggested that themes developed on Github are much easier to keep the updates coming and you can run a fork that is easy to update.
- Common problems to watch out for:
- Many plugins and themes put metadata in the_content plugin, which creates a problem, as most themes wrap the_content in e-content.
- Suggestions of specific areas of themes to work on/draw from:
- Modern themes that are responsive (https://premium.wpmudev.org/blog/free-responsive-wordpress-themes-reviewed/) (these are also most likely to have the longest supported lives)
- Themes for personal sites/blogs as opposed to magazine, corporate/business, seasonal themes to stay true to principles.
- Template themes like _s which designers can easily fork and build upon
- Subsequent themes would them be far more likely to support IW use
- Popular themes in broad/common use
- Might be worth looking at popular downloads on wp.org and look at forking them for IW.
- Nudge some of the popular "premium" themes to better support IW and microformats: https://www.elegantthemes.com/blog/resources/most-popular-premium-wordpress-themes particularly since people are paying for them and resulting functionality
- There was a plugin for Genesis themes on github to add mf2. Picking that up might be better solution for premium theme adoption; see also https://github.com/willnorris/willnorris.com-wordpress/blob/master/public/content/mu-plugins/genesis-indieweb.php has some code from willnorris though
- List of common/popular themes to test for general compatibility
- WordPress annual themes
- Twenty Ten
- Twenty Eleven
- Twenty Twelve
- Twenty Thirteen
- Twenty Fourteen
- Magazine-y in feel, but Chris Aldrich has run site(s) using it with relatively good IndieWeb results.
- Be aware that it themes on hentry which could potentially cause layout issues if used with plugins like UF2 (which isn't mission critical).
- Twenty Fifteen
- Twenty Sixteen
- David Shanske has a repo for developing this
- This theme does very well out of the box, but when syndicating content it can include information from Syndication Links and JetPack modules because Class entry-content div overextends itself
- It's also been reported that Syndication Links adds a u-photo tag on the avatar within the author box at the bottom of posts which can cause problems for those trying to use Bridgy Publish, though other means of syndication are available.
- Twenty Seventeen
- This is more corporate/business-esque in feel, so possibly not a great candidate, but there is a push to support microformats2 properly
- Other Themes
- WordPress annual themes
See also conversation from 2017-01-03
- Examples of Indieweb friendly themes that users are building and/or self-dogfooding (Note: these are actively being developed, so one's mileage may vary, but they can serve as interesting examples)
There are several efforts to add Indieweb Elements to WordPress Core and related projects.
- Add Microformats2 Support https://core.trac.wordpress.org/ticket/30783 (CLOSED AS WONTFIX)
- Improve Linkback Presentation https://core.trac.wordpress.org/ticket/32653
- Comments should have real permalinks(necessary for better and effective mentioning) https://core.trac.wordpress.org/ticket/34106
Also, the current WordPress theme, Twenty-Sixteen, has proper use of hfeed and removes the theme dependence on styling these elements. Similar efforts underway for minor changes to Twenty-Seventeen.
- Based on interpretation of the Wordpress Codex custom post types are intended for creating entirely new content types, not extending the existing post type.
- Ashton McAllan was using custom metadata on standard post types and working out how to display which posts in the theme based on whether or not the metadata is populated for a post, considering classifying posts with a custom taxonomy to make for easier handling in the wordpress administration.
- GWG decided the best move to get microformats markup was a custom taxonomy with terms like like/reply/repost that could be acted on. He had been working on this with a new custom post type, notes. Based on comments by Ashton McAllan, he switched to the simpler suggestion of adding the custom taxonomy to the default post type. The current implementation is based on the less popular Post Formats feature of WordPress.
- Ryan Barrett has a Press This-like plugin for inserting webmentions to a post from the bookmark bar: IndieWeb Press This bookmarklets for WordPress (or use the WordPress plugin)
"Filters are functions that WordPress passes data through, at certain points in execution, just before taking some action with the data (such as adding it to the database or sending it to the browser screen). Filters sit between the database and the browser (when WordPress is generating pages), and between the browser and the database (when WordPress is adding new posts and comments to the database); most input and output in WordPress passes through at least one filter. WordPress does some filtering by default, and your plugin can add its own filtering." [ http://codex.wordpress.org/Plugin_API#Filters | Wordpress Codex]
For the purpose of interoperability between Indieweb plugins and themes, GWG and pfefferle discussed using common filter names in Indieweb Wordpress themes to aid in development.
Suggestion for Common Filter Names/Placement (Work in Progress)
- Themes based on _s contain an entry-meta class which contains the metadata for the entry.
- A header_entry_meta filter which adds additional meta data to a div class entry-meta inside the header
- A footer_entry_meta filter which adds additional meta data to a div class entry-meta inside the footer
- The two entries share a class entry-meta, which is used for common styling.
- A before_content and an after_content filter which appear immediately above and below the e-content div
- I am not sure if this is needed at all, because the `the_content` filter should be enough to add something above or below the content. --Matthias Pfefferle
- Response from David Shanske to above... the_content filter styles the return from the content editor. But, wrapped around that is the markup identifying the content. There may be a better way to do it, but the idea is to be able to add data that is not inside the content block, and not in the header or footer. Example... adding the in-reply-to, or adding a p-summary.
- I would suggest to use underscores (instead of hyphens) in actions to use the same style as the WordPress "actions" --Matthias Pfefferle
- As of 2015-05-25, David Shanske is working on a 'better' idea of adding the 'entry-content e-content' div inside the content block using a filter attached to 'the_content'. This would require some minor theme changes, but would ensure the best compatibility for adding additional elements.
The above would allow data to be added/removed by plugins in a designated place outside the content block, either inside a block designated for meta data in the header/footer or not.
Wordpress does not have built-in location awareness or geodata storage for posts. However, it does have a standard for its storage.
It consists of standard keys for geodata in the meta for posts, pages, users, comments, etc.
- geo_public - 1 is public, 0 is private. If there is no geo_public, assume public
- geo_address - freeform textual description of coordinates. Accuracy level/detail/language is arbitrary
The advantage of using the standard meta keys is support by various plugins.
GWG has released a plugin for Wordpress that uses these values. The plugin called Simple Location, is supposed to add this support to Wordpress. There are plugins that offer location support, but none that implement it in a way best compatible with the location aspect described in the wiki and many would be overbuilt for the purpose. It is in a state of major rewrite now to be more user friendly.
Who: Developers interested in the WordPress plugin/theme ecosystem
What: First scheduled online chat/discussion on how to move forward with a plan to better organize interoperability of mf2 data
When: January 8, 2018 20:00 GMT
Where: IRC #indieweb-wordpress Slack #wordpress (See Discuss for more details)
Why: Nail down a protocol for how plugins and themes negotiate who renders mf2
See this GitHub issue for some previous discussion on the subject.
- Do we want to move to merge the plugins into fewer/single plugins? For example, the Indieweb plugin is both an installer and handles Indieweb identity.
- Multiple plugins have not just the PHP-MF2 parser, but code around parsing that interprets MF2 JSON into other formats. This could be consolidated into a single library and/or service that the others use.