kicken

A few things to try/check: Do you have any firewall enabled that might be blocking DNS requests? Clear your firewall entries and try again.First, save your current firewall configuration: iptables-save > firewall_rules Then clear the entires and reset the defaults to accept: iptables -P INPUT ACCEPT && iptables -P OUTPUT ACCEPT && iptables -FThen try resolving some domain names again. If it works, you'll need to re-configure the firewall settings to allow DNS traffic.To restore your saved firewall settings: iptables-restore < firewall_rules Can you ping the IP address of the nameserver(s) you are trying to use? What does your /etc/resolv.conf file look like? Are you allowed to use the nameserver(s) you are trying to use?Try some public ones like Google public DNS or OpenDNS

I'm not sure I really know what exactly your problem is. Perhaps you could describe it better? Are you having issues with your VPS resolving domains names, so that if you tried to do something like ping www.google.com it cannot resolve www.google.com to an IP address? Or are you having issues that others can no longer resolve your domain name to an IP because your name servers can no longer be reached? So someone else doing ping www.yourdomain.com would have troubles?

$_POST is for data sent in the body of a POST request. When you just tack a value onto the url as in ?name=blah then you need to use $_GET to access the value: echo $_GET['name'];

Make sure you enter the full URL, including the http://. I've seen some browsers in the past that do not recognize 'localhost' as a domain name and instead treat it as a search term. Adding the http:// resolves the issue and the browser treats it as a URL rather than search query.

Mysqli's API is not particularly friendly, especially when it comes to prepared statements and bound parameters, which is the ideal way to query with user-supplied information. PDO has a much cleaner api, and would be used as such: //Connect $db = new PDO('mysql:host=localhost;dbname=yourdatabase', 'username', 'password', array( PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION )); //Prepare the query. Since you didn't show a query this is just generic example $sql = 'SELECT SomeColumn FROM SomeTable WHERE SomeOtherColumn=?'; $statement = $db->prepare($sql); //Execute the query with the user-supplied data. $statement->execute(array($a)); foreach ($statement as $row){ //Process results } The purpose of the stripslashes is to undo the damage done by the magic_quotes_gpc setting. This setting has been removed so there is no reason to be trying to undo it. Even before the call should have been conditional, as in: if (get_magic_quotes_gpc()){ $a = stripslashes($a); } because running stripslashes if magic quotes was already off would at best do nothing, or at worst damage a user's input (ie, remove slashes they added intentionally).

A more fluid option than a periodic cron job would be to use something like Gearman to perform the work. You would setup a server script which accepts job requests and does your scrapping and stores the result. You'd then just need to retrieve that result for display on your page. You could either pass the result around in the database or use something like Memcached to store it temporarily. Here is an example of using memcache and gearman to run tasks and get their results. When a user submits a request that would require scraping, you would simply submit the scrapping request to the gearman job server then you can use an ajax poll to check for the results. If you want to get fancy you could set it up so that PHP will wait a few seconds for a result so that fast scraping jobs would be processed in one shot, but if the job is taking a long time (ie after 10 sec or so) go ahead and output a waiting page to the user with an ajax poll for the status.

