Took a look at the backend code for the Web UI. I examined a few files, here's what I found regarding it.
inc/dbconnect.php - use a constant for the version. Storing version data in a global variable named $version can easily conflict with other applications when trying to integrate.
inc/settings.php - why is there a function in the settings file? you have an include file named "functions.php" -- having a function in settings is a bad idea and can confuse an end user. Keep the codebase organized.
index.php - In one area I see there's "mysql_query()" being called, and in another it's "mysql_query() or die()". Be consistent.
- There's a lot going on with the HTML generation. In some areas you flip in and out of parsing mode with the PHP start/end tags, and in some other areas you just stay in parsing mode and echo out data. Try to stick to one method.
- All HTML tag attributes should be quoted.
-
Code:
<table class="" style="border:none" width=500" border="0">
^ width attribute has a problem here - it's missing the start quote.
player.php - those six lines to assign "$bcmathloaded" can be easily shorted like so:
Code:
$bcmathloaded = (bool) extension_loaded('bcmath') ? true : false;
Less code, same effect.
- The function getMostEffectiveClasses() declared here seems to be completely useless. Considered removing it?
- Inconsistent style again for handling MySQL query errors.
- Wtf indentation.
- The preg_replace call here is not needed, use str_replace instead - it'll be faster, and the power of PCRE isn't needed here anyways
Code:
$milTime = preg_replace ($find, $replace, $newTime);
- Be consistent with how you assemble your strings. Either use your vars inline using double quotes, or concat with single quotes, or use sprintf(). Try not to mix the styles.
- regarding the use of curl here, I can't tell if it's necessary. Considered using file_get_contents() against the remote URL?
- Determining the "best class" code seems repetitive. Likely, a loop or a function could reduce the amount of code needed and make things more readable.
- ALL attributes should be quoted in HTML to validate.
- Determining the stats in the HTML for K/D could be reduced in size with a function.
- Linking to the tf2 wiki for the weapon's info uses target=_blanc; it should be target="_blank"
Overall:
- I also see there's differences in the templating. The index page only uses <html>, while the player.php page uses the XHTML spec. Again, be consistent.
HTML problems can also throw browsers into the unreliable "quirks mode" which usually screws up page display. If you stay very close to valid against the declared specification, you're most likely to avoid browser display issues.
The web UI would benefit greatly from the use of a template library. Either Smarty or Twig would be good to look into - it separates the HTML from the PHP, allowing you to separate the logic from the display code, and making it easier to change the look of the page without breaking the application itself.
Plus, take a look at PDO. It's got error handling in it that is easy to take advantage of -- you can set PDO to use exceptions, and just try/catch around queries in case they fail. Escaping is extremely easy to take advantage of as well.
.
Linear Mode
