KingWarin.de

As my development machine starts to die and I’m currently setting up the replacement I came up thinking of what is necessary to port the blog-project to another system.

To have it as convenient as possible an installation-script would be nice, but there are some prerequisites that have to be met beforehand.
A script for creating new users is one of these.

So today I started off by creating a new form in the admin area which can be used to add a new user. Here a username, email, password and a salt have to be entered.
To verify there are no typos the password and the salt have to be repeated.
As can be seen on the addUser-function, on adding the user to the database the password and the salt will be sha256-hashed and afterwards both hashes are combined, hashed again and that’s what will be set as pass in the database.

Another thing that was living on my todo for quite some time now and I wanted to move today was parents for categories.
So I took the existing form for creating new categories and replaced the dummy parent textfield with a select-box where the options will be filled with the results of the getCategories-call and an empty option at the beginning in case the new category shouldn’t be a child-category.
This added the need for checking whether the parent-parameter is none and adding the new category with NULL as parent.

After creating a new category without parent and another one that was supposed to have a parent I took a look at the database and saw… no parents at all.
How come? Well, I placed a $parentId = NULL; in the first line of the createCategory-function as the parent-selection was not implemented yet.
So removing the line and adding a new category with another category selected as parent the next call to the database showed the category with the previously selected parent.

Cheers,
Sven

Today’s goal was adding the functionalities for setting and unsetting categories on each individual article.

I started off with what would be the first thing that a user could interact with, so obviously I’m talking about the checkboxes on the create article form. To achieve this I first of all had to create a small function in DBConnect which simply returns all available categories, it’s just a simple SELECT that returns all entries in the categories-table.
Displaying the categories is not much more than a foreach-loop that creates div’s for each available category (div’s because I already got some styling wandering around my head).

Done that I had to improve the processing of the create-form. This again is a small loop (this time a while-loop) that was added to the create_entry.php-File and just calls the new linkCategoriesToArticle-DBConnect-function.

Ok, creating articles and setting the categories on the fly works now, so next step is handling the categories on updating/editing existing articles.
So now I need to now which categories are already set for the article the user is editing, this means it’s time for another DBConnect-function „getCategoriesForArticle“ which is another SELECT, enhanced by a simple JOIN that returns all categories that are already linked to the article with the given id.
On the edit-form I added the same foreach-loop that is used on the creation-form, but in this case the checkboxes for the already set categories will be pre-checked (which is what I needed the new function for).
On the processing script I also added the same loop as for creating new articles, but to be able to unlink categories again I also call to the getCategoriesForArticle-function and check whether all of this categories are still activated for the article. If there are differences the newly selected categories will be added and the unselected categories will be unlinked for the article.

In total not much of a hassle and didn’t took to much time to implement.

So long
Sven

Ok, last time I was stuck a little, today I had a day off from work which I used to spend some more time on this project.

So what has happend?
In brief:
I created several forms and the scripts for processing that forms. The forms are mainly for creating and updating the blog-posts (or „articles“), creating categories and adding languages.

I started out creating the small and easy forms and scripts, more accurately I started with the form for new languages. This is absolute low-level as it consists only of two fields, one for the language name and another one for the path to the language icon (although I might have to figure out something better for the icons).
Processing is similiar, check if both values are set and insert them into the corresponding database-table (which is languages).
Those two files were created within some minutes and working fine, not much of a problem here.
Well, working on some other parts I realized that I should take a little care of errors. As I’m not quite sure on how I want to check whether a language is already existing when trying to create a new one I, for now, went with displaying all existing languages at the bottom of the create form.

Creating categories is also a small and not very exciting form so I won’t spend much words on this, although there is one thing I haven’t done yet (but it’s already on my todo).
At the moment, when creating a new category there is no possibility to specify whether there should be a parent category. This is something I will take care of soon.

Creating new blog posts
I started this one with some headaches. First shot just had a field for the articles heading (which will be used only for internal reasons) and a create and dismiss button.
Hitting the create button the new article was created in the database and the user was redirected to a page where he could create the content for one language.
For a first shot this was ok No it wasn’t, I’ve just been lazy. So I’ve almost immediately redone that and added the form for creating the first language content into the original form for creating the article itself and enhanced that form with a checkbox the user could set to immediately create another language-content after the article was created.
But this still means jumping from one page to another and to the next and that’s something I usually don’t like and therefore I want to avoid.
So I pretty much ended up redoing the form again until it was what it is now.
That is a form where the user must add the (internal-) heading and all possible languages are displayed right away. It’s the users choice to create the content for as many of those languages right away.
This is not a good looking form at the moment, but I already got some ideas on that.

