Can I Handle a PHP/MySQL site?

March 1, 2007 8:32 PM

An 800 item database driven site in PHP and MySQL? Am I crazy?

Is this a good project to cut my teeth on?

So I know XHTML and CSS. I'm all over static webpages. Now I need to step up to the next level.

My friend has asked me to create a site for her to sell her photography on. Each item will have several options (large or small, vertical or horizontal, caption A or caption B, whatnot). I've done all the math and there's about 800 unique possible combinations of products that could be ordered.

My idea would be to design the site so that users would drill down through the different combinations, with the options at each level narrowing as the user goes along, until finally the final product is selected. Then a string of data could be passed on to PayPal to handle the e-commerce and an email would be sent to my friend to ship the item. I'm mentioning PayPal here because as a newbie to PHP and MySQL, I don't even want to try and handle the security side of e-commerce.

I know I can find the PHP and MySQL tutorials on my own (I've found this and this right off the bat), but I'd like to know if I've bitten off more than I can chew here. I found this AskMeFi question, and I like this answer (Dreamweaver integrated with Contribute), but I'm not sure that answer applies to me (plus my standards-centric web classes have thoroughly ingrained me in the "WYSIWYG=BAD, Notepad=GOOD" brainwashing.

I've already got a LAMP through Dreamhost.

posted by mysterious1der to Computers & Internet (20 answers total)

What's your actual question? Is this too hard to do? Is this a good design? What?
posted by aubilenon at 8:35 PM on March 1, 2007

Best answer: You might just learn ruby on rails, it's sorta hyped, but it does keep the database specifics away from you while you spend time on design and the code. Similar tools exist for php and python and such, but rails is the coolest.

As far as the security side is, be sure to read up on SQL injection attacks, since that's the biggest attack that gets run against sites, there are certainly others, but that's the big one.

As well, in terms of database design, learn about normalization, and basically just keep in mind that you should basically abstract everything you can (well, within reason, read up...).

I don't have any experience in php itself, but try to split out the display part from the logic part. That'll make the code MUCH easier to work with later, instead of having to untangle html and php.

Hopefully that's a few things to start googling on, good luck on your project.
posted by cschneid at 8:42 PM on March 1, 2007

It's easy to do. If you've got the basics down, you'll be fine.

Remember, tutorials are your friend, Notepad is good, and php.net is a great function reference for PHP.

SQL is easy enough, Dreamhost makes it easier with PHPMyAdmin.
posted by thebigdeadwaltz at 8:44 PM on March 1, 2007

How much time do you have to learn this? Do you have any experience with databases? Any previous coding experience at all (are you starting from "hello, world") or have you worked with classes and arrays (etc.) before? How much do you know about web security?

Do you really need to start from scratch? Drupal has a ready made framework that is relatively simple to add commercial and image gallery/management modules to, plus there are many, many, MANY alternatives (I suggest Drupal because of my familiarity and love of the design). Drupal, at least, is based on PHP and can be made pretty and original with CSS.

I think a CMS would be a quick way to get the site up with as little fuss as possible, and you can use it as a way to learn PHP and MySQL at a pace that is more leisurely.

Just my thoughts as a advanced beginner in the PHP/SQL realm.
posted by dozo at 8:56 PM on March 1, 2007

How much do you know about web security?

I mean writing secure code, not "don't write down your passwords".
posted by dozo at 8:58 PM on March 1, 2007

From what it sounds like, you really may not need a database to accomplish this.

You say 800 possible combinations. So combinations effect the price, right?

So you've got, say, 10 items with 10 different colors and 10 different sizes.

So write code that runs a formula:

Base Price of item 1 = $10
If Color = 1, 2, 3, add $1
If Color = 3, 4, 5 or 6 add $2
If Color = 7, 8, 9 or 10 add $4
Add $1 for each size increment

So if I want Item 1 in Color 3 and Size 6:
$10 + $1 + $6 = $17 .. that's what my paypal button puts in as the price and I'm set.
posted by twiggy at 9:04 PM on March 1, 2007

Best answer: Eight hundred items is a pretty tiny database. See the "57967" in the URL of this page? That probably means there are almost 60,000 items in the database table.

Build an Online Store Today with PayPal, PHP, and MySQL

PayPal's Website Payments Standard: Overview and Shopping Cart

Code Igniter is a model-view-controller web application framework for PHP that's similar to Ruby on Rails. Cake PHP is another PHP framework.

I've installed Code Igniter easily on one of my Dreamhost sites. Dreamhost also supports Ruby on Rails.
posted by kirkaracha at 9:08 PM on March 1, 2007

Yeah... start with a CMS. Drupal, Textpattern, and others will do the trick. By checking out the code and making modifications you can do this without messing up terribly security-wise.
posted by tmcw at 9:09 PM on March 1, 2007

ExpressionEngine is a PHP/MySQL CMS (by the same people who did Code Igniter), and it comes with a commerce module.
posted by kirkaracha at 9:11 PM on March 1, 2007

Response by poster: Thanks all around. These are all great answers and I appreciate the push towards a "modify-an-existing-product" solution. I'll be checking all the links out.
posted by mysterious1der at 9:15 PM on March 1, 2007

This is certainly a great way to jump into PHP/MySQL. Or any web application programming for that matter. It's better to learn the nitty gritty then have everything handed to you. Even Ruby on Rails makes things easy.

It might not be the best way to build someone's e-commerce site, but it IS a great way to learn.

My suggestions. Download and install your own LAMP distro. Its better to mess around in the database this way without destroying anything. I use XAMPP (speficially XAMPP lite).

Get a MySQL frontend like HeidiSQL or SQLyog. I'd learn a little SQL before you start working in PHP. Then go to php.net/mysql and read up.

Have fun!
posted by mphuie at 9:19 PM on March 1, 2007

I'm running osCommerce on a shop with over 17,000 products. It's not hard. (The code is pretty nasty, but I'm not an uber-programmer and I've done all right at customizing it.) It has "product attributes" built in, which sounds like what you might need. That allows you to set lots of different options (with custom prices) for each product. So you could just have each photo as a product, and then have attributes for orientation, size, etc. osCommerce has a pretty active developer community too with lots of plugins available for various shipping/payment gateways.
posted by web-goddess at 9:45 PM on March 1, 2007

It's not completely absurd to try something like this as your first PHP/MySQL project, but it's going to be mighty difficult. Another thing that hasn't been brought up so much is who's going to maintain the site. If your photog friend is going to maintain it, she's going to need some sort of interface to add photos or change pricing or eliminate old stock.

Writing the code for that interface is arguably a third of the battle at least. So on top of figuring out a proper database schema (and exactly what is the database going to be used for? you never established that in the question—is it just to keep track of items, or are you going to track sales as well, or...?) and writing the logic and templates for the consumer site, you're also going to have to write an admin interface to add things to the database properly, that will validate info so your friend doesn't mistakenly muck up the site with bad data, and be relatively secure if it's to be hosted on the web—which probably means a simple server password, but could theoretically entail a user authentication system. In any case, it's another barrel of monkeys from the display site, and that could be a problem. Then you add in Paypal integration and it gets even lovelier, especially if you want to capture sales data after the transaction.

In short: I hope you really like challenges.
posted by chrominance at 9:57 PM on March 1, 2007

My first PHP/MySQL project was for a wedding photographer -- he hired me to build an online proofing system to which he could direct his brides after their weddings and permit them to order prints from him. It all sounded straightforward enough -- I mapped everything out in a notebook and set about coding it with php.net in one window and phpbuilder.com in the next.

It was much more than I anticipated, but I got through it. It took 3 times as long as I intended, but I got through it. I didn't get much sleep, but I got through it. Looking back at the code, however, it is the most embarrassing, utterly terrible project I've ever turned out. It's a great feeling 8 years later because it lets me see how far I've come.... but, like, I'd hate for your friend to be a guinea pig for what will likely be your future worst project.

Now... having said all that... I built my own photography sales website (selflink) that does essentially everything you've mentioned -- product variants, custom cart passes data to PayPal, etc. And even though I had about 6 years of additional experience coding some pretty heavy content management applications, my lil' photography site remains the most challenging project I've endured. And not even for the big picture items that'll likely benefit you most (e.g. connecting to mysql 101, how to use arrays, etc). It was stupid minor issues, like figuring out how to make the custom cart retain full functionality while remaining compatible with PayPal. Or how to write logic in php to generate the neccessary empty table columns if the current product list doesn't fill out the table. It's not the stuff that makes up 90% of the site -- it's the minor 10% of things that -- despite their seeming innocence -- are absolutely integral to the functionality of the site.

What I would suggest is you view your friend's e-com project as a long-term objective and work at it little by little. Don't try to build the whole thing up front. Break it down into smaller pieces: how do you structure the database? how do you insert records into the database? how do you pull them out? look at dynamic page generation and templating. I mean... all of these are quite large projects on their own. It's the CRUD. But they're pretty integral if you're aspiring to be a PHP knowitall. (And don't get me started on all those product variants -- that's a fulfillment and coding nightmare.)

And having just advocated PHP, I should disclaim that I totally gave up on PHP last year and am launching a completely retooled Ruby/Rails version of my site next week. If you're interested in riding the wave of internet pop culture, Rails will take a ton of the CRUD headaches out of your life (as will some PHP solutions like Cake), but I think learning the theory behind CRUD is still important.

I'm rambling -- I don't know that I addressed your question sufficiently, so in summary: the project you have described is doable, just like climbing a mountain or running a marathon, but it *is* in fact much more complicated than it seems on paper. Ruby/Rails might allow you to get further along in your project faster than PHP, but the actual project you've proposed is quite hefty. And finally the obligatory: I've been there before on both fronts for the same project, so if you have additional questions, please don't hesitate to shout -- email is in my profile.
posted by Hankins at 11:01 PM on March 1, 2007

The customisation of the products means that using a ready-made ecommerce package may not be viable; bespoke may be far simpler, although there'll be complications you haven't yet spotted.

If you have some inherent programming talent you can do it, but bear in mind your friend will be getting messy code, bugs and probably a security hole or two. If they're patient, understand that you're a beginner, and it's not going to jeopardise the friendship, then you can give it a go, but expect to make lots of mistakes.
posted by malevolent at 12:31 AM on March 2, 2007

Using a framework like Code Igniter, CakePHP, or Ruby on Rails would keep your code organized and might reduce the likelihood of bugs and security holes.
posted by kirkaracha at 6:59 AM on March 2, 2007

Definitely get into a framework. I think you will have a much easier time finding a decent web host for cheap going the CakePHP route. I have tried 3 different Ruby on Rails hosts before landing randomly at one that actually knows what they are doing, and the only reason I found them was because I was looking for someone who did mod_python hosting well.

Email me if you want to talk web hosts and why they sucked so much.
posted by zackola at 7:07 AM on March 2, 2007

I'm in a similar boat to the OP.

I've got some scripting background, but it's been years since I really was into it. It's something I've wanted to get back into, though. I've dabbled in PHP, and even picked up the "Web Database Applications with PHP and MySQL" book a while back, but never got very far.

The thing about adapting an existing CMS is that if it needs serious customization, you're going to need to learn all the conventions and utility functions in that CMS, so there's an additional layer. That said, it still may be faster to get something off the ground that way, and there's a lot of code you won't need to write.

I've got an idea for a community site, and I vacillated between trying to adapt an existing CMS (I already know and like Drupal) and writing it from the ground up. On the advice of some friends, I'm learning Ruby on Rails and going the ground-up route.

This is fine for me: my project has no deadline, and is as much a learning opportunity for me as anything. It may not be fine for you.
posted by adamrice at 7:09 AM on March 2, 2007

For your purposes, I'd stay with PHP for this one, especially if you're committed to using PayPal. There may be better packages out now, but I had to roll my own PayPal support when I put together an e-commerce site on Rails about a year ago.

Also, you'll have an easier time installing your app and getting it purring smoothly in most hosting environments short of a dedicated server; Rails, she is a finicky bitch.

There are some good, light frameworks out there no matter what language you end up writing in, but the Rails learning curve seemed steeper to me than PHP.

Zackola, can I ask which Rails host you ended up with?
posted by sonofslim at 10:47 AM on March 2, 2007

I agree with other posters - doing a full e-commerce site (even using paypal) is a huge task as your first site. Definitely break it down into smaller chunks - or mini-projects.

i would build a simple blog first - or just a tool to edit a 'welcome' message that is stored in a db. then build from there.

i recommend you stay away from frameworks. at least initially. start simple so you understand everything that is going on in your code. That said, I do recommend a templating system like Smarty so you don't mix your HTML and PHP. (i know PHP was designed to mix with HTML, but it's really better to keep them separate.)

os-commerce is a nasty spaghetti mess, and your site will look and work like all a million other os-commerce sites. it's more for people who want a cheap ecommerce site and aren't interested in learning how to do it right, or better. in short: quick and dirty.

I found drupal to be frustrating since it was a complicated, weird framework. and i hate coding PHP in a webbrowser. again, it seems to be more for non-technical people who just want to get a CMS up and running. i've been coding for years and the simplest things took ages. again, not a great place to start learning. (the main thing i learned was patience!)
posted by kamelhoecker at 8:20 PM on March 2, 2007