Build a Simple PHP Application isn't so simple

I feel the same way Andrew. I have one stage left, and I feel that it hasn't really been sinking in very well since the Paypal stage. My plan is to finish it up going just through the motions and copying and pasting, and then start over pretty much immediately.

Hey Andrew,

Thanks for the feedback! It sounds like there are two main things from the videos that aren't clear to you:

• What is the PayPal Shopping Cart? (Why is it better than the alternatives?)
• What does it take for PHP to send email from the server where it runs?

Does that sound right? If not, could you clarify what is still not clear? I'd be happy to try to explain these items a different way here in the forum -- with the hopes of finding a better way to cover these concepts in the videos. Those two items are about integrating PHP code with other software or services (a mail server or PayPal), and it's not surprising that these two items are causing some confusion.

(One other note: When you integrate with a third-party library or service, you very often will copy and paste the example code and modify it. There's no way you could know enough about the inner workings of these systems to sit down and write the code from scratch. How would you know what name to give their elements? Or what methods to call? Because of my previous programming experience, I can look at the example code and make some intelligent guesses about how the underlying code works. In the PayPal videos, for example, I tried changing the method from POST to GET just to see if it worked. It did! Then I knew I could link to the shopping cart page instead of needing to use a form submission.)

Regarding the contact form, I suspect there are two issues that are causing confusion:

1. Why can your web server send email but mine cannot?
2. What does the PHPMailer library do?

(1) Servers are just computers like a desktop or laptop computer. They have an operating system and other applications installed. If I sent you a Apple Pages document and asked you to open it, you'd only be able to open it if you had software installed that could do that. If I asked my web server to send an email, it's a similar issue: it could only send an email if it had software installed to do that.

If you have Apache running, the server can handle incoming and outgoing web traffic, which makes it a web server. But if you want it to be a mail server also, to be able to send and receive email, it needs something different. PHP does have a mail() function, but it will only work if the server can send email. Most shared web hosts do have that enabled, but my cloud server does not. (It's actually a good idea to use a different server for sending email than for handling web traffic; that's what I cover in that blog post you mentioned.)

(2) Because servers can all be set up differently, each server can require a different set of code to send an email. Instead of covering all the different ways that it might work, I decided to use a third-party library that can handle all these different scenarios with the smallest amount of differences in code. You include the library, create a new PHPMailer object, set a few properties, then call a method to send the email. That method call is the same regardless of your server set up because the PHPMailer library handles all the differences. It has a lot of conditionals that run different code depending on the server's configuration.

Does that help?

I think it's a pretty good dose of everything. PHP is a complicated language at first because it has so many moving parts all at once. I've struggled learning it for 7 months now, but things have finally start clicking.

Try watching the videos a second or third time. I did, and you pick up a lot of things you missed the first time. It helped me.

I just built a contact form using phpmailer and followed how Randy Hoyt taught it, and I can say that I got everything done without issue. Yes, phpmailer has changed, and it's now on github. But as it sounds like you figured out, you don't want to just copy and paste exactly what and where the video says too, but rather learn how to read the code for youself, so when it changes you can still understand what is going on. Sounds like you were able to do that! :)

In regards to this: "The whole time I was thinking this can't be the best way to set up an e-commerce site surely?"

It's not the best means by all, but it's not hacked together. But remember this was a basic course. It would have been way too advance to do it any other way.

I think it's always going to seem a bit of a hack integrating with 3rd party services like PayPal. I found the same issue while integrating with google maps ( JQuery project).

The key thing with the eBay integration is that Randy is showing you how to alter the standard code that eBay gives you to better fit your site's styling, while keeping the information needed to talk to ebay's cart when the new button is pressed.

Re-Watching definitely helps you figure it out.

Hi Randy,

Thanks for replying to this. I guess my biggest problem is that I don't simply like to copy and paste code without some level of understanding of what I'm doing and how it works. I may not have to understand all of the ins and outs but I would like to feel confident that I know what I'm doing and why for when I try to do something similar.

For PayPal, yeah I guess it was asking why its better than the alternatives. Creating a website which you can buy items from is a strong skill to have but after watching these videos, I was left thinking this is very flakey and that there has to be easier / better or at least more robust ways to build an e-commerce site.

