Post to another PHP file

[xxarmoxx]

Can someone please show me a simple example where I can gather information from one form in a php file and then post it to another php file?

This website gives a great example on how to post to itself http://www.tizag.com/phpT/examples/formvar.php but I would like to post to another file. Please let me know how to do that.

[the182guy]

The "Action" property of a form specifies where to post the form to, for example:

<form name="myForm" method="post" action="another_page.php">

The above would post to "another_page.php".

[xxarmoxx]

Great thanks, also in another_page.php I can grab the data that was submitted using the following code:

$Fname = $_POST['Fname'];
print $Fname;

Assuming $Fname was in the original php file.

[the182guy]

Thats right.

On that tutorial your using it posts to itself using <?php echo $PHP_SELF;> well all that is doing is getting the filename and path of the current PHP script, and inserting it into the action property of the form. If you do View->Source on your page when loaded, you will see what it inserts.

[xxarmoxx]

Whats the benefit to posting to self?

Whats the benefit to posting to another file?

Im trying to figure out which to use where, now that I know how to do it.

[dclamp]

There really is no benefit... It all depends on what your doing.

For example, the Search Dropdown menu on this page has a search bar, when you submit it, it submits to search.php (which is the main search page).

If you go to search.php manually, and type in your search, then it will post to it self because that it the page that does the mysql transaction.

[penagate]

You should think about form actions in the context of verbs and nouns and decide what is appropriate.

Forget about PHP scripts for a second, if you may.

Every location that you navigate to represents a resource. These are identified by URIs (Uniform Resource Identifiers); over HTTP, these are specifically URLs (Uniform Resource Locators).

http://example.com/
http://example.com/books/
http://example.com/books/search/

HTTP defines some actions (verbs) which clients (web browsers, automated tools, people using telnet...) can apply to resources (nouns). The most common of these are GET and POST.

GET means "give me a representation of this resource that I might be able to understand." The client tells the server what formats (e.g. HTML, plain text) and languages (e.g. US English) it prefers, and the server gives the client the best match out of those.

GET http://example.com/
Accept: text/html, text/plain, text/*
Accept-encoding: utf-16, utf-8, ISO-8859-1
Accept-language: en-US, en, *

POST means "take this data and do something logical and related with it." The action taken should be obvious from the noun (the URI) and the variables given in the POSTDATA. For example, I might want to add a new book to our example website.

POST http://example.com/books/
...
name=Introduction+to+HTTP&author=penagate

I post the book data to http://example.com/books/.


Or I might want to search the database.

POST http://example.com/books/search/
...

query=Introduction+to+HTTP

Here it should be obvious that we are searching a database at http://example.com/ for a book about HTTP. It would make less sense to post this request to http://example.com/ or http://example.com/books/, since we are specifically performing a search.

The server-side scripts which serve the actual content and perform the actions requested by the client can be organised differently again. There is nothing which requires one URI to represent one script. In actual fact, all of the above actions might be controlled by one file of PHP code.

Your job as the system architect is to design a sane back-end architecture, a sane URI schema, and map the two together. In Apache you can achieve nice-looking URLs by using the mod_rewrite engine; other web servers have other methods. If you can't do this then you might have to create one script for each URI which then includes other scripts to do the actual work. Just don't let back-end architecture dictate your URIs and vice versa.