PHP / XML / MySQL

[Slovak]

What would you recommend for a small book publishing business that's migrating their web site? Currently it's written in ASP with a MSSQL database back end. The current full-fledged content management system is an overkill for a site with less than 10 static pages and 20 book titles, with no new ones in the foreseeable future (years). The new web host has an Apache server, so PHP and MySQL would be the weapon of choice.

Static pages will more/less migrate with the current content. As I see it there are three options for managing the book titles:

1) Static site with each book title having its own page. It's not web 2.0, but it would be easy to manage the pages with no performance degradation due to polling back-end sources.

2) Semi-static site that stores the book titles and associated information in a standard XML. PHP loads the XML, parses it for the relevant title, displays information. Easier to manage the display template for all 20 titles. I am concerned with loading a 200K XML file each time a visitor clicks to see book details. In effect, this approach would be loading 20 books but only displaying one of them.

3) Delve into MySQL, effectively migrating their current setup from MSSQL. Would the increased development cost and necessary knowledge to manage it down the road be offset by 'doing it right'? Again, the book titles are not actively changed, nor are there any new titles scheduled for publishing.

Peter...

 

[Delameko]

By the sounds of it #1 is totally viable. As long as the person who will need to update the pages when the time comes knows how to read HTML (or at least how not to the break the HTML that is there) I don't see any problem in it.

I wouldn't recommend #2 - as you say, the XMLs will get parsed every time, unless you know how to impliment effective caching. Usually you'd use this method if the XMLs were changing a lot and being updated by a third-party.

#3 is possible. But sounds like a lot of work/learning/cost for something that can easily be achieved by #1.

 

[brisbaneguy29]

What About

I just know this will be flame bait to all the elitist web nerds on here, but for such a small site, why not consider contribute? It seems to me that anything more will be total overkill for the end client. 20 books just seems a waste to go and set up SQL and PHP or XML.
I know I will probably be shot down, and all the nerdlingers will tell you that it must be php all the way because that is the way it should be done, but in my humble opinion, what is best for the client?
How often do the book titles get updated? How often do the titles get added? If it is only very rarely, why go to the expense of 2.0? Does it need to be 2.0? When did just giving the end user static HTML not work anymore? If the end user gets the info they are looking for, job done. Sure 2.0 is cool, but does it really need to be? These are the questions you need to answer, before you build the site.

 

[Slovak]

By the sounds of it #1 is totally viable.

#3 is possible. But sounds like a lot of work/learning/cost for something that can easily be achieved by #1.

Thanks for your input. I tend to agree with you, but the geeky side of me wants the challenge of cool 2.0. I really think #1 is the most solid option.

 

[Slovak]

why not consider contribute?

Are you referring to a specific software/setup? Sorry to be so basic.

I know I will probably be shot down, and all the nerdlingers will tell you that it must be php all the way because that is the way it should be done, but in my humble opinion, what is best for the client?

The best? Simple and fast. They're paying $$$ for someone to 'manage' the CMS.

How often do the book titles get updated? How often do the titles get added? These are the questions you need to answer, before you build the site.

Never and never. OK, that may sounds too definitive, but not in years, and not for a few more is probably a very safe answer.

I do tend to agree with choice #1 as well. Appreciate your insight.

 

[tyr2]

I'd consider option 2 (the XML) but rather than one large 200k XML file have one XML file for each book with another one defining the index.

If you've only got 20 books then the index will be tiny and you could just parse that the load the relevant XML for a single book

Separation of content from presentation is (imho) important, especially with a view to long term maintainability. If you go for a fully static design your pretty much stuck with that design without a lot of faffing around if you want to make, even minor, changes.

 

[angelwatt]

I know I will probably be shot down, and all the nerdlingers will tell you that it must be php all the way because that is the way it should be done, but in my humble opinion, what is best for the client

You must be new here if you think that's the type of responses that are given.

Since the content doesn't sound to be changing much if any for some time I would probably go with a mostly static web site. Depending on how you define web 2.0, I doubt you need any of that. Are you asking for people to rate the books on the site, or give comments? Unless you are you aren't doing web 2.0.

For the XML, you can use XSLT to transform most of it into static web pages, if you have someone with the know how. I wouldn't toss away the XML, but leave it in archive in case you need it. The one thing you may want to use PHP for is to make things more manageable. You can have a common header, footer, navigation, etc. content managed from a couple PHP files and have those included on each page. This way you only have to update one header file and have the change propagate across all pages. That would likely be the extent that you would use PHP for.

For the MSSQL, I would try to find a way to migrate it to a MySQL format simply for future use. You wouldn't need it for this site. So getting this converted wouldn't be anything that needs to be done soon.

Contribute is OK, but isn't free. There's free options out there for doing web design. What you use will really depend on your comfort with the web languages involved or whoever you want to do its comfort with them. You can check the stickies in this forum to find various software. You might also want to look into a CMS (content management system) for controlling the site. Some are pretty easy to install and manage, though may be somewhat of a pain to migrate your current content into one.

 

[Slovak]

I'd consider option 2 (the XML) but rather than one large 200k XML file have one XML file for each book with another one defining the index.

If you've only got 20 books then the index will be tiny and you could just parse that the load the relevant XML for a single book

Separation of content from presentation is (imho) important, especially with a view to long term maintainability. If you go for a fully static design your pretty much stuck with that design without a lot of faffing around if you want to make, even minor, changes.

I already have the header / navigation / footer all in include files, but I like your idea that takes the individual books one step further. Thanks for the suggestion!

 

[Slovak]

Are you asking for people to rate the books on the site, or give comments? Unless you are you aren't doing web 2.0.

Nope, none of that functionality.

The one thing you may want to use PHP for is to make things more manageable. You can have a common header, footer, navigation, etc. content managed from a couple PHP files and have those included on each page. This way you only have to update one header file and have the change propagate across all pages. That would likely be the extent that you would use PHP for.

I'm already using the includes for header / navi / footer.

 

[SC68Cal]

Skip the XML? Use a small database.

 

[Slovak]

Wanted to thank everyone for their input. I ended up with one php file getting a value from the URL, then loading up the XML for respective book title (1 title per XML) into a standard presentation template. Works great and didn't take much time. Allows for possible content edits without needing to update multiple files; or changing the presentation elements in one place for all 20 book titles.