Add og:image:type metatag

[fabianmichael]

Just for completeness …

[Daandelange]

I'm surprised that's all. (?) Note that the extension is taken from the original file, not the thumb, as there's no $fileVersion->extension() in Kirby.

[fabianmichael]

I'm surprised that's all. (?)

If you are referring to #25: why should we deliver more code then necessary? Of course, we could all provide microformats, inline schema.org markup, JSON-LD and everything mentioned in https://github.com/joshbuchea/HEAD. But what’s the point of doing so? It will not make Meta a better/more useful plugin (gosh, I regret chosing this name, because a few days later a large corporation renamed itself to the same term) and will likely insert many more possible scenarios in which the plugin could break and the added complexity would make it harder to move forward. On top of that, it would send more unnecessary code over the wire and debugging issues would also become harder.

As you might have noticed, this is already a quite complex peace of software that has a long history, because its predecessor was developed specifically for the needs of getkirby.com. I liked the idea so much and was tired of re-inventing the wheel for every project, so I made this plugin and published it on GitHub. I don’t make any money from it directly, it is just a tool for my projects and I’m happy if it helps other people. But I really want to resist the idea to add stuff that does not provide any measurable real-world benefit for most of its users. And as pages in Kirby do not have a standardized set of fields, the plugin can never know by itself who is e.g. the author(s) or owner(s) or a document, how copyright information is stored (if at all), so making assumptions about these things calls for problems and might even make it impossible to integrate the plugin with existing projects.

---

The Toolkit has a function for getting the mime-type of a file from its extension, that could serve as a workaround? But on the other hand, as I am thinking about it for a bit logner: As OpenGraph tags work without the file information, let’s just close this ticket and omit the file type metatag. It seems to be unnecessary after all.

[Daandelange]

Hey,
Sorry, no I was referring to the commit referenced above, implementing the feature. (only 5 lines of code, including the toolkit mime function btw)

I understand (and appreciate) your position on keeping it minimal and maintainable, thanks for providing some deeper insights. I personally would love to see a bit more opt-in settings to prevent ±50% of the users rewriting the same functionality, but with your philosophy we get a more robust base to be customised/hooked. :)
And it's always possible to fork your plugin or extend it with a new plugin to provide extra shared functionality.

Regarding the og:image:type tag, your choice is ours (hehe). Indeed it's not a required tag, but it's a minimal (very maintainable) addition to your code that brings a sense of "completeness" to og:image.
On the other side, as you say, 1 request to the og:image URL and the mime is send in the header, so it could be considered bloat too, not to forget the saved bandwidth if left out.

[fabianmichael]

@Daandelange If there’s any real-world benefit from a possible addition, I am absolutely not opposed to it. Feel free to open an issue or PR if you need a feature or want to contribute, it’s very cool that the plugin is now available in French thanks to your help!

I believe the intended use of og:image:type is to serve the share image in different formats but have not found any examples of that usage. Let’s not forget that OpenGraph was probably designed in a nighthift by some team at Facebook years ago and is probably not as consistent as one might think. Let’s move on :-)