Forge: Provide a hook / Signal reference about typo3cms-reference-coreapi

[susannemoog]

fyi the adminpanel extended displays hooks and signals and input values given (https://packagist.org/packages/psychomieze/adminpanel-extended) and could be used as a start point / reference.

[lolli42]

Another note ;) It becomes relatively likely that core v10 changes both signals and hooks: psr-14 "Event manager" is basically a hook interface, this PSR is not yet officially released but is stabilizing. It is pretty likely that we'll use that and substitute both signals+hooks with that approach in v10. Thus, I'm not too sure if a full signal/hook reference is still worth the effort at the moment. If anyone still finds spare time and picks this topic up, it wouldn't hurt, though.

[DanielSiepmann]

Yeah that's an old one by myself. As far as I know this will come to the core in the near future? Don't ask me where I did hear that.

Anyway it would be to much work to create such a list by hand. What do you think @sypets @marble?

[sypets]

I don't have enough information what the current status is. If that is in any way possible, it would be cool to be able to autogenerate a list.

[sypets]

Finding hooks:

Resources:

• core api
• Daniel Siepmann: How to find hooks

As a crude method for generating list of hooks, this works:

grep -r -F "['SC_OPTIONS'][" typo3/sysext/ | grep -v ext_localconf | grep -v Test | grep -v "/Documentation" | perl -p -e "s/.*(\[\'SC_OPTIONS\'\])(\[(\'.*\'|[^ ]*::class|\\$.*)\])+.*/\1\2/" | grep -v "\\$" | sort -u

results: hooklist-typo3-9.3-dev.txt

The extension dmc_hooklist is outdated.

Another method is to browse through the changelogs:

• 79647: https://docs.typo3.org/typo3cms/extensions/core/Changelog/8.7.x/Important-79647-AddedHookForResolvingCustomLinkTypes.html
• ... https://docs.typo3.org/typo3cms/extensions/core/search.html?q=hook&check_keywords=yes&area=default

Finding signals

• core api

[DanielSiepmann]

That can't fully work. Some classes save the hooks in an internal variable and reuse them on multiple places. This way it's just not possible, without parsing all php files, to generate a full list of all hooks.

But still that might provide a nearly complete list which might be better than nothing.

[lolli42]

With the discussion in coredev channel https://typo3.slack.com/archives/C03AM9R17/p1526392541000230 in mind, I'd opt to close the issue for now.

[sypets]

As an alternative for closing this ticket, I would like the section on finding hooks / signals to be improved a little bit: https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Hooks/Concept/Index.html?highlight=hooks%20signals#finding-signals

If this can be improved with minimal effort and / or some links to already existing information added, it might be helpful.

If I understood correctly, Daniel is willing to handle this.

Details:

• "but they are easily found by searching the TYPO3 core for dispatch(." I would slightly disagree on the easily. For generating the list: Yes, you can find them but the output should be formatted to be helpful.
• The text says: "For finding hooks, look into the next chapter Hook configuration.". But the next chapter does not really mention finding hooks. I guess, it's kind of obvious you can search for SC_OPTIONS, but then at least write it in the corresponding section.

[sypets]

Related: #15

[lolli42]

Well, I'd argue that using a hook / signal usually forces to read the source that emits the signal / calls a hook anyway: The input and output values are almost always unique and specially crafted for this single place, a developer who wants to use a hook has to take a look at the implementation in detail. Having a (manual?) reference of hooks / signals thus won't help that much, if you're looking for something to slot/hook in, you have to know the according handling core side class already. So, a general "how a hook / signal usually works" documentation is needed, but I guess an (incomplete? / outdated?) list of hooks / signals is of very limited use. Thus, I'd still to close this issue. Maybe we find some generic solution with a new API in place, this should also consolidate the possible options, and reduce for instance the different hook incarnations (there are 3 or 4 different basic types), too.

[lolli42]

Had a quick talk with Sybille on this recently. We'll close that issue: It is unlikely we'll come up with a hooks / signal+slot reference anytime soon.