Smart WebApp Developemt in PHP

Developing a Better WebApp

Using PHP (Expanded Version)

Computer Science House

David Walker
azrail@csh.rit.edu

Introduction Welcome to the seminar. I'm Dave, your host to the wonderful world of PHP and WebApps

If you have a question about any of the material feel free to ask. I will do my best to answer, or hold off if it is a topic to be covered later.

Mostly, try to focus questions on confusion about the material, rather than focusing on "what if foo?" type questions. Write down other questions and save them for question breaks, if you can.

Sorry for those who know PHP, the start of the presentation will be an "Intro to PHP" where I will show some of the differences between it and other languages.

Most of the examples in this seminar are taken from a CMS that I wrote, BPLog. The source to BPLog is available for download at http://www.jdavidw.com

The slides can be found online at:
http://www.jdavidw.com/presentations/phpwebapp Topics Subjects to be covered:

The last few topics will be mostly code examples with me explaining them. Goals Hopefully by the end of the presentation you will know more about how WebApps work, and how to make better, more modular, and more secure WebApps using PHP. Confessions I want to begin by saying I am not a PHP internals guru. I have just used and programmed in PHP for many years, and can't stop reading documentation. Topics I bring up are just the best way I have found to do a given task, hopefully they will be of use to some of you too. What is PHP Quoting php.net:
PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML
PHP is a script programming language with a recurive acronym as a name: PHP Hypertext Processor. It behaves in a similar manor to other scripting languages: Perl, Python, Ruby. However I use more of a C like syntax with it.

The language is best documented at http://php.net. To find any specific documentation about a function, or a library built into PHP, you can go to here: http://php.net/mysql.

A simple PHP program looks like this: ]]> Note, all PHP scripts should begin with a <?php and end with ?>. Programming Logic One thing we need to realize is that PHP is not a continual functional language. It's a scripted language, and therefore ends when it's done outputting information.

Other languages like C, C++, Java, etc... run until the user quits them. With WebApps each page is an instance, that starts, runs, and dies. So we need to be thinking of that while developing. There are ways to retain information though the users "visit" to the WebApp, but that will be covered later. Simple PHP Code Examples helloWorld(); ?>]]> I hope many of you know this syntax, or figure it out quick, but for those that don't; `$` is a label for variable. Unlike other languages; scalers, arrays, hashes, objects, bools, etc... are all prefixed by the `$`

You can also see the function declaration. Since PHP is a variable typeless language, you don't need to declare a return type for functions. The function helloWorld could return anything if it so chose. We, the developer, know what and if a function returns relevant information, and will set it if need be. What is a Web Application? What is a Web Application? WebApps are just that, applications developed to be run on a website.

WebApps should be able to handle and manage multiple users connecting at the same time, manage some kind of central information, update information to share with others.

Information is the key. Without some content being used, there would be no reason to have a WebApp. So getting information to and from a store is a priority. Doing this in a smart, efficent fashion will keep wait-time at a minimum.

So, WebApps should:

  1. Keep simultanious connections separate
  2. Store current use information
  3. Have an efficent data storage system
  4. Do what the 'client' needs them to do
  5. Be Secure
 How to maintain sanity in PHP How, you may ask, do we maintain information for the user, and maintain users; Sessions.
  1. Keep simultanious connections separate
  2. Store current use information
  3. Secure
]]> Woah, what's that id business?

PHP Sessions track via cookies. They generate a long ID, but unless you change the ID of the session all the time, the session can be hijacked. This at least makes the application slighly more secure.

