Tiny steps at a time

I feel like I am inching my way along a precarious wall 100 feet in the air. With every tiny step there is another boulder to hurdle.

So, I got through the password issue, and into the refining of the script. I started getting the error handling messages (which I set up in the config.php file) on the username validation. Obviously there was an issue with how I set it up - so I looked at the coding.

I had taken much of the coding for the registraion page from chapter 13 of Ullman's book and had to adapt it because I was not going to require a first name and second name. So in place of the first_name and second_name I included a user_name and used the same character class :alpha and the same characters as would be used for a first or last name (Ullman, 2005, p. 406). However, I later changed the character class to :alnum, because I wanted the user to be able to use numbers as well as letters. But I forgot to change the characters within the brackets to include a-z0-9 as well. So when I tried registering the username it kept sending me the error handling message. Once I added the extra range of characters it worked a treat and I was welcomed to the Raspberry Whirl website and instructed to go to click on the link which was sent to my email address to activate my account. It was all so exciting...

EXCEPT!!!

I also had a message below the welcome which indicated that the buffering session could not be terminated as there had not been an action to commence it. I straight away checked to see if I had included the start buffering code in the header.html template, which I had. So now I have to deal with this issue.

Update: Can't work out why this is coming up as not being commencing. Have looked at the coding - very simple - but not sure. As I feel that I have some other more important things to deal with for now I have decided to take out 'output buffering' and address it later.

However, I did go to my email and I found the link there in an email for me to click on. I did so, but failed to get back into the site. Something else to look at - I suspect it may be linked to the buffering issue, or the issue below, but not sure.

Then I wondered if the new user information had been recorded in my database, so I went in there to look. I was very excited to see that it had. But the username column had the email address connected to it and the email address column had the username connected to it. So I guess the order in which you submit a query is important. I will now go in and delete my registration and see if I can get the order right so that the information can record correctly.

Update: I just discovered that I had changed the order of the form handling on the register.php page, and the INSERT INTO $query, but didn't change the order of the VALUES (line #40 on register.php). That is why it was registering under the wrong columns. :-)

Now it gets exciting - Puting it all together

Yesterday I finally got enough php pages completed for me to get the database going with the website. It was a bit daunting as I have been following the posts on the forum and get really worried that if all these issues are arising with others, then they are sure to arise with me, and half the time I have no idea what they are talking about. So it was with apprehension that I made my first attempt to register through the registration page.

Predictably it didn't go well. However, I soon realised that I had not written the mysql_connect.php page up correctly. I had the DB_HOST correct 'localhost', and the DB_NAME correct too 'geoffrey_Raspberry. But I wasn't sure of the DB_USER or the DB_PASSWORD. I spent some time wondering what they would be, then went into MYSQL on geoffreymultimedia, where my database was. There it was staring me in the face - the correct information on the MySQL Account Maintenance page. Under each database heading is provided the exact PHP connection code. However, I couldn't remember the password I had set so many weeks ago (I thought I had recorded it somewher, but couln't find it).

So I spent about 2 hours yesterday and this morning trying to research how I could either locate the password, or create a new one for the database. I went to the MySQL website and did a fair bit of research on it in the Reference Manual:

http://dev.mysql.com/doc/refman/5.0/en/access-denied.html
http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html


But could only come up with how the change the password - but of course I had to have the old password to change to a new one. So no luck there.

I made a post on the forum to find out if anyone could help me. I got one reply - suggesting I create another database. But I didn't have the time for that. However, it did lead me to think that I might be able to copy my database and create another one with the same data and then I could create a new username and password.

So I went into my database and discovered I could do just that. So geoffrey_Raspberry became geoffrey_raspberry and the new username and password went into the mysql_connect.php and it all worked well. It actually connected to the database, but of course, there was a list of other errors I had to deal with.

Activation Field

In working through chapter 13 and setting up my login, join, and logout process, I discovered I will need to include an activate field in the user table of my database. This is necessary for those who join the website. They will have to activate their account before they can login for the first time.

Some Lights are Turning on

As I start to get into the various files involved in setting up this site I am slowly realising that my innitial Design and Analysis Document is sadly lacking. Since submitting assignment 1 I have decided to base my site around much of what is presented in Ullman's Chapter 13 - Example - User Registration (2005, pp. 527-575). It covers a lot of what I wanted to include in my site, so i thought that would be the safest way to go. But I am now discovering that there is so much more in the way of file creation than I thought when I was preparing my Design Document.

Of course there are some aspects of his instructions which I won't need to use, and there are some things that I do want to use that he doesn't cover in this chapter. So it is a bit of give and take. But I thought I would highlight some of the changes or additions I will have to make here.

Header Template (header.html) - This is fairly straightforward as I covered it in earlier exercises. However, there are a couple of things that I needed to consider. At first I wasn't sure if I needed to use cookies or sessions, but after making some queries on the forum and doing some reading I will include the the sessions_start because i will be having users login and their information will need to be tracked by the server, which won't happen if I don't have sessions set up.
Footer Template (footer.html) - The footer coding in Ullman includes an option to login, logout, change password, and reset password. This is something that i had not considered innitially and will require me to create several more pages -
1. login.php - which is a separate login page. As I have the login table set-up on every page I have decided to just create a link back to the Home Page here, where they can enter their login details, rather than creating a whole new page for it.
2. forgot_password.php - This is for those users who have forgotten their password. I will keep this in, but am yet to understand fully how this works. This is an important page to have as it will offer an important service for the target audience (mostly over 60, poor memories, inexperienced Internet users etc.).
3. logout.php - This will be a fairly simple page to create as it will have a static message (tailored with the users name) on it. I will still include this.
4. change_password.php - I will include this page, but it will only be accessable when a person is logged in already.
**All these pages will be accessed via links across the bottom of every page and will be displayed according to whether a person is logged in or not (Ullman, 2005, p.530).

Configuration Scripts (config.inc.php) - This file will handle and display the errors. Innitially, as I set up the website, I will set it so that the errors will display on the web browser. When the site is complete I will set it up to notify me through email.
Database Script (mysql_connect.php) - This file sets up the database access information, creates the connection and sets up any specific functions needed to handle errors. As I have not yet attempted a connection I am still not sure how this happens, but will soon find out.
Home Page (index.php) - This page has been pretty standard as I have been through some of the earlier exercises which cover it.

Finally, as my site is not just a Registration site - unlike the excercise in Ullman - i will have a link to the registration page which will be separate to the Home Page, and it will not be mandatory to login before using the site. Anyone can use the site to browse for recipes. But to submit a recipe you must register and be logged in.

Yes, I am still here :-)

