[Typo3] COA_INT + Plugin = no FE-rendering

[Peter Niederlag]

Hi,

[sorry this is long and confusing, since it is a kind of transcript of a
debugging session. Just didn't feel like putting more work into it for
cleaning]

Franz Koch schrieb:
>> Can you provide me with a BE-Login(oldschool-templating, can't dive into
>> TV as for lack of time)? I would like to have a look...
> 
> 
> Hi Peter,
> thanks for your unresting help. Well, a BE-Login is some kind of 
> difficult. My testing had all been locally - and the DEV-system is
> double  password secured (top secret project, eh ;-)).
> But have you tried it on one of your installations?

Well if it is top secret, I am sure there is some bucks left for
sponsoring somebody or assoc trying to help you on this. ;)

> All you have to do for testing on a "oldschool"-system is quickly 
> replacing a allready present marker:
> -----
> temp.menu >
> temp.menu = COA_INT
> temp.menu {
>     10 < plugin.tx_newloginbox_pi1
>     15 < plugin.tx_veguestbook_pi1
>     20 < plugin.tt_news
> }
> -----
> tt_news is rendering (the only one of the tested ones beside my own
> exts,  for which used tt_news as coding 'reference' to see how things
> are done), loginbox for example not. Same with most other extensions.
> Can you  reproduce this? By changing to COA everything should renders.

-----------------
First thing:
-----------------
Why do you need a COA_INT here? I haven't ever been working with
*nested* [COA|USER]_INT elements afair.

Why would you need a COA_INT in that scenario you mentioned above? the
plugins themeselves take care of being USER_INT or just USER. So it
would be quite sufficient to turn temp.menu into a COA. If parts of that
COA are USER_INT they wont be cached.

-----------------
Second thing:
-----------------
I believe for some reason there is just some small piece of TS missing
at the appropriate place. Can't exactly tell where and what goes wrong
but what falls into my eyes could be a clue:

Due to historic reasons the tt_news plugin is registered in
'tt_content.list.20.9.=< plugin.tt_news' already in the *default
TS-Template*(wether it be content(default) or css_styled_content)

Modern plugins(espacially those made by the kickstarter) use a call like
 t3lib_extMgm::addPItoST43($_EXTKEY,'pi3/class.tx_newloginbox_pi3.php','_pi3','list_type',0);
to get this little piece into there(as well as taking care of putting it
into TS:includeLibs).
This in turn calls t3lib_extMgm::addTypoScript.....

----------------
to test
----------------
just add some line of typoscript to check if there's in relation to the
t3lib_extMgm:: API as mentioned above.

includeLibs.tx_foo = EXT:foo/pi/class.tx_foo.php
plugin.tx_foo_pi1 = USER_INT
plugin.tx_foo_pi1 {
   userFunc = tx_foo_pi1->main
}
tt_content.list.20.foo_pi1 = < plugin.tx_foo_pi1

That's it for now. ;)

I am still in no way convinced that this is truely the problem!

Now, digging into some further tests I found one thing about the config
you are using(well since i couldn't get a logging, I just hacked the
server now ;) )

Try this, change
'page.20.subparts.CONTENT.10'  manually into a USER-object and closely
watch the Typoscript-Debugger!

Voila: Class not found. ;)
That means you just need to rearrange your TS-Setup(copying aroud with
the TS-Objects) or somehow make sure that the class is included!

HtH,
Peter
-- 
Peter Niederlag
http://www.niekom.de * TYPO3 & EDV Dienstleistungen *
http://www.typo3partner.net * professional services network *