Bug #22359

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

Added by Mickaël PERRIN almost 9 years ago. Updated 8 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
AdminPanel
Target version:
-
Start date:
2010-03-31
Due date:
% Done:

0%

TYPO3 Version:
4.5
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Hello,

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 View (644 Bytes) Administrator Admin, 2010-03-31 15:26

13978-2.patch View (594 Bytes) 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 given Closed 2010-07-21

History

#1 Updated by Daniel Mueller over 8 years ago

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

#2 Updated by Fedir RYKHTIK about 8 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.

#3 Updated by Loek Hilgersom about 8 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.

#4 Updated by Martin Holtz over 5 years ago

  • Target version deleted (0)

Hi,

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 >

#5 Updated by Mathias Schreiber about 4 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

#6 Updated by Benni Mack almost 4 years ago

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

#7 Updated by Susanne Moog over 3 years ago

  • Target version changed from 7.4 (Backend) to 7.5

#8 Updated by Benni Mack over 3 years ago

  • Target version changed from 7.5 to 7 LTS

#9 Updated by Mathias Schreiber over 3 years ago

  • Target version deleted (7 LTS)

#10 Updated by Sybille Peters about 1 year 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!

#11 Updated by Susanne Moog 8 months ago

  • Category changed from Frontend to AdminPanel

Also available in: Atom PDF