Ingolme

It's working for me in Firefox, but Chrome doesn't fire the onload event because the window seems to already be considered loaded by the time I assigned the event listener. As a test to confirm this, I substituted the onload event with a setTimeout call that waits one second before sending the message and it works, that's an unstable solution. I'm currently trying to figure out a way to detect when the script is ready in Chrome, but it's not behaving properly. document.readyState is set to "complete" when I check it from the parent window even when the page isn't fully loaded.

From the output you're getting it sounds like the PHP is not actually being executed. This program has two parts that you have to debug independently from each other: The PHP part and the Javascript part. The Javascript part First, test the Javascript. In order to prevent any PHP errors from ruining the Javascript testing we'll just put this at the beginning of the PHP file which we'll remove once the test succeeds: <?phpecho 'Hello, World!';exit;?> Now in the Javascript code we'll just alert(xmlhttp.responseText) to see if it works. The PHP part To debug this, we have to open the PHP file right in our browser and give a test value to the q variable, for example getuser.php?q=1 If it displays what we expected it to, then the program is working. If it doesn't then there probably are some error messages which will be clear to see.

Try this: x=window.open("torek.html");x.onload = function() { x.postMessage("Hello world!","*");} In the second window, be sure you create the event variable: window.addEventListener("message",function(event){ The theory behind it is that the moment you open the new window, the Javascript inside it has not yet started running, so it's not there to listen to the message you sent to it.

Show the code you have on both of your pages.

I'm not sure, but I think you're referring to the fact that PHP is showing an error message on the screen. That doesn't necessarily mean that the program halted, the program continues running unless the error message is labeled "Fatal error". Which statement is throwing the PHP error? I can't find any information in the PHP manual that any of the mysqli functions throw an error.

If they say on StackOverflow that it can be done on the filesystem then it probably is true. I assume that if it can work on the local filesystem at all it probably only does with "*" as the target origin. When you pass "*" to the function, what error message do you get?

You don't need a comma, end the lines with a semi-colon, the comma might be interpretted as a syntax error, though I haven't tested to make sure. You can put as many instructions inside an if block as you want and you can call addClass() as often as you want. If the class isn't being added then your selector probably isn't pointing to the right element.

Here's the documentation: https://developer.mozilla.org/en-US/docs/Web/API/Window.postMessage The targetOrigin property contains information about the website that's meant to receive the information. It can be "*" or a URI which has the scheme (http: or https:) and the domain name of the site that's receiving the message. It's probable that some browsers won't allow this to work in the local filesystem for security reasons, I find it happens with a lot of features.

You can learn Javascript at the W3Schools Javascript tutorial: http://www.w3schools.com/js/default.asp

Selectors are ordered by the HTML tree. This structure is ordered .portfoliotext a img <div class="portfoliotext"> <a href=""> <img> </a></div> If you used the selector .portfoliotext img a Then you're assuming a structure like this: <div class="portfoliotext"> <img> <a></a> </img></div> :hover is a pseudo-class that you can put on any element. a:hover checks that the mouse is over an <a> element, img:hover would check that the mouse is over an <img> element.

Whenever you copy your HTML page to somewhere new you must copy all of the resources it's linked to as well. Make sure the image is in the same folder as the HTML file and that it has the same file name as what you've written in the src attribute.

If the rest of the code that's in the function depends on the result of the prepared statement then you should return. If it is not dependent then it's better not to leave the function so that the program can run as normally as possible.

First, do you understand what the code does?

You fix errors to make sure that something works. If it's working and it's working as it was designed to then there are no errors in it. There are a few different types of errors to deal with. The most basic ones are lexical and syntactical errors, if these errors are present then PHP will tell you, so you can be sure that you don't have any of those. The next level would be runtime errors. The program compiles right, but during runtime something that the program wasn't expecting happens. PHP tells you if it encountered a runtime error so if you haven't gotten any runtime error messages then you don't have any of those errors. PHP won't show runtime errors in sections of code that haven't been executed, so if you want to be completely sure that your program doesn't have runtime errors then make a test program that runs all of your functions. Ontop of that are logical errors. That means that the program works fine but it is doing something different than you intended it to. Sometimes these errors are obvious, sometimes you don't find out about them for a long time. In order to find all of the logical errors you need to test all possible cases for your program. In your most recent block of code you have three cases to test: 1. The data gets inserted into the database and is exactly the same as the data you sent to it. 2. The block of code correctly identifies an error when a prepared statement could not be created. 3. The block of code correctly identifies an error when the statement failed to execute. Here's how you could test them: 1. Run the program, then check the database (with phpMyAdmin, for example) and look for rows with the information you sent to it. 2. Deliberately make the prepared statement fail by passing a bad value instead of a proper SQL string. 3. Deliberately make the statement execution fail by, for example, passing the wrong amount of parameters.

Is it working or not?

The website http://regular-expressions.info has a whole lot of information that you can learn from.

That's a CSS problem, it doesn't matter whether the code is HTML or XHTML because it's the CSS that changes the appearance of everything. You can use the DOM inspector of your browser's developer tools to see which styles are being applied to an element. If I understood your description, your labels are overflowing outside of a <div> element that contains them. That means that the <div> has a fixed height. If you want it to be flexible you need to make sure that a height is not set. If a height is already set then you can override it with the value "auto".

That just means that the URL you linked to for the image is incorrect. What does your <img> tag look like?

You haven't shown any code or error messages, so I'll have to make guesses. You mentioned iframes. Here's their demo: http://jscrollpane.kelvinluck.com/iframe.html It says that if you're using iframes you have to put the code on the page that's being loaded inside the iframe. If that's not your situation, then show what code you used, tell me what is occurring and what you expected it to do.

Most modern websites today use CSS media queries to change the page for smaller screens.

A badly made htaccess file can cause an internal server error. Just give your files a ,php extension if you want to run PHP.

If you're getting an internal server error then something's wrong with the server's configuration and it's not caused by PHP.

If() statements are how I tend to validate form fields. I can't think of a better way. Normally I'll have an errors array. Each if() statement will append an error string to the array. If after all the validation the errors array is empty I will proceed with the task, if it's not empty I will redirect back to the form, sending the list of error messages to be displayed in a session variable. Sometimes I'll send the form data back as well so that the form can be repopulated and prevent the user some frustration.

I don't know what you mean by return either. Where are you reading the value of the variable and what value did you expect it to have?

Are you testing this on a server or on your filesystem? If you're loading it from your filesystem, make sure that when the browser prompts you to accept scripts running on the page you accept them. This doesn't happen on a server.