Project

General

Profile

Actions

Bug #55802

closed

Subheader inflation in BE forms

Added by Thomas Skierlo about 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
FormEngine aka TCEforms
Target version:
-
Start date:
2014-02-09
Due date:
% Done:

0%

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

Description

I have subheaders enabled by default for all CE

TCEFORM.tt_content.subheader.disabled = 0

Moving from TYPO3.CMS-HEAD-4f3b6ec (Jan.30) to TYPO3.CMS-HEAD-25e85a7 (Feb. 7) messes up all subheader fields in BE. See attached screenshots


Files

Actions #1

Updated by Georg Ringer about 10 years ago

  • Status changed from New to Needs Feedback

just this line alone does nothing in my system. are you using any additional extension/php code?

Actions #2

Updated by Thomas Skierlo about 10 years ago

Sure I have other code/extensions, like adding a header_layout, adding and removing of section_frames and enabling image_frames. But non of them is related to subheader rendering.

Reverting back to any older version instantly brings back correct subheaders (only 1 per CE instead of 4).

If the problem is present, even existing subheaders are NOT shown in the 4 subheader fields, while they are still rendered in FE. All 4 subheader fields have the same field-name. Reverting to an older HEAD brings 1 field back with correct content.

Actions #3

Updated by Georg Ringer about 10 years ago

the core does only show the subheader for ctype header & mailform.

So you need some additional code which adds the field to the TCA.

please test with an empty master or tell which code you are using ...

Actions #4

Updated by Thomas Skierlo about 10 years ago

I agree to a certain part. Typical behaviour until now was, to SHOW the subheader field only for selected CE by default. It always was available for all CE, which everyone can check by placing a header CE, entering a header and subheader, and changing type to some other CE, like text. Now the text is rendered with header and subheader, even if the text element by default doesn't offer a subheader. So the whole truth is: For some CE the field subheader was blinded in the form by default, while being still existent in the DB.

Until now, the following re-enabled the always existant field subheader for ALL CE, overriding the default. There was no need for any TCA action, since the subheader column always was part of tt_content. Have a look - it's right after column colPos.

TCEFORM.tt_content.subheader.disabled = 0

This worked fluently until TYPO3.CMS-HEAD-4f3b6ec from Jan. 30, and it stopped for me with TYPO3.CMS-HEAD-25e85a7 from Feb. 6. This very version does still enable the subheader for all CE, but present the field 4 times instead of only once. Did not try any later HEAD, since I'm currently into deeper struggel with indexed_search. Just wanted to report an issue right after it hit me. This is no big one, I can currently live with my 4 subheader fields in the BE.

Actions #5

Updated by Georg Ringer about 10 years ago

I can talk to myself as well.

If I use TCEFORM.tt_content.subheader.disabled = 0, there is still just the subheader in the content element "header" available and not e.g. in "text". Therefore I still believe that you got some extra extension/code working which adds the subheader element to more ctypes.

Please test that behaviour with a naked master of TYPO3 and rereport!

Actions #6

Updated by Thomas Skierlo about 10 years ago

Georg: Please beleave me, this one-liner is all I'm using to enable the subheader field for all CE. I'm using it since 4.6 throughout all releases/sub-releases, and it was working fine up to and including 6.2.0beta3.

Possibly after 6.2.0beta3 something has changed in subheader handling, like, "from now on we do hard-limit it to cerain CE types, while we formerly only blinded the input field". I just tried today's HEAD (same problem), and I dug deeper this time. If I open CE type header, I get 1 header and 1 subheader field. Perfect.

If I do the same with a CE which is not supposed to have a subheader by default, I'm getting a form with 4 subheader fields, none of them containing any existent subheaders. All 4 are empty.

Changing the symlink back to a HEAD up to Jan. 30 gives me back my expected behaviour. One subheader for CE-Type Header, and one subheader for any other CE.

My installation is as fresh as can be, since I started over again 7 times within the last two weeks.

If this is expected behaviour for the future, just close the issue. Would render TYPO3 unusable for me, since I'm very much dependant on my subheaders.

To verify the option to enable the subheader for all CE, just use that TCEFORM directive on any TYPO3 version until 6.2.0beta3.

Besides that I'm also using the option to re-enable the hidden 'Graphical Frames' for Images:

TCEFORM.tt_content.image_frames.disabled = 0

This one is not effected and works well with latest HEAD.

Actions #7

Updated by Thomas Skierlo about 10 years ago

Stop: Back to start.
There is another one-liner needed in ext_tables.php

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addFieldsToPalette('tt_content','header','--linebreak--,subheader;LLL:EXT:cms/locallang_ttc.xlf:subheader_formlabel','after:header');

Was searching in other extensions, and forgot my own, where this is set. Sorry about that - but the message stays the same.

Actions #8

Updated by Thomas Skierlo about 10 years ago

Can hunt it down to typo3/sysext/core/Classes/Utility/ExtensionManagementUtility.php (addToAllTCAtypes), which was rewritten when the error occurred. This happend shortly after beta3.

Actions #9

Updated by Alexander Stehlik about 10 years ago

Please test if the patch for #55932 fixes this issue. This could be the case because the header palette contains these fields:

  • header
  • header_layout
  • header_position
  • header_link

which all start with header. So currently the field would be added four times.

Actions #10

Updated by Thomas Skierlo about 10 years ago

#55932 solves it for me. Great Job!

Actions #11

Updated by Georg Ringer about 10 years ago

  • Status changed from Needs Feedback to Closed

Thomas: believe me. I know the core well.

If you told me the line, a git blame would have showed

Actions

Also available in: Atom PDF