#37 handled file uploading and is limited to 'image' only now

Make this better:

• use file path from the field settings,
• save multiple files

e.g. https://aaronparecki.com/2018/03/07/7/stackoverflow

headers are ok, but users don't discover this easily.
it be nicer if people can just post an url to send it

This will be a dedicated section being 'Feeds' in the admin interface.

• add rel="feed" bridgy for post-posse-discovery - I can point to my timeline as an example.
  figure out if I can create a view which renders nodes and comments, or create a controller which renders entities with the microformat view mode then and let users configure this on that screen.
  Different timelines with even a different path instead of 'timeline' is probably easiest then. Talk to snarfed how lang this page can be or if it can use paging. Spin of in #135

• this is also useful for microsub readers. Talk to aaron if for instance aperture can discover microformat feeds from a header link on the homepage (or anywhere). If not, document that so users can for instance should create a link to microformat somewhere. Spin of in #136

will probably happen automatically when we start with tests

when channels are removed, or when the module is uninstalled, we need to cleanup config
or fix dependencies at least
same for content types, bundles

for everyone basically, it can all be optional right

comments and replies (from myself then for instance) don't always come back in order it seems from brid.gy

See if we can manipulate this.

On the other hand, it would help users if we put this in config too and it's not such a big thing I guess.

This would be killer feature, but maybe we don't even need this at all, we'll see how micropub evolves.
Adding more hooks might be a better way inititally

see https://indieweb.org/Micropub-extensions#Post_Status

Maybe this already exists as a drupal module, so if it exists, document it.

what's the use case and do we need default support ?

see https://twitter.com/schnarfed/status/971397440665366528 and brid.gy/about#link

Currently, they are limited to nodes.

The code in indieweb_node_form_alter could be abstracted so they element/widget can be used everywhere.

they are used now so publishing is possible, but maybe users only want to pull

• use injection everywhere
• use db api (there are too many sql queries here and there)
• don't hardcode on table names (e.g. comment table name)
• replace drupal_set_message (should be fine already)
• make sure storage methods exist (should be fine already)
• move complex hook implementations to services (should be fine already)

This throws an error now that they are checkboxes (used to be one at some point)

Currently the block exposes hardcoded theming.

We can use the view modes to render variants of a webmention.

#The webhook response of webmention io vs the api response format are different.
aaronpk/webmention.io#95 gives a hint how we can make this the same

This means we can create one function for parsing in the controller as well as in the drush command.
Maybe we can use a library too (double check xray, but since the webhooks are relatively simple, we could probably live with this for now, but a nice object would still be nice though)

(note, the issue printed on the micropub settings screen is now going to be fixed in #132)

double check https://github.com/aaronpk/p3k-micropub
however as we're using symphony, maybe we are actually ok and using Request() will solve it all ..

Instead of the formatter, we could simply use the view modes, however, we should be able to expose the author avatar too somehow.

This depends on the plugins being done.

Default channels we can ship with are all brid.gy webmention urls

This is currently done in settings.php

When this is battletested more, expose this in config

When the micropub request is a post, all is fine.

This needs a media enpoint if you accept json. Will figure that out later if we really need this or not.

• This allows to receive mentions from say twitter on which you then can add a comment which will be send as a reply on that. Funky :)
• or create a node from from a mention/like from a webmention from another site
• we should store the syndication url than too, especially if it came from twitter so bridgy can monitor it to store any replies on it too eventually

property is micropub_payload, and then you can for instance on hook_node_presave() look for it to do additional things.

Added hook too: hook_micropub_node_pre_create_alter

Currently this is using file_get_contents, we should rather use the drupal http client which makes more sense, and is probably safer too :)

What in case the author doesn't have an avatar, show default ?

add u-url
add dt-published
add p-name
add p-bridgy-twitter-content

test settings form
test callbacks to see if they react on settings
test the 2 hooks

Joris' image always seems to be broken, e.g. https://realize.be/notes/1217 (and other pages)

When a comment is created with a reference to a webmention which comes from a silo, allow liking that one.

This can be as easy as creating a link with a prepopulation field to the 'like' node type.

When this happens, we will be able to match replies on this one again too.
Related with #58

Currently the publishing is done with a drush command.

We can keep the Drush command, but we should use a proper queue class.
Note that we should stay in the queue, because sending the mention on creation has many problems!

It should be possible create multiple channels to publish to.
They simply consist of

• label
• url

e.g.

• Label: Brid.gy publish twitter
• url: https://brid.gy/publish/twitter

These then expose the pseudo fields

Spec is at https://indieweb.org/Microsub-spec#Timelines

Also document https://indieweb.org/Microsub in this README

see https://quill.p3k.io/docs/syndication