Sessions and request vars (3-rd level domain)

19 Posts

bounz Reply #1, 16 years, 3 months ago

Hi there!
I found out a problem with my site installed on third level domain makeup.bounz.net.
The problem is that MODx remembers request variables from first request after cache cleanup, and don’t want to see any other request variables.
Problem is somewhere inside framework. Why? I’ll show you.
I use getPage snippet configured to look for "page" request variable. So, let’s use php_info(32) to see what request variables are there.
First, I insert php_info(32) at the begining of getPage snippet. Save it. Clear site cache. Open the page http://makeup.bounz.net/?page=2. Ok. Our variable is there:

Variable		Value
REQUEST["page"] 	2

Let’s go now to http://makeup.bounz.net/?page=1. And what we see? Still

Variable		Value
REQUEST["page"] 	2

Strange, yep?
Ok. Let’s insert the same function call in index.php:

$modx->setDebug(E_ALL & ~E_NOTICE);
echo phpinfo(32);
/* Initialize the default 'web' context */
$modx->initialize('web');

Clear cache. Go to http://makeup.bounz.net/?page=2. Ok, they both are there

Variable		Value
REQUEST["page"] 	2

and

Variable		Value
REQUEST["page"] 	2

Let’s go to http://makeup.bounz.net/?page=1
First php_info output shows

Variable		Value
REQUEST["page"] 	1

while the second (from snippet) shows

Variable		Value
REQUEST["page"] 	2

Oops. Value has been changed!
Even if I remove parameter from adress string second php_info() output is

Variable		Value
REQUEST["page"] 	2

The problem is in versions Revolution RC1 and RC2.
So. What can I do to make it work properly?
Thnx.

P.S. I made a short video. http://www.youtube.com/watch?v=gCxl_GEXQDE
For now it is still processing by YouTube. I hope it will be avaliable soon.

MODX Staff
10,725 Posts

opengeek Reply #2, 16 years, 3 months ago

I assume you are calling getPage uncached? e.g.

[[!getPage@propertyset]]

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

19 Posts

bounz Reply #3, 16 years, 3 months ago

Yes, of course.
Only one detail: getPage is called not directly, but from another uncached snippet:

[[!getResourcesTag@BlogList]]

MODX Staff
10,725 Posts

opengeek Reply #4, 16 years, 3 months ago

Quote from: bounz at Jun 09, 2010, 02:09 PM

Yes, of course.
Only one detail: getPage is called not directly, but from another uncached snippet:
[[!getResourcesTag@BlogList]]

LOL, well what does it do?

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

19 Posts

bounz Reply #5, 16 years, 3 months ago

Well, it’s from MODx Sample Site package.

<?php
/**
 * MODx Sample Site
 *
 * Copyright 2010 by Shaun McCormick <[email protected]>, excepting
 * subpackages installed by the component.
 * ...
 * @package modxss
 */
/**
 * Wrap the getPage/getResources call to implement tagging
 *
 * @package modxss
 */

if (!empty($_GET['tag'])) {
    $scriptProperties['tvFilters'] = 'tags=='.$_GET['tag'];
}

$elementObj = $modx->getObject('modSnippet', array('name' => 'getPage'));
if ($elementObj) {
    $output = $elementObj->process($scriptProperties);
}
return $output;
?>

MODX Staff
10,725 Posts

opengeek Reply #6, 16 years, 3 months ago

Yeah, that Snippet is not setting the Snippet it is calling manually uncacheable. It should look like this:

<?php
$elementObj = $modx->getObject('modSnippet', array('name' => 'getPage'));
if ($elementObj) {
    $elementObj->setCacheable(false);
    $output = $elementObj->process($scriptProperties);
}
?>

Otherwise, that Snippet is cached into the page by tag signature, which is not unique in this case, because you are using a GPC variable to vary behavior.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

19 Posts

bounz Reply #7, 16 years, 3 months ago

Ok. Thank you very much! Now it works.
I didn’t thought that cache engine doesn’t take request variables into account..