Summary: Talk page for HttpVariables.
Maintainer: MartinFick (minor updates: Peter Bowers)
Users: +4 -1 (View / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.


I uploaded a version (20220617) which works with PHP 8, but requires PHP 7 or above: Attach:httpvariables_7.phpΔ. Should this become the default version, with the previous version retained for users of older PHP installs? Or kept as is? SaidAchmiz

Thanks for this. My personal preference is to try and keep it backwards-compatible as practical, recognizing that it may take a little more effort/skill to update and maintain -- I consider it a puzzle to solve, fun, so it never bothers me. OTOH I wouldn't impose my preferences on other developers and maintainers. And in a practical consideration, as the old version breaks in PHP 8, and the new version has some limited overlapping compatibility, maybe it is okay to offer the 2 versions.

We should make a poll about what PHP versions people currently use for running PmWiki, how many hosting spaces and if their hosting provider allows for enabling/migrating to a more recent PHP version. If everyone is currently running PHP 7, and/or if they would be able to upgrade, then we may free the PmWiki core (and recipes) from the older compatibility targets. --Petko

I’ve modified the updated version for backwards compatibility and uploaded it. It should now work with both PHP 7 and 8, and older versions.

The polyfill function I added (HV_PSA(); I couldn’t think of a better name...) might be useful for implementing PHP 8 support / backwards compatibility in other recipes also, as it’s less verbose than writing out the full isset($foo) ? $foo : $bar logic each time. —SaidAchmiz

Line 96 ought to be if(!$sec) $sec = false; instead of if(!$secure) $secure = false; or do I see this wrong -- Daniel Feb 19, 2022, at 23:11 PM

Indeed, thanks for notifying us, recipe updated. --Petko

Please update this for PHP 7.2+. There are four instances of Markup_e(). -- RandyB August 03, 2018, at 06:32 PM

Franz Frese (2018-01-10)

Problem: I get the value of a cookie only after a refresh of the page

( :if ! equal "{$?FFVersion}" "":)
( :cookie FFVersion {$?FFVersion} path="/":)
( :ifend:)
( :include {$ Group}{$@FFVersion}.{$ Name}:)

How can I make it work?

Try replacing the last line with:
(:include {$Group}{$Lang}{$^FFVersion}.{$Name}:)
Said Achmiz January 10, 2018, at 10:01 PM

Thx, that helps a lot (Now I understand the documentation). Still like to have a default value to use, if none matches.
Franz Frese

2014-10-31 - I just modified your routine and removed all '/e' references and wondered if you would like to check the code for accuracy? How can I upload it for you to check? DannyB Oct. 31, 2014
2014-11-30 - I uploaded an updated version, for PHP 5.5 compatibility - HansB

2014-01-29 - The documentation states about REQUEST variables "You can use them if you don't care how the information you seek was submitted." But I usually DO care. If the URL variable exists, I want to use that since it gives me the value on the current page load, rather than having to wait for another load. Is there a technique, or if not, can the "!" option be changed, or another option added, so that I can get URL variables in preference to cookies if both exist? - RandyB January 29, 2014, at 09:18 PM

BTW, I'm trying out adding this line to the HttpVariables function on my own system, to (hopefully) solve the problem, but I'm not the maintainer so I'll leave the official solution to the maintainer:

    case "^": $val= ( $_GET[$var] ? $_GET[$var] : $_REQUEST[$var] ); break;  

- RandyB January 29, 2014, at 09:18 PM

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')
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/  
 in /var/www/virtual/ 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

Talk page for the HttpVariables recipe (users).