shiftJIS

As such, I can't be of much help. Without line notation, I can't tell whether the snippet you provided contains line 262.If it is, the error message refers to the part of code ("foreach($list as $delete)"). What it means is that $list isn't an Array. It has been defined a few lines earlier as "$list = $_POST['list'];", which I expect is an array. It'll be good to see more of the code regarding the creation of the <form> element and please let me know exactly where line 262 falls.

Or you can use substr_replace to stick it in the middle. You don't need to explode an array or nothing. $original = "blahblah"; // refers to the variable that contains the text$dl = "\n\n"; // however you want to identify where to insert the imageif (($a = strpos($original, $dl))=== false){ //sets $a to the position in $original where $dl is//gets evaluated in case strpos() returns FALSE, meaning no match was found $a = strlen($original); //otherwise we'll just put the image at the very end.}$text = substr_replace($original, $image, $a, $a); //inserting image Of course, you'll probably not want to use so many variables. I did so in an attempt to make it easier to understand.But of course, I'd just use regex.

Read up on what it means to be well formed: http://www.w3.org/TR/REC-xml/#sec-well-formedThe closing tag is require for all elements within the document element. The DOCTYPE declaration is outside of that.Regardless, as it is still "descriptive markup" (meaning the user-agent knows how to parse it for information based on the way it's declared), I see no problem referring to it as a tag.You should also note that "<p>Content</p>" in its entirety is NOT a tag. "<p>" is a tag (called the opening/start tag), and "</p>" is another tag (called the end tag).

Actually, if you look at where they actually define the word tag: http://www.w3.org/TR/xhtml-modularization/terms.html#a_termsyou will see that <!DOCTYPE> is a tag. I think you're confusing a few things. The literal "<!DOCTYPE>" is a tag, the DTD is the document that the <!DOCTYPE> tag REFERS to. Much like, for example, CSS isn't a tag, but what we use to refer to it (<style>) is.Just for your information, here's an example of an actual DTD: http://www.w3.org/TR/html4/strict.dtd

Besides the fact that you're only SELECTing fields from the database, not DELETEing them? What sort of error message are you getting? Can't help you much until we know what's going wrong.

You're using a user-defined function createSQL() that's probably defined in mysql.php - and we can only guess at what the contents are. What I mean is, other than giving you wild guesses - we can't help you at this point.If mysql.php isn't too long, consider posting that. MORE IMPORTANTLY, post the actual error message you get - or describe whatever deviant behavior you're seeing on the site.

I think the askaninja site uses that sort of trick when you play one of their videos.Basically, they add in an element (it could be anything, div, p, span for all it matters), set the width and height to be the browser window, position it absolutely and set the z-index high enough to override everything.Anyhow, this can be done with accessing the DOM with javascript. Tutorial here: http://w3schools.com/htmldom/dom_intro.aspThe best way, if you're using XHTML, is to use the XML DOM: http://www.w3schools.com/dom/dom_element.aspcreateElement and appendChild are so neat.

