However is there a way to “upload” files without using a web form, but only by telling the PHP script where to find the image. First and most important the image should be web visible and accessible by HTTP.

The solution is quite easy – you can grab the file using file_get_contents, and than put it on the desired server folder with file_put_contents. Here’s some source:

$image = file_get_contents('http://www.example.com/image.jpg');
file_put_contents('/var/www/my.jpg', $image);

Extending the Case

You can go even further by downloading any kind of files with the same approach. What will be the case for an mp4 video is shown in the next example:

$video = file_get_contents('http://www.example.com/video.mp4');
file_put_contents('/var/www/my.mp4', $video);

Usage

This can be quite useful when trying to automate an remote upload process. In this case when somebody uploads an image on his site, you can duplicate this file on your server! However don’t forget the copyrights!

It’s strange how powerful PHP can be. There’s a legend that cURL is the only way to perform a HTTP POST with PHP, but that isn’t the truth. An extremely useful script is by using stream_context_create:

$optional_headers = null;
$params = array('http' => array(
                'method' => 'POST',
                'content' => http_build_query(array('name' => 'my-name'))));

if ($optional_headers !== null) {
    $params['http']['header'] = $optional_headers;
}

$ctx = stream_context_create($params);
$fp = @fopen('http://example.com/post.php', 'rb', false, $ctx);

Well this is only a snippet. You can change a lot this code and perform any request, but here’s a small start up. However note that this will do the same as while posting to example.com/post.php via web form!

// before
$mail = new Zend_Mail('utf-8');
$mail->setFrom('sender@example.com', 'Sender Name');
$mail->setBody('message in Html');
$mail->addTo('recipient@example.com', 'Recepient Name');
$mail->setSubject('Subject');
$mail->send();

// after
$mail = new Zend_Mail('utf-8');
$mail->setFrom('sender@example.com', 'Sender Name');
$mail->setBodyHtml('message in Html');
$mail->addTo('recipient@example.com', 'Recepient Name');
$mail->setSubject('Subject');
$mail->send();

You want to submit the form by clicking on a link or some other element on the page and this is a simple task. You know that by simply adding something like document.forms[‘the-form-name’].submit() this will work.

    
    Submit

However you’d like to submit the form not only by clicking on that particular element, but also by clicking on the Enter while the focus is on a input field, and this wont work! That’s because you don’t have a input type=”submit”.

OK, first thing is to add a hidden input type=”submit” – than by clicking both on the Enter keyboard button and on the link with the onclick=”document.blah.blah.blah” will submit the form.

    
    
    Submit

But this is not true!

Than you’ll receive the following message:

document.forms['myform'].submit() is not a function

Why? This isn’t working, but ever line seems to be OK. The answer is – don’t name the input type=”submit” with the trivial – “submit”. Just give it another name:

    
    
    Submit

$httpClient = new Zend_Http_Client('http://..../');
// request via post
$response = $httpClient->request(Zend_Http_Client::POST);
// or get
$response = $httpClient->request(Zend_Http_Client::GET);

However the interesting and useful thing is that you can perform authenticated requests:

$httpClient = new Zend_Http_Client('http://username:password@example.com/');
// or define it later
$httpClient = new Zend_Http_Client('http://example.com/');
$httpClient->setAuth('username', 'password');

That’s an opportunity to send/receive authenticated POST requests.

$httpClient = new Zend_Http_Client('http://username:password@example.com/');
// now post
$httpClient->request(Zend_Http_Client::POST);

The job can be done with a event’s which check. Let me show you some JavaScript/jQuery code:

$('.selector').click(function(e) {
	console.log(e.which);	
});

Note that this can be checked under Firefox and/or Safari like browsers which support the console object. This will give you the idea which key is pressed in a number value. The Enter is usually 13!
If you don’t have such browser, you can replace that code with something like:

$('.selector').click(function(e) {
	alert(e.which);	
});

However thus the PHP code goes quite clean and maintainable.

$scripts = $this->view->inlineScript();
$scripts->appendFile('/scripts/production.js');

This is quite interesting because in the case of multiple scripts you can chain them into this:

$scripts = $this->view->inlineScript();
$scripts->appendFile('/scripts/production.js')
            ->appendFile('/scripts/development.js')

But that’s not everything. Although it looks very pretty and clean, PHP gives you the correct syntax of something like this:

$scripts = $this->view->inlineScript();
$scripts
            ->appendFile('/scripts/production.js')
            ->appendFile('/scripts/development.js')

And that’s particularly good when it comes to fast switching between production and development scripts includes.

$scripts = $this->view->inlineScript();
$scripts
 //        ->appendFile('/scripts/production.js')
            ->appendFile('/scripts/development.js')

You’d ask why I’d to comment my script includes. Because as it appears to be fashionable the JavaScripts are concatenated and compressed. This gives you performance benefits on the client side when downloading and executing the script. So it’s usual to have one compressed/minified and several development scripts. That’s why this commenting strategy is very useful.

In example when saving a HTML formatted text you can use simply the htmlspecialchars method

$description = htmlspecialchars($_POST['description']);

Than you can be sure everything’s in the database, but it’s not actually HTML. Thus you don’t have any tags at all in the database field.

When you show this in the client side and you’d like to strip some tags, i.e. to keep only the <a> tag you can do this:

echo strip_tags(htmlspecialchars_decode($description), '<a>');

That’s the most simple way to keep everything as the original source. By me it’s better to keep whatever HTML markup there is on the input.

I was reading an article where the author says it is not a good practice to store data in the DOM. Indeed this is a bad practice and you should avoid it. After that he gives an example with using the DOM with the ALT attribute:

$('selector').attr('alt', 'data being stored');
// later the data can be retrieved using:
$('selector').attr('alt');

and after that the more clean:

$('selector').data('paramtername', 'data being stored');
// then later getting the data with
$('selector').data('paramtername');

OK, is more clean. But however it is bad practice to use such a “heavy” construction to store local data. It is obvious you can prefer to store it in a local variable. Thus you avoid the extra performance.