Project

General

Profile

Actions

Bug #73598

closed

Three hash (###) marker in JavaScript creates the problem in TYPO3 6.2.18

Added by Jignesh Prajapati about 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2016-02-22
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
medium
Is Regression:
No
Sprint Focus:

Description

I had one extension which is pi based.

It was working fine with TYPO3 6.2.15 but after upgrading to TYPO3 6.2.18, it creates the problem in rendering of the extension template using the function substituteMarkerArrayCached.

After debugging the extension HTML template, i find out that below line of JavaScript was creating the problem.

$("#obj_price").formatNumber({format:"#,###.00", locale:"de"});

If you see the above JavaScript line, then you will find out that it has "###". If i removed this three hash then extension template is working fine. But i'm not able to remove it because it is used by jQuery library for the purpose of number formatting.

Can you please provide the workaround for this issue?


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #44270: wrong result in substituteMarkerArrayCachedClosedFranz Holzinger2013-01-02

Actions
Actions #1

Updated by Steffen Müller about 8 years ago

  • Project changed from 1865 to TYPO3 Core
  • Is Regression set to No
Actions #2

Updated by Markus Klein about 8 years ago

  • Category set to Frontend
  • Status changed from New to Accepted
  • Assignee set to Markus Klein
  • Target version set to Candidate for patchlevel
  • Complexity set to medium
  • Is Regression changed from No to Yes
  • Sprint Focus set to Stabilization Sprint

I wonder how this ever worked before the change, but fair enough, this is valid.

Actions #3

Updated by Markus Klein about 8 years ago

I suppose your template has other markers before or after that JS code, right?

I fear we have to limit the allowed marker name length, otherwise there is no way to solve the issue as the engine can't judge whether ### is part of a marker or not as any character is allowed for marker names.

Actions #4

Updated by Markus Klein about 8 years ago

A quick-fix for you would be to simply use a marker for the format and pass this one in.

Actions #5

Updated by Markus Klein about 8 years ago

  • Status changed from Accepted to Needs Feedback
  • Target version deleted (Candidate for patchlevel)
  • Is Regression changed from Yes to No
  • Sprint Focus deleted (Stabilization Sprint)

This is really an edge case and I'm not sure if I really want to introduce an artificial limit for the marker name length.
It would be wrong by definition.

Would it be ok for you to simply use the proposed workaround instead of making the life of others possibly harder?

Actions #6

Updated by Jignesh Prajapati about 8 years ago

Hello Markus,

Thanks for your solution.
I will implement this and do not want to make the life of others harder :)

Actions #7

Updated by Markus Klein about 8 years ago

  • Status changed from Needs Feedback to Closed
  • Assignee deleted (Markus Klein)

Thanks. Closing this ticket then.

Actions

Also available in: Atom PDF