I guess we should look at forms here. HTML forms are used to 'post' information to a PHP page. We can access that information from a superglobal variable named $_REQUEST. That contains all information passed in to this script via the post method. The other superglobal we see here is $_SESSION. It contains information regarding the session that we have begun. We see that we can store informaion to it, like an array, and retrieve information from it in the same way. Back to Programming Logic We know PHP is a scripted language, so we must program it as such. Below is a very simple directory structure for the most basic of WebApps We see the index file, the "main" of our webapp. Then we see the folder called inc. Think of this as your main include, and your API area. Since every "page" in this WebApp need very similar things done to them we can re-use much of the same code to build our page. Main Page Example Here is what your sample "page" template can look like: ]]> Alright well the black box here is what is in header.inc. This file should "set up" all defaults, restore the session, and "start" the application. Your Main Header Here is a short example of what a header.inc file can contain: My First WebApp ]]> Woah! It doesn't close the HTML tag?!
Remember PHP is scripted, it goes from start to end, in that order. The index file "included" the header. So the header file does this for every "page" in our WebApp. Leaving body open gives you the ability to just put content in your "page"-file. Now here is a trick, instead of closing the BODY and HTML tags, use register_shutdown_function. This PHP call takes a function pointer, I will show you in the following example.
Add the first two lines in the example below, before the session_start(); line in the header. } ?> ]]> the register_shutdown_function will run right after your "page" finishes execution. So its the last portion of code to run before the page is sent to the browser. Note that in the normalExit we clean up the tags we opened in the header. Expanding the WebApp Ok, now that we have a really basic understanding let's get bigger.
Below is an example from a project I have worked on. It shows how you can use the header.inc file to get up your page environment, as well as get all your includes. J. David Walker | <?=$title?>

]]> Ok this does a lot. Lets break it down:
  • Declares a program version number
  • Includes data from: root.inc, auth.inc, functions.inc, and database.inc
  • Runs a function called isAuth, don't know what that does (yet)
  • Loads Modules (will talk about that soon)
  • Sees if a nooutput variable is true, if it is return if not call a function
  • Has a pageHeader function, which does the page setup. Note it leaves style open.
Why is the header information in a function, don't you always want to have the header print?

Well, there are cases where you don't want to print out information too early. Where printing information will prevent the system from using headers to send the client elsewhere in the application. An example is after submiting a form we want the user to be sent to a different page than where the form was submitted.

We will see that in the next few slides.

And the expanded footer file for this would look like this:

]]> We see it just closes the style, loads a sidebar page, and closes the tags. Simple, no? App Datastorage I want to start by saying this is not a SQL seminar, so I won't teach syntax.
With that said, PHP has bindings for many different versions of SQL, LDAP, and other data storage. Depending on what you want to use look at the PHP docs for them. This WebApp will use MySQL as a data backend.

Knowing what to store is very critical. Since the purpose of a WebApp is to relay information from a datastore in a cohearant manor we need to think of what/how to display information. In this example we will be using software entitled TCenter.

  • Content Information
  • Comments
  • Tag Information
  • Author Information
  • Other Modular Information (Will get to this later)
Knowing all that we can construct the database. Which will consist of at least 4 tables:
entries
Content Information: created, author, content
comments
Comment Information: commenter, comment, entry (e_id)
tags
Tag Indormation: tag, entry (e_id)
authors
Author Information: name, password, salt, profile, contact, access
 Adding Datastorage to our WebApp Remember in a few examples back where we included a file called database.inc? Let's see what that does: In short we can see it set a few variables, and pass them on to mysql_connet to make the connection to the database. In the perfect world, you would have a page in your WebApp that will be able to edit those values. Note, to do that the file will need to have write permisions for www-data (or webserver user). Question Break Questions about the basics? Next will be more depth and code examples, and logic design. Creating a Basic Functional API (With Modules) I guess the first thing here that is new is the modules. Why would we want them?

Simple, you want modules to make extending the WebApp easier, This is covered in the next slide. But what does the core API need to have to be useful?

  • Common Functions
  • Functions that allow extending the system
  • Structure and management of modules