That sounds like a NAT problem. Normally the FTP client would open a listening socket on a random port, then send your IP and port number to the server so it can connect. Your client is sending a private IP (192.168.x.x) which the server is then rejecting (because it'd be pointless for it to try and connect to a private IP). This issue is typically resolved by using passive mode FTP so check your settings and ensure you have that option enabled. For WinSCP it is under the advanced settings in the connection category. As for the other times when it just times out, you can try running a traceroute to the FTP server when you have issues. The problem may lie somewhere between you and the server, at one of the intermediate hops. A traceroute might help to identify if that is the case.

Is the 404 being generated by the webserver, or by your API? If it's generated by the webserver you should check the server's error log for information about why. If it's generated by the API you'll need to debug the api code to figure out why.

Probably something like this in your main .htaccess (or virtualhost block) would work (untested): RewriteCond %{HTTPS} =on RewriteRule ^/hotels(.*)$ http://yoursite.com/hotels$1 [R=permanent,QSA,L] You'll need to make sure whatever you use to force SSL to be on for the rest of the site will ignore these paths, otherwise you'll just end up creating a loop. Out of curiosity, why do you want to disable SSL for these paths?

In your code, you are missing the $ on select_stmt in your while loop. You have: while (select_stmt->fetch()){ It should be: while ($select_stmt->fetch()){

Ignore the class. All you need to do is check the value of $_FILES['userfile']['error'] and see what it contains. If it's anything other than 0 (UPLOAD_ERR_OK) then you need to output it's value and then look up what the error is on that page by finding the appropriate constant. As part of your //---------------------------------validation code here block, you should have: if ($_FILES['userfile']['error'] != UPLOAD_ERR_OK){ //report an upload error somehow echo 'Failed to upload file, error code is: '.$_FILES['userfile']['error']; $problem = true; }

Make sure the address you are trying to bind to exists on the computer's network interface and that the address/port combination is not already in use by something else.

Because so many people have written bad HTML over the years, browsers have come to be able to recognize and fix many errors automatically. How a browser would interpret the above would depend probably on how it handles such errors. Chrome appears to just merge the a tag into the input tag as attributes, as in: <div class="button-container" style="top:20px; left:0px"> <input type="submit" name="submit" value="Get Report" <a="" href="#" class="large-button" style="left: 0px"> <div class="button-glare"> </div> </div> If you look in the chrome tools at the elements tree you can see the input element and how the a tag is simply absorbed as extra attributes. Firefox appears to handle it similarly. You can see in the above though, your CSS still applies because the class structures is still valid (.large-button is within .button-container, .button-glare still exists as a div tag). If you had prefixed your classes with tag names (ie, a.large-button) then it would fail because the large-button class is now on the input tag, not the a tag.

From what I can tell briefly looking at the script if you want to store the tone into a variable you need to create another generateTone function which will create a new oscillator object at the proper frequency. Eg: function generateTone(context, frequency){ var oscillator = context.createOscillator(); fixOscillator(oscillator); oscillator.frequency.value = frequency; var amp = context.createGainNode(); oscillator.connect(amp); amp.connect(context.destination); return { oscillator: oscillator, amp: amp }; } That would create the oscillator and an associated amp object and return them. You'd then use the oscillator to alter the tone's frequency or the amp object to alter it's volume level. You could wrap that all up into a Tone object so that you'd just have to do something like var tone = new Tone(context, 100); tone.setVolume(0.6); tone.start(); tone.changeFrequency(60); tone.stop(); //etc

You'll want to add some concurrency to the process. The easiest place would be in the downloading stage using a library such as Rolling-CURL to download several URLs at once. If you're feeling adventurous then you could also look into pcntl_fork to create multiple processes which will process urls/results concurrently as well.

Add a new line to the end of your input. The C program is probably waiting for a new line before processing the input, as that is the normal behavior. $bytes = fwrite($stdin[0], "$input[0] $input[1]".PHP_EOL); As for why the stand-alone code works without the new line, that is likely because you are closing the stream in that code which tells the child process there is no more input so it will process what it got.

You could also take a picture of the fabric with a digital camera and then use some image editing software to determine the red, green, and blue values and then convert that to hex.

Since re-creating the event, have you re-tested adding new rows and seeing if the event will then see them (without being re-created again)? I've not yet used the event system but prior to posting I did test it on my server by creating an event which periodically updated a table with the count of rows matching a pattern in another table, then I periodically added new rows both matching and non-matching and the count properly updated each time the event ran with the new information. What exactly does your event do and how is it defined? Are you sure it's even being run after the rows were added?

Then the correct solution to your problem is to get a new host, not fix the script. Your host is severely out of date with the PHP versions. If they are that out of date with PHP, who knows what other software they are using is out of date and full of security holes. Besides, there are a few things in that script besides just the array dereferencing that will need adjusted to work on php4, such as the use of PDO and filter_* functions. It's not worth your (or our) time and effort to rewrite the script.

No, you do not have to re-add events for them to see newly inserted data. You re-adding the event probably just resolved some other issue such as the event maybe being disabled, or the event's query not being what you thought it was.

Whenever a user logs in, you'd record the time that they logged in at in your database. Then on your page you'd have a little JS that periodically queries the server for anyone who has logged in since the last check. If anyone meets that condition you'd send back their info and have your JS code show the dialog.

Your array is multi-dimensional so in your function $val is another array (the second dimension), not a number. You can use a loop to go over the first dimension. foreach ($data as &$arr){ array_walk($arr, 'myarray'); }

Alternate do-while version: do { $roll = rand(0,6); if ($roll != 6){ echo 'You lose! You rolled a '.$roll; } } while ($roll != 6); echo 'You rolled a six! You Win!';

It's not supposed to run from the browser, no bot is. A bot is a script that will need to run continuously for a long time. These kinds of scripts are not supposed to be run from the browser via apache as you may have issues with the server killing it due to a timeout. Just run the script from the shell as designed, forget about running it via the browser.

You need to cancel the event if the user clicks no. The old method of doing that is to return false from the event handler. The more modern way is to call preventDefault() on the event object. function confirmation(e) { var answer = confirm("Are you sure?") if (!answer){ e.preventDefault(); return false; } } <a href="delete.php" onclick="confirmation(event)">Delete record</a> No, not with the built in confirm/alert functions. You'd need to use a custom modal dialog such as Jquery UI's .dialog(). Because this type of dialog would be processed asynchronously you need to handle the event differently. Rather than wait for the answer to determine whether to cancel the event, you need to just cancel the event immediately. Then once you get the answer you can either re-trigger the event or perform the delete using Ajax.