As for sending email, yeah. I watched the videos and followed the examples and again I can copy and paste the code but I wouldn't say that I understood what I was doing or why I was doing it and I wouldn't feel confident I could do it myself, especially if your web hosting does not allow you send email

Thanks for the reply! Let's start by talking about the PayPal Shopping Cart. I'll first explain what it does and how the code we copy and paste from their site works; then I'll explain why we are using it.

(1) When we first wrote our contact form, we started with a file called contact.php that had the form on it. A site visitor could fill in some information and click submit. That information was sent to another file called contact-process.php. In the form on the contact.php page, we specified an action attribute that told the form where to submit like this:

<form action="contact-process.php" method="post"> ...

We could then write code in the contact-process.php file that received the information from the form and did something with it. Remember all that?

The "button code" we copy and paste from PayPal does essentially the same thing. The main differences are these:

• The action attribute on the form points to a page on PayPal's servers.
• Most of the input elements have a type of hidden instead of text to define the values sent to the server (instead of requiring a user entering them).

When a user clicks on the Add To Cart button on our site, it submits information in hidden input fields to a file on PayPal's servers. PayPal has server-side code that adds the product to a shopping cart. Which leads me nicely into ...

(2) Building a shopping cart and checkout process on your site is actually quite complicated. I touched on this a little when I talked about "persistence," but let me go into a little more detail here. With our contact form, we aren't saving the submission anywhere. If someone sends us a message and the clicks Home, our website has no idea that they sent us a message a few clicks earlier.

Let's say we code the Add To Cart buttons to submit to our server instead of a file on PayPal's server with an action something like add-to-cart-process.php. We'd have to somehow save the fact that this user added a product to their cart. But where would we put it? We couldn't edit our PHP code every time someone did this to add it to an array. We could save it in a session or a database, but that requires more sophisticated code. We'd have to tie each shopping cart to a user and secure it somehow so that one user couldn't see or manipulate what another user had added to their cart.

The shopping cart is difficult enough, but the checkout process is worse! We'd have to encrypt all our traffic with SSL so that no one can intercept our customers' personal contact or payment information. We don't want to save credit card information on our web server, so we'd have to integrate with a third-party merchant account API to bill the credit card. It can be a lot of work to set up this integration securely.

For people just starting out, I recommend using a third-party shopping cart service like PayPal, Shopify, or ShopLocket. I volunteer time to run a website for a non-profit literary organization, and I use these exact same techniques for a catalog with hundreds of products. I also run a commercial web service with monthly subscription fees, and for that I went through all the steps I described above.

Does that help understand what PayPal is and why we are using it?

Yes, I think spelling it out like that helps, thank you.

I guess the one problem I have with using paypal is that you have to essentially create all of your products in paypal, and again on your website and tie the two together which could potentially be a lot of work. Perhaps this is something thats more steamlined once you get more into dealing with database driven websites?

I appreciate you taking the time to reply to my posts. Very helpful for when you get fundamentally stuck on something :)

You are correct about this drawback to using PayPal: the way we are using a PHP array to fill data into a template file does require us to add new products in both places. PayPal actually does have a way that you can bypass this by letting you create any product you want on the fly. (That's what I use for the non-profit site I mentioned.) They can't verify the pricing in that case, though, so you have to double-check every order -- but it's definitely much easier to maintain. Adding a database is not enough to streamline this process; you would actually have to manage the whole shopping cart process on your own site to solve that.

(I still owe you a response about the contact form and PHPMailer. Stay tuned for that soon! :~)

(Oh, and I will definitely be updating the video to mention Github now. PHPMailer has been hosted on Google Code for years. As soon as I make a video tutorial, of course they move the project to GitHub! :~)

Yeah, I think that clears that up, thanks Randy. Just to check, if your hosting doesn't allow you to send email and you have to use a service like Postmark or SendGrid, is it just a case of either using their API or using SMTP and combining that with some more features of PHPMailer?

Excellent! Postmark lets you send email using SMTP or their API. You could use their API, but it would probably be easier to use some more features of PHPMailer to send it using SMTP.

If you use the API, you can get a few more features. If you use SMTP, it will be much easier to switch to another provider in the future.