|
Friday 15 August 2008 5:06:11 am
In /index.php file there is this piece of code responsible for storing last accessed URIs, probably mostly for redirection purposes: // Store the last URI for access history for login redirection
// Only if database is connected and only if there was no error or no redirects happen
if ( is_object( $db ) and $db->isConnected() and
$module->exitStatus() == eZModule::STATUS_OK )
{
$currentURI = $completeRequestedURI;
if ( strlen( $currentURI ) > 0 and $currentURI[0] != '/' )
$currentURI = '/' . $currentURI;
$lastAccessedURI = "";
$lastAccessedViewURI = "";
$http = eZHTTPTool::instance();
// Fetched stored session variables
if ( $http->hasSessionVariable( "LastAccessesURI" ) )
{
$lastAccessedViewURI = $http->sessionVariable( "LastAccessesURI" );
}
if ( $http->hasSessionVariable( "LastAccessedModifyingURI" ) )
{
$lastAccessedURI = $http->sessionVariable( "LastAccessedModifyingURI" );
}
// Update last accessed view page
if ( $currentURI != $lastAccessedViewURI and
!in_array( $module->uiContextName(), array( 'edit', 'administration', 'browse', 'authentication' ) ) )
{
$http->setSessionVariable( "LastAccessesURI", $currentURI );
}
// Update last accessed non-view page
if ( $currentURI != $lastAccessedURI )
{
$http->setSessionVariable( "LastAccessedModifyingURI", $currentURI );
}
}
What I can't figure out is whether there is actually any way of skipping that, for example for one particular custom module view, without modifying the index.php file itself, of course. Wouldn't a module declaration or in-view setting to turn off the above mechanism be a good idea in general? So that I can choose for which custom views I can skip it? The problem I'm encountering is with an IFRAME, which is displayed in the module result part and which is loaded after the result itself, which means that IFRAME's URI is stored as last. Then, come a function that makes use of that stored URI (for example: clear cache), I get redirected to a view that is only supposed to be displayed in the IFRAME. I'm most likely to cope with that, but there could be similar problematic scenarios. Greatly appreciate any thoughts on this.
Thanks,
Piotrek
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|