What we're most excited about on the new Community site

Sebastiaan:

"For me it's easy: all the integrations. Picking a single favorite is hard though, because there are so many, but these three stand out for me.

The first is the blog feed submitter. If you run your own blog and want it showing up in our community blog grid, you paste in your RSS URL, get a live preview of exactly how your posts will look, and then submit it for inclusion. One detail I like is the honeypot field for bots: if something fills in a hidden field a human would never see, we just quietly tell it the submission worked instead of showing an error, so it doesn't learn anything from being caught. There's a plain rate limit on the endpoint too, so nobody can hammer it. Once a feed is approved, it lands in the refresh cycle that keeps our community blog cache up to date, which is what makes the next one possible.

Because that same cache is what feeds the Discord bot that posts new community articles into our server as embeds. It's satisfying to see it work: someone submits their feed, a post shows up, and it's announced without anyone touching a keyboard. That same feed also powers UMB.FYI, an external platform, and it's really cool to be able to offer a tight integration like that for something built entirely outside our own team. Bonus info if you love RSS: you can subscribe to the feed directly at https://community.umbraco.com/feeds/community-blogs.xml.

The other one I find genuinely fun is what happens when you hit a 404 on the site. Instead of a dead end, we run a semantic search over the site's actual content, so a mistyped or outdated link still finds you something genuinely relevant instead of a keyword miss. Credit to Søren Kottal for sparking that idea. Getting it safe to run in production took some work too: capping concurrent lookups so bot traffic can't hammer the database, and denylisting file extensions so a scanner poking around doesn't waste a single AI call on it."

Laura:

"One of the things I felt was important on this site was taking the time to write down why the code looks the way it does. There’s a documentation section available on the site that provides “primers” as a grounding in the technologies we used, “foundation” tutorials exploring some of the problems we faced and how we solved them, and “refinements” that build further upon some of those solutions. This section started because the problems we came across were interesting enough to be worth explaining — the specific Umbraco quirks, the dead ends we hit before landing on something that worked, the trade-offs we made consciously rather than by accident. This isn’t a full “here’s how Umbraco works” (the official docs cover that), but the messier, more useful version: here's the specific thing we needed, here are the options we considered, and this is the shape that we settled on.

What I find super satisfying about having it here, on the site itself, is that the code the tutorials reference is the code running right now. When a tutorial walks through how to show filtered blocks in the block list selector or scoped inline SVG styles, that's a real decision that we made, reviewed, and is live on this community site. They aren’t contrived examples either, they’re retrospectives in tutorial form. That kind of grounded, "this is the problem and here’s how we solved it" writing is what I've always found most useful when I'm stuck on something, and when the code is open for all to explore it feels right to open source the thought processes behind it. "