It is entirely optional. I use NO width/height tags and I've never had problems with validation. People recommend you use width/height because a lot of layouts depends on the image being a certain size - meaning, if the image doesn't load, some element following it will be out of place. Also, if somebody turns image loading off (perhaps they're still on a 9600bps modem or on a cellphone) then your layout could turn to poop. Also, even if the images do load right, they don't start loading until the HTML is downloaded (I think - either way, the HTML gets downloaded a lot quicker than the images), meaning the user will find a crummy looking layout that jumps around as images fill in their spots. I get away without using width/height because I rely on CSS to control layout.

You run down to the store and hand over money ($400) for a copy. Or you download nvu for free. Both are WYSIWYG capable editors, meaning you can edit the document like you would a word file - with layout and styling showing up as you type it out.If you don't know how to create "frame_a.htm", you need to forget about frames for the time being and learn html first. Your very own w3schools has a tutorial here: http://w3schools.com/html/html_intro.asp

I think they were referring to using an image to publish the email, NOT providing a mailto: link. Meaning, if you want an easy link that the user can click on that will automatically launch their email app and fill in your address - you're out of luck. Spammers will steal that address.People usually just publish the email address (no link involved) and obscure it somehow. Some methods are typing it out (me AT email DOT com), inserting text, using html entities, using javascript, or images instead of characters. With this method, users of your site will need to then manually type out your email (oh the horror!) if they want to email you.

While it's not impossible to store image data in a database, people tend not to. I think the reason is that fetching the image back then requires connecting to the database, fetching out binary data, and then formatting it with the right headers so that browsers will treat it as an image. Thus, you'd need a .php file as a wrapper, and every time someone looks at the image, you'll be calling mysql and spending a lot of processing time when you could just have the image on a file that the server would easily spit out.What usually happens is that people take uploaded images and move them to some specific folder, put some name on them, and sync this information up with a database (putting in tags/information etc, but especially the filename that it was saved under). So, assuming you amass a whole bunch of images, you can make a query for specific image, and use the filename provided in the database to retrieve the actual image. You can surely imagine that having a field of image data (which could be 1mb or over) slows down queries of the database.As for the unique names, I've seen methods that used md5 hashes. I personally just use the unix time that the file was uploaded (then the field will serve a double function). If you're programming a huge site like flickr where obviously people will be uploading things at the same time, then I'm sure you have some full-proof way of making sure images are unique (perhaps every user has their own folder? I'm sure they have software engineers with more creativity than me working for them). I'm sure the others in this forum have ideas/tricks of their own also.As for updating both separately or together, it's all up to your code. The database makes no restrictions on what you do with the fileserver and vice-versa.

No need ask for the code, it's right there.The problem is you have code like this: <strong>BACKGROUND IMAGE THAT ISNT TILED</strong><br /> This will create a background image that doesn't repeat: <style type="text/css"><!--BODY {background: #ffffff url(bg.gif) no-repeat}--></style><br /> I'm assuming the point of the page is to show pieces of css/html code that people could use on their site. The problem is, you didn't bother to escape the code, and the browser is treating it as actual style to be applied to the page. I think if you change the <'s and >'s to their html equivalents, then not only will your background not be white, but the intended code will be visible. <strong>BACKGROUND IMAGE THAT ISNT TILED</strong><br /> This will create a background image that doesn't repeat: <style type="text/css"><!--BODY {background: #ffffff url(bg.gif) no-repeat}--></style><br /> Gosh, it was complicated as heck trying to get those amps and stuff to show up right on the forum! The forum code kept converting them!

Well, I'm not an expert in this area and I don't have time to futz around to figure it out. What I'm assuming is that the iframe acts as an independent browser page, meaning that it has no knowledge relatively of the frame that contains it. If that's NOT the case, then there might be something you overlooked when you wrote your relative paths.I expect though, that there's no way for the iframe to look at it's container to decide where to go for relative paths (I mean, without some messy javascript sending information there). Thus, I suspect that you're forced to use full-paths. At least, this is how I would approach the problem, though I'm sure those that are trained in AJAX and whatnot could probably do a better job: //Javascriptfunction change_pages(val){var url="http://somethingsomething.com/";switch(val){ case 'Something': url.='something.php'; break; case 'Somethingelse': url.='something1.php'; break; default: case 'Home': url.='something2.php'; break; }document.getElementById("form_frame").src=url;}//html iframe portion:<iframe src='http://default frame/full path.php' id="form_frame"></iframe>

Your very own w3schools has an example on it: http://w3schools.com/js/tryit.asp?filename=tryjs_two_iframesExcept in your case, there won't be two frames. Maybe something like this?: //Javascriptfunction change_pages(val){var url;switch(val){ case 'Something': url='/something.php'; break; case 'Something': url='/something1.php'; break; default: case 'Home': url='/something2.php'; break; }document.getElementById("form_frame").src=url;}//html iframe portion:<iframe src='/something2.php' id="form_frame"></iframe>

Question looks really familiar.Again, I think we need some more information before can help you out. Have you checked the upload folder in whatever document root is? If the file is there (and if php ran the script without any errors, I assume it is) and it doesn't show up on the browser then perhaps it's a permissions problem.

Just a thought, why not put an iframe in there, and have javascript redirect that frame (depending on what val is set at) to separate static html (or a php file in the case where you want to preserve that content) files on the server? That way, the html code is removed from the javascript - clearing off a lot of clutter. Also, when you want to update any of the forms, you can just edit that particular html file. You don't have to worry about escaping quotes and having that cause javascript errors also.Also, I'm sure javascript has a switch control statement. Use that instead.

Few options:Do a search and replace: $text = "<select name='subject'>\n<option value='Sales Enquiry'>Sales Enquiry</option>\n<option value='Comment About Website'>Comment About Website</option>\n<option value='Other Enquiry'>Other Enquiry</option>\n (& there will be a few more options)</select>\n";//via str_replace$newtext = str_replace($_POST['subject'], $_POST['subject']."\' selected", $text);//via regex$newtextb = preg_replace('/('.$_POST['subject'].'\')/', '$1 selected', $text); The other thing, the method that I would recommend is to dynamically build the list using the method previously mentioned: $array = ("Sales Enquiry", "Comment About Website", "Other enquiry", "Etc", "Etc");$text = "<select name=\"subject\">\n";foreach ($array as $choice){ $text.= "<option value=\"$choice\" ".($_POST["subject"]==$choice ? " selected=\"selected\"" : "").">$choice</option>\n";}$text.= "</select>\n"; This way should be easier. If you want to add new subject choices, you just add to the $array variable. Otherwise, you'd have to craft a new line of code for each choice.

The clear property is described at the w3 here: http://w3schools.com/css/pr_class_clear.aspBasically it sets the br below all previous floated items. It doesn't really need to be there - the two div boxes would still sit where you intended them to go, but any content after those divs would act funny (they might be behind the floating divs) and the border of the containing div doesn't behave as you would expect (if I remember correctly it'll collapse)I personally use <div style="clear: both; height: 1px; margin-bottom: -1px;"> </div>. It makes a absolutely invisible clear as I'm a stickler for these sort of things.

*sigh*. The echoing of the variables was to show you the exact state of the variables as they are. It's always good to put a few here and there when you're developing to make sure what you're saving is really the variable you want, NOT some mysql resource ID number.

Obviously, if you have make a feature that's more robust and intuitive, it'll have more overhead right?

The question has already been answered, but I do have my 2 cents.I tend to use regex instead of nl2br. The function is cool and all, but does tend to put a lot of linebreaks where it shouldn't belong intuitively if you allow html in the input. I make an expression that changes \n to <br /> in all situations except where it occurs before and after the end tag for block elements.

A few notes:I notice pswd spelled as pswde in the if($user) block.Also, I've never seen code of this format: mysql_query('SELECT uname FROM userinfo WHERE uname=?', $_COOKIE['rmbr_uname']); Are you thinking prepared statements or does this follow some other programming scheme? I don't think it works in PHP. Try: $var = mysql_real_escape_string($_COOKIE['rmbr_uname']);mysql_query("SELECT uname FROM userinfo WHERE uname=\'$var\'"); Make sure you escape input. Cookies are yummy but they can't be trusted.Also, just making the query doesn't retrieve the values you want. You have to do this: //make a query$something = mysql_query("SELECT fishy FROM table WHERE id = SOMEID");echo $something; //...IS NOT WHAT YOU WANT. Outputs something like : mysql_resource id#$row = mysql_fetch_assoc($something);echo $row; //... IS NOT WHAT YOU WANT. Outputs something like : array()echo $row['fishy']; //..IS THE VALUE YOU WANT. Outputs : Red Snapper Also, I can't make sense of the logic behind the code. I'm assuming there's more before this snipped that you posted (in the case that this is the beginning of the file, you have a BIG problem). Otherwise, after you include"dbconn.php", you match username and pass. In the case where it matches the database, you check to see if the cookies for user and pass are set. Don't you already have the username and password at this point? If the cookies are set, you do a mysql query (that always evaluates as true). Because it's always true, you check the database for a password match - this has already been done at the first query!Are you missing some end brackets?... That might be the case.

Not or, but *and*. As far as I know, z-index doesn't work unless you actually position it.

With just the bits that you've shown, I'm not seeing the indention problem. So without any more info, I can't be much help. I might have some clues that could help you with your problem. Apologies if you've tried these already.IE treats padding as included into the width. So if you specify a width or height and a border, the box you see is whatever dimensions you specified. In most other browsers, padding is added to whatever width or height you specify. This could lead to different layouts on different browsers if you haven't fixed for it.The other thing is that I usually begin all css files with: *{ margin: 0px; padding: 0px;} There's a set default style that browsers use to display elements. Thus, even without specifying styles, you'll see space between <p>'s and headers will have appropriate format. Form elements have default styles also, and all of these defaults differ between browsers. It's usually a good idea to clear the slate if you're being specific about a certain layout.Hope this helps.

Depends what you mean by security risk. I can't think of any way which doing so would compromise the system. As long as whatever method you use to change the CSS only affects the file itself.The thing is, not only can they change the layout, but certain browsers allows the insertion of content through CSS. This means they can alter input fields (to spoof-steal passwords from any login-forms you might have).It also depends on how the CSS is attached to the page. If it's included inline dynamically, I can see where that might cause some problems. It'll be safer to @import it. This point is moot if the user-defined CSS only applies to his/her own session though (no point in spoofing your own passwords).The Css Zen Garden takes user submissions for CSS files. They do go through a moderation process, but you can fudge with the URL to include your own CSS. It seems safe enough for them.