[TYPO3-core] RFC: #8092: defect wsid check in workspace-overlay delivering wrong record versions from DB!

Franz Koch typo.removeformessage at fx-graefix.de
Sat Apr 12 11:16:16 CEST 2008


Hi Martin,

as mentioned in the other post - this is the following situation:

>> i don't understand. If param is omitted, it's set to -99, otherwise 
>> it's an integer.
> 
> But -99 is an integer.

yes - the wsid is set to '-99' by default, but will be substituted by 
$GLOBALS['BE_USER']->workspace in that case.

>>  // Check if workspace is different from zero and record is set:
>>   if ($wsid!==0 && is_array($row)) {
>>
>> check for different to zero is !=0 in this case, or !intval($wsid). 
>> And Franz tested and got right result after this change, so imho it's 
>> correct?
> 
> I want to know why either workspaceOL is called with $wsid being a 
> string or why $GLOBALS['BE_USER']->workspace contains a string. Neither 
> of that that shouldn't happen.

and it's not the case. It's no string - it's simply EMPTY/undefined. It 
seems that the workspaces are not initiated to that time, when the the 
method t3lib_befunc::BEgetRootline is called for the first time. I found 
that out by placing some debug output on various places (beginning of 
BEgetRootline,end of BEgetRootline, beginning of workspaceOL). And by 
the first call to the rootline of the current selected page, the wsid is 
empty. And due to the fact, that the rootline is cached, every other 
call to get the rootline of the current page will return the defect result.

So, question is now - when is the first call to BEgetRootline done. I 
assume this might be when pageTS is read for the first time - but I'm 
not that deep in the source of the core that I would know where to look 
for it. So hopefully someone could help me out here to get that fixed 
for 4.2 and 4.1.7.

--
kind regards,
Franz


More information about the TYPO3-team-core mailing list