It's not that other platforms suck, it's just that so many pop up that don't address what I think people really want: something that's easy to use, nice to look at, and not bloated. A lot of newcomers are missing key features, aren't aesthetically pleasing, or are geared towards devs. Postleaf tries to find that perfect balance :)
I mean, you've described vanilla WordPress and most vanilla blogging platforms (easy to use, nice to look at, and not bloated). It's only when you need functionality outside of the vanilla features that things get hairy. If I need to extend PostLeaf in any way, it will probably end up a bloated ugly mess too, no?
Maybe blogging platform weren't meant to be extended in the end. Like, don't use woocommerce, use a blog and an online shop instead and ask for both being accessible with the same credentials.
I think a blogging platform should have that capability, but we've grown accustomed to "themes" being frameworks and plugins being apps. My ultimate goal is to design themes, not develop them, and to write plugins that extend various parts of the app, not pile entire new apps on top of it.
A lot of people would argue that vanilla WP is still somewhat bloated and not super nice to look at. These are subjective statements, sure, beauty is in the eye of the beholder. It never hurts to have an alternative. Competition encourages innovation :)
Sure, but in doing so, you're accepting that readers will be looking at what you present within the frame of certain parameters. I agree with the title change. (ctrl-f for 'suck' on this page of comments.)
You kind of are though. You could've gone with a whole slew of different things but by saying "that doesn't suck" it implies that other things that are used for blogging do. It doesn't have to imply that but that's the connection most people will make and why we use phrases like that. You wouldn't go with "that like all the other solutions doesn't suck either", that doesn't set you apart in any way.
If you want to distinguish yourself then say what you are good at, what makes your experience better/different and to what kind of users this solution is tailored to.
That's true, and it was a bad decision in hindsight. In my defense, I've submitted to HN before and never really saw results after dwelling for an hour over the title. I just typed something and hit submit, what luck, eh? Thanks for looking!
Nice work on the site. I'd give the software a shot on my own server but its sort of hard to give up the WP ecosystem. Any import capability for messages and categories?
Yes, it's an uphill battle. I'm not trying to chase WordPress, though — just provide a good alternative for those who want to get back to blogging. No categories, only tags. I think having both is redundant for the scope of this project.
What's really needed is a WYSIWYG GUI editor that exports all (custom and editable) fields to JSON, so you can use something like Middleman to generate a static site based on that content.
This way, anytime someone updates and saves content through the GUI, a script will trigger and re-build your static site based on the new JSON file, and publish to s3. To completely decouple the editing experience (and those who create and maintain content) from the actual design and code, is the real ticket.
Agreed. I had a project recently and was looking for something like this. There are "API first CMS" systems like Contentful and Prismic that could allow this, but they are paid services. A cool open source version that has plugins for middleman and other static site generators would be really cool.
I think what you're referring to is called a "headless CMS", which is an interesting idea and something we can discuss as the project evolves. It may not be a good candidate for core, but a plugin that outputs the data in the format you're looking for wouldn't be that hard to build (once plugins land).
For example, the existing internal API has a backup method that exports all MySQL tables to JSON files. The heavy lifting is already done for you. (It also wraps all your themes and uploads into a TAR along with the JSON files so you have a real, full backup — not just your post content.)
What you describe closely resembles Webhook (webhook.com), where the CMS updates Firebase, which spits out Json, triggering a build and a static site on Google cloud storage.
Screwed up on the initial post and it wouldn't let me resubmit. Noob moment.
Handlebars because PHP isn't great for webpage templates. There are many alternatives, but handlebars has implementations on many, many platforms. It makes the project easier to port to other platforms in the future.
So far I've got database errors and a douchey landing page that tells me all about how Postleaf has no truly differentiating features and then asks me for money.
After going to the "Features" page and reading through it, pretty much every feature highlighted is something that almost every other blogging platform has as well.
I commend the author for the design, though. It certainly looks nice.
My droplet's getting slammed. Don't knock it until you try it. I'm not expecting much money from donations — it's there for those who ask for it, which is my experience for other open source projects I maintain. :)
In any case, I for one do still immediately drop interest in a project when I see that it is implemented in PHP. (Unless it's a vulnerability scanner designed to operate on PHP source!)
I copy/pasted that section from your readme to save others time. I am certain that I am not the only one not interested in a PHP blogging platform.
Not bait, just curious as to why you'd say that and didn't want to make any assumptions.
Sure, I could have built Postleaf in Node, for example. It's all the rage these days. I even considered it, but then I considered my end users who (sadly) still have trouble setting up a basic PHP app on a shared LAMP box.
I think part of the allure with Postleaf is the ease of use from the initial install all the way to publishing a post. If I had chosen Node, most of my target users wouldn't have been able to install it. Sure, I could have taken advantage of that to offer paid services that do it for them, but that's not why I developed Postleaf.
The choice to use PHP wasn't me sitting on a platform high horse, it's just what's available pretty much everywhere TODAY. It's also convenient that they're already familiar with the stack. That may change in the future, and Postleaf will pivot accordingly, hence why themes use Handlebars, not Twig or another platform-specific template system.
That PHP+MySQL apps are universally terrible is very subjective. You can build shitty apps with any language :)
What's this issue people have with PHP? It might have bad things but it IS powering hugely successful businesses. If you don't like it then don't use it, but if someone do like it - why not let them?
This looks nice. Would you consider adding Micropub support (https://www.w3.org/TR/micropub/) so that someone could use this editor with their own blog backend?
For example, I have my own software that runs my website, and I've spent a lot of time making it work exactly how I want. But, I'm not the best at building editing interfaces, so I have avoided building an inline posting interface. I would much rather use a tool that someone has spent a lot of time making work well, if it can save articles to my own website.
55 comments
[ 2.7 ms ] story [ 109 ms ] thread* unmaintainable / poorly organized code == suck
* untested code == suck
* easily spammable == suck
how many answers you need? because i can do this all day...
> Unable to connect to the database: The database is not responding. Is the host correct?
Well it's a good this blogging platform doesn't suck.
If you want to distinguish yourself then say what you are good at, what makes your experience better/different and to what kind of users this solution is tailored to.
That said, it does look very nice.
PSA: if you put open source in the title of your product but don't put a link to the source on your front page, you are doing it wrong.
Anyways, the link to GitHub will be on the homepage soon. As I mentioned earlier, the org repo didn't even exist until late last night!
This way, anytime someone updates and saves content through the GUI, a script will trigger and re-build your static site based on the new JSON file, and publish to s3. To completely decouple the editing experience (and those who create and maintain content) from the actual design and code, is the real ticket.
One day when I get some more time...
For example, the existing internal API has a backup method that exports all MySQL tables to JSON files. The heavy lifting is already done for you. (It also wraps all your themes and uploads into a TAR along with the JSON files so you have a real, full backup — not just your post content.)
I'd love to explore this more down the road :)
Why oh why handlebars?
Also, why submit the .net if it just redirects to .org?
Handlebars because PHP isn't great for webpage templates. There are many alternatives, but handlebars has implementations on many, many platforms. It makes the project easier to port to other platforms in the future.
"doesn't suck"
After going to the "Features" page and reading through it, pretty much every feature highlighted is something that almost every other blogging platform has as well.
I commend the author for the design, though. It certainly looks nice.
Maybe you are suggesting that PHP+MySQL apps aren't universally terrible. In this case, please state that and defend it.
Or you are unaware that PHP+MySQL apps have a history of being terrible. In this case, I am not sure what to say.
I copy/pasted that section from your readme to save others time. I am certain that I am not the only one not interested in a PHP blogging platform.
Sure, I could have built Postleaf in Node, for example. It's all the rage these days. I even considered it, but then I considered my end users who (sadly) still have trouble setting up a basic PHP app on a shared LAMP box.
I think part of the allure with Postleaf is the ease of use from the initial install all the way to publishing a post. If I had chosen Node, most of my target users wouldn't have been able to install it. Sure, I could have taken advantage of that to offer paid services that do it for them, but that's not why I developed Postleaf.
The choice to use PHP wasn't me sitting on a platform high horse, it's just what's available pretty much everywhere TODAY. It's also convenient that they're already familiar with the stack. That may change in the future, and Postleaf will pivot accordingly, hence why themes use Handlebars, not Twig or another platform-specific template system.
That PHP+MySQL apps are universally terrible is very subjective. You can build shitty apps with any language :)
Why? Is it because this dev is clearly trying hard and looking for support?
I'm GIVING support. Much, much more than I got when I was searching altavista for information about how CGI works.
I don't recommend using PHP for your next project.
...nope, sorry. Web server agnostic or I won't even consider you these days.
For example, I have my own software that runs my website, and I've spent a lot of time making it work exactly how I want. But, I'm not the best at building editing interfaces, so I have avoided building an inline posting interface. I would much rather use a tool that someone has spent a lot of time making work well, if it can save articles to my own website.