Right, so what would that look like? 250) || ($imgsize[1] > 200)) { /*== temp image file -- use "tempnam()" to generate the temp file name. This is done so if multiple people access the script at once they won't ruin each other's temp file ==*/ $tmpimg = tempnam("/tmp", "MKUP"); /*== RESIZE PROCESS 1. decompress jpeg image to pnm file (a raw image type) 2. scale pnm image 3. compress pnm file to jpeg image ==*/ /*== Step 1: djpeg decompresses jpeg to pnm ==*/ system("djpeg $imgfile >$tmpimg"); /*== Steps 2&3: scale image using pnmscale and then pipe into cjpeg to output jpeg file ==*/ system("pnmscale -xy 250 200 $tmpimg | cjpeg -smoo 10 -qual 50 > $imgfile"); // remove temp image = unlink($tmpimg); } $imgname = basename($_FILES['p_picture']['name']); // Set the new image name and move it into the img directory $newimage = $_SERVER['DOCUMENT_ROOT']."/img/".$imgname; move_uploaded_file($imgfile, $newimage); } function imageExists ($imgname) { return file_exists($_SERVER['DOCUMENT_ROOT']."/img/".$imgname); } // Real delete directory...like for realz! function rmdirr($dirname) { // Sanity check if (!file_exists($dirname)) { return false; } // Simple delete for a file if (is_file($dirname) || is_link($dirname)) { return unlink($dirname); } // Loop through the folder $dir = dir($dirname); while (false !== $entry = $dir->read()) { // Skip pointers if ($entry == '.' || $entry == '..') { continue; } // Recurse rmdirr($dirname . DIRECTORY_SEPARATOR . $entry); } // Clean up $dir->close(); return rmdir($dirname); } ]]> Ok that's a bunch of code. What all does it do? Well remember from the first half of the presentation the register_shutdown_function called normalExit here is where we can define it. Then we have a function to upload an image. Since more than one module may be wanting to upload images. Then we have a function to completely remove a directory. This API call is there so modules can delete files or directories the user uploads. Making your WebApp Modular Ok so what's this about modules?

Right, so modules are just what you think they are. Provide different and new functionality to a WebApp. The process of writing modules, and libraries to a WebApp should be easy. And it can. As we saw from the previous slide, there is a simple way to "load" a module. It's more like loading a header for the module, and letting it boot-strap. The following slides show how modules are managed in the API, and how they are loaded. Extending the Core API to Modules The first thing we need to do is think about how modules will interact. Secondly, how they are stored in a file directory sence. Then we need to think how they will be loaded, and what they can extend.

Loading modules can be done in a multitude of ways, but one of which I found to be better. This involves a directory called modules, and each module being in a separate directory named after the module. /modules/myModule Now all the contents of that module are contained into that directory. So now we need a way to load them. Well the ability to enable and disable modules is important, so what we need is a config file to do just that. Below is an example of the config file to use.

/modules/module.inc

]]> So we see that myModule is turned on, and offModule is off. The key in the array is the name of the module in question.

Next we need a way in the core API to load the modules into the system, and allow them to extend the function set.

/inc/functions.inc

$val) { if ($val) include_once ROOTDIR."modules/$key/$key"."Load.php"; } } function moduleEnabled ($mod) { global $modules; if ($modules[$mod] == 1) return true; return false; } // Make sure that function includeFunctions($file) { include_once ROOTDIR."modules/$file"; } ]]> Awesome, so we now have a way to load modules, and extend the function set with the includeFunctions API call. Seeing how to use these will be shown next. Writing a Simple Module The simplest module will make a button to click and echo out hello world. So lets do that now!

First thing to know is that we need to know where we can put information on the page. Places we can post will be core dependant. Since the different style will dicticate where we can post module information. Chances are, that will be in a side bar for links. So there will be a $sidebar variable that we will modify.

Remember the module loading function searches in your module directory for a modNameLoad.php file. In this case, it will be myModuleLoad.php

/module/myModule/myModuleLoad.php

]]> First I note that the file myModule/moduleFunction.inc is loaded. This effectivly extends the API allowing these functions available to the system. We can see that the sidebar allows for two types of information, public and admin. I can guess that the admin side, will only be displayed to people with admin level access to the system, and that public will be shown to everyone. We also see that the link that will be shown is: SomeAdminFeature and SomePublicFeature. Both of those will link to the given php page set to that part of the sidebar array.

Next is the functions file. In here is just a set of functions that will be added to the system for use by all parts of it.

module/moduleFunctions.inc

".$param['r_title']."\n"; if (isAuth()) echo "

[Edit]

"; echo "

".str_replace("\n", "
", $param['r_desc'])."

\n"; echo "

"; } ?> ]]> Note a standard I try to follow. Since this function is part of myModule, I prefece the function with that and an underscore. Problems with Modules There are a few unavoidable problems with PHP and this scheme for modules. The most major is the inability to create namespaces. PHP lacks this feature. There is talks on if it should be included in PHP6, but it is still unknown. That is why I highly recomend prefacing your module function names, and variables. Data Management Managing data can sometimes be really tricky with WebApps. Trusting users to always be nice is a mistake. Chances are at some point a user will try to exploit the code of your App. Secure User Authentication User Management and Privledges Style Frameworks End Thank You for listening to the presentation. I hope you learned something about WebApp development and will be able to apply something to a later use.

If you have any questions, ask away.