KingWarin.de

Ok, now the serious stuff starts.
I’m actually writing code now (or try to do so)…

As I haven’t done all the planning in advance, there was a little problem something like an hour ago:
Where to start?
First thought: Go for the home page… just add a data-sample to the db, mix in a sql-statement to fetch that data and then go for the nice looks. – Wait, this is not what I want to do, the „nice looks“ (I smell CSS…) is something which will take place pretty much in the end.

Ok, think again, where to start? Think. Think! THINK!
Where do you start if you want to write a new blog-post?
– Most likely it’ll be the login-page, so maybe that’s a good start.
So first of all I created a sample login-page which really just consists of a headline, a textinput for the E-Mail address, another textinput for the password and a submit-button.
For creating the script this will work out. There is no JS for hashing the password prior to sending it, no css, no nothing. But that’s fine.
For now I can add a line in the script that takes care of the hashing.

Second thing I started on is the processing of the login.
First I want to check whether the variables are received by the script and well, half of them are.
But why just half of them?
Mail is received, password is not even on the request… double checking the server config (and quite everything else I could figure out) left me with a non-working script yesterday.
I even tried changing the html-input type from password to plain text – still no values.
So I saved everything and took a rest, went to work, came back home and sat at the problem again.
Wasting half an hour checking everything (again!) and reading posts on stackoverflow, I finally came back to the sample HTML login form (which I already checked like five times) and suddenly spotted that the name-attribute on the password field was not highlighted like the one on the mail field.
Oh nose, a typo. I must have hit an m instead of an n while creating that field.
After correcting that typo values are now received like they should.

How did it come I didn’t see that earlier?
For what it’s worth, I’ve been really tired yesterday. Ok, but what about today? Well, the screen I’m using is not the newest and there are some issues on the resolution PLUS my seat is way to low, so sometimes the characters on screen get a little blurry and so I just didn’t see the difference between the m and the n.

I re-adjusted the screen and it’s way better now.
– By the way, I’m not using a fancy IDE on this project, just VIM enhanced with my standard .vimrc and NerdTree, so there is no auto-completion and no smart-correction.

Focus Sven!

For the login-script.
This is a pretty simple one. I just take the given mail and password, check if there is a user with that mail in the database and if there is one, the given password will be hashed and compared to the one in the database.
If password is incorrect user will be redirected to login-page (maybe later with an error message), else some data (userId, userAlias and a hash containing the user-agent) will be set to session.

Et voila, there is a working login.

And here some color…

So long.

Ok, I start to get a feeling of stupidity, but I guess that’s ok.

Yesterday I told you about how I forgot to add a users-Table and showed the updated graph with the added table etc.
Now there comes the next point… As I feel obliged to add at least some security I’ll spice it up a little by adding a salt field to the users.

The salt will be used while cooking up the hash in the login process, we’ll see some of that later on.

Another thing is I created a github-Repo where I will subsequently create the project.
Sometimes it might be possible to see improvements and/or new code earlier than on this blog.
As of writing this, the repo mainly contains the Readme, a small leaflet containing some notes and the sql-statements needed for creating all tables (so far).
Annotations are welcome…
Repo can be found On my GitHub Account

Right now I’m starting on the first PHP part by writing a small login script (which I think shouldn’t be much of a hassle…)

More to come soon.

Cheers
Sven

You could just say D’Oh…

Starting to create the tables on the sql-database I realised I missed one essential table:
Users
Obviously there has to be a place where I store the users (or authors) that are allowed to write posts.

So added a new table Users with fields:

• userId
• userAlias (also known as Nickname)
• userMail
• userPass

So db-overview now looks like this:

Ahoi,

just like said in the last post I needed to do some refinement on the multilanguage part of the database design.
So I added another table Content which will hold the actual articles per language, in order to get it nice the heading and content moved from Articles to this new table. Also there is now a languageId in this table which is used to distinct between all available languages.

LanguageId is part of the second new table Languages which will accommodate the available languages. It simply consists of the languageId, the language (aka the display-string) and an languageIcon.

Here’s an update overview-image

Not much for today but I hope to keep it coming…

So long,
Sven

Ok, so starting the development first step (at least for me) is quite obvious.
Think about the data handling and data storage.

As the primary project goal is learning PHP, this step is somewhat small, but still it’s needed.
My first thought some time ago today was „What tables and which fields do you need?“
So I furiously started scribbling on a piece of paper and soon realised what was drawn on the paper is not what I need.
It was a great mess trying to get all the stuff that is possible in the design, instead I should start low and focus on what I really need in order to get the base functionalities.

Well, what is the baseline in terms of functionality a blog needs? Obviously the blog-posts (or articles), so one table for the articles might be a good start.
Of course that table needs some fields. Again the question, what is the baseline? That’s an easy one – Headline and Content should do the trick, plus a unique id for internal useage.
Ok, that’s a little bit to basic, so add a creation date, author (maybe sometime I want to invite someone to participate on the blog, who knows…)
More advanced, sometimes there is not enough time to finish a new post straight, so maybe a status for „draft/published“ should be available, so add that too.
Last there is a feature I want for the blog that could should be taken into account too:
Multilanguage support. So for now there will be two fields for the headline (german and englisch) and also two fields for the content.
Yes, this is something that definitely should be refactored and yes I shouldn’t wait too long before refactoring as this is ugly, hardcoded and not easily extensible, but for today I’ll leave it just like it is.

