roopurt18

I've not tried this when using an iframe for RTE purposes, but what about setting up a script that takes an article ID through $_GET and displays the article. Then you could just set the src attribute of the iframe to that script.

Assuming that is how the second argument for strip_tags is formatted, yes. You had it in your original code I think, but remember you only need to stripslashes if the gpc magic quotes are turned on.

How much thought, care, and design you put into a program is really answered by the question: How much do you care about its maintainability? If it's a large project that you'll be working on for a while or may be coming back to in six months, putting some thought and effort into some sort of design (whether it's object oriented or procedural), will pay off. If this is a quick project that you're setting up for someone else it really doesn't matter if you put a lot of thought or effort into it since they don't know squat about it. I know this sounds like lousy advice but the primary concerns for the client are 1) How long will it take (i.e. cost) 2) Does it function? No matter how well designed or implemented, there is no such thing as a software project that doesn't require maintenance. Therefore, clients and project managers will budget this accordingly. They expect to pay you or someone else at a future point to come in and modify the software. If they ask you to return to maintain it then you've won yourself more money in the pocket. If they ask someone else and your design is terrible, that next person might hate your guts, tell the client how bad you were, and then the client might hate your guts; but that didn't hurt your situation as they didn't ask you to maintain the software anyways. Note that what I said about not needing to design does not imply that you should be careless about validating data or error checking. You should always take the proper precautions when dealing with user input. It's hard to design when you're first starting off. It takes a lot of practical experience to be able to sit down ahead of time and think of everything before you actually face it. A lot of the developers that frequent these forums have their own code libraries that they've built up over time, adding new features as the need arises. The good news is that programming is a self-optimizing art-form. After you perform the same 3 lines of code repeatedly on a single page you will say to yourself, "Maybe I should wrap this in a function." Let's say those particular three lines dealt with data validation. After you've created a bunch of data validation functions that are jumbled all over, the better sense in you should be saying, "I really should gather those into a central location." Design can only be taught by others to a certain extent. Most of what people know about design is what they've experienced first hand. P.S. Don't bother with template engines. As rlindauer pointed out, PHP is itself a temple engine.

It bothers us all I think! I've seen enough of your posts to know you know a thing or two about what you're talking about. Anyways, to answer Nightslyr's question, adding strip_tags or htmlentities to your database cleansing function is not really necessary as it doesn't protect the database. In most cases, stuff going into the database is going to be re-displayed to other users later, so it is usually appropriate to do something about embedded HTML / Javascript. But this is not a concrete thing that you do 100% of the time like you do with mysql_real_escape_string(). When you remove HTML from a user's input depends on who that user is and how that input will be used later. A CMS, for example, may not strip html tags from posts coming from the site's administrator because you can assume the site's administrator is not trying to harm their users. However, you would want to remove at least Javascript and iframes from comments posted by anonymous users. A lot of sites combat this in one of two methods. Either they use BBC markup and remove all tags from the input and replace the BBC markup with actual HTML markup when redisplaying the input. The other alternative is to allow certain HTML tags and strip all others via the second parameter to strip_tags.

Well, it was your edit that got me. I was going off the code block at the top of your original post. I still prefer htmlentities as it will show you the full content of the originally entered characters. Also, I'm not sure strip_tags will protected against: ?p=<sc<script>ript>document.href.location=www.spoofeddomain.com</sc</script>ript>

@frost110 Stripslashes removes backslashes and is used before inserting data into a database. The code originally pasted isn't inserting anything into a database; it is echo'ing it to the screen. Therefore, stripslashes will do nothing against the following: http://www.domain.com?p=<script>document.href.location=www.spoofeddomain.com</script> htmlentities will protect against that.

That's right. Whenever you echo an array, the text "Array" comes out. Change your echo statements to: echo "<pre>" . print_r($ValToEcho, true) . "</pre>";

In the name attribute of your select multiples, try appending square brackets. i.e. change <select multiple name="select"> to <select multiple name="select[]">

