PmWiki | Cookbook / HttpVariables

Summary: Access http variables in the page, such as Get variables, Post data, and Cookies.

Version: 2010-06-28

Prerequisites:

Status: Feature Complete

Maintainer: MartinFick (minor updates: Peter Bowers)

Questions answered by this recipe

How can I insert GET, POST, COOKIE or SESSION values into my pages and how can I set or unset cookies and session variables?

How can I customize a user's site viewing preferences?

How can I pass a value between pages without using a page text variable?

How can I tell from which page the user came?

Answer

Put httpvariables.php Δ in your cookbook/directory.

Add the following line to local/config.php

    @include_once("$FarmD/cookbook/httpvariables.php");

Use the following markup extensions to access GET, POST, REQUEST, COOKIE and SESSION variable values:

  {$!request_var}  - GET, POST, COOKIE or SESSION variables
  {$?get_var}      - GET variables are added to URLs (http://yoursite/page?foo=bar)
  {$|post_var}     - POST variables are submitted by forms (action=POST)
  {$@cookie_var}   - Set/unset cookies with the cookie directive (see below)
  {$~session_var}  - Set/unset session variables with the session directive (see below)

Note: that is a tilde, not a dash for the session_var.

Use this directive to set/unset cookies:

  (:cookie foo bar [options]:)  - set cookie foo to bar
  (:cookie foo:)                - unset cookie foo

options are any of the following (more option info):

  name=<cookie>         - to set a name that would be interpreted as an option
  value=<value>         - to set a value that would be interpreted as an option
  expires=<time>        - set the expiry time (any valid strtotime format)
  path=<path>
  domain=<domain>
  secure[=true|false]
  httponly[=true|false] - only works with php 5.2 or above

Use this directive to set/unset session variables:

  (:session foo bar:)   - set session variable foo to bar
  (:session foo:)       - unset session variable foo

Background

GET variables are variables that appear after the ? in URLS. They are often used to alter queries or the way that a page looks. They are convenient because they can be added to a link and therefor do not require a form. Naturally this convenience means that GET variables should never be used to affect things permanently (i.e save/delete a document), especially since a crawler is likely to 'click' on every link on your site!

GET Example: you may link to the current page while assigning Bar to the GET variable Foo like this:

[[{$FullName}?Foo=Bar]].

You may then embed the value of Foo your wiki page with {$?Foo}.

POST variables on the other hand may to be used to permanently modify or 'post' things to a web site. They are normally associated with forms but javascript can also post data to a website. While forms that modify things can use POST, if a form simply performs a search it should be OK to use the GET method in the form instead.

POST example: you can create a form in pmwiki with a text field named Username and use the POST method like this:

   (:input form method=post:)
   (:input text name=Username:)

You may then embed the username in your wiki page with {$|Username}

COOKIES are variables that maintain state on the client (browser) side and can be used to create a form of session. Every time a user loads a page from the same place he got a cookie, the cookie is sent back to the server. This allows a web site to keep track of information about a user. While this can be evil, it can also allow a user to customize the way he interacts with a web site.

SESSIONS are similar to cookies but some of the burden of managing session data is transfered to the server side. But sessions do not exist on their own, for sessions to work they need to have at least as small key that is managed on the client side. This is usually done with a cookie, but could also be done by appending GET variables to every link. PHP can manage sessions transparently.

REQUEST variables are an all inclusive PHP specific way of referring to variables provide by any of the four methods mentioned above. You can use them if you don't care how the information you seek was submitted. Note: For php5, and Apache 2 at least on MACOSX the REQUEST variables are only POST and GET, and not Cookies or Sessions. This recipe does set and retrieve these variables though. (VG- 2011-01-09)

Notes

This recipe could be used to implement an alternative form of DynamicWikiTrails.
I'm not sure how, but I imagine that conceptually there are security concerns with this idea.

Examples

Live example

You can see (and edit) a live example of this recipe here.

Using Get to divide a long page into separate parts to read:

(:if !equal {$?partToRead} "part2":)
 This is part 1 of what could be a long page.

 [[{$FullName}?partToRead=part2|View part 2...]]

(:if equal {$?partToRead} "part2":)
  You just clicked on part 2 and so are seeing another section of the page.

 [[{$FullName}?partToRead=part1|Back to part 1...]]
(:ifend:)

Using Get to pass a value from one page to another:

In the above example a page passed a value to itself. You can also pass values across pages:

If MyPage has three links:
[[Called?passedvalue=A|Let's pass "A".]]
[[Called?passedvalue=B|Let's pass "B".]]
[[Called]]

And the Called page has this markup:
(:if equal "{$?passedvalue}" "":)
No value passed
(:else:)
{$?passedvalue}
(:ifend:)

The Called page will display "A", "B", or "No value passed", depending on which link the user clicked on MyPage.

An example of how to use this: a page can pass its own name as {*$FullName}, so the target page knows who called it.

Release Notes

2010-06-28 (Peter Bowers)

Changed to respect $Charset in the final htmlentities() call. Helps for pages with UTF-8 needing to pass info via the URL. (Requested by RandyB)

2010-02-05 (Peter Bowers)

Fixed incorrectly named rules to improve rule handling.
Added RecipeInfo line so recipe checks will work.

Version 1.3 - 2008-03-20

Added complete cookie parameter support
Made all assignments (cookies & sessions) occur after conditionals
Made httpvariable substitutions occur before and after pagevariable substitutions

Version 1.2 - 2008-02-15

Removed the extra slashes added by php on quoted material.

Version 1.1 - 2006-07-02

Added SESSION variables. Changed the clearing order of cookies.

Version 1.0 - 2006-06-06

Initial release

Comments

2010-12-28 - SteP - The 2010-02-05 update broke many markup expressions on my site. In particular PowerTools {(pagelist $:var={$!request})} didn't resolve the request variable before passing it to pagelist. This issue wasn't happening with version 1.3. So now I'm using version 1.3 with all the updates from versions 2010-02-05 and 2010-06-28 except for the rule name fix, and it works for me.

Since both markup expressions as well as the second httpvars rule both have their timing set at ">{$var}" that means the actual order of these 2 in relation to one another is undefined. Could you try changing the 2nd Markup() in httpvars to use '<{(' as the 2nd argument? If that works I'll make another release. (On my system, with my particular set of recipes, httpvars always fires before markup expressions and so I can't test it without a lot of messing around.) Peter Bowers December 29, 2010, at 02:47 AM

I changed the 2nd argument of the 2nd Markup() per your instructions and it didn't work; {(pagelist $:var={$!request})} still didn't resolve the request variable before passing it to pagelist. SteP January 14th, 2011.

Can you give me a site to look at? —Peter Bowers January 16, 2011, at 03:39 AM

Unfortunately not, the online site where this happens has my patch applied otherwise its main page would break completely —SteP January 21, 2011

Could you do something like this:

if ($pagename == 'Test.HttpVar')
   include_once("$FarmDir/cookbook/httpvar-2010-02-05.php");
else
   include_once("$FarmDir/cookbook/httpvariables.php");

That way I could take a look at it without impacting any other page on your site. (Incidentally I would need diagnostics turned on so I can examine the order of rules.) —Peter Bowers January 21, 2011, at 12:25 PM

06-27-2010 - RandyB - For me, some characters such as ú were getting corrupted. This appears to be because the recipe uses the default charset provided by the the PHP htmlentities function, while I was using utf-8. My solution was to patch the httpvariables script to make the charset explicit, by changing a line to: if($val) return htmlentities(stripmagic($val),ENT_COMPAT,'utf-8');

See release 2010-06-28. --Peter Bowers June 28, 2010, at 12:35 PM

06-22-2008 - RandyB - Could you give an example of setting a cookie that expires 30 seconds after creation? I tried (:cookie foo bar expires="+30 seconds":) but that didn't work.

use singulars in time units: second, minute, day, week, month:(:cookie foo bar expires="+30 second":), and note that each time you reload the page with the cookie directive, the cookie is set afresh with a new expire time! - HansB

09-01-2007 - Renato - So, say that the input for $_GET (maybe others) is "Foo Bar"... It gets \\\"Foo Bar\\\". Any work around for that?

Fixed in the latest release, check it out. Martin Fick February 15, 2008, at 02:46 PM

if I put the set cookie markup in somwhere else than in the main page I get the error:

 Warning: Cannot modify header information - headers already sent by (output started  
 at /var/www/virtual/netstreams.org/htdocs/devel/cms/pmwiki.php:1070)  
 in /var/www/virtual/netstreams.org/htdocs/devel/cms/cookbook/httpvariables.php on line 39

Any Idea whats wrong? nos ? March 20, 2008, at 01:42 PM

I don't quite understand what you mean by "in somwhere else than in the main page". If any script/recipe/markup outputs text directly with an echo statement (I don't think that this should happen with a normal pmwiki install) before the (:cookie:) markup is processed than this will be a problem. Could you perhaps setup an example of this problem on the example site? Thanks! Martin Fick March 20, 2008, at 02:40 PM

See link below. I simply added a cookie markup in the sidebar. Link

could you please ad an option to specify the path to set the cookie? Done! Martin Fick

Contributors

User notes +4: If you use, used or reviewed this recipe, you can add your name. These statistics appear in the Cookbook listings and will help newcomers browsing through the wiki.

HttpVariables