TYPO3 Core

There is also a warning message at typo3.org that 2 dependant extensions fh_library and table were not be available:

Extension key: tt_products
Version: 2.4.9
Category: plugin
State: Beta
Review state: Not reviewed!
Dependencies:
depends on cms
depends on table 0.0.9-
depends on fh_library 0.0.8-
depends on php 4.2.3-
depends on typo3 3.8.0-4.0.20
conflicts with zk_products
conflicts with mkl_products
conflicts with ast_rteproducts
conflicts with onet_ttproducts_rte
conflicts with shopsort
conflicts with c3bi_cookie_at_login
Warning: Some of the extensions (or versions) are not available in the official repository!

Shy extensions declare themselves as shy, the EM has to observe this.

Really, is TemplaVoila a shy extension, because it will only show in EM if Display Shy Extensions is enabled. This is response that you sent is a frustrating snd insulting response and makes it appear that you aren't truly researching to see if there is a problem.

This is a bug please look into it.

Bill, sorry if I was insulting you - that was not my intention.

But look at it from my perspective: a two-line bug report without any further details about expected and actual results or steps to reproduce about something which works fine for me. Why should I really investigate, instead of looking at one of the other reproducable, well described, more severe bugs ?

So please provide some more information, thanks!

While working on another bug I found (the|a) possible reason for this. If you could attach the ext_emconf.php file of the TemplaVoila installed at your setup, that would be fine.

If I am right, it contains a line
'shy' => 'false'

This evaluates to true (because it is a string with some content). (It seems this is a TV bug, though.)

Hi Robert, we talked about this earlier - could you please check your local ("master") emconf file for this?

In related issue 2992, I have extension sr_email_subscribe in which I have set 'shy' => 0.

However, after uploading to TER some transformation seems to happen. A user reports that on import, ext_emconf contains 'shy' => 'false'

Should be ok, yet the extension is considered shy.

Perhaps, this should be generated as 'shy' => FALSE ?

Hi Karsten,

please check whether this is a bug on the EM or TER2 and change the bug report category accordingly.

I have set the severity to "block" because this must be fixed before 4.0 is released in case it is a bug of the EM and not TER2.

cheers,
Ingmar

Stanislas, if it was
'shy' => false
it would work. But it seems to become
'shy' => 'false'

(edit: I wrote this based on the notification mail, in which the edit by Stanislas apparently wasn't contained... So we're on the same side.)

At least we know it's not the "source" ext_emconf.php that's broken. I'll look into the issue tomorrow, to see where it happens.

Ok, some thoughts.

The emconf data coming from the repository has 'false' already in case of sr_email_subscribe 0.3.1. This evaluates to true and so on, we know the rest. How does it come that there is'false'?

In arrayToCode() is a check whether some value is numeric, to wrap it in single quotes otherwise. This is done using t3lib_div::testInt() which does
!strcmp($var,intval($var))
which obviously fails for something like '0' (which is a string but could be considered a numeric value). So, ok, we keep it as a string. Fine.

All this still doesn't explain why it becomes false in the first place.

Could this be caused by something in the TER? SOAP? Something that transforms '0' to 'false'?

I could add a check for 'false', but I'd rather understand the reason first...

In tx_ter the method uploadExtension_writeExtensionInfoToDB() contains the line
'shy' => (boolean) $extensionInfoData->technicalData->shy ? 1: 0
which obviously makes this a boolean - and if this was supposed to return an integer it should be:
'shy' => ((boolean) $extensionInfoData->technicalData->shy) ? 1 : 0

But after looking at it for a few minutes it seems this isn't the cause of the problem, as this is only prepared for inserting into the DB. The stuff written to the extension file is taken straight from the uploaded data, it seems.

Now, it would be interesting to see what comes out of the SOAP channel on the TER side. Let's see... The TER receives false all(!) the time - as string! This is caused by wrongly using utf8_encode() on the shy value in the EM, turning it into a string locally.

So change this to intval() - now we get true/false on the TER side of the SOAP channel (after feeding it an integer). This true/false is received as a string(!) again. And written to disk as a string, and downloaded as string. And a string with content evaluates to true... So everything uploaded eventually becomes shy. Doh!

Hi Karsten,

thanks for your work.

So do I get right that the solutions is still not found?

My suggestion would be to use 1/0 all the time instead of true/false, because for 1/0 it doesn't matter at all whether they're treated as a string or an integer, they will always return the correct boolean value when used in an if() in PHP.

if(0) will be false
if("0") will be false as well

Is that an option?

cheers,
Ingmar

Next try is feeding the SOAP call true booleans, not integers. Still we receive strings with true and false, the error persists.

OK, then I definitely suggest to use 1/0 everywhere. That is handled by all SOAP libraries and all PHP versions correctly so you won't have problems anymore.

BTW, aside from shy also uploadFolder and clearCacheOnLoad are affected.

Robert and I fixed this during a telephone session - it seems to be a bug in the PHP SOAP implementation. The WSDL defines those variables as boolean, but when a true boolean is fed to the SOAP call, a string is received.

Robert now (in addition to my EM fixes - not using utf8_encode on the affected values and feeding tru booleans to the SOAP) changed the TER code so it works around this bug.

So did you change something in the TYPO3 Core?

4.0rc3 is going to be released in about in hour, so please send me the patch if any.

cheers
Ingmar

Just sent the patch...

I am sorry to say but as far I can tell the problem is still not quite solved. :-<

EXT:pdf_generator2 according to his Author has set 'shy' => 0 before uploading.

Importing this extension however results in 'shy' = 1 with TYPO3 4.0

I just checked and could not reproduce it with current SVN (which has not changed in related parts since 4.0.0). Works as expected.