TYPO3 Core

I`m not sure but maybe the patch from http://bugs.typo3.org/view.php?id=2840 solved the problem described in bugnote 2840 but caused this one here?

I just tested a little more and noticed that the problem is not limited to the search alone. Also when you click on the "title" link which usually results in alphabetic sorting of the records (Link href is "http://localhost/typo3/browse_links.php?id=3400&table=&act=&mode=db&expandPage=&bparams=&table=tt_news&sortField=title&sortRev=0")

No result will be shown. Same goes for the button below the records that allows browsing to the next page of records (Link href is "http://localhost/typo3/browse_links.php?id=3400&table=&act=&mode=db&expandPage=&bparams=&pointer=20&table=tt_news")

This will also produce an empty result. So it is impossible at the moment to select records with the element browser at the moment.

in some parts "expandPage" will not be set as expected/needed. The links just contain expandPage=''

One Solution seems to be to make an additional check on the expandPage-Parameter in browse-links.php, when it is compared to session data in function processSessionData($data)

attached patch 'browse_links.diff' adds an !empty in there so session-value is used if expandpage is just submitted as ''

It doesn' t seem like an appropriate solution but cures the problem.

IMHO this is a blocker, since currently there is no chance to reach any element, thats is not amonst 20 first elements (happens quite often with related news for example)

There's still some issue with the handling (maybe inside the session?). After using the sorting-link or the search-function or the "click to see mor than 20 elements" thingy reports:

"error: reference to main window is not properly set"

With or withut the patch applied. Since I have no clue on where any relevant changes have been introduced (cvs history of browse_links.php and class.browse_links.php doesn't reveal any relevant change to me) I give up for the moment. :-<

OK. I think I got at least the problem/reason. :->
(I just love that class-structure of TYPO3)

typo3/browse_links.php was restructured in february. The huge pile of several weird classes were removed from the old SC (script-class) into another file class.browse_links.php.

More important class "SC_browse_links" was split into into "SC_browse_links" (still in browse_links.php) and class "browse_links" (now in class.browse_links.php)

problem is that some functions (notably TBE_browser_recordList->ext_addP() here) rely on some parameters in the usual $GLOBALS-way for example: $GLOBALS['SOBE']->expandPage

now this does not work anymore since they have been moved from the script-class to the new Nutzklasse (usage class) browse_links in class.browse_links.php.

can anyone follow me up to here?

I put it in that detailt since I am not sure if it affects any more code-pieces...
I guess it needs a check on access to $GLOBALS['SOBE'], I'll do that in a minute and think about a more nice solution...

Thanks very much for taking care of this, Peter!

This is indeed a showstopper for 4.0, it must be resolved: Either by a fixing patch, or by reverting René's change to put most of the browse_links.php code into a separate class file.

I assigned the bug to you, Peter. If you don't find an easy solution to the problem, please send a reminder to me, so we can organize what to do.

If I remember correctly, this element browser stuff was changed by René. So I would say that you should ask him via Core list to fix this stuff.

There is one more issue related with this which I had already posted on the core list. Will set up an additional reminder for René...

- michael

OK, here is another suggestion for this series:

1) move local $browser var into a class var of SC_browse_links
2) access Variables by $GLOBALS['SOBE']->browser->foo instead of $GLOBALS['SOBE']->foo

seems to work here but I would ask for some guidance if this seems an appropriate measure

see patch browse_links-2.diff

a small grep showed that htmlarea is providing its own version of mod3/browse_links.php which also access stuff like $GLOBALS['SOBE']->expandPage

So it needs an additional check and maybe even some changes there also.

Also I am quite positive the original change that caused this trouble will also brake backwards-compatibility with anybody that extended the element-browser !!! (I am not saying that this is bad, I would just think it needs some documentation about it)

should be fixed