WordPress/Data

In order to ensure interoperability between Indieweb WordPress plugins, as much as possible, the same data structures should be used.

= Metadata =

WordPress allows for for metadata to be attached to various objects.

By default, WordPress includes a metadata table for post types(posts, pages, etc), comments, taxonomy terms, and users.

WordPress contains a Metadata API that it uses to handle metadata.

Microformats data
Originally proposed by, store top-level microformats2 properties in metadata with the property names as the keys, prefixed by.

In accordance with MF2 JSON format, all values MUST be specified as arrays, even if there is only one value, identical to the Microformats 2 JSON format. This was implemented in the latest version of the Micropub plugin.

For example, this RSVP snippet:

would be stored in post meta with the key  and value.

use uf2 instead of mf2
undefined minor revision of 's proposal - same but use "uf2" instead of "mf2" because the "u" looks closer to a µ for "micro":

why mf2 is better than uf2
Per 's follow-up in IRC:
 * mf2 is seen in existing code much more often than uf2
 * e.g. php-mf2, mf2py, mf2util, etc
 * mf2 is more obvious (and maybe less clever)

Post
The Micropub and Post Kinds plugin currently store MF2 properties using the above prefix. Micropub uses the MF2 JSON guidelines of storing everything as an array, and Post Kinds has adopted this in recent versions, although earlier versions may have stored single properties For this reason, Post Kinds takes over returns in Micropub to normalize that data.

The Syndication Links plugin stores its data in mf2_syndication and is cross-compatible.

User
WordPress supports user metadata. As part of the revamping of the Indieweb plugin, metadata reflecting rel-me and reflecting h-card properties were added to the user profile.

However, the rel-me silo URLs were not prefaced with mf2_ as using just the sitename...e.g. twitter instead of mf2_twitter allows for cross compatibility with other plugins that store this data. There were issues with those, due to standardization issues amongst different plugins.

Comment
Webmention Plugin adds an additional comment type of 'webmention' to comments. Webmention stores the following properties in the mention:


 * webmention_target_url
 * webmention_source_url
 * webmention_target_fragment - The Fragment of the Target, this is so fragments can be searched/matched
 * webmention_created_at - Comments only have a timestamp, not a modified stamp, so this stores the original creation time.
 * webmention_response_code - registered but not currently in use. This was meant to store the response code returned during verification
 * webmention_vouch_url - Stored if sent
 * webmention_vouched - Whether or not this webmention was vouched for - only if vouches are enabled

Semantic Linkbacks stores extra information in the comment metadata.


 * semantic_linkbacks_canonical - the canonical source url
 * semantic_linkbacks_avatar - the author avatar URL
 * semantic_linkbacks_type - the comment type. The plugin currently supports the following types:
 * mention(default)
 * reply
 * repost
 * like
 * favorite
 * tag
 * rsvp:yes, rsvp:no, rsvp:maybe, rsvp:invited, rsvp:tracking.
 * As of Version 3.4.0, Semantic Linkbacks stores various parsed properties in comment meta using the mf2_ prefix. It basically stores everything that isn't expressly blacklisted, such as properties which are converted into WordPress properties.

Syndication
's Syndication Links plugin uses the property mf2_syndication if it exists.

It previously used a single data field with the key 'syndication_urls' with URLs separated by newlines for syndication URLs to be marked up for syndication, before that, the plugin formerly stored an array of URLs of various syndication services under the metadata key 'synlinks'. This is now deprecated and if it finds these properties, it will move and delete the old.

Comment Data Brainstorming
Built into the WordPress Comment Database, the following relevant properties are stored:


 * comment_author - Name of the Author of the 'comment'
 * comment_author_url - While officially the author_URL, this is used by Pingbacks, Trackbacks, and Webmentions to reflect the source URL for a linkback, which creates an issue
 * comment_type - comments are stored as '', otherwise name of type. 'webmention' is a custom type used by the Webmention Plugin
 * user_id - Theoretically, the comment author and such could be stored as a user in the user table. But this is not done by everyone.

Avatar/Author photos by default in WordPress is derived from Gravatar. The WordPress Webmention plugin does not modify this in any way, but Semantic Linkbacks sets an external URL for the avatar. There are multiple plugins for local avatar storage, but they only store photos for users, not for commenters.

launched the ActivityPub plugin for WordPress, which also stores in comments. ActivityPub stores three meta properties.


 * source_url
 * avatar_url
 * protocol

