Bug #26915: stdWrap.cropHTML does not recognize TYPO3 link attribute correctly (and removes text around) - TYPO3 Core - TYPO3 Forge

Custom queries

12 LTS
Accessibility
Dashboard issues
Easy tasks
Extbase Issues
FAL Issues
FAL Sprint 2023
Hierarchical Issues
Issues reported for v11
JavaScript issues
JavaScript Issues (w/o Epics/Stories)
Most wanted Bugfixes
Most wanted Features
My open issues
New & Unassigned
No feedback within 90 days
Open Bugs
Open issues of 10
Page Tree Regressions after 2020-07-28
Recently modified
Regressions
Stabilization Issues
Usability or UX

Actions

Copy link

Bug #26915

closed

stdWrap.cropHTML does not recognize TYPO3 link attribute correctly (and removes text around)

Added by Jakub Černek almost 13 years ago. Updated over 11 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Content Rendering

Target version:

Start date:

2011-05-19

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

4.4

PHP Version:

Tags:

Complexity:

medium

Is Regression:

Sprint Focus:

Description

Hi,
when the cropHTML try crop text inside TYPO3 link in longer form (e.g. <link email@example.org - mail "Open email window">email@example.org</link>), then all paragraph (or other tag with content) around this link is removed.
It can lead to remove all content.
Responsible is RegExp on line 4323 in typo3_src-4.4.7/typo3/sysext/cms/tslib/class.tslib_content.php
It doesn't handle dash and doublequote signs…

Files

26915.diff (510 Bytes) 26915.diff

Fix

Jakub Černek, 2011-05-20 01:38

Related issues 1 (0 open — 1 closed)

Related to TYPO3 Core - Bug #30005: stdWrap.cropHTML wrong on full-word crop shortly inside HTML-element

Closed

2011-09-19

Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Jakub Černek almost 13 years ago

File 26915.diff 26915.diff added
% Done changed from 0 to 50

Probably fixed. Testing and verification needed.
PCRE's sign \w doesn't contain a dash sign '-'. Doublequotes is not a problem.
May be it is a localy dependent.

Actions

Copy link

Updated by Mr. Hudson almost 13 years ago

Patch set 2 of change Id7274fdab0be96a9118341a95dab82386d01c903 has been pushed to the review server.
It is available at http://review.typo3.org/2641

Actions

Copy link

Updated by Mr. Hudson almost 13 years ago

Patch set 3 of change Id7274fdab0be96a9118341a95dab82386d01c903 has been pushed to the review server.
It is available at http://review.typo3.org/2641

Actions

Copy link

Updated by Philipp Gampe over 12 years ago

I can not reproduce either. Works fine for me with 5.3.6 (x86_64) on fedora.

Actions

Copy link

Updated by Jakub Černek over 12 years ago

OK, sorry for not proper description how to reproduce it.
My settings:
stdWrap.cropHTML = 82 | ... | 1
and text is not parsed by parsefunc.
Training text:
'Welcome
blah blah blah on email <link email.address@example.org - mail "blah blah blah blah blah blah bl">email.address@example.org</link> blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah'

Without fix it make "Welcome"
Proper break is somewhere "Welcomeblah blah blah on email email.address@example.org blah blah blah blah"

Actions

Copy link

Updated by Helmut Hummel over 12 years ago

The question is: why do you use "cropHTML" to not actually crop HTML but the pseudo HTML content TYPO3 stores in the database?
To my understanding it's an abuse of that function which should not be "fixed".

Actions

Copy link

Updated by Stefan Neufeind over 12 years ago

Helmut, while in general I agree with you that it's not really "normal" HTML-content (and maybe not "the right weapon" to choose) I don't see why cropHTML needs to be overly restrictive. There might be a character like this minus in the string - but no browser or whatever would have a problem with that I expect since it would first search for the closing tag and be done with the general parsing. What the function currently does is fail "somewhere" in the middle of a tag which imho is "fully broken".

The word-characters (\w in this PCRE) don't include the minus-sign. But even if you say this pseudo-HTML is "artificial" and not really html, what if tomorrow somebody throws something like

at it. Okay, that's not valid HTML and he/she made an error not to use the correct style-tag for it. But why should the crop-functionality fail on this one?

That having said: I'd favor for the function to be more open about "unexpected" characters and try to solve the job as easy as possible trying to find the closing tag and be done.

Actions

Copy link

Updated by Mr. Hudson over 12 years ago

Patch set 4 of change Id7274fdab0be96a9118341a95dab82386d01c903 has been pushed to the review server.
It is available at http://review.typo3.org/2641

Actions

Copy link

Updated by Mr. Hudson over 12 years ago

Patch set 5 of change Id7274fdab0be96a9118341a95dab82386d01c903 has been pushed to the review server.
It is available at http://review.typo3.org/2641

Actions

Copy link

#10

Updated by Oliver Hader over 12 years ago

Status changed from New to Under Review
Complexity set to medium

Actions

Copy link

#11

Updated by Mr. Hudson over 12 years ago

Patch set 6 of change Id7274fdab0be96a9118341a95dab82386d01c903 has been pushed to the review server.
It is available at http://review.typo3.org/2641

Actions

Copy link

#12

Updated by Mr. Hudson over 12 years ago

Patch set 7 of change Id7274fdab0be96a9118341a95dab82386d01c903 has been pushed to the review server.
It is available at http://review.typo3.org/2641

Actions

Copy link

#13

Updated by Chris topher over 12 years ago

Subject changed from stdWrap.cropHTML not recognize TYPO3 link attribute correctly (and remove text around) to stdWrap.cropHTML does not recognize TYPO3 link attribute correctly (and removes text around)

Actions

Copy link

#14