Bug #15871

Searching for records in record-browser window is not possible in records browser

Added by Sacha Vorbeck over 15 years ago. Updated about 15 years ago.

Must have
Backend User Interface
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


When i click on the "Browse for records" button in a content element type "insert records" there`s a search box in the right frame of the element browser. When I enter some string there and click on search no result will be returned. See attached screenshot.

(issue imported from #M2949)


element_browser_search.gif (6.82 KB) element_browser_search.gif Administrator Admin, 2006-03-21 16:12
browse_links.diff (628 Bytes) browse_links.diff Administrator Admin, 2006-03-28 14:02
browse_links-2.diff (7.82 KB) browse_links-2.diff Administrator Admin, 2006-03-29 08:31

Related issues

Related to TYPO3 Core - Bug #15934: Element browser: No folder change possibleClosedPeter Niederlag2006-03-29

Related to TYPO3 Core - Bug #15957: function ext_addP() in class.browse_links.php does not set url-param 'expandPage' properlyClosedPeter Niederlag2006-03-31

Related to TYPO3 Core - Bug #15916: Elementbrowser doesn't show elements when klicking on 21-...ClosedPeter Niederlag2006-03-28

Related to TYPO3 Core - Bug #15724: Choose Dataset does not work correctClosedPeter Niederlag2006-02-26

Related to TYPO3 Core - Bug #15870: not able to link image (in text & image) to special content elementClosedRupert Germann2006-03-21


Updated by Sacha Vorbeck over 15 years ago

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?


Updated by Sacha Vorbeck over 15 years ago

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.


Updated by Peter Niederlag over 15 years ago

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


Updated by Peter Niederlag over 15 years ago

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.


Updated by Peter Niederlag over 15 years ago

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)


Updated by Peter Niederlag over 15 years ago

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. :-<


Updated by Peter Niederlag over 15 years ago

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...


Updated by Ingmar Schlecht over 15 years ago

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.


Updated by Michael Stucki over 15 years ago

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


Updated by Peter Niederlag over 15 years ago

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


Updated by Peter Niederlag over 15 years ago

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)


Updated by Peter Niederlag over 15 years ago

should be fixed

Also available in: Atom PDF