Now we can display articles, but wait, maybe there should be a refinement in favor of organizing several blog-posts together. Of course I’m talking about categories, so add another table for the categories. This is a very simple table, as it just needs three fields: Category-Name, Category-Id and advanced a Parent-Category-Id.

Not much of a fuzz, so what’s next?
Do you need comments? Well, I don’t really need them, but it would be rather nice to have the feature, so there is table number three.
What is the baseline? Of course an unique id (like quite always). Next a Name (single field, just a nickname maybe?) and the comment itself.
I’d like to know if a comment is old or new, so creation date is a must! And sometimes I might want to contact the user who left a comment, so add a field where an emailaddress can be added.
Maybe said user want’s to share his own page/blog with me (and obviously the world), so why not adding a field for website?

Ok, looking sweet and easy so far – still we need a place where we can define in which categories each article is contained; same for the comments.
This leaves me with a basic db design displayed in the following pic.

Like said, I have to refactor the multilanguage part of the articles table. I’m already thinking about the possible solutions (and which might be the best or at least most suitable for my needs/wishes).

So long.

Well, quite obvious I’m already writing a blog, so what’s this about?

Recently I decided that I want to give PHP another try – having last worked with PHP4 (and only taken a very small glance at PHP5) learning PHP7 might be worth giving a try. That’s not something new, in fact, I decided this more than half a year ago, but as always, if there is not a project it is hard (at least for me) to learn another language.
So what are my opportunities? What is it I can try to code? At best I’m able to use whatever is created once it is finished, but also if it’s not working out something that can be thrown away or at least be replaced by some already existing software.
The solution for this problem is easy, I’m writing a blog (actually a blog-system… and besides I can write a blog about writing a blog)!
Yes, there are several solutions for this on the web (like wordpress which I’m running right here). Yes, they’re well tested (or at least claim to be) and there are dozens of features and plugins available.
So why still writing a new blog?
Well, just for the sake of writing something and learning of a new language.

Of course there are some features I’m missing (at least in this wordpress-system) that I want to implement.

Reversed (or timely correct) order of posts
One could also call this „reading-mode“ or something similiar.
Reading a lot of travel-blogs I always get the creeps if I’m starting to read a new blog which is on it’s way for at least several months when I start reading. Why?
Because newest/latest entry is first!
If you (like me on those travel-blogs) want to get the whole experience of that blog you’ll have to go to the first (or more correct: last) page of that blog.
Now there are, as we all know, several types of „pagination“ which can be more or less pain when you want to reach the first entry ever:

• Standard pagination which displays several pages and a „First/Last Page“ Button
  -> easy mode, just click on last page and you’re good to go
• Older/Newer-entries pagination
  -> well, you have to do some scrolling and some clicking but sooner or later you’ll reach that last page
• Infinite Scrolling
  -> this is basically the screw-you-mode of pagination. Why? You almost never can jump several pages at once and you mostly can’t set a bookmark on the page you are currently reading. This is massive pain for me.

But assuming you finally reached the last page, now the earliest entry is at the bottom of that page, so you search for the beginning of the entry, which might be slightly above the end of the page, read that entry top-to-bottom and then scroll up to the next entry. And you’ll have to do that over and over again.
Doesn’t sound like a big problem at first, but think about a travel blog which is like two years on it’s way with one entry per week when you start reading. You’ll have to do all that scrolling hell like a 100 times.
By simply reversing the order of the pages and the entries for display there would be a coherent reading experience and you literally just go on and on reading, so that’s a feature I definitely want to have!

Another thing is multi-language support. Although it’s not widely used even if available (maybe because you have to write your posts for each language on you own)…
Still I do want this option as my intention is to write at least in German and English. Whether I’m ending up using the feature or not is something I’ll figure out later.
Regarding this feature, maybe there should be an „default language“ option, where posts will be displayed in given default language if not available in the currently selected language, maybe that idea is not that smart, but I’ll figure that out sometime in the future.

As a JavaScript-developer I tend to use Plugins and Libs which are wide-spread around the internet. Also I see that quite every page I visit is literally bloated by js and near to unusable if js is not available (ok, no js is a corner-case, but still there’s some interest for me), so one goal is to have as less js in the blog as possible.

Personally, like many many other people out there, I use several different devices to browse the internet. As screen sizes may vary (my desktop-system has one 22″ 16:10 and one 19″ 4:3 screen) the blog should not only be readable but also all pages and functions useable on quite every device.
You probably already got it, I’m talking about responsive design, which again is a feature I want and also one that’s on the „must-have“ list.

That’s it for now, this list doesn’t claim completeness or something similiar, it’s just a starting point and might get refined along the way.
Also there are many features that are not worth mentioning as they are standard functionalities.

So long
Sven