PHP-based Site: Worth It?

[Mongooseman]

Last summer I took a job working on a small company's website. At first I just added some pages they wanted, but by the end of the summer, I rebuilt it from the ground up. The original version looked like something from the nineties, complete with scrolling text and a table-based layout. The new version was made using valid strict XHTML and CSS.

The website has sixteen main pages, and all but four of them are fairly static. The non-static pages are updated in diverse ways. One contains links to PDF files that are overwritten with new information. Another is a table that my supervisor (who has very little web tech experience) updated manually by editing the XHTML file. Another is updated in a similar manner, and the last is a regular XHMTL page that is updated by just adding new divs. The last two hadn't been updated since last summer when I returned to the job last month.

To remedy the painful updating (on my supervisor's part), I started dabbling in PHP, and now I have a system to update the two table-based pages by uploading a CSV file to the server. I'm handling the other two pages a little differently, but the concept is the same. I'd like to eventually get a database backend and an AJAX frontend to make updating even easier and less error prone. In any case, I now have two PHP-driven pages, and two more will be up soon.

I've been considering the usefulness of making the entire site PHP-driven. Most of the content is static, but PHP would potentially open the door for more frequently updated pages. However, I'm not sure whether the time invested in revamping the entire site to use PHP would be worth the outcome. The individual pages I've been changing have definitely been worth it, but I'm not convinced of the benefits of making static pages PHP-driven.

I suppose my question is, should I invest the time and effort into making a largely static website PHP-based? My idea is to create a simple template system, whereby common elements of the page (header, sidebar, footer, etc.) are stored in separate files and placed on the requested page via include() calls. A similar effect is currently achieved using Dreamweaver templates, but that system has a few annoying aspects that I don't like.

[chrishea]

You should look at using a CMS that has most of the work done for you.

[Mongooseman]

I've considered that as well. Our web host has support for several CMSs, including Drupal and Joomla, built-in. I've used Joomla before, and I'm not much a fan. I'd be interested in learning Drupal, though. It seems quite powerful, but it may be overkill for what I'm planning to do. I'm looking into it, though.

[ndeniche]

IMO, the implementationof a database with an AJAX front-end should do the trick (a little hypocritical, since i've ujust done the same thing in my company, but with Joomla)... But since there's much more content (like news posting and bulletin boards), I kinda needed the implementation of a CMS to solve my problem in a faster way.

Using the same method to control pages (files) in a website is not necessarily a bad thing. Just as a CSS file can save hundreds of changes, so can include files. Dreamweaver templates deserve to die a horrible death - you're better off with proper php includes. E.g. a navigation system placed in its own include file can save a LOT of time when it comes to debugging/changes.

If you're importing CSV files, perhaps getting to grips with MySQL would be beneficial. You just upload the CSV, let php do some processing on it - or even load it directly into MySQL. The MySQL data output will always be under control via php-generated html.

Personally, I'm not a big fan of CMSes as they tend to be too restrictive, that's why I go for include files, BUT, if there are a few of you working on content, CMSes are probably the way to design your site - sharing source files and uploading them after each edit is not a good way to do things. There are ways around this, but they tend to be too heavy handed for the casual updater.

I'm not sure about your intended use of Ajax - do you really need it? It won't make updating easier and less error-prone. Although it's flavour of the month, it's just adding another layer of complexity. IMO, you're better off constructing a robust php/MySQL solution.

[scaiferw]

Hand coded PHP and CMSs each have their merits. For a fairly static site like yours hand-coded PHP might be the answere.

You probably don't want non-tech people in the code though.

Consider having the supervisor update the data with a spreadsheet, then put a macro in the spreadsheed to save as a .csv file. Then your PHP page would parse the .csv file on demand and render the page.

I wrote a PHP script (http://www.tutorius.com/import-csv-file-to-mysql-database-using-php) to import a .csv file that you may want to take a look at. (I see WordPress has borked the code display, will fix it when I an but you may find if useful anyway.)

[Mongooseman]

Using the same method to control pages (files) in a website is not necessarily a bad thing. Just as a CSS file can save hundreds of changes, so can include files. Dreamweaver templates deserve to die a horrible death - you're better off with proper php includes. E.g. a navigation system placed in its own include file can save a LOT of time when it comes to debugging/changes.

That's my main reason for wanting to make it all PHP. The Dreamweaver templates cause annoying problems, especially when I sometimes edit outside dreamweaver. Having a similar modularized system without the nasty effects would be the biggest benefit I can see.

If you're importing CSV files, perhaps getting to grips with MySQL would be beneficial. You just upload the CSV, let php do some processing on it - or even load it directly into MySQL. The MySQL data output will always be under control via php-generated html.

MySQL is the next step in the plan. I went with CSV at first because my supervisor (who updates the tables) is comfortable with spreadsheets, I already had some code for handling CSV files, and I wanted to get something out quickly. I managed to get a system in place within a week. I'd like to convert the backend to MySQL but keep CSV as the method for updating, for my supervisor's use. It doesn't sound too hard to do.

Personally, I'm not a big fan of CMSes as they tend to be too restrictive, that's why I go for include files, BUT, if there are a few of you working on content, CMSes are probably the way to design your site - sharing source files and uploading them after each edit is not a good way to do things. There are ways around this, but they tend to be too heavy handed for the casual updater.

Only my supervisor and I ever change the site. She doesn't know web technologies well, but she can update without too much trouble. However, I'm trying to remove the need for her to touch the source directly. I've done so with the pages containing tabular data, but another page, which contains press releases, will be trickier.

As it stands, the press release page hasn't been updated in over a year. This needs to change, so I've begun implementing a page with a form for adding press releases similar to the forms used on other sites to add forum posts. I haven't decided exactly how to do this, though. For one thing, I'll need the page to be only accessible to me and her. I'm not sure how involved a secure login system would be. Next would be the backend. Is MySQL conductive to holding large blocks of text? A press release usually contains well over 1000 characters. I've considered using XML, too; I have a little experience with XML parsing.

A CMS would be useful for this one page, but this is just one page. I'd hate to go through the process of converting to a CMS and enduring the restrictions for a page that's seldom updated anyway.

I'm not sure about your intended use of Ajax - do you really need it? It won't make updating easier and less error-prone. Although it's flavour of the month, it's just adding another layer of complexity. IMO, you're better off constructing a robust php/MySQL solution.

My idea for Ajax was for updating one of the tables. Essentially, my supervisor would click a button beside a row to delete the entry, type in a textbox within a cell to update the field, etc. It would be a little more intuitive for this table than using CSV. It would be dependent on my ability to keep this secure against anyone besides my supervisor and I, though.

My idea for Ajax was for updating one of the tables. Essentially, my supervisor would click a button beside a row to delete the entry, type in a textbox within a cell to update the field, etc. It would be a little more intuitive for this table than using CSV.

OK, I get it. Well, you could use Ajax - the only benefit is that you don't refresh the page every time you change a record value. HOWEVER, the server still takes a hit. A tip here would be to disable update buttons immediately after update click and then to enable them after the server has responded.

From your description, it sounds as though you'll be going for a hybrid include / CMS system. The CSV and CMS updating should happen behind a secure admin area. Using 'sessions', you can build this into your system quite easily. This is another reason for using includes - it would be a nightmare to manually code these routines in every single page.

There are a million ways to skin a cat. One approach I would take:

ROOT/

(top level pages - 16 or so?)

 includes/
   banner.php (gives banner, meta data, head data)
   nav.php (dynamic navigation info)
   config.php (for any global constants or variables)
   functions.php (e.g. for csv routines)
 admin/
   index.php (main page for csv upload)
   edit.php (main page for editing content - can change files or update DB entries)
   login.php (if not logged in, this is the default page when the admin urls selected)
   logout.php (clears login data)
 css/
  (css files and images)
 scripts/
  (any js files)
 content/
  (like includes - but just static content - these can be changed via WYSIWYG editor)

A WYSIWYG editor like CKEditor, Spaw2 or TinyMCE would be useful for creating or updating content (like press releases). I would suggest that these should be saved in a DB as opposed to a file. And yes, DBs are big and clever and will store almost anything you want.

[Mongooseman]

Awesome. Thanks for the help! This is the approach I'm going to take, then. I'm researching the session and database stuff now, and hopefully I can have a working product out soon. Again, I appreciate your input. :)