dump
Created initial scaffolding.

The spec hasn't been changed (there are going to be some additions soon-ish),
but I've started work on making this a reality.

Anyways, right now, there's a mysql schema (only for mysql) that you can use
to insert into a database and have the basis of what's needed for Branch.

Change might be made to the schema, so, beware...

I'm attempting to use object oriented php as opposed to my previous PHP
excursions, which should hopefully make things better.

A future hope of mine is that by the end, the entire database will be
abstracted away and the entity classes will perform most of those actions. I
really like how Django and Rails do this.
password spec?
More Updates!

So you can now create a user in the database.

The Users class is mostly static, being that I want one to call `Users::foo`
to do things. There's a DBUser class which will be the object that gets
manipulated by people (as in DBUser->changePassword, etc). Users is just for
global user-y things (for now).

Passwords are salted and hashed (hashed a lot). So guessing a password and
attempting to brute force your way in will be a little hard.

The DB abstraction layer, BranchDB (okay, not all that abstracted, but a little
abstracted) automatically processes queries and safe-ificates them. Which is
good.

There isn't anything else it can do besides create a user, but that's enough
for now, right?
Users can login!

And it works! Well, it returns true or false if the username/password combo is
correct.

I'll add how the passwords work to the password spec eventually.
Changed how login works, started on a playground

The old Users::login function is now Users::isPasswordCorrect (okay, I'm
probably going to change this to Users::validatePassword, but I didn't think
of that name at the time when I changed it). The new Users::login is the start
of a framework to generate a session that declares that you're logged in.

Speaking of sessions, while I haven't started working on that yet, they're
probably going to be their own class, just to make things easier on myself (I
hope?). I'm not quite sure yet...

So, don't actually use Users::login right now, just use
Users::isPasswordCorrect (that should probably be private, but, I'll get
there).

As for the playground, there are two new files called playground.php and
ajax.php. playground.php is the page for actually playing around in the
browser to see if things work. Right now it has two forms: a create user form
(which works); and a log user in (which worked, until the Users::login change,
which I'm currently working on).

ajax.php is the page that ajax request are made to from the playground. One of
the big Ghost features that I really like was the previewing everything before
performing an action, which to me says ajax and potentially pushState (but
mostly ajax to get data and such). I think that having a page specifically for
processing requests is okay.

It isn't secure though (yet?). As a part of the session stuff (which is what
I'm going to work on next) is securing the site as much as possible. After
sessions are put together, I'm going to work on having playback require a
login (or, have a variable switch, I'll build an installer later...) to access
it.
Made BranchDB and Config classes static

This has been done because they don't change except for when they're first
initialzied (the initializer is the init() function, which is called after the
class declaration), and we don't need a bunch of scattered BranchDB and Config
objects running around, now do we?
More playground stuff.

Sessions are now a thing. They're a fairly simple abstraction layer for
$_SESSION, but, as your sterotypical programmer, I like abstractions...

This means that there is logging in actions to be had! Well, it kinda/sorta
requires that you have a user in the database. If you're going to try to run
this on your machine, you should comment out the if logged in parts of the
user creation, create a user, and take the comments back out.

User creatation will eventually have a security layer, most likely in where
it's called (well, actually, having it in the function itself means that if
plugins are eventually supported a plugin can't just call Users::create(...),
so, this is something I'm going to need to think about).

My next task is actually making posts. This'll be fun, right? Especially if
you consider how I'm going to store posts (each post has a file on the server
which has a copy of the database's contents in yaml (with tags expressed as an
array) and the content of the post itself in markdown). So, fun times are
ahead...
Hey, there are posts now, kinda...

All posts can be queried (but not specific ones, yet). The scaffolding for
getting specific posts is done, I just need to apply them...

Posts are done using a hybrid database/file mechanism. My thinking here is
that by putting the contents of the posts (and duplicating their database
information in yaml frontmatter) sites are infinitely more portable, post
contents are safter from sql injections (I'll probably explain that more
later).

Eventually and import tool will be built, but that's a task for much later.

I should add a pre-commit hook to export the database's sql for people to use
while in development...
updated directory structure
Added in database.

It should do this automatically from now on
update db spec to show there is an sql dump
wrap password code in php tag FOR SYNTAX
minor tweaks and such
Posts, they happen now.

Posts are now a thing, and they can be created and deleted (just check out the
playground!).

Tweaks have been made to things, but nothing major, mostly additions of find
queryies.

BranchDB now displays the error message if an error occurs. It's a good thing.
pre moving?
Moving towards final directory structure
Added in jQuery UI, started working on theme

Added in jQuery UI because I wanted to make something shake (I know, I could
probably have done it myself fairly easily, but I may want some other UI
things later (if I don't, I'll get rid of jQUI).

I also started working on the "real" theme, as in the one that people will see
both when they visit the Branch website and when they install it for the first
time.

This will probably be the theme most users stick with, because I don't really
know if anybody will *want* to write themes for Branch.

I hope to make this semi-professional and nice looking...
no more sass-cache and also, a gitignore!
spec updates