Bug #32252
closedStory #69712: Further FormEngine development
Unable to set Publish Dates and Access Rights on any alternative language content element
Added by Sara no-lastname-given almost 13 years ago. Updated about 7 years ago.
100%
Description
In all alternative language content elements (not localised elements - this is for separate localisation) both 'Publish Date' and 'Expiration Date' fields are uneditable and show 01:00 01-01-1970. This means only the default language can be published as a timed element.
This happens in both live and custom workspaces.
Typo3 4.6.1
Updated by Michael Stucki almost 13 years ago
- Category set to Backend User Interface
- Priority changed from Must have to Should have
It seems like this functionality was disabled because the feature has never worked (see #24211).
I'm actually wondering why the field was turned into read-only rather than fixing the real problem. Is it so hard to fix?
Updated by Sara no-lastname-given almost 13 years ago
Why thas this issue been change to 'should have'? We cannot publish timed content elements at the moment and this is a huge issue for us.
Please reconsider the importance of this bug. Thank you.
Updated by Henrik Ziegenhain almost 13 years ago
I agree with Sara.
This is a very important point for us to set different publish and unpublish dates.
We never discovered that this feature never worked. But this is somehow better for clients than disabling the fields.
Updated by Sara no-lastname-given over 12 years ago
This feature has always worked for us until we upgraded.
Please could someone bump this so it is solved. We have a huge problem in not being able to use this feature.
Updated by Andreas Kießling over 12 years ago
I also can't recall, that this feature "never worked".
The only thing that never worked, was to disable the default content element and only enable the overlay. But this is the case for pretty much all extensions.
getRecordOverlay uses enableFields and if the TS is set like this, then a disabled overlay will not be shown, either if it is hidden or due to start/endtime restriction
config.sys_language_overlay = hideNonTranslated config.sys_language_mode = strict
enableFields does not analyse the l10n settings, so if you have previously entered dates in starttime/endtime, then you can't change them anymore...
@Sara and Henrik (hope it may still help you):
If you need to "enable" the fields again, you can unset the TCA config in your extTables.php
t3lib_div::loadTCA('tt_content'); unset($TCA['tt_content']['columns']['starttime']['l10n_display']); unset($TCA['tt_content']['columns']['starttime']['l10n_mode']); unset($TCA['tt_content']['columns']['endtime']['l10n_display']); unset($TCA['tt_content']['columns']['endtime']['l10n_mode']);
I would highly appreciate to reconsider this change. If you use e.g. templavoila, i think it is very common to create content elements that have no "default" record. You can't even set a starttime/endtime for these elements, because sys_language_uid is tested in t3lib_TCEforms, and not if there is a value set for l18n_parent.
With the "classic" page module and styles.content.get, this is also doable, but probably not that common.
Updated by Lorenz Ulrich over 10 years ago
I would also appreciate if this could be reconsidered. If you add an element in the non-default language only, you have no way of setting the starttime/endtime. Therefore I don't see the advantage of disabling the fields...
Updated by Philipp Wrann about 10 years ago
I back that thought.
Configuration should probably be:
l10n_mode = mergeIfNotBlank
Updated by Mathias Schreiber almost 10 years ago
- Target version set to 7.2 (Frontend)
- Is Regression set to No
Updated by Benni Mack over 9 years ago
- Target version changed from 7.2 (Frontend) to 7.4 (Backend)
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack about 9 years ago
- Target version changed from 7.5 to 7 LTS
Updated by Gerrit Code Review about 9 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44101
Updated by Gerrit Code Review about 9 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44101
Updated by Gerrit Code Review about 9 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44101
Updated by Gerrit Code Review about 9 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44101
Updated by Gerrit Code Review about 9 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44101
Updated by Gerrit Code Review about 9 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44101
Updated by Gerrit Code Review about 9 years ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44101
Updated by Gerrit Code Review about 9 years ago
Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44101
Updated by Mathias Schreiber about 9 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset ef67ca33b90ced3da15ade4ab102c244f445f9d9.
Updated by Thomas Sperling over 8 years ago
Could we have this bugfix to TYPO3 6.2, too?
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Resolved to Closed