Bug #22359

No FE editing with only field edit icons and with "old" feedit extension

Added by Mickaël PERRIN almost 12 years ago. Updated about 2 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:



I was unable to make FE editing work with this UserTS setup :

admPanel {
enable {
edit = 1
hide = 1
override {
edit {
displayFieldIcons = 1
displayIcons = 0

Setting displayIcons = 1 does the trick however this enable features I don't need.

It seems there is an issue with the test function isFrontendEditingActive which is testing only if $GLOBALS['TSFE']->displayEditIcons 1 but not if $GLOBALS['TSFE']->displayFieldEditIcons 1.

A simple patch is attached.

Many thanks for your review

(issue imported from #M13978)


patch1.patch (644 Bytes) patch1.patch Administrator Admin, 2010-03-31 15:26
13978-2.patch (594 Bytes) 13978-2.patch Administrator Admin, 2011-02-08 09:46

Related issues

Related to TYPO3 Core - Bug #23245: Argument 3 passed to t3lib_frontendedit::displayEditIcons() must be an array, null givenClosedSusanne Moog2010-07-21


Updated by Daniel Mueller over 11 years ago

Your problem might root to the same source as Issue 0015194. It seems you may not unset displayEditIcons.


Updated by Fedir RYKHTIK almost 11 years ago

2 Daniel Mueller

No. It's seems to be an another problem. Existing verification is not complete, it checks only the case when edit icons are rendered aside content records, and not the case when edit icons are rendered aside individual fields of content.

So the proposed patch should resolve the bug. I've made a little bit more clean version of the patch. Check in the attachment.


Updated by Loek Hilgersom almost 11 years ago

Just ran into the same issue, summarized:
for non-admin be-users, you cannot enable admin panel displayFieldIcons without also enabling displayIcons.

The problem still exists with v4.4 and 4.5

The second patch, 13978-2.patch, is clean and working for TYPO3 v4.5.0
+1 by reading and testing, should be a no-brainer.


Updated by Martin Holtz over 8 years ago

  • Target version deleted (0)


i can confirm this issue with TYPO3 6.1.1

a Workaround is, to remove the editPanel via TypoScript. If you need to have it different on usergroup, you can use conditions for checking for hat.

tt_content.stdWrap.editPanel >


Updated by Mathias Schreiber about 7 years ago

  • Description updated (diff)
  • Category changed from Communication to Frontend
  • Target version set to 7.2 (Frontend)
  • TYPO3 Version set to 4.5
  • Is Regression set to No

Updated by Benni Mack over 6 years ago

  • Target version changed from 7.2 (Frontend) to 7.4 (Backend)

Updated by Susanne Moog over 6 years ago

  • Target version changed from 7.4 (Backend) to 7.5

Updated by Benni Mack over 6 years ago

  • Target version changed from 7.5 to 7 LTS

Updated by Mathias Schreiber about 6 years ago

  • Target version deleted (7 LTS)

Updated by Sybille Peters almost 4 years ago

Thank you for your report.

Even though it has been some time, would you consider checking if your patch idea is still up to date and upload it to our Gerrit review server?

Someone could do this for you, but I am thinking you might like the opportunity to contribute to TYPO3 yourself.

You can find a description of the TYPO3 contribution workflow here: https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/

Hint: If you get stuck anywhere, ask on Slack in the #typo3-cms-coredev channel. You can register in the TYPO3 slack workspace here: https://forger.typo3.com/slack

Thank you in advance!


Updated by Susanne Moog over 3 years ago

  • Category changed from Frontend to AdminPanel

Updated by Susanne Moog about 2 years ago

  • Status changed from New to Closed

As feedit was moved out of the core, please report the issue at https://github.com/FriendsOfTYPO3/feedit if it still exists.

Also available in: Atom PDF