HTMLy: Databaseless Blogging Platform (Flat-File Blog)
github.com
github.com
You will either end up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of SQLite ... or, you will fail to even attempt the features that SQLite gives you - such as locking and dealing with concurrency - and you will have bugs.
For example, you use file_put_contents. See this comment: http://www.php.net/manual/en/function.file-put-contents.php#...
Please don't go and add locking now! (It's hard to get right). SQLite was invented to be a better fopen() - use it! There is no reason not to, if you are requiring PHP 5.3. If you want a simple plain text dump of your SQLite DB, that's not hard to add.
Personally I also use a flat file blogging platform, and I explicitly rejected putting stuff in a database because I want to be able to edit the articles with emacs and check them into a git repository. Concurrency in my case is a non-issue because, well, there's only one of me.
There are plenty of scenarios where you really should not use SQLite nor any other RDBMS because it overcomplicates things that are really exceedingly simple.
This project as it stands, quite frankly, looks like the worst of both worlds.
It's okay if you think like that, but you should try it first and then compare it with other similar solutions (i.e Ghost).
<!--t Here is the post title t-->
For example, Markdown has a special syntax for <h1> tags. It looks like this:
This is a title.
================
Or maybe use the MultiMarkdown convention of colon-separated header fields at the top of the file, like:
Title: This is the title.
Tags: foo, bar
Date: March 3, 2014For the next point as tags, dates, I chose to put it as a filename for the sake of speed.
I'd pondered a flat file based php 'blog' engine once - with all the benefits of markdown or whatever - no database complexity, easily rsyncable for deployment, git can keep revisions, etc...
The problems you have with jekyll, pelican, et al is that you lose site-side search, 'related posts' (without some reasonably complex compile-side clobber), etc. etc.
Using extremely minimal PHP lets you deploy just as easily, you don't get too much of a performance hit (a hell of a lot better than wordpress, etc), you can still do search, related posts, forms, embedding, and all that.
PHP as a server-side 'clever templating' language really isn't that bad. It's only awful when used to build anything massivly complex (such as joomla! or drupal...), and that it encourages messy project design.
I only touch PHP as little as possible, and work with a legacy PHP codebase, but AFAIK, it hasn't evolved a tag to automatically HTML-escape/JSON-escape content. So, it's as good a templating language as it is a programming language: pretty terrible. I'll trade PHP for something as barebones as Python with WSGI + Jinja2 any day.
The fact is that it has been surpassed by Twig, Jinja2, Cheetah, and many other templating languages - which rather proves the point of @mercurial who you're arguing with, which is that PHP is not a great language to use for templating.
And, to be honest, I agree with him, actually. I'd be very very hard pushed to start a new project in PHP. Python+Jinja2 is a much more powerful and sane way to work.
However, as a templating language, for basic blogging stuff, if you're careful, PHP can be made to work, and, on a cheap host, may end up being easier to deploy than a technichally better system.
Just as BASH can sometimes be an easier solution to some problems than python or perl or whatever else. I'd never claim that BASH was a nice language to work in, but for very simple scripting, it can end up being an easier automation system than the alternatives.
- software cannot evolve
- the notion of sanitizing input/output has magically appeared out of thin air in the last 15 years (I'm pretty sure that Perl Mason could do that when it first came out, around the same time PHP did)
Since clearly neither is, attributing the current state of affairs to bad technical decisions early on followed by inertia is the most logical explanation.
It's like comparing Java and C#: C# has managed to regularly introduce interesting features, while Java has stagnated for a long time. Of course it's easier when you start from scratch, but especially for simple features like escaping, which I highly doubt would require major changes in architecture, there is simply no excuse.
Or a Bitcoin exchange
If a tool gets a job done, does the language matter?
No language is perfect. I know PHP feels "dirty" but the misuse of it is likely the cause of widespread disparaging. Even the English language is not perfect. Does this stop you using it?
Just a thought. I tend to close tabs when I come across stuff written in languages I can't write in... :-)
Dynamic generation - make!
https://github.com/jaspervdj/static-site-generator-compariso...
Currently, this listing is for only projects that are either or both a Flat File CMS and Static Site Generator, but not for projects which are only Dynamic Servers (such as WordPress and Ghost).
HTMLy is flat file cms :)
I prefer not to rely upon external comment-providers though, which is why I wrote my own self-hosted comment-server:
I wanted to think that the hurdle is very low. It's a bit higher than just entering text in a text box and clicking a button. But sending an email isn't that hard either.
I received maybe half a dozen emails since I introduced my form of static comments. Most in the form of 'Does this work?'. For obvious reasons I didn't publish them. I redesigned my blog a few weeks ago and didn't add the comment feature back in.
https://caurea.org/2012/03/31/this-blog-has-comments-again.h...
Moving away from the browser to my mail-client to compose things would distract me and cause me to be a little confused.
Other than that it doesn't seem like an unreasonable approach.
As for harvesting email addresses, I think you could solve that by using a CouchDB view, which is essentially a function that processes and returns JSON documents. In this case, it could just delete the "email" key and return the rest.
You would probably still need to block the direct access to the document via frontend proxy, since I don't think Couch allows you to specify fine-grained per-user permissions, which is definitively a drawback.
Alternatively, since you're already willing to send hashed versions of the emails (as Gravatars), you could just store only the hashes in the first place, and never commit the plaintext to disk.
With my thing yes it can be crawled, since requests to /comments/ID will return the JSON comment-data. However there is no enumeration of the valid IDs possible, short of a dictionary attack. (This is where I was thinking that exposing CouchDB might expose more data.)
I did consider not storing emails, and for my use-case that's fine, but I figured sooner or later somebody will want to access them so ruling it out unduly would eventually result in a bug report.
Yes, you'd probably need to block that URL with a proxy, and only allow single page views to be requested. I think this is definitively a shortcoming of the BD; it should allow finer grained permissions.
However there is no enumeration of the valid IDs possible, short of a dictionary attack.
Well, by default CouchDB uses UUIDs, so enumeration shouldn't be possible either. Of course, both are subject to simple scraping of the HTML pages; a simple wget + grep can probably list them all, so you don't gain much, except for private pages you might have.
I did consider not storing emails, and for my use-case that's fine, but I figured sooner or later somebody will want to access them so ruling it out unduly would eventually result in a bug report.
Fair enough. I actually don't think CouchDB, as it is now, would necessarily be a better solution than yours. But the question is, why not? I believe the direction is correct, but the current implementation falls short, and that's a shame.
My blog is flat file because I like to work on a version on my home server, editing stuff in emacs, commit to git and push an updated version atomically. Even if I continue writing at my current pace for the next 100 years, my current server would hardly notice having to re-read every single article.
As for reinventing the wheel, the code for pulling in the articles from flat files and slicing and dicing them simply by iterating over an in memory connection is so small and simple that there's hardly any wheel to re-invent.
still lots of room for experimentation, i would say.
-bowerbird
I can think of a lot of disadvantages with not using an actual database. What's the benefit of going back to flat files?
Edit in your editor of choice. Use your source control for edit history. Trivial to keep a separate instance to edit/test on, and push with rsync. Makes it trivial to treat the code and the content as one unit, so that e.g. if you change parsing of the articles, update the articles and need to revert, you don't need to mess with reversing database updates separately).
Fewer moving parts. For a typical modern blog with comments farmed out to Disqus or similar, the data is likely to be tiny and very static. My blogs data, for example, is about 8.3MB of text that changes maybe a couple of times a month, so the 1-2 second cost of reading every article I've ever written in from individual files on disk is hardly an issue.
But then, when you click "post" it rips through the database using a library of markdown -> HTML or whatever the case may be. Thhere can't be must overheard to a single include to pull in the html, but you could render the enter page. I just can't see php falling down too much with a few includes and functions being called to generate a header, the included rendered HTML, and a footer with some design elements.
It's not much fun building your own database out of flat files. I cut my teeth on a Mac only system that more or less only talked to Filemaker, which was only as fast as the actual screen could redraw and search out the data. It could be painfully slow.
In a way I am glad, as I learned how to do things and think differently when most were just running a "select * from foo where bar = 'x'" which was a 15 minute luxury I didn't have. There were no joins, no tables, you actually ran applescripts on the database and it returned the data somehow back to a web server on the Mac.
So we used the database on the backend, where admins could be more patient, or do more intricate things, but almost always generated out some HTML, so in the end, the site was semi-dynamic. I think I was doing "caching" of data as a result almost 15 years ago.
The rule was, no more than 2 database calls per page, ever. And you couldn't do things like update foo set name = 'me' where id = 1, because there was no exposed notion of a record id, it was internal, so you had to select name from foo where name = 'whatever' which would return the name, but also a RedID value, which you then got to run another query to update foo set name = 'me' where if = <special RecID token>
Made me think a bit different.
HN is apparently flat file based.
I actually have a 100% static site deployed in production. It is served off nginx, built with make, shell and sed (does some include processing and index generation) and is deployed with rsync from make and uses git for version control.
This platform prioritizes writing through the admin panel, the convenience for users, particularly for non programmmer or for those who are not familiar with coding at all.
If you have other views, you can contribute to the project, so that we can discuss it further.