The purpose of this project is to assess the code and to determine if our lack of using a formal framework is negatively impacting the development.
• Good PHP code should be consistent. Whether that means setting rules for the names of variables and functions, adopting standard approaches to recurring tasks like database access and error handling, or simply making sure all of your code is indented the same way, consistency makes your code easier for others to read.
• Good PHP code should be portable. PHP has a number of features, such as magic quotes and short tags that can break fragile code when they are switched on or off. If you know what you’re doing, however, you can write code that works by adapting to its environment.
• Good PHP code should be secure. While PHP offers excellent performance and flexibility out of the box, it leaves important issues like security entirely in the hands of the developer. A deep understanding of potential security holes like Cross-Site Scripting (XSS), Cross-Site Request Forgeries (CSRF), code injection vulnerabilities, and character encoding loopholes is essential for a professional PHP developer these days.
MVC, OOP and tiers are design concepts, not language constructs, nor file-structuring. We are not using any of the standard frameworks.
From what I have gathered when not using a framework, and when there's not different teams for programming and designing; there's no value in using another template system on top of PHP. Also, separating code from layout doesn't necessarily mean doing it on different files.
For one-off, seldom expanded, PHP web apps these are the recommendations which need to be verified.
Write a 'general utilities' file; there i put some formatting/sanitising functions, as well as a few DB access functions:
• getquery(): given a SQL, returns a result object
• getrecord(): given a SQL, returns a record object (and closes the query)
• getdatum(): given a SQL, returns a single field (and closes the query)
• Put all configurations (DB access, some URL prefixes, etc.) on a '[url removed, login to view]' file
• Write a model layer, either one file, or one for each object you store on DB. There, will be all the SQL constants, present a higher-level API, based on your conceptual objects, not on DB records.
That’s your 'framework', and then you write the 'presentation' layer:
• One PHP file for each page, starts with some simple code to fetch the objects needed, followed by HTML with interspaced PHP code, just to 'fill in the holes'. With very few exceptions, the most complex code there should be for loops. I make a rule to use only one-liners, the ?> should be in the same line as the opening <?php
• Each data-entry form should point to a small PHP without any HTML, that simply gets the POST data, enters into the DB, and forwards to the calling page.
This has all the separation of intents you need, without drowning in a lot of files for a single user action. Each page as seen by the user is managed by a single PHP file.
We require someone to assess the quality of the current code in the application developed to date and to prepare a list of where improvements should be made and why. That's it.