[TYPO3-core] RFC #16177: Add DB structure update pre-processing hook in EM

Ernesto Baschny [cron IT] ernst at cron-it.de
Tue Nov 2 08:37:48 CET 2010


Franz Holzinger schrieb am 02.11.2010 08:27:

>> Please find enclosed v3 which takes care of hiding any "import static
>> data" that should not be shown while the hook provides another form.
>>
>> I now have a working patch for DBAL [1] which detects invalid
>> table/field names, have a method to suggest a better naming (should
>> still be enhanced), shows the form to the user and updates localconf.php
>> with the mapping. Once the hook detects that all seems good (no more
>> problem with table/field names), it lets EM works as usual, that is show
>> tables to be created.

> I still would like to have some modification.
> 
> The hook has a break in the for loop. This means that the hook will be
> executed only for the first extension and not for the others.

I think the idea is that each hook will have its own rendering and
processing time, one after the other. So first you see the "form" for
the first hook caller, then you submit it, do stuff, until that first
hook is "satisfied" and no longer outputs anything, then the second hook
will be called. This would avoid a mix of different forms or "wizards"
on the same page.

> (...)
> And another proposal: Add the extension key to the hook. In most cases
> you will write a hook only for one or very few extensions. The hook
> shall not be called for other extensions.
>
> foreach
>
($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['typo3/mod/tools/em/index.php']['checkDBupdates'][$extKey])
> as $classData) {

Probably the only implementation of that hook will be DBAL. And DBAL
needs to see all extensions being updated in the EM and not dbal itself.
So I see no use in restricting it like you suggest.

An extension cannot hook itself in its "own" processing anyway, because
its ext_localconf.php won't be loaded before the extension is fully
installed.

Cheers,
Ernesto


More information about the TYPO3-team-core mailing list