I can't believe this thread made it as far as it did before someone pointed out watching for embedded HTML or Javascript in the $_GET variable. Good job mj

Why not use $_SERVER["REFERER"]? I think it contains the URI of the previously visited page.

I'll answer your questions in reverse. 1) I did leave off the bit about the class path, in it's place is a comment: // Here we would do a require_once using the $path, $class, etc. Although honestly I don't think that part would be necessary. If the function is accessed through the class statically then you would have to assume the file had already been included. 2) __CLASS__ is the same as __LINE__ or __FILE__. They are replaced with the actual value at run-time. In this case, __CLASS__ evaluates to the name of the class it is used within. The default value of the singleton::getInstance will evaluate to "singleton". This gives the singleton a way of knowing if the function is being called through the singleton class itself or a derived class; an instance should be created only if being called through a derived class. Therefore, there is a check at the top of getInstance to see if $class is equal to the default value ("singleton"), if it is, the function returns early. I still don't know how I feel about this design. It has the disadvantages of requiring extra code in each derived class, most of which is duplicated but can't be derived. It also has the disadvantage of the class file needing to be included before being used. The alternative is a factory method, such as that suggested by Buyocat. It has the obvious advantage of not requiring extra code in each class, additionally class files don't need to be included by the calling code as the factory method can take care of that step. Decisions, decisions!

Simple. Create a global var named formSubmit and initially set the value to false. In the onunload handler, if formSubmit is set to true, return early and do not execute any code. Then create an onsubmit handler for your form and in there set the global variable formSubmit to true. Now the unload even will only trigger when the form is not being submitted.