Next I wanted to proceed with editing the articles. So I started to write on a form for editing. Again first shot was the absolute minimum and only displaying the heading and the content fields.
While I always had to access that form by typing in the url and specifying the articleId in the url-bar of the browser I decided to intercept the writing of this form by creating a small page where all existing articles will be displayed and can be opened for editing by navigating through the admin-area.

Said that I first created the function that fetches all the articles information from the database. Displaying that data is no sorcery. A simple foreach-loop iterating over the articles array returned by the getArticles-Function that outputs an div displays the heading, the current status, creation date and the userId of the user that created that entry (which will be enhanced so the username is displayed instead of the id) and a link to get to the edit form.

Done that I went back to the edit form.
Ok, this already has some fields but it’s not the state I wanted to achieve, so I added another foreach loop that iterates over the existing contents and displays them in the form, making them editable in place.
But there still is the possibility that onenone or more new language contents should be created.
The first shot just drew another line in the form with a heading and content textfield and a select-box for language.
Closing with the already known „Do you want to create another language-content?“-checkbox.
Still not exactly what I wanted, so go on Sven…
I need to know for which languages there is no content created for the current article, so I opened up my MySQL-console and started to figure out what statement I’d need to get the data I want.
Well, here comes my first real problem. Having spent quite some time on that I’m stuck with an ugly SELECT-SUBSELECT-statement at the moment (see below), but I’m quite sure the same result can be obtained with some sort of JOIN, but I’m just not getting there right now.

SELECT l.languageId, l.language, l.icon FROM languages l
WHERE l.languageId NOT IN
(SELECT c.languageId FROM content as c WHERE c.articleId=:aId)
My ugly SELECT-SUBSELECT… If someone has ideas on a nicer solution feel free to contact me

Ok, with that SUBSELECT stuff I’ll get the result I want, so I can go on.
I now added another loop that creates blank form-lines with language pre-selected if there are any languages without content left. These lines do have a checkbox which indicates whether that content should be saved or not and all of this works pretty fine.
But it’s not good looking at all (but optics are something I’ll work on in a later stage of development), but again, I already got some ideas for that.

Ok, that’s what we got so far, some stuff is still missing (e.g. specifying the categories for the articles, creating users, managing comments,…), but most of the basic (admin) functionality is already there (which is quite surprising for me). I guess next steps I’ll take on are specifying the categories on articles and user creation.

Cheers,
Sven

Ahoy,

so last time I created the basic login script, pretty much no hassle there…

While creating that script I also set up the first sql-Statement and a simple dbconnect.php script.
Well, simple is almost to much, the file literally only consisted of the standard opening and closing php tags and furthermore one additional line
$con = new PDO('mysql:host='.HOST.';dbname='.DB, USER, PASS);

Didn’t look that clean and not at all satisfying to me, so while I wanted to continue with the script which will be used to create categories I felt the urge to do something about that piece of code inside of that dbconnect-File.
So I took that file and created a new class Connection which houses a private PDO-connection and several public functions that will take care of the sql-statement related stuff.
– Huge plus, if I’m going to use another db, like postgres or even such crazy stuff like a Lotus Notes database I just have to switch out that connection class, not much hassle inside of the other scripts.
(Just kidding about that Lotus Notes stuff, I don’t know why one should go through the pain of using Notes voluntarily, but I got a professional background on working with Lotus Notes, so why not toss it in)

So I took the whole statement stuff that was living inside of the login-function (located within the helpers) and turned that into the first public function getActiveUserByMail which sets out a SELECT statement to the database and tries to retrieve a user by the given eMail and return the result as an associative array.

Having done that first thing to try is whether the login still works. Besides tackling some php-errors that originated from forgetting to create a constructor-function (and missing the n on that function after creating it), everything worked out pretty nice.

So I could go on creating the next public function createCategory which I think doesn’t need further explaining.
The processing script is just taking in the POST variables, verifying they are set and passing them to the createCategory function.
Along comes a small form for the creation, this, again, is not a big thing. A simple php-File which checks whether the user is allowed to see that page and redirects to the login-page if he is not.
If the user is allowed to create new categories he’ll see a small form where he can set the category name and select the parent category (if any).
As it really is that simple, it wasn’t a surprise that everything worked nice and clean on first try.

Right now I’m adding some more functions to the connection class, mainly the functions that come to my mind at the moment because I’m a little stuck with writing the scripts/forms and need to get all other stuff out of my head.

So long
Sven

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