Bug #42299

Since 4.7.5 _LOCAL_LANG pi_list_browseresults_page can´t be empty

Added by Christian von Holten about 9 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Must have
Assignee:
-
Category:
-
Target version:
Start date:
2012-10-23
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.7
PHP Version:
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

Description

Hallo,

since I updated from 4.7.4 to 4.7.5 I dicovered a strange behaviour. I am using the latest version of tt_news. The pagebrowser for list view is configured like this

plugin.tt_news._LOCAL_LANG.default.pi_list_browseresults_page =

to have pagebrowser like this (worked in 4.7.4):

<< < 1 2 3 4 5 > >>

Now I get a page browser like this:

<< < Page 1 Page 2 Page 3 Page 4 Page 5 > >>

I tried

plugin.tt_news._LOCAL_LANG.default.pi_list_browseresults_page = &nbsp;

but this results in

<< < &nbsp; 1 &nbsp; 2 &nbsp; 3 &nbsp; 4 &nbsp; 5 > >>


Related issues

Has duplicate TYPO3 Core - Bug #42417: Since 4.7.5 _LOCAL_LANG pi_list_browseresults_page can´t be emptyClosed2012-10-23

Actions
#1

Updated by Oliver Hader about 9 years ago

  • Priority changed from Should have to Must have
#2

Updated by Benni Mack about 9 years ago

  • Status changed from New to Accepted
  • Target version set to 4.7.6
  • Complexity set to easy
#3

Updated by Sebastian Schmal about 9 years ago

