Dev Diary Ep75 - Blogging Preview

Elements Dev Talk
22

Hey everyone,

Thanks so much for all the feedback, it’s been great hearing what everyone’s hoping for from a lightweight, markdown-based blogging system :laughing:

I sat down with @ben this morning, and we went through each post in this thread. We took some notes, and I’ll do my best to summarise everything below. Here goes…

1. Online Editing / Client Login

The good news: all blog posts are just Markdown files in a folder on your server. So, in theory, anyone could create an admin back-end to manage them ( write, edit, publish, the works).

And yep, you can simply upload Markdown files to a specific folder on your server, and they’ll magically appear as new posts on your site. You can even link to online resources. No RapidWeaver required.

One of our main goals when building anything for Elements is to keep it all as flexible and as open as possible.

So… what about online editing? Well, what @ben demoed is just half of the story.

Yes, online editing is part of the plan. Once it’s ready, it’ll let you (or your clients) log in and add/edit posts from anywhere, on any device.

Right now, we’re focusing on getting the front-end polished so you can start blogging locally. The back-end editing tools will come later, as a separate set of components. All components will be included in all versions of Elements, but there will likely be an extra ongoing cost for the online editing functionality.

2. Adding images and videos

Yes! You’ll be able to embed images and videos using standard Markdown, you’ll just need to make sure you know the resource name, and Elements will handle the rest of the path.

That said, we know some of you will want a bit more control over how images and content are displayed. So keep in mind: this is Markdown-based, and there are a few limitations. For things like image alignment, you’ll need to wrap elements in a bit of HTML/CSS (or Tailwind classes) as needed.

Markdown is awesome, but working with plain text files always comes with trade-offs. That said, we’re aiming to keep things as smooth and flexible as possible.

3. Open Graph Support.

Yes, we’ll be generating Open Graph tags from the post content automatically. :victory_hand:

4. More Features!!!

Things like showing related articles, post authors, and generating RSS feeds are on the roadmap and all doable. Keep an eye out for next week’s update to see what we’ve managed to tick off.

Phew… did we miss anything?

We’re not going to promise the moon on a stick :full_moon_face::lollipop: but just like all the other features we’ve built with your feedback, we’re going to do our best to create something we all want to use.

I hope this post covers everything. If I missed your question or you want more detail on something specific, just reply here and I’ll do my best to help :blush:

Thanks!

6 Likes
23

I realize that Markdown itself can support embedding. The issue is aligning the stored image/video with the “file” within Elements. The minute we have multiple programs necessary to do the work, it becomes less “bloggy” and more “codey.” Also, the tendency will be to end up with a /Media folder that just sprawls out of control.

24

I would also add: this could be a “for sale” extra, either by RW themselves or working in conjunction with another developer.

I’m starting to worry that Elements is going to “do everything.” While ultimately I suppose that’s a good goal, it’s a goal for Version 3.0 and the entire web of add-ons, themes, and supplements. What Dan proposes for blogging is a good “base case,” and if extending that into a full static CMS system requires other apps/components/etc. for cost, I’m fine with that.

25

Sounds good. And as I noted elsewhere, the basic blog function you’re defining is probably fine for Elements 1.0, and if we have to pay for the Online Editing function component/app, that’s fine, too.

I did have one other comment after looking at this again: the current “name” of the file is a date/time. As menus get extended into more function, I’d like posts to be menu-able. Is that just putting a MENU: NAME addition in the Markdown header? Summary: seems like there needs to be a connection of posts to menu that isn’t currently clear to me.

26

No, you’d have to manually create those inside of Elements. You can use the new “link page” feature to create those.

27

Can you clarify the correlation here ? Will something be on your servers connecting to ours? :thinking:

28

We’ve not written the back-end components, and the exact scope is currently in flux, so I can’t give you a definitive answer. Right now my gut feeling is no, our servers won’t need to connect to yours.

29

I’ve been using RapidWeaver since the beginning and have invested quite a bit in add-ons that have now disappeared without warning—like Elixir and Stacks4Stacks.

What I want now is a development platform backed by a solid company—not a one-man-band—and built for the long term.

Realmac Software, as the maker of Elements, is the company I want to trust. But for that, Elements needs to be more self-sufficient. I’d gladly pay for official plugins or extras, as long as they’re reliable, well-supported, and part of a broader ecosystem that meets today’s web development needs.

3 Likes
30

Both the markdown files and the resources (images, video etc) you can embed, are just files on a server.

You could build (or have built) a front-end for your clients that allows them to upload resources to the file structure, and then allow them to embed them using markdown. This is how Alloy did things, and how Poster 2 does things in the RWClassic eco system.

