Project

General

Profile

Actions

Bug #24939

closed

GIFBUILDER / LOAD_REGISTER issue with generating image file names

Added by Thorsten van Stipriaan about 13 years ago. Updated over 12 years ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2011-02-03
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Given a two line pagetitle. Output was something like "LINE_ONE_LINE_TWO_b62300e380.png" with 4.4.6

In 4.5 the setup below produces cryptic file names like "TY7IY7~0.PNG" in typo3temp/GB

The resulting wrap contains the filename as it should be.

Setting fixes text values (commented out below) works fine, so the problem may lie within the usage of LOAD_REGISTER.

tmp.pagetitle = COA
tmp.pagetitle {
2 = LOAD_REGISTER
2 {
line1 {
field = title
case = upper
split {
token.char = 10
cObjNum = 1
returnKey = 0
}
}
line2 < .line1
line2.split.returnKey = 1
}
10 = IMG_RESOURCE
10.file = GIFBUILDER
10.file {
XY = [10.w]+[20.w]+15, [10.h]+6
10 = TEXT
10 {
text.data = register:line1

#text = Line1 <- this works
offset = 10,15
fontColor = #ffffff
fontSize = 18
niceText = 1
fontFile = {$filepaths.fonts}Klavika-Medium.otf
}
20 < .10
20 {
text.data = register:line2
#text = Line2 <- this works
offset = [10.w]+15,15
}
}
stdWrap.dataWrap = &lt;h1 id=&quot;page_title&quot; style=&quot;background-image: url(&#039;/|&#039;);&quot;&gt;{page:title}&lt;/h1&gt;
}
(issue imported from #M17463)
Actions #1

Updated by Jo Hasenau about 13 years ago

I don't get the point here.

The TS setup you posted should have no influence on the filename at all, since you are just changing the image itself with the register.

Even if it had, what would be the use case, since the images are created in a temporary folder anway?

Actions #2

Updated by Jo Hasenau about 13 years ago

Sorry - I forgot the "meaningfulTempFilePrefix"

It seems that the stdWrap functionality is not working as before here, so $conf['text'] is not changed by the data property anymore.

Actions #3

Updated by Thorsten van Stipriaan about 13 years ago

Good catch, disabling meaningfulTempFilePrefix "fixes" this issue.

Your assumption $conf['text'] is not affected by the data property is not quite right. It works well on a title with just one line.

So my assumption is, that something in the split function could be damaged!?

Actions #4

Updated by Jo Hasenau about 13 years ago

OK - I did a test and found out that anything is working as expected.

meaningfulTempFilePrefix has been changed in revision 7720 (end of May 2010) though, so that it is not just a switch anymore but can contain an integer value to crop the prefix to a certain length.

After setting this value to 100 the filenames contain the complete text, with or without using the data property.

So IMHO this can be closed.

Actions #5

Updated by Jo Hasenau about 13 years ago

Just to make sure that the rest of the TS is working:

Can you read the text provided by the data property when looking at the image regardless of it's name?

Actions #6

Updated by Thorsten van Stipriaan about 13 years ago

It can not be closed. The meaningfulTempFilePrefix value is set to 100. This is not the issue since it worked on 4.4.6.

Yes, the created image shows what it has to, just the file name is broken.

Actions #7

Updated by Jo Hasenau about 13 years ago

Which is what I can't reproduce here neither with current state of 4.5.1-dev nor with trunk.

Page title is: Page 1 D whatever
split token is D
results in filename: typo3temp/GB/PAGE_1___WHATEVER_9f19275ecc.png

Actions #8

Updated by Thorsten van Stipriaan about 13 years ago

Lucky you. Though this is really strange.

Than please close this, maybe something else is twisting the settings here.

Thanks anyway

Actions #9

Updated by Steffen Gebert over 12 years ago

  • Status changed from New to Rejected
  • Target version deleted (0)
Actions

Also available in: Atom PDF