KevinM1

Do you have any recommendations? The online manual? http://www.php.net/manual/en/

Tool

That has 'bad idea' written all over it. Why do you feel it's necessary to store code to be executed in the db?

You seem to be confused about what we do here. We help others as they work on their own code. We do not simply hand out fully formed apps. If you want to hire someone, post in our Freelance section. Otherwise the answer is a resounding no.

Generally, there's two sides to handling data: 1. Validation - is the incoming data valid? Does it fit the basic criteria I'm looking for (e.g., does the phone number field actually contain numbers)? Validity depends entirely on what your site does, what you expect data to be, what should be allowed, what shouldn't, etc. In other words, while there are ways to validate incoming data, the actual methods you use are wholly dependent on what you consider represents validity. 2. Sanitation - like scootstah says above, sanitation is about actual security. Making sure the database isn't compromised, that user-supplied data doesn't effect other people negatively, etc. Escaping string (text) data before using it in a SQL query is a must, so use mysql_real_escape_string, or, better yet, prepared statements from MySQLi or PDO. For cross-site scripting (XSS) attacks, turn any potential submitted HTML and/or JavaScript into entities with htmlentities. For images, read through this thread: http://www.phpfreaks.com/forums/index.php?topic=353735.0 That should get you started.

Okay, so have you done anything to secure your data at this point, or are you looking for guidance from step 1?

Do you have any forms? Allow users to upload files? Use a database? It's difficult to recommend a course of action without knowing specifics.

A couple things: 1. You need padding between the <hr /> elements in the right column. 2. You need to format your blurbs better: The paragraphs don't have any padding/margins between them in FF 10.

A .jpg can also contain code.... EDIT: When you can, get yourself a copy of this book: http://www.amazon.com/Pro-PHP-Security-Application-Implementation/dp/1430233184/ref=sr_1_2?s=books&ie=UTF8&qid=1329096463&sr=1-2 It will answer all of your security concerns, and likely inform you of things you never thought of.

Ooh, that's a bad way to describe classes, especially given the language construct of abstract classes. More to the point, classes are NOT objects. The two terms have very distinct definitions in OOP. Classes are definitions. They describe what individual objects are - what they can contain, how they act, etc. No more, no less. It's a bit awkward to describe access control in terms of scope as the object itself will always have complete and total access to everything in its class. Access control defines how code external to an object of that particular class can interact with it.

This topic has been moved to CSS Help. http://www.phpfreaks.com/forums/index.php?topic=353608.0

The first way is far superior. Think about it: Is the API a database? Of course not. It uses a database, but it isn't one itself. Inheritance creates is-a relationships, where an object of a child class is an object of the parent class, with just a little bit extra. Always favor composition (objects containing references to other objects) over inheritance. Unless you're building a family of objects, inheritance will only set you back.

Debbie, this is where writing test cases/prototypes comes into play. Looking at the process in the terms of "I'm going to study, study, study, but only touch code/the database in my live project" is the wrong way to go. We all - even us admins, mods, and gurus - experiment with code we don't fully understand on the side. You need to give yourself the web development equivalent of scratch paper: an area where you can make a bunch of PHP test files and database tables you can play with that's separate from your project space. Reading documentation is good, but it's only half the equation. Don't be afraid to write code. Yes, it's time consuming, but is it any more wasteful than coming on here to ask a question that may not be answered to your liking in whatever time you have? To say nothing of the benefit of actually seeing your code work/fail, seeing any unintentional side effects, and ultimately building your own suite of test cases you can fall back on in case you forget something down the line. Testing and experimenting is an integral part of the process. Don't neglect it.

If those numbers are supposed to represent ids, then you need to stop what you're doing and normalize your data. Relational databases like MySQL are not supposed to be used like spreadsheets. Sticking relationships between different tables into one column is a very bad idea, as you are starting to see. For a quick crash course, read through: http://mikehillyer.com/articles/an-introduction-to-database-normalization/

So, you simply wanted to waste our time when you could have simply written, what, a 5-7 line prototype and see for yourself? Sorry, that doesn't fly. Testing code and writing small use cases and prototypes comes with the territory. Further, you've been here long enough to know that yes/no threads, especially when it's something you can answer yourself in mere minutes, are not acceptable here.

Wow, all of my problems are solved! I'll never have to post here again, because all I have to do is test my code! Debbie That is generally how it works.

super inefficient. Exactly. The whole point of the separate ids is that they represent different entities. Keeping them in separate columns facilitates joins, and allows the db to do the work it was designed for.

This topic has been moved to Miscellaneous. http://www.phpfreaks.com/forums/index.php?topic=353448.0

Ah, okay. Makes far more sense now.

Why use expensive regex when math is easier? $num = 67; $feet = (int)($num / 10); // cast to an integer, otherwise it would be 6.7. So, 6 $inches = $num % 10; // modulus means division remainder, so 7. echo "$feet feet $inches inches";

As an American, I have to ask: What the hell is a quid?

This topic has been moved to JavaScript Help. http://www.phpfreaks.com/forums/index.php?topic=353367.0

In the future, place code within or tags.

Like I said before, without being competent in PHP itself, frameworks aren't going to help you much. The very worst thing a new developer can do is try to rush through things. You'll only wind up learning bad habits and write shit code. Get decent at PHP, learn some OOP, then look to frameworks like Zend and Symfony2.

This is a big leap, especially if you've never programmed before. Frameworks are nice because they do all of the common, low-level tasks for you. That said, unless you actually understand what they do for you, and how they tie into the language itself, you're not going to get the full benefit. You'll also be required to write regular PHP code regardless (frameworks are nice, but they don't do all the work for you). So, learn the language, try to learn best practices (there's definitely a right way and a wrong way to write PHP), and go from there. As for the actual design process, I like to start with the domain - that is, what the site is supposed to do - and work from there. How is your data going to interact with each other? What rules govern those relationships? How will a user be able to use the data? The rest - HTML, JavaScript, etc. - is really just a skin layered on top of the actual domain. Figure out the important stuff first, and the rest will follow. I also tend to address security last. It makes more sense to get things working correctly, then to layer security on top of it all. Hope this helps.