It stores the type of response in the comment_type as opposed to the meta and only stores the protocol in the meta. This mirrors a proposal that has been in the Semantic Linkbacks plugin for some time, but would require the migration of old data to a new system.

The latest proposal is to adopt a new comment structure for these social protocols and migrate all data to a common storage method.

WP_Comment Table Properties


 * comment_type - Would refer to the type of response. Reply, like, etc. For compatibility with existing WordPress comments, an empty comment type would indicate a reply or traditional comment
 * comment_approved - Used for moderation. There is no comment_status option to allow for a queued or verification status unless this is custom implemented.
 * comment_author_url - For pingbacks, trackbacks this was used as the source URL. For comments, author URL. For the new version, it would only be used for the author URL.

Comment Meta Properties


 * protocol - the protocol, such as 'webmention', 'activitypub', etc
 * source_url - Will reflect the source URL of a comment. For webmentions, etc this would be the source url
 * avatar or avatar_url - The Activity Pub version is avatar_url, Semantic Linkbacks uses semantic_linkbacks_avatar. Now, the issue with the _url addition is that this assumes the only way to store avatars is by URL. Avatars might be stored as attachment IDs, etc. This requires further discussion.
 * date_created - This again, to cover the lack of a modified option, using the table property for comment time as last modified and this as original creation time. The question is if this should be local time, GMT, or iso8601 with timezone offset.

The storage of parsed microformats would not change.

The usage of target properties is specific to Linkbacks. In order to address whether this should remain webmention_ or not is whether or not a new proposal would involve Pingbacks, Trackbacks, and Refbacks. Refbacks are a custom plugin, and therefore no issue in changing, but it is still a question as to whether the other standards should be included.

Location
WordPress currently provides a Geodata data structure.

(float) decimal degrees -90 to 90 (negative values are in the southern hemisphere).
 * geo_latitude REQUIRED

(float) decimal degrees -180 to 180 (negative values are in the western hemisphere). (int) Not part of the WordPress standard (int) is the geodata public (1) or private (0)? If value is missing, assume public.
 * geo_longitude REQUIRED
 * geo_altitude OPTIONAL
 * geo_public OPTIONAL

(string) freeform textual description of coordinates. "221B Baker St, Westminster, London NW1 6XE, UK", "Pasadena, CA", "Soho, NYC", "Idaho", etc. Accuracy level and language is arbitrary.
 * geo_address OPTIONAL

As of WordPress 4.4, taxonomy term metadata is allowed to attach to a taxonomy term. Therefore, is planning to declare a venue as a taxonomy term, and add location properties as taxonomy term meta attached to them.

= Taxonomies =

A taxonomy called 'kind' is currently used for the Post Kinds Plugin. This is meant to indicate the post kind. Several kinds are in use and/or reserved for future use due no UI for them having yet been built.

Post Kinds Plugin
In response to 's proposal to organize using mf2_ as a key prefix, changed to using the citation nested inside the property for the specific type of post instead of 'response'. All fields are optional(See Below)


 * ['url'] - The URL the post is responding to.
 * ['name'] - The title of same
 * ['author'] - The URL of an h-card (if external)
 * ['published'] - URL publish date in ISO8601 with timezone offset
 * ['updated'] - URL updated date in ISO8601 with timezone offset
 * ['publication'] - The name of the site, or for citing articles in publications with more than one author.
 * ['featured'] - Featured Image
 * ['content'] - the content or partial content of the work itself.
 * ['card']['name'] = Author Name / Artist Name
 * ['card']['photo'] = Author photo

Deprecated
The Post Kinds Plugin, prior to Version 1.2.0,used the following array of metadata using the key 'response' to store details on what a post is responding to. All fields are optional.


 * response['url'] - The URL the post is responding to.
 * response['title'] - The title of same
 * response['author'] - The author name
 * response['icon'] - The author icon/image/avatar
 * response['published'] - URL publish date in ISO8601 with timezone offset
 * response['content'] - Content or a Citation...to allow for an excerpt for context.

= Themes =

Both 's mf2_s fork and 's SemPress theme register theme support for 'microformats2'. This allows both themes to tell plugins and other functions that they support the microformats2 standard and to act appropriately.

This usually means workarounds such as adding in microformats by the plugin can and should be disabled if this is set.