TYPO3 Core

IMHO this causes that TCA configuration is cached.
PHP functions like

strtotime('foo')

or

mktime()

will be interpreted newly, each time cache is flushed, and then keeps the value from the time, the cache was generated.

Joerg Kummer wrote:

IMHO this causes that TCA configuration is cached.
PHP functions like

[...]

or

[...]

will be interpreted newly, each time cache is flushed, and then keeps the value from the time, the cache was generated.

I can't follow your though. Could you elaborate?

I think I didn't explain enough. Let's look at the following scenario:

1) Today is the 30.10.2018 15:40
2) I set the "evstartdate" as 30.10.2018 15:41 and save
3) I close the change in the BE at 30.10.2018 15:43
4) At 30.10.2018 15:45 I reopen the changed event record
=> the "evstartdate" inputDatetime field flashes up with "15:45 30-10-2018" as value and then gets cleared

5) I remove/comment the range part

                'range'      => [
                    'lower' => strtotime('today 00:00'),
                ],

6) I reopen the changed event record
=> the "evstartdate" inputDatetime field contains "15:45 30-10-2018" as value and then doesn't get cleared

7) After undoing step 5 the result is again same as in step 4

When I debugged "/typo3/sysext/core/Resources/Public/JavaScript/Contrib/bootstrap-datetimepicker.js" I see that after loading the iframe (edit form for the event record) the input still got the correct value "15:45 30-10-2018". Atfer running through "/typo3/sysext/core/Resources/Public/JavaScript/Contrib/bootstrap-datetimepicker.js" the inputDatetime field for "evstartdate" is empty.

Please have a look at the temporary files of your TYPO3 8 installation ../typo3temp/var/Cache/Code/cache_core/tca_base[ANY_LONG_HASCH_VALUE].php_,
after cache was generated. This TCA configuration should contain your entries, where php functions like strtotime() has been executed.

'evstartdate' => array (
    'exclude' => 1,
    'label' => 'LLL:EXT:myextension/Resources/Private/Language/locallang.xlf:db.tx_myextension_domain_model_event.startdate',
    'config' => array (
        'type' => 'input',
        'renderType' => 'inputDateTime',
        'eval' => 'datetime,required',
        'range' => array (
            'lower' => 1536105600,
        ),
    ),
),
'evenddate' => array (
    'exclude' => 1,
    'label' => 'LLL:EXT:myextension/Resources/Private/Language/locallang.xlf:db.tx_myextension_domain_model_event.enddate',
    'config' => array (
        'type' => 'input',
        'renderType' => 'inputDateTime',
        'eval' => 'datetime,required',
        'range' => array (
            'lower' => 1536134639,
        ),
    ),
),

The values for config.range.lower will be keept, as long the cache is valid, or will be regenerated with new values, each time, the cache is flushed.
Therefore i think, your TCA configuration will never work as expected for editors. In other words - I recommend to avoid such php functions in TCA configurations.

Joerg Kummer wrote:

Please have a look at the temporary files of your TYPO3 8 installation ../typo3temp/var/Cache/Code/cache_core/tca_base[ANY_LONG_HASCH_VALUE].php_,
after cache was generated. This TCA configuration should contain your entries, where php functions like strtotime() has been executed.

[...]

The values for config.range.lower will be keept, as long the cache is valid, or will be regenerated with new values, each time, the cache is flushed.
Therefore i think, your TCA configuration will never work as expected for editors. In other words - I recommend to avoid such php functions in TCA configurations.

Yes, you are right. This is also the logical consequence when the cache is handling it like this.

But this is a daily scenario. E.g. when a user enters a datetime in the BE a time ago and then revisits the record after the entered datetime then this issue occurs. A possible solution would be to never cache this field when evaluating?

Caching is a good way to get software running fast. Why not configure such TCA fields for your needs. Try to remove the 'range' configuration, clear cache and see, how your fields in backend acts in the next days.
Your date fields will be filled automaticly with current date/datetime, what you initial want to achieve.

Joerg Kummer wrote:

Caching is a good way to get software running fast. Why not configure such TCA fields for your needs. Try to remove the 'range' configuration, clear cache and see, how your fields in backend acts in the next days.
Your date fields will be filled automaticly with current date/datetime, what you initial want to achieve.

Yes, you are absolutely right that caching is a good thing. But I think there's a misunderstanding with what I am trying to achieve.

I want to give the BE user the possibility to select datetimes which are not prior the current date. Which I managed by setting the lower range to today. But the buggy thing is that when the user checks the datetime later (after the set datetime) again then the datetime flashes up and is gone.

You can see this effect in the movie "inputDatetime.mov" I attached in the ticket.

Frank Naegler wrote:

The TCA is a configuration and is cached, the TCA must not contain any logic.
E.g. if you think about using a yaml file or ini file for TCA config, you can't use time() function as well.
So, I guess we can and should close this issue, we will not support any kind of dynamic code in TCA.

Hi Frank,

your argumentation seems logic since the TCA is meant for configuration.

For further misuse I think it would be nice to mention this in the documentation (https://docs.typo3.org/typo3cms/TCAReference/ColumnsConfig/Type/Input.html#range).

Could anyone close the ticket? It seems I don't have the rights to do so.

Susanne Moog wrote:

Thanks for the feedback, I'm closing the ticket for you. If you want, you can request a change of the documentation: on the top right of the docs is an "edit me on Github" link - you can add a hint to the docs there.

Thank you too for your help. I did as suggested and added an edit for the doc.

Have a nice day