Petter Hassberg

The breaking of this one seems to correlate with the addition of workarounds for zones with CAA records (#506) (which the API does not support) ```bash curl -s -X GET...

Maybe but on the other hand each provider needs to handle the content for the record it wants to create and it's pretty easy to split on space and stuff...

I wrote a bind zone file provider and found that templating a bind zone file is much easier than parsing a zone file, because there are so many corner cases...

> I am unable to examine this right away, but look forward to giving it a look as soon as I am able. Good because I just added some finishing...

I just added one final thing: `extension_preferences` as something where each individual plugin could be configured, i. e something along the line of: ```yaml extension_preferences: 'InstaPlerd::Post': filter: 'InstaPlerd::Filters::Artistic' width: 800...

I _think_ that I've addressed the points you raised, including having the TestExtension actually do something, albeit a rather pointless thing. I did also add some perldoc to help clarify...

Yes, and no it does not strictly _have_ to be a subclass but it would have to implement all Plerd::Post methods which Plerd uses when dealing with posts, so even...

I have in my head a concept which could work for extending Plerd using the moose before after and around hooks for all method and attributes which moose knows about....

> * Plerd carries a registry attribute that maps file extensions to Plerd::Post subclasses. The default has two entries, mapping .md and .markdown to Plerd::Post::Markdown. (Which, see below.) I made...

> I do prefer the idea of changing the registry into a nice, clean, attribute-stored hash like this, rather than a bag of regular-expression snippets. But would this approach be...