
HTMLy: Databaseless Blogging Platform (Flat-File Blog) - danpros
https://github.com/danpros/htmly
======
spookylukey
You should _really_ use SQLite!

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#...](http://www.php.net/manual/en/function.file-put-
contents.php#82934)

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.

~~~
vidarh
A blogging platform for personal use is not magic. Avoiding things like
concurrency problems in small platforms like this is often trivial.

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.

~~~
yen223
If you don't want to use a database, go for one of the many static site
generators. That way, you won't even need to muck around with PHP.

This project as it stands, quite frankly, looks like the worst of both worlds.

~~~
danpros
> 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).

------
kijin

        <!--t Here is the post title t-->
    

I hate non-standard stuff like this, even though I myself do similar things
all over the place. It's the kind of the thing that's OK if you do it to
yourself, but immediately rings an alarm when it is distributed to the general
public. When you're already doing something non-standard by using a flat file
instead of a well-known DB format, you might as well use standards in other
places so that people have fewer reasons to complain.

For example, Markdown has a special syntax for <h1> tags. It looks like this:

    
    
        This is a title.
        ================
    

Since it is extremely unlikely that an <h1> tag will be used for anything
other than the title of a post, why not use it to mark a line as the 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, 2014

~~~
danpros
The initial version was using a standard markup for the title but I change it
due to avoid if there is a double h1 :)

For the next point as tags, dates, I chose to put it as a filename for the
sake of speed.

~~~
kijin
In HTML5, it's OK to have multiple <h1> tags in a page, provided that they
belong to separate sections, articles, etc.

~~~
danpros
If you try it, you will realize that to write an article using the admin panel
is quite user friendly :)

------
hayksaakian
Don't take this the wrong way, but why PHP?

~~~
noonespecial
Outside of "the bubble" the web is basically made of php and perl. Its like
the dark matter of the internet. If you want to reach all they way down to the
weekend dabbler, you really need to choose one of those 2, and of those 2, php
seems more immediately accessible.

~~~
codygman
Sadly the web is made up of a lot of php code. Luckily this graph lets me
sleep better at night:

[http://www.indeed.com/jobtrends?q=php&l=&relative=1](http://www.indeed.com/jobtrends?q=php&l=&relative=1)

~~~
vidarh
I think you'll find that graphs like that are meaningless. I work for an
agency that does mostly PHP work, and we _never_ advertise, because for common
skills like PHP, recruiters and potential hires inundate us with calls every
single day. I expect the very common skills like PHP are severely under-
represented in ads for this reason. For less common skills, you need to
advertise, as people won't know where to go.

------
est
Next step: on-demand flat files which is dynamically generated and has an in-
memory cache !!!

~~~
bananas
Already got that. It's called the OS buffer cache.

Dynamic generation - make!

------
sankethkatta
we can add it to the list:
[http://staticsitegenerators.net/](http://staticsitegenerators.net/) :)

~~~
pipeep
I don't think it's a static generator as there's no compilation step. Rather,
they just replaced the database with file lookup. The server still needs a php
interpreter.

~~~
fahmi182
Should be added in
[http://staticsitegenerators.net/](http://staticsitegenerators.net/)

[https://github.com/jaspervdj/static-site-generator-
compariso...](https://github.com/jaspervdj/static-site-generator-
comparison#requirements-for-additions)

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 :)

------
stevekemp
The biggest problem with static blogs is the lack of comments. I see this
project uses either facebook or disqus which is a solution a lot of people
like.

I prefer not to rely upon external comment-providers though, which is why I
wrote my own self-hosted comment-server:

[https://github.com/skx/e-comments/](https://github.com/skx/e-comments/)

~~~
wereHamster
I use jekyll for my blog and looked for ways to integrate comments. I ended up
with a simple solution: Provide a per-post unique email address where people
can send comments to. The idea was then to manually process the comments and
only put the most useful ones on the website.

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...](https://caurea.org/2012/03/31/this-blog-has-comments-again.html)

~~~
stevekemp
I find that a very interesting solution, but I suspect I'd not use it in
practice (to submit comments).

Moving away from the browser to my mail-client to compose things would
distract me and cause me to be a little confused.

------
themichael
We use BitNami and Wordpress to generate static files. Works great. Paired
with cloudflare, the site is faster than 99 % of the web (according to
[http://tools.pingdom.com/fpt/](http://tools.pingdom.com/fpt/)).

------
w4rh4wk5
I created a similar project, you might want to have a look at it
[https://github.com/W4RH4WK/Phoenix-Tpl](https://github.com/W4RH4WK/Phoenix-
Tpl)

------
MrBlue
How does this compare to
Dropplets?([https://github.com/Circa75/dropplets](https://github.com/Circa75/dropplets))

~~~
danpros
Read this section [https://github.com/Circa75/dropplets#writing-
posts](https://github.com/Circa75/dropplets#writing-posts) HTMLy no need
complicated stuff like this :)

------
evacchi
well, let me add my old project [http://flatpress.org](http://flatpress.org)
it does feel dated, as it uses BBCode, but there plugins for Markdown. If I
had the time, I would make MD the default nowadays.

~~~
danpros
That is a great project, before make this things I already try yours :)

------
ivanhoe
Never really understood why people try to avoid DBs? It's OK for a very basic
pile-of-online-texts blog, but the moment you try to show whatever relation
between blogposts (e.g. the related articles or the latest articles) you end
up reinventing the wheel

~~~
vidarh
Most blogs are small enough that caching all the content in memory and
sorting/selecting is so cheap and simple it really makes no difference these
days, and you gain simplicity.

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.

------
bowerbird
i'm glad to see there is a pleasant range of disagreement on some of the
crucial dimensions running through this...

still lots of room for experimentation, i would say.

-bowerbird

------
yen223
Replacing the database with flat files? We have gone full circle, haven't we.

I can think of a lot of disadvantages with not using an actual database.
What's the benefit of going back to flat files?

~~~
sheraz
I wonder what simple blogging / CMS engines are out there that use sqlite as
the backend. This also has the benefits of simple backups without the
complexity of another process running. Most (if not all) webhosts will have
this baked into their PHP installs.

~~~
biturd
Perhaps using sqlite as the "backed" in that you build it like any other blog,
so you get the simplicity of building it out, using one good sql framework
etc.

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.

------
gararapa
Why are you versioning the dependencies?

~~~
danpros
Did you mean the PHP 5.3? There is a library that requires PHP 5.3 or greater.

~~~
gararapa
No. I meant the dependencies contained in vendor/ directory. And the
composer.phar file itself. Is there a reason why you're versioning these
things?

~~~
danpros
Basically I just want all dependencies works as well as when I test it, and in
accordance with the guidelines getcomposer.org :)

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.

