TYPO3 Core

version 2.1.3 typo3 3.8.0

I think this should be made configurable.

keyword:accessibility

I would generally change from POST to GET

Still no fix for this issue ?

@Wolfgang Podbregar: Masi once sent me some comments about shortening the arguments in order to make browsing with GET parameters possible. Currently it would probably not work because the URL becomes too long.

That issue prevents Typo3 indexed search extension to be used for fully accessible websites.

Problem solved on www.greenpeace.de

however they done it :-)

Why not ask them for a small contribution?

I'm currently working on a solution that creates URLs as value of the href attribute. But this is for an older version, so I need some time to create a patch file for the current version.

IMHO this solution isn't optimal. It would be better to create a submit button for every page so the URLs aren't screwed up. But I didn't dig into that solution yet.

The attached diff introduces a new attribute $pointerVars in class tx_indexedsearch. This is filled with the necessary piVars when makePointerSelector_link() is called for the first time. So the list of parameters in the URL doesn't get too long.

The generation of URLs instead of "#" is disabled by default and can be enabled by setting plugin.tx_indexedsearch.browseLinks_setUrl in TS.

Many many thanks for the patch, Thorsten! Great work. I've edited your patch (so the line number may be wrong) because I don't want those onclick events if I use "browseLinks_setUrl". I added some XHTML-compliance with htmlspecialchars on $url.

Hey Patrick,

any chance on sending this patch again to the core list so it goes int o 4.2 ?

Guys, I created a new version of this patch, that applies against the current trunk. Anyone interested in putting this to the core list?

And one more patch for this old issue.

Attached bug-1347_03.patch fully contains Thorstens/Benjamins solution.

Additionally, it implements Thorsten's idea, mentioned on 2006-10-11: to render the browselinks as forms, thus preventing any shortcomings that may arise by extended length of the browselink-URLs.

Alternatively to the property (renders browslinks as URLs, not needing JS)
plugin.tx_indexedsearch.browseLinks_setUrl = 1

you may use the property (renders browselinks as forms, not needing JS)
plugin.tx_indexedsearch.browseLinks_useForms = 1

with browseLinks_setUrl having precedence to browseLinks_useForms.

If browseLinks_useForms = 1, you may want to add additional parameters to each submit button (for more styling maybe) by adding them to
browseLinks_useForms.submit_params

Example:
browseLinks_setUrl = 0
browseLinks_useForms = 1
browseLinks_useForms.submit_params = class="myclass"

Any objections against putting this to the core list for 4.2.1?

Confirmed that the patch works with 4.2.8 and fixes the javascript invalid pointer issue with firefox 3.5.3

related to #19465 (patch 0009574_v7.patch)

Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/20189

Patch set 3 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/20189

Patch set 4 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/20189

When will this Patch get merged into the core? Is this Ticket still active?

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/20189

Patch is working for me.
Because of wrong line numbers i had to patch manually but it works.

I use it in TYPO3 6.2.9.

It's working fine for me, too.
My TYPO3 Version is 6.2.9

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/20189

Hi
I'm wondering whether this patch makes sense any more in 2015.
The original issue was created ~10 years ago, when relaying on js for navigation was an accessibility issue.
I don't think this is a case right now.

I know that the indexed search js is not pretty, but this is a different topic.

So, I'm opting for abandoning the issue. However if you really see the usecase, please let me know, maybe I miss something.

• avoid "crufty" inline JS
• enable easy interception of paging action by JavaScript and doing paging with AJAX afterwards (quite dirty to achieve this with the standard JS)
• avoid very long GET http requests with the POST option; GET might even lead to errors, if webserver doesn't accept very long GET requests

Just for the records: I'm against closing this issue for the reasons mentioned in #note-36