Ways To Improve Your PHP
I've collected some ways to improve your PHP web application development over the years.
MAGIC QUOTES
Turn off magic quotes. These are very bad because it can mangle strings and make it hard to parse stuff. You can google for what I'm talking about.
TEMPLATE
Use a template page. Usually my template page, from the top down, consists of a graphical banner, a ridge, a section title to define where we are in the page, another ridge, a thin spacer line, a breadcrumb set of links to define what page we're on and where we came from, along with "Home", and then a band where on the left I have the username and full name of the logged in user, and on the right on that same band I have the series of menus. I follow this with another thin spacer line. From there on out, it's a blank white page (because these print nicely to a printer) that I can customize to do anything I want. But behind the scenes in the server-side code, I start with PHP tags and then follow it with the HTML. Unfortunately, however, this got a bit messy because I was interspersing HTML and PHP, creating a confusing mess, so now I do all my HTML via functions inside my PHP code section and have no HTML section anymore. Also, I even go as far as building a template of sections in the PHP (using comments) that define what I will do in the page. I've done so many things in PHP now that I've got a standard way of doing things, such as doing includes at the top, followed by initialization of vars with initial values, then read any form vars, or query parameter vars from the URL, then do some business logic, then read from the database, etc. You get the idea. Do what works best for you.
CSS
Worship Cascading Style Sheets. Do not use font tags in HTML and instead put everything through CSS class tags. Think about having the ability to easily reskin the app -- that's cool! The big test is that without this CSS file, your page should be white with no banner, no images, and only black text. You need to run this test on every page and if you're not to this level, then switch things out to use more CSS so that you are.
COLOR THEMES & SKINS
Define a variety of 3 color themes on white pages and then find colors that are in the same hue but blend well with one of these 3 colors. In your CSS, use this theme consistently through your pages to keep users feeling comfortable.
DIVs
Use DIVs, combined with CSS, to format the page instead of doing it with tables, EXCEPT in the case where tables make sense like with columnar grid data like what you'd see with helpdesk tickets or inventory records. Of course, using DIVs when you've used TABLE tags for so long can be frustrating and a big learning curve. Spend about a week trying to overcome that, using examples from the web, and then from there on out you should be okay.
EMBED HTML
HTML can get in your way and it gets confusing to see PHP, then HTML, then PHP again. It's almost impossible to improve and follow. Instead, create a class page with an object called "page" and then call methods (functions) off of that object so that it draws the HTML for you. That way, everything on the page becomes a kind of "gadget". Then, it's easier to compose pages as well as make them look similar.
SEPARATE DATABASE PAGE
Consolidate all your database calls into one single class file page that you include as you need. No single page should use database API specific calls except this page. In this manner, you can now swap out this page with another page and talk to a completely different database. That's cool! I also don't include SQL strings in my pages if I can help it. Instead, I put all my SQL strings into a single settings page.
CONF PAGE
A .conf file is like a Windows INI file. You set settings in it that the application can read and use, and someone who hosts the website or administers it can edit this to change the application functionality a little. Well, I wouldn't bother much with learning the PHP to read these files, nor bother with composing it in this way. Instead, just make a class file with all the settings inside set by prefixing them with $this->
, such as "$this->CURRENCY = 'USD$';". End everything with a semicolon. Then, include this page with the page that needs to read it by using require_once(). You'll find that by using this technique, the speed of the application in reading these files will improve slightly. Also, because this is a PHP page, hackers can't easily see these settings like they could a .conf file in the same directory as the web app.
TEMPLATE SQL
In my settings PHP page (my .conf file replacement), I use SQL strings that has little caret symbols inside "^" where I mean to place some value before it gets sent to the database. I have a short little routine that pushes values into these strings where these symbols are.
SQL INJECTION AND PASSWORDS
Never take a user-supplied password and send it to the database. Instead, read the password from the database for the given username and compare it with the password that was typed. Otherwise, someone could use a technique called SQL Injection to login to your application when they should not. Also, to do things better, create shadows of your passwords with your own encryption routine and store the shadow in the database. Then, when the user submits their password, you could create a shadow on the fly for it and compare it with the shadow stored in the database. By using this means, you have more protection against hacking.
IMAGES
Create a separate folder for your images. You'll make the application programming less confusing. Also, use them sparingly. You'll be amazed how clean an app can still look if you use CSS and sections of color more often then you use images. A few well-planned images are what I recommend, instead. Besides, it improves application performance. Note also that you can use CSS to simulate a kind of gradient or jazz up your banner rather than including images. You can also use CSS and Javascript to make DIVs into buttons.
BIG BUTTONS
If your application has a common functionality that people will most naturally want to do on a given page, then make that functionality into a big button to improve ease of use. If you have a case where you would end up filling the page with big buttons, then sort by functionality and consider using either 1, 2, or 3 buttons from that list, instead.
INDENTING
Properly indent your code!
LINE SPACING
Use line spaces between sections of code that exemplify a certain concept, or which use a certain kind of control structure like if {}, for {}, etc.
COMMENTING
Properly comment your code -- not too much, not too little.
VARIABLE NAMING CONVENTION
For my variables, I use this convention:
- rsA = Rows A
- rwA = Row A
- hA = Handle/Pointer A
- nA = Numerical A
- sA = String A
- dA = Date A
- bA = Boolean A
- cx = Char c1, c2, c3, etc.
- oA = Object A
- uA = Unknown data A
- xA = byref (&) of A
- a + x + A = array of "x" for A
- i, j, k, x, y, z (alone) = loopvars
- g + x + A = Global A of var type "x". To sort of indicate a page "global" in special rare cases where necessary.
SEQUENCE PAGES
I really hate recursive pages and use them sparingly when they make sense. Recursive pages, where you submit form information on a page back to itself, can create some confusing code. Instead, I prefer to create another page. However, if I have login page, I don't call it "check_login" as the page it submits to. Instead, I use "l1" and "l2", where "l1" is the login page and "l2" is the page it submits to. This helps programmers understand my logic a little better.
SMALL FOOTPRINT
I like to build apps with a small footprint. I don't require a lot of dependencies if I can, and I make it easy to deploy my apps by simply putting them on the webserver in a virtual directory, followed by hitting the URL. The website should automatically detect that it has not been configured and provide a way for me to configure it by showing me either a "wizard" set of pages of sorts, or just pages with screenshots and instructions of what I should do manually to configure the application and get it ready for use. So many applications I download from the web have huge, frustrating footprints and steep learning curves before you can use them. This is somewhat aggravating.
This is also why I don't use Flash, Java applets, a bunch of Java, and excessive Javascript (as well as too much AJAX) with my site -- it raises the dependencies.
BACKUP DB SCHEMA
I like to store a backup database schema for those zero day cases where you need to recover the schema again and recreate the database.
REDUCING OOP CRAZINESS
I'm not a big fan of OOP. I use it sparingly where it makes sense. Instead, I use OOP to classify like functions together as methods, and then it's like a toolbox I can include on each page. I don't try to make everything an object. For instance, some developers I know would practically make the lint of their customer's toes into an object if you let them. And why do I do this? Because I want to get work done, not be stuck in meetings all the time.
FOUR HOUR BACKUPS
PHP code usually compresses rather nicely if you don't stick the database into the same directory. Therefore, since I develop on Linux, I use a cron schedule and I schedule backups every 4 hours to occur to copy my directory and back it up to a large USB hard drive. In this backup script, it compresses a copy of the folder as well as deletes any old compressed backups that are older than about 6 months. Routinely I also use a USB memory stick to backup up these compressed backup files so that I have a redundant copy. You never know when you need that old code.
THE JOY OF AN APPLICATION REWRITE
Frustrated with the way you wrote your existing app and how hard it is to improve it? Fine. If you have the time, then classify it as a "prototype" and rewrite it. Sometimes there's great joy in rewriting something along with having a backup of the old one so that you can use it to demonstrate certain features you want to re-implement in the new application.
AVOID PAGES THAT SNAP
Put your most visually-complex page out on the web on a slow server, and test the download. Does this cause your page to download stuff that's messy and then all of a sudden this snaps together, creating an unprofessional experience? If so, then you've done something wrong and you need to rethink how this page is done or investigate the CSS and Javascript as well. You might also want to run it through a tool on the web called HTMLTidy to see if that fixes at least the HTML of it.
TRY DIFFERENT MONITOR SIZES, DIFFERENT OSes, AND DIFFERENT BROWSERS
Before you roll that app out, you should at least test it on Windows, Mac, Fedora Linux, and Ubuntu Linux. You should make it work best in Firefox and make it work okay (but may not look 100% as visually appealing) in IE. Never use IE-specific HTML or Javascript code! Also try different monitor sizes. I've found that the best font is 11px for regular font, and 8pt or 9pt on everything else that I want smaller. Note I must use "px" on the 11px, and "pt" on the smaller stuff, in order for it to come out perfect to my tastes on the web.
ERROR PAGE
Create a single error page where you will send users if they do something wrong in the application or if the application is misbehaving. That way, you can troubleshoot the application a little better.
JAVASCRIPT
Use a single Javascript file to store all your Javascript, and use that extremely sparingly. This reduces dependencies and increases your manageability of the code.
WEB PAGE
Create a class called "web" and stick all your web related methods inside like page redirection, form reads, etc.
STRINGS PAGE
Create a class called "strings" and stick all your string related methods inside too. This will provide a way for you to not have to repeat as much string manipulation code.
TIMEZONES AND OTHER INTERNATIONAL SETTINGS
Don't forget that you need to account for use of your application simultaneously across multiple timezones and you need to accommodate this. You also need to ensure you use a decimal for real numbers in the USA, but it's a comma in Germany and a few other countries. There's a few PHP routines to help you with this, so consider that.
