D4DME – HTML Forms (Part Three)

The next step I took when validating my user credentials form was to make sure that certain fields only contained certain characters (such as the email field). I used a couple of PHP functions to determine whether the inputted data had been typed in the correct format; for instance, email addresses would not be accepted if they did not contain an ‘@’ sign or a ‘.’. Names and surnames would not be accepted if they contained anything other than letters and whitespace.

<?php
$name = ucfirst($name);
if (!preg_match("/^[a-zA-Z ]*$/",$name)) {
   $nameErr = "Only letters and white space allowed";
}
$surname = ucfirst($surname);
if (!preg_match("/^[a-zA-Z ]*$/",$surname)) {
   $surnameErr = "Only letters and white space allowed";
}
$email = refine_input($_POST["email"]);
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
   $emailErr = "Invalid email format"; 
}
?>

However, I could not get this further stage of validation to work with my already existing validation, as only one would work (it would still submit data even if it didn’t meet the requirements above).

<?php 

    if ($_SERVER["REQUEST_METHOD"] == "POST") {
        $name = refine_input($_POST["name"]);
        $name = ucfirst($name);
        if (!preg_match("/^[a-zA-Z ]*$/",$name)) {
            $nameErr = "Only letters and white space allowed";
            $x = 0;
        }
        $surname = refine_input($_POST["surname"]);
        $surname = ucfirst($surname);
         if (!preg_match("/^[a-zA-Z ]*$/",$surname)) {
            $surnameErr = "Only letters and white space allowed";
             $x = 0;
        }
        $username = refine_input($_POST["username"]);
        $password = refine_input($_POST["password"]);
        $email = refine_input($_POST["email"]);
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            $emailErr = "Invalid email format"; 
            $x = 0;
        }
    }
?>

<?php 