You won’t need multiple programs - you just need an editor page. You can, right now, using Elements, build an admin page using Sitelok (Sitelok is compatible with Elements). All we need to complete the equation is a few elements that you put on that page, that allow the user to upload these files.

If Realmac doesn’t build this, I’m sure someone else will. And perhaps there already is a solution out there for Tailwind that you can just paste in (I’ve not looked).

Cheers,
Erwin

1 Like
31

Right. What I see is a standalone Markdown app that knows how to put the blog files in the right folder, and any embedded image/video files in a /media folder. It doesn’t even have to be online while writing a new post. It could simply have a Post button that causes it to log into your server and add the proper files. (Actually, doesn’t even need to do that; could just Save into the Elements folder structure, and posts go live next time you upload the site.)

32

One last bit: some Markdown editors support tables. Is this part of RM’s markdown engine?

33

Perfect for building a template and then just blogging. Simple and hands off. Spot on!

34

Good to hear all features blog is coming in elements thanks @dan and your team

1 Like
35

Hi @dan,

have been on vacation and missed the initial update on this. I did not yet get to read all of the text but in general what I have seen I agree with Image support and so on and I love that this is getting into shape.

That been said I am having only one major concern, since @ben mentioned based on PHP and markdown

PHP Requirements

Does that mean I require a PHP server?

I loved in classic that the blog was managed by Classic and I could use stupid plain html hosting for my content. The unique selling point for Elements or Classic for me at least was that a non IT person can create a webpage and I can use low tech backends. So my hope / concerns for the blog system is just a requirement for PHP on the server site. Since Elements is doing the publishing it would be possible (?) to just generate all pages by elements and have them being static html. Even the approach you showed could do that. Instead of .md file use a .blog which could be a differently named md file. And then just process them into .html. Not sure how you do it for now.

Currently I am managing my pages based on handlebars and pug. To generate dynamic content via Node.js into static files. That approach is good enough for me as an IT person, but not for a non-Programmer. Also plain html hosting is cheaper then PHP because mostly they pack a Database with it and I rather spend my money on something like Elements then on the server.

If I am not using a backend, I do not need to worry about security of it.

You guys have already collections which can be used to gather data. So from what I am seeing what is missing is a way to get a collection or any collection and throw it into multiple pages :smiley:

But yeah not sure how it works but I hope the blog solution wont be a PHP MUST HAVE, since that would be a major show stopper for what I am trying to achieve. Because in that case I can just wrap a database behind it.

That been said, I could still work on single pages and use those as blogs, would have been just more handy to have the linking automated.

P.S.: Online Editing would have the same issues. Increasing the backend requirements.

36

I would say, this is even better than creating some sort of web interface to manage blog posts. I guess this means that I can use any markdown tool to create blog posts, like Ulysses, and save the md files in to an elements folder? If so, that’s fantastic, and would be even easier for a client to use. In theory a client could then use a common tool like Google Docs to create blog posts, and no need for them to learn yet another system.

37

Totally agree, it’s a nightmare re-installing Rapidweaver everytime I upgrade my platform and trying to find and update all the stacks that I had installed before.

1 Like
38

Testing the new blog listing functionality, this is just a simple example…

It’s fun to build this visually in Elements :blush:

2 Likes
39

Yes, the blog will require PHP.

In theory, yes—but if the blog is intended to support online editing, either built-in or via third-party integrations, then generating pages dynamically (i.e. on-the-fly via PHP) is the most practical and scalable solution.

The approach we’ve chosen (Markdown and PHP) means anyone can integrate with the blog system by simply reading and writing markdown files in the appropriate folder.

That’s the Power of Elements: an open, flexible system that’s easy to build for and integrate into :grinning_face_with_smiling_eyes:

If PHP is a blocker for you, there are other services—like DropInBlog—that allow you to embed a blog system into your site without PHP.

While it won’t offer the same level of integration within Elements, it’s a good alternative for “must-not-have-PHP” setups.

Absolutely! You can manually create and manage blog-style content using individual pages within Elements. That approach can work really well for smaller sites — obviously you just need to mindful that as your site grows, it could become difficult to manage.

40

In theory, yes! You could save markdown files directly to a folder on your server.

I’m pretty sure this is how the blog will work, however, keep in mind that this is an early preview and things can change as we build out the blogging system :slight_smile:

41

Extra ongoing cost.. there will come a point in some years when all this “extra ongoing cost” along with the subscription cost of software that wasn’t supposed to come with “extra ongoing cost” will add up for users, and the very ones who currently think they’re getting a great deal in comparison to classic RW and Stacks, will realise that all this has caught up with them in the end, and maybe their pockets are emptier than they would have been, had they paid once for RW and whatever Stacks they use.

1 Like