WordPress/Development

From IndieWeb
Jump to: navigation, search

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.

Contents

Working On

There are several projects to improve both the level and ease of supporting IndieWeb formats & protocols in WordPress.

IndieWeb Plugin

Brainstorming/discussion at https://github.com/indieweb/wordpress-indieweb/issues/47

Plugins

Ease of installation and management

Themes

  • 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.
      • SemPress supports a solid mf2 structure and is easily customizable/extendable --Matthias Pfefferle
      • My understanding is that SemPress is a great out-of-the-box theme, but I also wanted a "blank" theme that indieweb designers could build from scratch on. — gRegor (talk) 08:51, 17 June 2014 (PDT)
  • Some common defaults that non-technical users could try out, like Twenty Fourteen with microformats2 support added

Brainstorming

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.

See also conversation from 2017-01-03

Core

There are several efforts to add Indieweb Elements to WordPress Core and related projects.

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.

Brainstorming

  • 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

"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.

Location

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_latitude
  • geo_longitude
  • 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.


WordPress
Topics Getting Started on WordPressAdvanced WordPress Set UpPluginsThemesExamplesWordPress with BridgyDevelopmentDataSecurityWordPress related wiki pages
Plugins Indieweb PluginWebmentionSemantic LinkbacksPost KindsOpenIDMicropub
Themes SemPressSemPress Lite (SemPress Child Theme)SenPress (SemPress Child Theme)Index (Sempress Child Theme)Independent Publishermf2_s
Assistance WordPress Outreach ClubJoin the #indieweb chatIRC and other chat options


See Also

Personal tools
Namespaces
Variants
Actions
Recent & Upcoming
Resources
Toolbox