PFMaBiSmAd

You will find that it also does not work in Opera. This is because you are using images as your submit buttons and the HTML specification only states that the x,y coordinates where the image was clicked are to be submitted. Since you are using more than one button, you will need to use the buttonname_x variables in php to test which one was clicked on. See this link for how button data can be processed in php (AFAIK works in all browsers) - http://www.php.net/manual/en/faq.html.php#faq.html.form-image

Variable assignment takes on the value when the assignment statement is executed (fancy way of saying the value in the $error array elements are set when the code in global.php is executed.) You can use a simple template and place-holders. In the following {x} is a place-holder in any message, x = 1, 2, 3, ... <?php $error[2] = "Your PM has been sent to {1}"; $error[3] = "Demo showing more than one place-holder - {1}, {2}, {3}, repeat the second one {2}"; function message(){ $arg_list = func_get_args(); // array of the passed arguments $text = preg_replace('/\{(\w+)\}/e', "\$arg_list['$1']", $arg_list[0]); echo $text; } $to = 'some to name'; message($error[2],$to); echo "<br />"; message($error[3],'first value','second value','third value'); ?>

<?php echo is the correct usage.

There's nothing wrong with what you are doing (test it in a file by itself.) If you are getting an empty variable later in your code, either your code is clearing the variable or the variable is not available due to it being in a different scope. You would need to pin down where in your code the variable has the expected content and where it does not. If you want us to help determine where in your code that is occurring, you will need to post your code.

For debugging purposes, add the following lines of code right after the first opening <?php tag - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(E_ALL);

Is the demo user in fact an Admin? Based on the code error in the delete logic that neil.johnson pointed out and the large negative post count for the user Admin, either any visitor or a normal logged in visitor was responsible for the deletion of your posts by iterating through a range of post id's. We cannot tell you specifically which of those actually caused the original problem because you have not shown the whole actual code from the start of the page through to the code that deletes the data. Based on that code error and the other things visible on the site, such as wrong thread/post counts and the problems with the growing number of escape characters (I also notice that in the code you did post that the $title data is not being escaped) that code is not ready for a live site. The functional testing that should have occurred before putting that code on a live site should have found the = vs == problem and if a non-admin (either a guest or a regular logged in member) can delete/edit posts. The only good thing I see is that the php code that sspoke included in the content that he changed the posts to was not executed, so you are at least not using eval() in your code. However, I suspect that injected javascript would execute in a visitor's browser, creating a XSS problem. That in fact just caused a thought to occur, perhaps someone injected some XSS into a post on your site that sent them either your session id cookie or your log in cookie values and they then visited your site as YOU and deleted the posts?

The phpinfo() Loaded Configuration File value is the php.ini that is being used. The Configuration File (php.ini) Path is just the default path that php was complied to use. If you check the web server error log you will probably find an error concerning loading the php_mysql.dll file. Assuming they have not fixed the errors, it is because the auxiliary libmysql.dll cannot be found. The best solution for this is to add the c:\php folder to your Windows path statement. You need to reboot your computer to get any change to the Windows path statement to take effect (or you can just log out of Windows and back in.) You also need to stop and start your web server to get any changes to the php.ini to take effect.

Have you debugged what is going on in your code and your data by echoing $fetch_users_data->userlevel to see exactly what is in it?

LOL, everything I wrote above has to do with the security of the login system. It has nothing to do with if your delete code allows any logged in visitor to delete anything they want. You must both check when you display the links/check-boxes if the current user has permission to have those things output for any record and you must checking in your form processing code if the current user has permission (or ownership) to actually affect the row(s) in the database tables.

You can use the mysql STR_TO_DATE function directly in a query to convert any date format into a mysql DATE value - http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_str-to-date If necessary, you can then use the mysql UNIX_TIMESTAMP() function to convert that into a Unix Timestamp - http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_unix-timestamp Yes, it will likely reduce the amount of code and result in faster execution. It's never too late to fix design problems.

Every header() redirect needs an exit; statement after it to stop the execution of the code at that point or you need to insure through conditional logic (i.e. an else{} statement) that you only execute the code you want when you want it. This is not secure - if(some security test here){ header('Location:.....'); } // code here is still executed while the browser performs the redirect This is secure - if(some security test here){ header('Location:.....'); exit; } // code here is not executed while the browser performs the redirect

I'll second that. If you search for REFERER on that page you will find more than one example.

No, it's not. There are two possible exploits. 1) It does not stop execution of the code on the page when it redirects, so when a login fails, the code on the page is still executed. 2) If you are not stopping the execution of the code on the page after you check if someone is not logged in, your delete code is still being executed. Edit: And I just looked at the 'admin' code that comes with that script. If you copied what it is doing, it is not protecting and preventing the code on your pages from being executed. All a hacker needs to do is ignore the header() redirects (which is the default if someone was using a CURL script to access your pages) and he can get any of your 'protected' code to execute.

It's highly likely that your form processing code where you actually delete posts (and perhaps on all of your admin functions) is either not checking if the current visitor is logged in as an admin or the code you are using to check that can be bypassed. The code we really need to see would be for the delete function and the login security you are using on that page. Just an FYI: HTTP_REFERER is a header that comes with the HTTP request. It can easily be set to anything and in fact most of the web proxy scripts set it to be the same as the domain being requested so that requests that come through such a proxy look like they are from someone who is actually browsing on your site. HTTP_REFERER cannot really be trusted or used for anything more than informational purposes.

Your form processing code is NOT even checking if any form was submitted. Every time the page is requested, either by a search engine spider or a spam bot script, it will send an empty email or in the case of a spammer, it will send an email with the data that the spammer posted to your code. At a minimum, you need to check if the submit button is set - if(isset($_POST['verzenden'])){ // your form processing code here... } Also, your form processing code is not validating any of the form data that reaches the server after it is submitted. Javascript form validation ONLY helps legitimate visitors that actually goto your form page. Search engine spiders and spam bot scripts request your form processing page directly and don't care what you do on your form page. You must validate all external data when it is processed on the server.

That IS exactly how you would do it.

The offending data is enclosed in double-quotes (so that you can distinguish the comma that is within the data from the comma that is the column separator.) If you use fgetcsv() to read the lines, it will parse the data correctly - $file = 'http://spreadsheets.google.com/pub?key=t1lEdkCoz0-FUi9FY1QXyBw&single=true&gid=0&range=B4%3AG25&output=csv'; $handle = fopen($file, "r"); while (($ldata = fgetcsv($handle, 1000)) !== FALSE) { echo "<pre>",print_r($ldata,true),"</pre>"; // replace this line with your code that uses the contents in $ldata } fclose($handle);

That would indicate that the WHERE clause does not match any row in your table. echo $query to see exactly what it contains and check to make sure that the value in $ID actually exists in your table.

Does the or die(mysql_error()) on the mysql_query() produce any message?

KILL is a reserved mysql keyword (there's a table in the documentation.) Either rename that column or enclose the name in back-ticks `` every time you put it into a query.

What settings are you trying to change because most settings CAN be changed using either a local php.ini (when php is running as a CGI application) or a .htaccess (when php is running as an Apache Module) file?

You can either use file_get_contents() and use the URL of the page or you could use an include() and use the output buffer to capture the resulting content.

Is your code using $_GET to access the value or is it using $_REQUEST? Also, what does a phpinfo(); statement show for register_globals?

Keep going. You need to pin down where in your code, right up to the point where the function(s) are called, that it no longer has the value. Your specific code between the point where it does have a value and where it does not is where the problem is.

The problem is that those are not straight-quotes, i.e. " or ' and escaping or not escaping has no affect on them. See this link for more information on different kinds of quotes in electronic documents - http://en.wikipedia.org/wiki/Quotation_mark_glyphs I'm going to guess that this text was copy/pasted from a word processor? You can either correct the text to use straight-quotes or you need to setup the character encoding on the page to a specific encoding that has the ability to display the type of quotes being used.