Using the built in search
February 9, 2016
Installation Issues
February 10, 2016

Using the Built in Profile Features

UserSpice is not and was never meant be be a CMS, but I had a very specific reason for creating a profile feature. The profile feature serves as an example of how to do things that I really wasn’t doing anyplace else in the system. It’s another one of the features of UserSpice 4 that you can take or leave. It’s not deeply integrated and it’s easy to pull in our out. It’s also important to note that the system is not and isn’t scheduled to be fully developed. The point is that it can serve as a starting point for your own dynamic content.

Here are the parts of the Profile system…

The Profiles Table

The profiles table is one that we won’t touch in the development of UserSpice. Other than the first 3 columns of id, user_id, and bio, you are free to do whatever you want with this table and you can rest assured that we won’t touch it during the upgrade process.

The User Class

If you look in public function create in the User class, you will see that when a new user is created, a new row is automatically created in the profiles table that automatically populates the user’s id and a “default” bio. This serves as an example of how to do this with other tables.

account.php

Since UserSpice isn’t forcing you to use the profile features, the only place it is mentioned currently is on the default account.php file. It’s expected that you’re going to customize this page, so you can implement this however you want. Right now there are 2 basic links… a link for the user to edit their own profile and one to view all users and their profiles.

view_all_users.php

This is a great example of how to call all information from the database and convert it to a table. You’ll notice that the usernames are links to the individual profiles and that they pass the user_id through as a GET variable. This isn’t really a security risk in this situation because either all profiles are public or none of them are at this point. Since the page is marked “private” by default, non logged in users would not be able to access this information.

edit_profile.php

This is similar to the profile.php file below, but there are big differences in how everything is handled. In this case you would NOT want to just pass the id through as a get variable because it would allow one user to edit another user’s profile. So, in this situation we are getting the id from the logged in user’s $user variable and NOT the id.

By default this page only has a place for a user to enter a full bio as one big section. Obviously you can enter your own fields in the database and other inputs on this page. One thing to consider is that your users are entering content that will be visible to other users. As such, you want to make sure they’re not posting malicious code and javascript. With normal form inputs, the Input::get function does all the sanitizing for you. Unfortunately, you can’t do that with the WYSIWYG editor or the content they enter would come back with all the html stripped. Instead, you’ll notice that when I do the database update like this…
$newBio = $_POST['bio'];
instead of the usual
$newBio = Input::get['bio'];
Because of this you want to be very careful how you output this information. More on that in the profile.php explanation

profile.php

This is where you view a user’s public profile. You’ll notice that the queries at the top give you access to all the info for the user from the user table AND the profile table. In fact, there are two commented out lines.
dump($thisUser);
dump($thisProfile);
Feel free to comment them back in so you can see what you have access to.

The most important thing you need to remember about profile.php is that you have unsanitized user input that is being output. You want to output the text from the bio like this
html_entity_decode($thisProfile- >bio);

We will probably develop a more sophisticated user output function, but for now, just be aware.