message is lost when switching from html view to plain

[cebe]

Hi,

When switching from html to plain text composing, message totally disappear. Cleaning/sanitize function seems to be a little brutal.
A good html to plain text conversion is required (striptags php function is good for that).

Thanks.

[till]

I am almost certain that striptags has issue and while it's able to filter good html code, what about injections, etc.. I think that is why the function is sort of brutal.

I agree that if the message disappears, there is an issue.

[alec]

Please attach sample message.

[luca.cervasio]

Basically bin/html2text.php misses an include. I don't know exactly why, but the easy patch attached solves the situation on my setup.

[luca.cervasio]

Simple patch which solves the issue on my setup

[alec]

Replying to luca.cervasio:

Basically bin/html2text.php misses an include. I don't know exactly why, but the easy patch attached solves the situation on my setup.

No, no, no. iniset.php contains autoload definition, so we must find why it's not used. And I think it'll not fix cebe's issue.

[luca.cervasio]

You're right: I don't have a comprehensive understand of RC as you have; I was just trying experiments and I found that html2text class wasn't load.

Now that you explained that iniset.php is used for autoloading and that this is the design to be used in the global application logic, I found that instruction 'include_once' in autoload method doesn't make use of include_path php environment variable as stated in php manual:

"Specifies a list of directories where the require(), include(), fopen(), file(), readfile() and file_get_contents() functions look for files". ​http://it.php.net/manual/en/ini.core.php#ini.include-path

So I just changed 'include_once' in 'include' at line 82 in iniset.php and bug was fixed on my setup (debian stable, apache2, php5.2, mysql5, firefox3 on windows as client).

Please forgive if I didn't consider any other higher logic !!

[alec]

Replying to luca.cervasio:

Now that you explained that iniset.php is used for autoloading and that this is the design to be used in the global application logic, I found that instruction 'include_once' in autoload method doesn't make use of include_path php environment variable as stated in php manual:

"Specifies a list of directories where the require(), include(), fopen(), file(), readfile() and file_get_contents() functions look for files". ​http://it.php.net/manual/en/ini.core.php#ini.include-path

but it's working on my server, so include_path is used by include_once() also

So I just changed 'include_once' in 'include' at line 82 in iniset.php and bug was fixed on my setup (debian stable, apache2, php5.2, mysql5, firefox3 on windows as client).

it's not a solution

[luca.cervasio]

Replying to alec:

but it's working on my server, so include_path is used by include_once() also

Alec, you're right again ! I changed 'include_once' to 'include' and I saw the html2text conversion working so I though that the former function didn't use include_path while the latter did.
But as you said it's not a matter of using includ_path, as both use include_path (I could check this on my own too).

But for sure changing include_once to include in autoload method in iniset.php has the effect that html to plain-text conversion starts working on my system.
I can't figure out why ! Do you have any ideas or clues ?

[rosali]

Replying to luca.cervasio:

Replying to alec:

but it's working on my server, so include_path is used by include_once() also

Alec, you're right again ! I changed 'include_once' to 'include' and I saw the html2text conversion working so I though that the former function didn't use include_path while the latter did.
But as you said it's not a matter of using includ_path, as both use include_path (I could check this on my own too).

just a cross link: #1485505

But for sure changing include_once to include in autoload method in iniset.php has the effect that html to plain-text conversion starts working on my system.
I can't figure out why ! Do you have any ideas or clues ?

[rosali]

Looking at the patch, this ticket could be closed as fixed (#1405505).

[alec]

Ok, closing. Cebe was talking about brutal tags stripping, so I'm not sure if this fixes his issue. Reopen if needed.