Recently, in an effort to migrate some of my MUD's content to the website, I picked up some PHP. My first project of note with it has been creating a front-end to interface with the mySQL database that now stores our helpfiles.
The MUD itself has a rather steep learning curve (even the help system is relatively complex, as it features a number of different syntaxes to give a power-user the ability to perform various searches), so my goal with the web-based help system was to make it as simple and intuitive as possible to find the information required.
Any feedback on the layout and design would be most sincerely appreciated, as would any pointers from the more experienced PHP gurus out there regarding the structure of the code.
Honest opinion, I think you did a good job with it overall, it functions well overall and seems to be well put together from the front-end side. But I did want to mention that in order for people to look at the actual coding that you used to do that you will have to 'provide' a source copy of the code since browsers will only see the HTML code, not the PHP code. If you do put out source, remember to remove vital information like database names, username/passwords and any other information that you wouldn't want the public to get a hold of.
Very well done! As mentioned in the other post, we can't help you much on the PHP source without seeing the code.
A couple of layout/design issues to investigate: 1.) Font size on Mozilla in the right hand frame is about 8pt, thus hard to read. IE is fine. 2.) Frame border is distracting. Experiment with changing the backgrounds of the frames to either 'blend' the page or keep a distinction depending on your preferences. The current background also has seams. (Intentional?) 3.) Instead of adding a style tag (10 lines or so), have the PHP add a one line link to an external stylesheet. Results in quicker pages, less bandwidth, and more flexible code. 4.) 'Index' isn't very intuitive. 'Help Topic Index' or something in that vein would be more helpful.
1. I actually tested the site at 800x600 on both IE and Mozilla, the latter of which is my primary browser. I'm a bit of a small-font freak, so I rather enjoyed the look; I just wanted to make sure the font in IE didn't get too bloated in size. Of course, now that you point it out I can see how the small font might be a problem for others - any idea if there's a way I can specify a larger font for Mozilla/Netscape-based browsers, while making sure the IE font doesn't get any larger than it already is?
2. Probably would look best if the search index had a solid background color while the display frame had the current background; I'll play around a bit. Regarding the seams - no, not intentional, just a complete and total lack of any artistic/aesthetic ability on my part. I'll have to see if perhaps I can touch it up in a photo editor.
3. Being a total novice at anything more than rudimentary HTML, I'm not totally sure how to accomplish this - does that use standard SSI syntax, or a special bit of code? If it's a server side include, as far as I'm aware it drops the content of the linked file directly into the page, so I'm not sure it would actually reduce b/w usage.
4. Changed. :)
Regarding the PHP code; I've posted the two scripts on our website here and here, sans any sensitive information.
From the article, 'Size Matters' 'The nature of the discrepancy is that WinIE4/5 implements 'small' as the initial value, rather than 'medium' as called for in CSS-1. The result is that without correction, all sizes specified in keywords will be one size smaller with respect to user preferences in conformant browsers than in WinIE4/5.'
There's a workaround in that article, but you could always use absolute font sizing (9pt) or a percentage value (80%) to get a near pixel perfect font sizing between IE and Mozilla.
A stylesheet would be linked to a page in the header, where the file style.css contains the styles defined in the html style tag:
I agree the savings right now might be minimal, but if you decide to 'stylize' everything by adding to your style tag, your pages will start to slowly bloat. Think of it this way, instead of sending 10 lines, 20 lines, or 100 lines of styles defined in the HTML, you'll only need to send 1 line no matter how stylish you decide to get. By including styles in an external file (which will be cached after the first visit), the direct download to the user will be much lighter and your server won't have to generate the additional style tags for each page. Again, a small savings at the moment, but it adds some flexibility to your site design further down the road.
First off your code, so far as I've seen ATM, looks great, well organized. One suggestion that I have from experience is that instead of using 'custom' error messages when things don't work out see if you can implement the actual MySQL based error messages. This will provide you with a much more accurate idea of exactly what, why and where things may have gone wrong. Side note, I'm using your second posted script as the one I'm analizing but all aspects will apply to both. An example is as follows:
mysql_select_db('yourdatabasename') or die('Error: '.mysql_error());
Other small cosmetic things which you might do just to touch it up and such to standards are as follows:
org --mysql_select_db ('shadows'); new --mysql_select_db('shadows');
add an error check to this as well as exampled above, just in case.
if ( !$db ) { echo 'Could not connect to the help database; please try again later.'; exit; }
You probably don't need this as it's kinda the long way to go about things, instead, implement the 'or die();' function here as well and add your own comment after it or something if you want people to check back, such as:
$db = mysql_connect($server, $user, $password) or die('Error: '.mysql_error().' : Please Try Back Again Later);
Those are the only modifications that I can really see and they're more of a cosmetic matter than a functional one. Again great job. =)