PHPMailer and php thoughts.

First question.
Has anyone thought about the stopping of support PHP4 in future Evolution release?
If Evo 1.1 will be compatible with PHP4, then we need to add transitional class between PHPmailer and scripts like japanese guys did.
They created modxmailer class. Here is the source http://pastie.org/private/ogreturaq1plobne5njnw
We can use this class to solve encoding problems in all scripts (again, like jp guys did) and not just encodings but selecting proper version of PHPMailer depending on PHP version (if 1.1 will support php4 of course)

I just want to say, that we can do several important things.
- Update PHPmailer to latest version (2 different distribs for 4 and 5\6 version)
- Solve encoding issues. No more junk in subjects.
- Work with both PHP versions.

So what do you think? If you have time, look at Japanese MODx here http://code.google.com/p/modx-ja/
Just want to do something. (This is prior task in Russian community)

hello Paprikas, this is compatible and simple code for world.

<?php
/*******************************************************
*
* MODxMailer Class extends PHPMailer
* Created by ZeRo (http://www.petit-power.com/)
* Modified yama
*
*******************************************************
*/

include_once dirname(__FILE__)."/class.phpmailer.php";

class MODxMailer extends PHPMailer
{
function MODxMailer()
{
global $modx;
$modx_charset = $modx->config[’modx_charset’];

switch($modx_charset)
{
case ’japanese-utf8’:
case ’japanese-euc’ :
mb_language(’japanese’);
mb_internal_encoding($modx_charset);
$this->CharSet = ’iso-2022-jp’;
$this->Encoding = ’7bit’;
$this->FromName = mb_encode_mimeheader($this->FromName,$this->CharSet,"B",$this->LE);
$this->Subject = mb_convert_encoding($this->Subject,$this->CharSet,$modx_charset);
$this->Body = mb_convert_encoding($this->Body,$this->CharSet,$modx_charset);
breadk;
default:
$this->CharSet = $modx_charset;
}
}
}

............ this is missing.

Having recently errantly committed some code to the Evo core that relied on a non-default php extension, I want to raise a caution here that mbstring is a non-default extension as well.

Quote from: Paprikas at Apr 17, 2010, 07:34 AM

First question.
Has anyone thought about the stopping of support PHP4 in future Evolution release?

I’m personally against stopping PHP4 support in Evo. We recreated it for PHP 5 as Revo for a reason IMO.

Quote from: Paprikas at Apr 17, 2010, 07:34 AM

If Evo 1.1 will be compatible with PHP4, then we need to add transitional class between PHPmailer and scripts like japanese guys did.

I agree, lots of improvements can be made in this way.

Quote from: netProphET at Apr 17, 2010, 10:29 AM

Having recently errantly committed some code to the Evo core that relied on a non-default php extension, I want to raise a caution here that mbstring is a non-default extension as well.

Correct, ALL code must be properly checking for optional extensions and features when using them (including PHP version specific features in versions after PHP 4.3.3 or whatever we determine to be the oldest supported version) and provide alternatives when they are not available. We don’t want to break it for those that might not have some non-standard extensions (based on their version of PHP). This can be a little trickier and require some more robust community testing/input, but it can be done.

Hi,all,

This is Nick of Tokyo, Japan.

I and Yama would like to make a proposal about MODx’s mailer:

Why don’t you apply the "MODx mailer class", which had been developed by Japanese community, to the next version of MODx Evolution?

As Paprikas and Jason said, with the MODx mailer class, we can solve a multi-byte language issues in mailer.

At the present, MODx uses mail function and php mailer class.

Though in the Japanese environment, like all multi-byte language countries, we cannot use both mail function and php mailer class directly.

So we have developed "MODx mailer class" and it invoke php mailer class to handle e-mails.

If original MODx Evolution would apply this solution, a lot of users who are in multi-byte language countries, can maintain mail-system with ease.

Yama is saying that he would make a modification and commit it to the next release version, if our proposal would be adopted.

So please give a consideration for our proposal.

Can someone merge 1.0.3 and 1.1 branches, and make new experimental branch for PHPMailer updates? (I can try it by myself, but I’m not sure that I can do it well)
And by the way, we have already a lot of mb_string extension usages in MODx. So, is it still not-acceptable extension to use it in class?

These files use this extension.


I think that we need to add warning about this extension. (Check this during installation and after, in manager)
And add some logic to work properly if user doesn’t have this extension installed.

Quote from: Paprikas at Apr 18, 2010, 10:30 AM

Can someone merge 1.0.3 and 1.1 branches, and make new experimental branch for PHPMailer updates? (I can try it by myself, but I’m not sure that I can do it well)

Thanks for bringing this up. I will take some time to review the state of 1.x development, merge, and start discussing the future of Evolution development early this week. I think it’s time for some changes to the process and the tools we’re using and I want to solicit for feedback on some ideas. Regardless, I will get the merge done and let everyone know.

Quote from: Paprikas at Apr 18, 2010, 10:30 AM

And by the way, we have already a lot of mb_string extension usages in MODx. So, is it still not-acceptable extension to use it in class?

These files use this extension.

assets\plugins\tinymce\inc\tinymce.linklist.php
assets\plugins\tinymce\jscripts\tiny_mce\plugins\spellchecker\classes\GoogleSpell.php
assets\plugins\tinymce\jscripts\tiny_mce\plugins\spellchecker\classes\PSpellShell.php
assets\plugins\tinymce\jscripts\tiny_mce\plugins\spellchecker\classes\utils\JSON.php
assets\snippets\ajaxSearch\classes\ajaxSearchPopup.class.inc.php
assets\snippets\ajaxSearch\classes\FirePHPCore\FirePHP.class.php
assets\snippets\ajaxSearch\classes\FirePHPCore\FirePHP.class.php4
assets\snippets\ajaxSearch\classes\search.class.inc.php
manager\actions\search.static.php
manager\media\browser\mcpuk\connectors\php\Commands\DeleteFile.php
manager\media\browser\mcpuk\connectors\php\Commands\DeleteFolder.php
manager\media\browser\mcpuk\connectors\php\Commands\RenameFile.php
manager\media\browser\mcpuk\connectors\php\Commands\Thumbnail.php
manager\media\rss\rss_parse.inc

I think that we need to add warning about this extension. (Check this during installation and after, in manager)
And add some logic to work properly if user doesn’t have this extension installed.

It cannot be a required extension; not everyone has it installed. It’s fine to use it, but the code must be responsible and detect for it’s existence before calling it. Same goes for any non-standard extension, including Zip, or anything else. The FirePHP stuff is another one since it is PHP 5 only. Again, I don’t think it’s a problem to use these things in MODx Extras, or even core code, but they should be used with degradation in mind so we keep Evolution accessible to as wide a variety of PHP’ers as possible.

We can target more modern environments in Revolution, though even there I would say the principle still applies. The baseline is just a little higher.