Bug #26522
Document "printBeforeContent" for cObject EDITPANEL
| Status: | Closed | Start date: | 2011-04-30 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | Francois Suter | % Done: | 100% |
|
| Category: | - | |||
| Target version: | 4.5.0 | |||
| Votes: | 0 |
Description
Added with #19161 (added for TYPO3 4.3) the content object EDITPANEL got the following new property.
In TYPO3 4.5 the code is located in typo3/sysext/feedit/view/class.tx_feedit_editpanel.php:
Property: printBeforeContent Data type: boolean Description: Normally the edit panel is displayed below the content element it belongs to. If this option is set, the panel is printed in front of the according element. Example: tt_content.stdWrap.editPanel.printBeforeContent = 1 This displays the edit panels in front of the according elements, if you use css_styled_content. Default: 0
Setting the property as in the example above works, but setting it in a content object of the type EDITPANEL did not work in my quick test:
10 = EDITPANEL # does not work for me 10.printBeforeContent = 1
Anyone successful? I want to have a working example like 10 = EDITPANEL ......
Related issues
| related to Core - Feature #19161: Make Position of Editpanel more variable | Closed | 2008-07-28 |
Associated revisions
Fixed bug #26522: Document "printBeforeContent" for cObject EDITPANEL
Added note about dependency on feedit for EDITPANEL, references #26522
Corrected a couple of typos
Added callout-box around note for FLUIDTEMPLATE
History
Updated by Francois Suter about 2 years ago
I tried and observed the same behavior, but I would say it's normal. The property says that the edit panel will appear before the content to be edited. But if you insert an EDITPANEL as a content object with TypoScript, it's not related to any editable content. So what should it be placed before?
As far as I understand it (having never used an EDITPANEL as a stand-alone cObject) I would say that it's only purpose in such a use case is to provide icons for creating new records in some table.
Does that make sense?
Updated by Chris topher about 2 years ago
Francois Suter wrote:
I tried and observed the same behavior, but I would say it's normal. The property says that the edit panel will appear before the content to be edited. But if you insert an EDITPANEL as a content object with TypoScript, it's not related to any editable content.
First sounds logical, but must not necessarily be true: I tested with a config where I took css_styled_content and used stdWrap to ".append" an EDITPANEL cObject to each content element on the page. It then also contains the buttons, with which you can edit the connected content element. That's why I thought that changing the position should work, too.
In my setup I appended the EDITPANELs and they appeared behind the content element they belonged to.
Now I see how to easily change that: If I wanted to have them in front, I would just have had to use .prepend instead of .append, I guess. So that way we do not need that option at all in my usecase and it is no real shortcoming that it did not work as I expected.
As far as I understand it (having never used an EDITPANEL as a stand-alone cObject) I would say that it's only purpose in such a use case is to provide icons for creating new records in some table.
And to edit existing elements. That is why I thought that the implementation was incomplete (see thoughts above). But that's clear to me now.
I would say: Add the text, maybe some way like proposed in the description
And add a note that if you added an EDITPANEL as own cObjects to a content element using stdWrap, you can change the position of the EDITPANEL by using the right stdWrap property (.prepend instead of .append). So you do not need that option there.
Updated by Francois Suter about 2 years ago
- Status changed from New to Accepted
- Assignee set to Francois Suter
- Target version set to 4.5.0
I looked at this again and made the following improvements:
- improved the introduction to clearly explain what appears according to what configuration (which is not so simple)
- added an example of usage in template
- added the new printBeforeContent property
I would quite like your review on these changes, especially the introduction.
In general, I realized that all these properties relate to the "feedit" sysext. So they should - ideally - be moved to the documentation of that extension, but it doesn't exist. Every FE-editing extension may have its own settings. When such a content object is used, its rendering is simply delegated to whatever FE-editing viewer class is currently registered.
Updated by Francois Suter about 2 years ago
- Status changed from Accepted to Resolved
- % Done changed from 0 to 100
Applied in changeset r754.
Updated by Chris topher about 2 years ago
- Status changed from Resolved to Under Review
Francois Suter wrote:
(list of changes)
I would quite like your review on these changes, especially the introduction.
I will do. I guess that makes sense, when you have finished your review (and not before).
In general, I realized that all these properties relate to the "feedit" sysext. So they should - ideally - be moved to the documentation of that extension, but it doesn't exist. Every FE-editing extension may have its own settings. When such a content object is used, its rendering is simply delegated to whatever FE-editing viewer class is currently registered.
So maybe we should add a note, that - beginning with TYPO3 4.3 - the ext feedit needs to be installed, same as we have such a note in place for FLUIDTEMPLATE.
Updated by Chris topher about 2 years ago
- Subject changed from Document "printBeforeContent" for cObject EDITPANEL? to Document "printBeforeContent" for cObject EDITPANEL
Updated by Francois Suter about 2 years ago
- Status changed from Under Review to Resolved
I think the description is good enough now. I want to go ahead and publish.
Updated by Chris topher about 2 years ago
- Status changed from Resolved to Closed
Updated by Chris topher about 2 years ago
I have just reviewed the changes as promissed.
I also fixed some formatting issues which you see, when you have a look at the HTML version of TSref on typo3.org: Some lines of ordinary text still had the internal formatting "headline" (the known bug). I hope that I could solve that, too.
Committed in r788.
Updated by Francois Suter about 2 years ago
Thanks. I would say this is nothing urgent. Let's wait for other bug fixes before releasing a 4.5.1 version.