What's in my forks, and what might be worth bringing upstream

[rmdes]

I've been running a heavily modified Indiekit for a while. Rather than keep carrying the forks quietly, here's what's in them — partly so I know which ones can be retired, and partly because some of it might be worth having in the project.

Happy to be told no on any of it. That's useful too: it tells me a fork is permanent and I'll stop treating it as debt.

Writing posts

A real markdown editor. The post form uses EasyMDE with a floating selection toolbar — select text, get formatting. More usefully, the toolbar has a media browser: you can browse everything you've already uploaded and insert it while writing, instead of leaving the form to find a URL.

Multi-file uploads. Upload several files at once rather than one at a time.

Category typeahead. Start typing a tag and get suggestions from what you've already used, so your taxonomy stops drifting into indieweb, IndieWeb and indie-web.

Content warnings, pinned posts, layout hints — additional controls in the post form's advanced section.

Finding posts again

The post list becomes usable at scale. Filter, search and sort. Once you have a few thousand posts, the current list is difficult to navigate.

Older posts stop 404ing. Post lookup goes through MongoDB _id rather than a ?q=source round trip — this is the bug @eclecticpassions hit in #843.

Permanent delete and bulk purge for soft-deleted posts.

Syndication

Reply to anyone, not just your own instance. Today, replying to a post that isn't on your own Mastodon server throws and the whole syndication fails. The fork resolves the remote status through Mastodon's v2/search and threads to it properly. RSVPs too, since they carry in-reply-to.

Opt in or out of external likes and reposts — the configurable behaviour I mentioned in #843.

Bluesky posts get rich previews. Link facets so URLs are clickable, OG card selection, reply threading with root/parent resolution.

Webmentions

Moderation. A blocklist by domain, hide and unhide individual mentions, and a dashboard. Spam webmentions are currently something you have to live with. There's also h-card discovery, which fills in author avatars that webmention.io returns empty.

This one is the biggest departure — it stores mentions locally and syncs, rather than reading through to webmention.io. More a feature proposal than a patch. I've written 99 tests for it.

Under the hood

Service worker fixes. Auth and preview pages no longer get cached, which was causing stale login state. Cross-origin requests are skipped rather than intercepted. Stale-while-revalidate with update notifications.

Micropub query filtering by category and search term.

Syndicator update/delete hooks — the CRUD idea from #581, so a syndicator can react when a post changes or is removed, not just when it's created.

Where things stand

endpoint-auth and endpoint-syndicate are nearly retired already — most of what I carry is merged or in #884, #891, #893. endpoint-files, endpoint-share and preset-eleventy are small and mostly additive.

The bigger ones — frontend, endpoint-posts, syndicator-bluesky, endpoint-webmention-io — replace upstream logic in places rather than only adding to it, so those are conversations rather than patches.

I'll keep this updated as things land. Tell me which of these you'd actually want and I'll start writing PRs with tests.

[eclecticpassions]

Thanks @rmdes for sharing your extra features and fixes. I would appreciate any extra features for the Markdown editor and the auto complete with existing tags (I've set up the json list of all my categories (ie tags) used in the config but it never worked).

I actually have a question about the editor not sure if you fixed it in your fork? There are red squiggly lines for what it thinks are spelling errors (eg US vs GB spelling, or genuine typos) but right clicking does nothing and I can't turn it off. I tried messing in Firefox about: config (turning everything related to spell check off) but I don't think it's related. These red lines only show up in the Indiekit Markdown editor text field.

And running your plugin in the meantime to fix the 404 on old posts and getting the content sort has been great! Would love to see it in the official plugin. Thanks for everything Ricardo. 👍

[rmdes]

In relation to markdown editor improvements, I have this :

this means I can write a long form article and I can invoke some basic formatting right from the selection, no need to go up the page to reach basic tooling, also, there is a new button next to image/media upload, which allows you to browse existing media files server side and insert them directly on the current text, its quite handy !

in relation to the red squiggly lines - I think these appear because we have spellcheckers enabled on our browsers, this is a "client" / browser config, nothing related to the editor in itself, but I do agree its confusing, even with the spellchecker properly configured, at least in Vivaldi browser, I can see errors but when I right click I don't have any suggestions to fix the error, this is confusing for me too

Honestly, If I could choose, I would migrate to something like Carta https://beartocode.github.io/carta/ because I think this markdown editor is just much better, minimal, slick, extendable with more plugins, but that's a different path than a improvement of the existing markdown editor and its Svelte related, so not sure this could fit indiekit, but there are other markdown editors out there

And in relation to categories suggestions, what I have now allowed me to merge a lot of duplicates categories I had created over the last few months with different spelling, having it suggest when I start typing is a real improvement worth bringing to indiekit !

[rmdes]

Another change I would love to see upstram is the vertical menu in the indiekit backend :

This is not an issue when you use Indiekit core, but the moment you start using more plugins that have a backend admin config setting you quickly find yourself filling the horizontal default menu until it becomes a big mess, my fork of the frontend package propose a vertical menu but i think it has room for improvement, the way plugins register their menu is one of the area it could be improved

[rmdes]

Another aspect I have not included in the table in the OP is my homepage plugin and site-config plugin, together they allow me to configure h-card, site identity, default opengraph image, default user image and many other aspects

This one below is tightly integrated with my eleventy theme, but its really nice to have :

it allows me to change the colors, and other configs (typo etc) without having to change the code, its not stable code tho, its very experimental, my idea was to test the idea of providing a "universal" indiekit theme that users could tweak for their taste without the need to touche the code, its part of the homepage plugin, which allows me to control how the content is rendered, again, without touching code :

this allows the user to re-order widgets in the sidebar, in the main section area, for the homepage but also for post-types (tho this is still in development) my idea was, how do we bring something like "block editor" found on wordpress (elementor and other comes to mind) but without a super heavy bloated block configuration system, I wanted something simple, that could govern how Eleventy would behave, from a UI configurator.

[paulrobertlloyd]

As a broad sense of direction, and for getting to a place where we can release v1.0.0, I would prioritise as follows:

1. Bugs - fixing anything that is clearly broken
2. Documentation - making it easier to get started with Indiekit
3. Foundations - addressing long running sores like the MongoDB dependency and handling mismatches between what’s in the database and what’s saved to a content store
4. Compatibility - improving compatibility with supported specs (such as IndieAuth and Micropub) and syndication targets
5. Protocols – adding support for protocols Indiekit currently lacks (such as Microsub and Webmention)
6. User interface improvements

On that last point, I’d like to transition the frontend to use something like Web Awesome. That would mean this project no longer needed to build and maintain it’s own suite of frontend components and patterns. It may also make it easier for plugin authors to provide extensions to the interface.

There’s likely an unending category of improvements that can be made to make Indiekit a full-fledged CMS, and maybe that’d be welcome over time. But it could also be a distraction. I’d be open to revisiting this once the foundations – including an extensible UI framework – are in place.