the same problem in 4.6.15 :(
plz bugfix!

#4

Updated by Sebastian Schmal about 9 years ago

plugin.tx_indexedsearch._LOCAL_LANG.de {
  pi_list_browseresults_page =
  pi_list_browseresults_next = nächste
  pi_list_browseresults_prev = vorherige
  word_page =
  word_pages =
}

Output:

<< < Page 1 Page 2 Page 3 Page 4 Page 5 > >>

#5

Updated by Elmar Athmer almost 9 years ago

Same in TYPO3 6.0.

#6

Updated by Jens Hoppe almost 9 years ago

Same problem in TYPO3 4.7.7 with tt_news 3.2.1

#7

Updated by Andreas Becker almost 9 years ago

Also in TYPO3 4.7.7 with tt_news 3.4.0.

Are there any workarounds?

Btw... Target version should be updated.

#8

Updated by Jens Paul almost 9 years ago

I have a ugly workaround :(

- make a copy from tt_news_userPageBrowserFunc.php
- in your TS:
includeLibs.userPageBrowserFunc = fileadmin/templates/main/tt_news_userPageBrowserFunc.php

and
plugin.tt_news.userPageBrowserFunc = user_substPageBrowser2

- edit in tt_news_userPageBrowserFunc.php
below: function user_substPageBrowser2 ($markerArray, $conf) { ...
the Marker ###BROWSE_LINKS### around line 233

original:
for ($i = $firstPage ; $i < $lastPage; $i++) {
if (($begin_at >= $i * $pObj->config['limit']) && ($begin_at < $i * $pObj->config['limit'] + $pObj->config['limit'])) {
$item = ($pObj->conf['pageBrowser.']['showPBrowserText']?$pObj->pi_getLL('pi_list_browseresults_page', 'Page'):'') . (string)($i + 1);
$markerArray['###BROWSE_LINKS###'] .= ' ' . $pObj->local_cObj->stdWrap($item, $pObj->conf['pageBrowser.']['actPage_stdWrap.']) . ' ';
} else {
$item = ($pObj->conf['pageBrowser.']['showPBrowserText']?$pObj->pi_getLL('pi_list_browseresults_page', 'Page'):'') . (string)($i + 1);

$markerArray['###BROWSE_LINKS###'] .= $pObj->pi_linkTP_keepPIvars($pObj->local_cObj->stdWrap($item, $pObj->conf['pageBrowser.']['page_stdWrap.']) . ' ', array('pointer' => $i), $pObj->allowCaching) . ' ';
}
}

new:
for ($i = $firstPage ; $i < $lastPage; $i++) {
if (($begin_at >= $i * $pObj->config['limit']) && ($begin_at < $i * $pObj->config['limit'] + $pObj->config['limit'])) {
$item = ($i + 1);
$markerArray['###BROWSE_LINKS###'] .= '<span class="activeLinkWrap">' . $pObj->local_cObj->stdWrap($item, $pObj->conf['pageBrowser.']['actPage_stdWrap.']) . '</span>';
} else {
$item = ($i + 1);

$markerArray['###BROWSE_LINKS###'] .= $pObj->pi_linkTP_keepPIvars($pObj->local_cObj->stdWrap($item, $pObj->conf['pageBrowser.']['page_stdWrap.']) . '', array('pointer' => $i), $pObj->allowCaching) . '';
}
}

This is my workaround currently
Result ony numbers

#9

Updated by amus almost 9 years ago

A simple workaround:

plugin.tx_indexedsearch {
   _LOCAL_LANG.de.pi_list_browseresults_page = ###
   _LOCAL_LANG.default.pi_list_browseresults_page = ###
   stdWrap.replacement {
      10 {
        search = ###
        replace = 
      }
   } 
}
#10

Updated by Matthias Oberritter almost 9 years ago

Sorry, "simple Workaround" won't work for Typo3 4.7.8, Indexed Search 4.7.7. Any other suggestions?

#11

Updated by Daniel almost 9 years ago

Matthias wrote:

Sorry, "simple Workaround" won't work for Typo3 4.7.8, Indexed Search 4.7.7. Any other suggestions?

You must use tt_news instead of tx_indexedsearch

plugin.tt_news {
   _LOCAL_LANG.de.pi_list_browseresults_page = ###
   _LOCAL_LANG.default.pi_list_browseresults_page = ###
   stdWrap.replacement {
      10 {
        search = ###
        replace = 
      }
   } 
}
#12

Updated by sushie.net over 8 years ago

Same Issue in Typo3 4.7.10 / Indexed Search 4.7.7

both "simple Workaround" wont work for me (dont have tt_news installed anyway)... any other suggestions except patching php ?

*cheers

#13

Updated by sushie.net over 8 years ago

quick workaround with jquery

$(document).ready(function(){
 $('ul.browsebox li a').each(function(){
  $(this).html($(this).html().replace('Page ', ''));
 });
});

*s

#14

Updated by Kim Christiansen over 8 years ago

Try this:

_LOCAL_LANG.default.pi_list_browseresults_page (

)

The empty line must be kept!

#15

Updated by Sven Burkert over 8 years ago

Is this now fixed? I had this problem, too, but now it is gone (TYPO3 4.7.12, tt_news 3.4.0).

#16

Updated by Dimitri Lavrenük over 8 years ago

Here is a fix for Typo3 6.x

/typo3/sysext/frontend/Classes/Plugin/AbstractPlugin.php

Line 532
change
$pageText = trim($this->pi_getLL('pi_list_browseresults_page', 'Page', $hscText) . ' ' . ($a + 1));

to

$pageText = trim($this->pi_getLL('pi_list_browseresults_page', '', $hscText) . ' ' . ($a + 1));

As you can see, the 'Page' is hardcoded in the core as an alternative label

#17

Updated by Gerrit Code Review over 8 years ago

  • Status changed from Accepted to Under Review

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

#18

Updated by Ryan Klarhölter almost 7 years ago

This is not a core bug and the fix shouldn't be implemented, it's a tt_news bug. It has to do with changes made in the TYPO3 method pi_getLL introduced by commit aef055c88c5954444bbc9f226b33ecc04532a748 (https://review.typo3.org/#/c/14237/) and later extended/fixed by 97a6a1bcd74817d7ae764d7e76fc37a222b4ef71 (https://review.typo3.org/#/c/17151/). The underlying problem is not that the string "Page" is hard coded (I think this has a useful reason). Nevertheless it wouldn't fix the problem because tt_news is calling the pi_getLL method by it's own (with "Page" as alternative label too). So fixing it in the core hasn't any effect. I have suggested a solution in https://forge.typo3.org/issues/43804#note-3.

#19

Updated by Benni Mack almost 7 years ago

  • Status changed from Under Review to Rejected
  • Is Regression set to No

this issue is not related to the core but expected behaviour.

#20

Updated by Michael Stucki over 5 years ago

To deal with this, you need to set the following in your plugin:

$this->LOCAL_LANG_UNSET[$this->LLkey][$key] = '';

See #43804 / https://review.typo3.org/#/c/39706/

Also available in: Atom PDF