Hi @dan,
wrote a small feedback about the Blog feature in Elements. I am just curious what your plans are related to the server specs. In general for forms I can see third party solutions if someone does not want a full PHP server. But for the Blog stuff I do not see a workaround on that.
Ideally, we wanted to keep it to just HTML and JavaScript so it would run on any server. While that is mostly true, we decided to add PHP into the mix for the form and blog functionality everyone wanted.
As we have the Elements API, Iām confident that some other options will emergeā¦ or you can build exactly what you need.
Hi @dan,
as long as there is a way to get a pagination over a folder of pages then that would work. I played already around with collections and stuff to get that achieved but that ends up in a configuration nightmare. And you would have a single page for all blog entry previews, while if it would be element driven those pagination pages could be create on publish.
Having thought about this a bit more ā if you use consistent and predictable folder naming across your projects, thereās nothing stopping you from creating a /blog folder and using your hooks file to traverse the pages in that folder to generate a blog-style listing.
You could use the Menu Description field (that you can set on each page) as the excerpt for each blog post, and youād already have access to useful metadata like the page name, URL, etc.
Youād have to get a bit creative for features like authors, tags, or categories, but for a simple blog list, this approach is definitely doable.
You could also build a previous/next navigation component using the pages object ā just use a bit of js in your hooks file to find the current page and then grab the pages before and after it.
This approach relies on sticking to a consistent project structure, but if itās for your own use, then maybe that wouldnāt be an issue! 
Hi @ben,
to be honest my main consideration about Elements was so I do not need any of those stuff and thats how classic worked.
If the Blog requires a PHP solution then I can also move my page to a wordpress hosting or anything like that. Main reason for me was to manage it locally.
The only issue that I am seeing at the moment is the dynamic generation of pages or the links. When using markdown files on a server and publishing both, it means as well that I got duplicated content on my server. The only system that I knew so far that let you do the local managing of your Blogs was RapidWeaver Classic so I did not think you would break that unique selling point. Was by the way the main reason why I used Classic 15 years ago, bought it for my dad, wrote him a custom theme and he used it to manage his business page until he retired.
The Menu Description I tried that but that is also used for on page header stuff. If there would be more fields available that are for an offline blog I could definetly write a pagination component. But what is missing is following as independent page props:
Since the component would be custom someone could still use proper design on the props of that component. I hope you could consider an option like that.
By the way those pages below are all template (handlebars) driven I just wanted to avoid to write an interface for it. So far we have been able to recreate all of them within Elements except of the Blog stuff. That is the last thing we are waiting for before going live with the new pages.
I am using a lot github and for that build project pages and so on. Github supports only plain HTML so thats the use case I am having in mind, adding blog features to projects hosted on github.
By the way that capabilty would open also for other use cases.
Product Overview, Custom Testimonials and so on. For me itās not just a blog it is literally anything on a page which is list based.
The blogging system we previewed last week lets you manage your Blog locally in Elements. Create, edit, and publish directly from Elements.
Itās the dynamic display of post listings, individual posts, related posts, etc that needs to be done in PHP.
As I said, if we want online editing capabilities and for others to easily integrate with the blog in Elements, then I donāt currently see a better alternative ā but weāre always open to new ideas or different approaches, so long as itās better than what we have
Thereās just one markdown file per post. No duplication.
Hi @ben,
I will give that blog feature a try for sure.
I got an idea for you guys how to keep it dynamic with all the freedom but support it without PHP but thats a too long discussion to write down here.
Would not even require a major change as far as I understand how it could work. I can prepare something and present it if you guys are interested. Would need a bit time to implement it so.
Maybe I should say it like that. Itās not be a particular Blog component so let us name it differently and I show you what I try to achieve 
actually what you described in the new dev diary video is actually what I am looking for. I created in the example project below a āPaginationā and āEntryā Component. If the page props would be able to hold a besides the icon and additional
Then it would be possible without working with a custom selection. Would be curious how you guys selected that folder in the props. I did that based on the title at the moment.
Its the same concet that I try to achieve but instead of using the icons have access to other meta data.
elementsapp://downloadDocument/a8Dr8rD3OhCz
P.S.: I did not add styling props or stuff like that. Kept it simple for now.
Forgot to mention. If one would use the current meta data description field, it shows a warning when the text is too long.
Yes, weād be interested in seeing what you had in mind 
as I mentioned I wanted to show you an idea. This one works because I used a collection to access that data. But if those props would be on the page props it self and it could be accessed via the hook, that could be used to build pagination over pages together with summaries. Benefit would be, that the data and the pages would not be ripped appart.
At the moment I can not build the component I used without a devpack, because the collection is not fully funtional in custom components. But I can send you the devpack file via email.
I like this idea!
We do want to add some form of project-wide data that could be shared between pages and components ā weāve actually discussed this at length internally ā however, I donāt think itās something thatās going to make it in to v1, unfortunately.
Hi @ben
thats all fine for me. As long as something like that is coming I can work around it in the meantime. For like 5-10 pages doing it manually is fine. Long term that would be annoying.
and 
I donāt want to make any big promises, so please donāt hold me to this!
I think we would like to have something similar to this, but I canāt promise if/when anything like this might make its way in to Elements.