The last week has been fairly quiet because, firstly I have had other assignments due this week, so have spent the bulk of my time on that, but secondly I have spent most of my NED24 energies on getting the various pages for my site written up. As this is fairly straight forward - using the manual to make sure I have covered everything - I've not had any real issues with it. So consequently, not much to report here.

Right now I am trying to get my index.php page working, which is proving bothersome, as I keep coming up with all these sintax errors. Normally this would be really frustrating, but since I understand that syntax errors just require a bit of patience and proof reading to be fixed, it doesn't bother me.

What is bothering me is that it is so quiet at the moment. It feels like the calm before the storm. Everything is going too well. This calm and quiet has to mean that there is going to be something major happening around the corner. I know that as soon as I start to put all this together into a working web site that the problems are going to start. With only a week to go for assignment 2, I am not sure I am ready or equiped to solve them.

Oh well, just keep going, one foot at a time and face one problem at a time.

One change I have made to the overall design of the site is to use PHP to dynamically display the appropriate login, logout, change password, forgot password links. I have followed the instructions given in Ullman to do this (Ullman, 2005, p.530).

Progressive Decisions

I have decided that I will add just a few recipes to the database to start with. Then I will try and get the database linked to the php files and get that working before I enter too much data. I think that if I try to get all the data in there at once I may be confusing myself and also making it more difficult to work out the connection process. I have yet to really work through the chapter on 'Using PHP and MySQL' and don't want to create something bigger than I can handle before I master the basics.

Next Phase

I almost forgot that this was here. I was so buried in my first assignment that I haven't had a chance to consider this blog. But as it is a requirement to show my progress in the next assignment I am going to have to make sure I touch base here a bit more often from now on.

Well, I have to say that getting the first assignment out was very stressfull. There were several time when I considered if I should actually drop this unit. It felt like I was constantly hitting a brick wall when trying to understand database structuring. My biggest hurdle was understanding where to put what in each table and then how to link them. It really stretched the logical side of my brain - not my strong side. But I have to say that once I got it (somewhat) I really did feel like a door had been opened. What capped it off was when another student posted their database structure on the forum and asked for feedback. I was able to look at it and get an idea of what it was all about and even make a suggestion on how to adjust it. I knew then that I would at least be able to come away from this unit having learnt something completely new.

This is how the structure turned out:




However, today I have been working on the actual creation of each table and have decided that I need to add a category table, with associated id, and link it to the recipe table. There will only be four categories - Main, Dessert, Cake and Biscuits - but I figure that it will be easier to link the category_id to each recipe rather than the actual name of the category.

This, I have discovered, also means that I will need to move the unique index I have placed on the category_id in the recipe table to the category column of the category_id table.