if(isset($_POST["submit"])) {

        if(empty($name)) {
            $nameErr = "Name is required";
        } else if(empty($surname)) {
            $surnameErr = "Surname is required";
        } else if(empty($username)) {
            $usernameErr = "Username is required";
        } else if(empty($password)) {
            $passwordErr = "Password is required";
        } else if(empty($email)) {
            $emailErr = "Email is required";
        } else if($x == 1) { (SQL query here..)
?>

After talking to Kyle (workshop tutor) about my issue, he suggested that I introduce a boolean so that the data could not be submitted if it didn’t meet both sets of requirements. This made it so that the validation could check that there was both data in the field and that it met the required format.

Advertisements

D4DME – HTML Forms (Part Two)

After doing a bit of research on w3schools, I found out how to start the process of validating my form.

13

Screenshot of my code in Brackets

The first thing that I added was in relation to security. As this is our first coding project, I know that there is no emphasis on security, though I thought that learning this practice now would be useful for the future. The above image demonstrates the use of a PHP function that stops a user from being able to inject code into the page.

16

Screenshot of my code in Brackets

The next thing I did was create a function (in a separate file that I linked in with PHP) that would validate the data inputted from the form. The function will strip any unnecessary spaces at the beginning/end of the data and will remove any special characters.

17

Screenshot of my code in Brackets

I then set the function to run in my main index file (with the addition of the ucfirst() function to both name fields) so that the data would be updated before being sent to the database.

14

Screenshot of the data before validation

15

Screenshot of the data in the table after validation

Finally, I ran a test to see how my new function would handle the data. As expected, the data that I put in was validated nicely, with the name/surname being capatalised and all unnecessary spaces removed.

D4DME – HTML Forms (Part One)

Whilst I was waiting to hear back from Simon, I put my time to good use and started to build the form(s) using HTML (and later on PHP for form validation). For the time being I used some of my own CSS so that I could see everything clearly on the page, though once everything is working, I will be able to integrate my coding into the CSS that Chace is making. Starting with the sign-up form, I coded a basic page and form  that linked to a table in PHPMyAdmin, which looked like this:

9

Screenshot of my initial Website

The table within my database that the form submitted to looks like this (as based on my ERD):

10

Screenshot of PHPMyAdmin

Once my PHP were working together with my database, it looked like this:

12

Screenshot of my code in Brackets

Last but not least, my HTML (which at this point was just the form and it’s containing div(s)) looked like this:

11

Screenshot of my code in Brackets

At this point, anything inputted into the form fields would be sent to my ‘user’ table in my database (only if there is something in every form, however, thanks to the first step of form validation I conducted). My next step is going to be validating the form properly.

D4DME – The Database (Part One)

One of my tasks for today (as decided in our group meeting) was to create the tables in our database that the users will be able to submit content to. One of these will be a user credentials table that will contain information about anyone who signs-up to our site (name, username, password, email, etc). The second is going to be slightly more complicated, as it will contain recipes submitted by users with varying criteria.

The user credentials table will look like this:

Untitled7

Screenshot of PHPMyAdmin

With five columns of information (id, name, surname, username, password, email and date joined). This table will be fairly straightforward to link up to. The only fields that will be required to sign-in are username and password, so the process will be fairly simple to code.

The recipe table is going to be slightly harder to produce, as the fields need to be refine-able in the search options of the website.

Untitled8

Screenshot of Student Recipes

To help me think of the different fields for the submission form, I had a look at a pre-existing student recipe website called Student Recipes. This form covers the basics such as the recipe name, ingredients and method, though after our discussion in the group meeting today we decided to include as many fields as possible to make the search results specific to the user.

Untitled9

Screenshot of Word

Above is a list of fields that I am going to suggest to my team mates that could be included in the recipe form. Before I make the table I will need to check whether they want to use all of these fields or whether some are unnecessary.

References

Bailey, J., 2004. Quick and easy recipes for students [online]. Available from: http://studentrecipes.com/ [2/19/2015].

Workshop Compilation (Building the dummy website)

Over the last ten or so weeks, Kyle (workshop tutor) has been teaching us how to create a website from scratch. This post contains a compilation of screenshots from each step in the process with highlights over the new content added to each stage. (This is mostly here for my reference to go over what we covered but it is still relevant to the unit). 


Continue reading

D4DME Workshop (Project folder/files hierarchy)

For the first official workshop of the D4DME unit, Kyle (workshop tutor) got us to set up an example project folder to use as a starting point for any website project.

3

Screenshot of Project Folder

The layout was fairly straightforward, as we had setup a similar folder for our dummy website in the past series of workshops. The only new element to the above example was the addition of the templates folder, which allows for cleaner HTML/PHP files (as you can make separate files such as a ‘navigation’ to be included at the top of every file rather than having the same code on every page).

D4DME – The Brief

The next unit for our level C year is ‘Design for Digital Media Environments’ or D4DME for short. On the 3rd of February we were introduced to the brief of our new unit. Our task is fairly straightforward, though the means of doing so are where it is going to be interesting. This unit is to be conducted in groups of three, in which we will have to create a website that uses databases through the use of PHP and SQL.

Over the last month or so, Kyle (workshop tutor) has been teaching us how to build and structure our own webpages with the use of HTML and CSS. Having already taught myself basic practice with these two languages before starting University, I was familiar with everything that was covered in these workshops and found the sessions to be a nice revision of my prior skills.

However, after we had created the front end design for our dummy website, Kyle (workshop tutor) introduced us to the next step of building a website – PHP.
PHP is a programming language that is used to maintain the back-end of websites, as well as to include the use of databases which result in minimal HTML content.
Previously in the year, Kyle (workshop tutor) taught us the basics of Processing, which bears a slightly similar syntax to PHP in that they both frequently call on functions, except the two languages have different names and structures for them.

The focus of this unit is on our ability to work well together as a team. Rob started our morning lecture by introducing us to a vast array of free, open source software that is available to us as digital designers. Due to the collaborative nature of coding, he strongly advised us to start working with Github so that we could easily backup and make changes to our code as a group.

We currently do not know who we are going to be working with on this unit, though I decided to sign up to Github anyway and played around with the software.

GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Over eight million people use GitHub to build amazing things together.


1

Screenshot of GitHub Website

2

Screenshot of GitHub Software

Another thing that Rob suggested was to add a Wiki to our Dakar domains. Wikis are a great way to collaborate ideas and content, so I had a go at installing one on my domain directory. Wikimedia itself will be a great place for us to find content with different copyright restrictions (such as copy left) so that we will be able to use content without inflicting on any legal rights.

4

Screenshot of MediaWiki

To start the ball rolling, I asked the blue seminar group if they wanted to make a Facebook page so that we all had a place to socialize outside of our individual groups. They thought that this would be a nice idea, as it would give us a place to discuss our work without getting in the way of our actual projects. I created the page and so far most people have joined.

Hopefully we will find out who our individual group mates are within the next couple of days so that we can start to formulate some website ideas together.

References

Preston-Werner, T. Wanstrath, C and Hyett, P J., 2008. GitHub [online]. United States: San Francisco
Available from: https://github.com [2/5/2015].