WICKED COOL PHP.
Copyright 2008 by William Steinmetz with Brian Ward.
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.
Printed on recycled paper in the United States of America
12 11 10 09 08
1 2 3 4 5 6 7 8 9
ISBN-10: 1-59327-173-5
ISBN-13: 978-1-59327-173-2
Publisher: | William Pollock |
Production Editor: | Megan Dunchak |
Cover and Interior Design: | Octopod Studios |
Developmental Editor: | Tyler Ortman |
Technical Reviewer: | Scott Gilbertson |
Copyeditor: | Linda Recktenwald |
Compositor: | Riley Hoffman |
Proofreader: | Jeanne Hansen |
Indexer: | Karin Arrigoni |
For information on book distributors or translations, please contact No Starch Press, Inc. directly:
No Starch Press, Inc.
555 De Haro Street, Suite 250, San Francisco, CA 94107
phone: 415.863.9900; fax: 415.863.9950;
Library of Congress Cataloging-in-Publication Data
Steinmetz, William. Wicked cool PHP : real-world scripts that solve difficult problems / William Steinmetz and BrianWard. -- 1st ed. p. cm. Includes index. ISBN-13: 978-1-59327-173-2 ISBN-10: 1-59327-173-5 1. PHP (Computer program language) I. Ward, Brian, 1972- II. Title.QA76.73.P224S74 2008005.13'3--dc22 2005033702
No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other product and company names mentioned herein may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurrence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.
The information in this book is distributed on an "As Is" basis, without warranty. While every precaution has been taken in the preparation of this work, neither the author nor No Starch Press, Inc. shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it.
INTRODUCTION
This book is for the developer who has stumbled on to PHP and wants to know how to get things done. You should know the basics of programming, and chances are you've seen many online code samples. But you may be wondering why some examples are much more complicated than others when they do the same thing.
Care has been taken to keep the examples in this book as simple as possible and to explain as much as possible about every piece of code. To keep client and server code confusion to a minimum, there isn't much JavaScript here. Everyone's impatient, so , "PHP Security," deals with keeping your scripts secure.
, "Working with Files," deals with file manipulation.
With these fundamentals covered, , "User and Session Tracking," covers the details of session tracking and management. With multiple users on a complex website, it's important to keep track of what each user is doing so that one user's session doesn't interfere with another's.
, "Working with Images," cover email and image manipulation, respectively. These tasks are often ill-suited for webserver scripts, so the chapters describe relatively lightweight tasks that can add significant value to your site.
In , "Using cURL to Interact with Web Services," you'll learn how to make your server interact with web services on other sites via XML.
Finally, , "Intermediate Projects," contains three fun little projects that can be incorporated into larger websites. These projects build on what you've learned elsewhere in the book.
Chapter 1. THE FAQS OF LIFETHE SCRIPTS EVERY PHP PROGRAMMER WANTS (OR NEEDS) TO KNOW
The scripts contained in this chapter answer several questions that clog PHP forums and discussion groups all over the world. They include the following:
How do I add Previous/Next links to my shopping cart?
Is there an easy way to make every other row in my table a different color?
I have a big array that I need to sorthelp!
What's the best templating system to make the same HTML enclose my data on every page?
Although there are more complicated scripts later in this book, and many others that you may find more valuable, these scripts answer the questions that I see again and again. The only thing these beginning scripts have in common is that theyre either the things that everyone should know or the things that everyone wants to know. Hand this chapter to a beginning PHP programmer you love. Shell thank you for it.
Note
If you're not afraid to start root will also help the beginning PHP scripter and can make life a lot easier for the midlevel PHP programmer. You might want to go there next .
#1: Including Another File as a Part of Your Script
Most serious applications have a core library of variables and scripts that are used on almost every page. For example, if you're writing a shopping cart that connects to a MySQL database, you could declare the MySQL login name and password on each page of your cart. But what if you need to change the password? Changing and uploading every file in your shopping cart could become a huge issue.
Rather than declaring the password in each of your page scripts, you can store that name and password in a separate file. You can then include that file as a part of your script, and whatever variables you declare in that file will be declared in your script!
Furthermore, you can store long scripts or functions in a separate file and include them only when you need them. For example, the function that gets real-time UPS shipping quotes is 24KB worth of XML processing goodness, but you use it only when someone chooses UPS as a shipping option. Why not store it in ups_ship_quotes.php and call it only when necessary?
In fact, almost all heavy-duty PHP applications have a file called something like config.php, which declares the critical variables that every page needs to know, such as the MySQL name and password. Those same applications also store frequently used scripts in different directories. Programmers then mix and match, taking the check-to-see-if-a-user-is-logged-in script from one directory, including the get-the-relevant-data-from-the-database script from another directory, and writing a central script that screens the data based on whether the user is logged in or not.
And here's how to do it.