So what happens if I'm using Opera and just turn off Javascript? I can still access your page and I can still edit the source. I'm sorry but browser blocking, through any mechanism (client or server-side), is a dumb, idiotic, and highly retarded practice in 99% (I'll grant possible exceptions) of all situations. Browser blocking to increase site security is a dumb, idiotic, and highly retarded thing to do in 100% of situations though. I suggest you code the back-end properly or hand the project over to someone that knows what they're doing.

Think about this for a moment and see if it doesn't help you solve the problem: In order to be useful to a server-side script, a form field has to have a name; assigning IDs to HTML elements is only useful to a client side scripting language. If you look at your document.FormName.field statements, you are using the ID attribute. Try using the name attribute instead. To tie that back in with my original statement in this post, document.FormName.field is meant to access a control within a form. It would make sense to have a correlation between field and the actual element that is almost guaranteed to exist. Since all useful elements have a name, but not necessarily an ID, the name attribute was chosen.

You can accomplish this without AJAX. Use the DOM to create an invisible iframe and point the src attribute at the script you'd like to run. When the iframe is created, you can assign it an onload event handler that destroys the iframe; that way you aren't left with dozens of iframes if the user clicks the link multiple times.

akitchin is correct, I just wanted to add that you should avoid using innerHTML as much as possible.

You shouldn't be storing PHP code directly into the database to execute. Store the code in a file and use include() or use functions like someone else suggested.

The error is telling you that your SELECT query isn't working properly. Did you try and plug the query directly into phpMyAdmin? Are you positive that your msql_select_db call is successful? Are you sure that you actually established a connection to the DB?

Slightly more concise: <?php $n = 0; $colors = Array("red", "white"); for($i = 0; $i < 10; $i++){ echo $colors[$n++ % 2] . "<br>"; } ?>

I think you should read up on arrays before continuing with what you're doing. You're missing a very fundamental idea here.

4. I personally don't like CAPTCHA. 5. If you don't want a file to be loaded without going through another file, put it in a non-web-accessible directory.

If you're House.PhotoID is only going to point to a record with a single other value, you might as well just store that other value in the House table. However, what happens if I want to upload multiple pictures for a single house? Your current design would require multiple duplicate records in the House table with only the PhotoID field changing. I suggest removing PhotoID from the House table altogether. Instead, change your Photo table to: id houseID file Then you will be able to upload multiple files for a single house.

(EDIT) Damn it I mis-read what neylitalo wrote. So instead... Welcome to the forums!

I feel like I just got hit in the face with a brick.

I set out to develop a method of implementing singletons in PHP with a simple initial critera: To not use any non-class helper functions and have as much of the behavior inherited as possible. Here's what I came up with: class singleton <?php abstract class singleton { // associative array; "className" => "instance" private static $s_singletons = Array(); /** * Retrieve the instance of the class if it exists, otherwise instantiate * and return the new instance. Return null on failure. * @var string Class name * @var string Path to class definition file */ public static function getInstance($class = __CLASS__, $path = null){ $instance = null; // No instance initially if($class == __CLASS__){ // No override check echo "derived class didn't override singleton::getInstance<br>"; return $instance; } if(isset(singleton::$s_singletons[$class])){ echo "already instantiated<br>"; $instance = singleton::$s_singletons[$class]; }else{ echo "not instantiated<br>"; // Here we would do a require_once using the $path, $class, etc. $instance = new $class(); if(is_object($instance)){ echo "created new instance<br>"; singleton::$s_singletons[$class] = $instance; // Save instance }else{ echo "couldn't create new instance<br>"; } } return $instance; // null or a class instance } public static function dumpInfo(){ if(!count(singleton::$s_singletons)){ echo "No singletons created.<br>"; return; } echo "<pre>" . print_r(singleton::$s_singletons, true) . "</pre>"; } } ?> I then created three derived classes. In the final derived class, c, I didn't override the getInstance() method to make sure my override check was working correctly. <?php class a extends singleton { public static function getInstance(){ parent::getInstance(__CLASS__, dirname(__FILE__)); } } class b extends singleton { public static function getInstance(){ parent::getInstance(__CLASS__, dirname(__FILE__)); } } class c extends singleton { } ?> I then ran the following: <?php a::getInstance(); b::getInstance(); c::getInstance(); singleton::dumpinfo(); a::getInstance(); b::getInstance(); singleton::dumpinfo(); $a = new a(); echo "<pre>" . print_r($a, true) . "</pre>"; ?> Here is the output: not instantiated created new instance not instantiated created new instance derived class didn't override singleton::getInstance Array ( [a] => a Object ( ) [b] => b Object ( ) ) already instantiated already instantiated Array ( [a] => a Object ( ) [b] => b Object ( ) ) a Object ( ) 99% of the time in an application I'm only ever using a single instance of a Database object. So the code will end up doing something like $db->select($sql); However, sometimes it would be nice to access database functions using the currently instantiated Database object but without having a reference to it. Here is one way of implementing that: <?php class database extends singleton { /** * Run a SELECT query */ public function select($sql){ } /** * Run a SELECT query statically */ public static function st_select($sql){ $obj = __CLASS__::getInstance(); return is_object($obj) ? $obj->select($sql) : null; } } ?> This enables me elsewhere in the code to do the following: // If I have a reference to the $db object, I can do: $db->select($sql); // But if I don't have a reference to the $db object, I can still run the following: // (It's slightly more typing, but it may allow me to be lazy in other regards, such // as finding a nifty way to pass an object somewhere it was never intended to // go.) database::st_select($sql); Overall, I like this approach because it uses inheritance and locates the actual getInstance() method in a single location, should I need to modify it later. Also there are no non-class functions which also makes me happy since I try to avoid polluting the global name space. One reservation that I have about it though is that I can create an additional instance of any of the derived classes. I'm sure I can disable that ability somehow, but I'm not sure I want to. This would seem to defeat the purpose of creating singletons in the first place, but here is a possible scenario. Let's say for arguments sake that 99% of my application is using a single Logging object. This object is writing to a specific file in a specific directory; this means the majority of my program would be using calls like $log->msg($msg); or logger::msg($msg); However, now let's say I need to debug a portion of the program and logging is the best way to do so, but I don't want to add extra information into the current logging process. I could still create an extra instance of the logger object, set it to log to a different file, and use it temporarily for debugging. Curious what you folks think about all this.