Community Forum

If you have questions about my software, chances are this forum has the answers.

You'll need to register before you can post on the forum to ask your question or to answer another one. A reply will be posted to each and every question that is asked so there is no need to double post or bump your post. I do my best to answer promptly but in some cases it may take a day or two. Bear with me and I`ll get your question answered quickly.

Here are a few tips to help you to get your questions answered more rapidly.

IMPORTANT: Posts in English only. I don't have a translator and I'll be unable to understand your message properly and will probably delete it.
SEARCH: Use the search option to see if your question has been answered on the forum before now or if there is an answer in the documentation of your software.
PRIORITY SUPPORT: If you have purchased a commercial version of any software, using the contact option at the licence centre ensures a faster response.
AUTO DELETION: Accounts older than 5 days, with no posts or topics, are automatically deleted. Only register if you are thinking of posting.
LINKS: Any links posted are not clickable and must be copied / pasted into your browser address bar.

You are not logged in.

#1 y3000 09-07-2018 14:20:44

Maian Support 4.0

Problems with umlauts (ä, ö, ü, ß) and/or missing text in outgoing mails
Convert and save the mail templates (e.g. in folder /content/language/german/mail-templates/) as UTF-8 files instead of ANSI/LATIN1/ISO-8859-1.

The column "Assign To" is empty and so you can't assign ticket to a supporter
Enable mail notification for the staff or edit the file /admin/templates/system/tickets/tickets-assign.php and remove the following term in the MySQL-Query for $q_users: WHERE `notify` = 'yes'

Message "parse_str(): Calling parse_str() without the result argument is deprecated" when catch mail via IMAP
Edit file /control/system/init.php and replace "$cronp = parse_str($argv[1])" with "parse_str($argv[1], $cronp)" and replace "$cronp2 = parse_str($argv[2])" with "parse_str($argv[2], $cronp2)".

When catching mails via IMAP blanks in subject are replaced with "_"
Maybe a dirty workaround wink Edit /control/classes/class.imap.php and replace the following line:
'subject' => ($h->subject ? mb_decode_mimeheader($h->subject) : $msg_piping6),
with:
'subject' => str_replace('_', ' ', ($h->subject ? mb_decode_mimeheader($h->subject) : $msg_piping6)),

Last edited by y3000 (16-07-2018 10:26:30)

#2 msworld 09-07-2018 16:21:05

Thanks for the updates. smile

I have tested it with umlauts with no issues, but thanks for the code. Not sure if the issue is related to certain emails.

Have you actually enabled the assign system via a department? If no departments are set as assign departments, the system isn`t enabled. Changing the sql code should make no difference, the 'notify' variable is for email notifications, nothing to do with the assign system. smile

I do know about the 'parse_str' error, that started being thrown in php7.2. It would have been fixed in the next update. But thanks for reminding me about it. smile

#3 y3000 10-07-2018 06:59:34

Thanks four your answer, here are my comments:

Problems with umlauts (ä, ö, ü, ß) and/or missing text in outgoing mails
When the encoding of the mail templates ist not UTF-8 we had the same problem as mentioned by KAVATCH in this post: https://www.maianscriptworld.co.uk/forums/viewtopic.php?id=3718. His solution was to remove the line "$this->convertChar($MSPARSER->mswAutoLinkParser($cont));". But then the links get not parsed, so my first solution was to edit the /control/classes/class.parser.php and add " $data = utf8_encode($data);" at the top of mswAutoLinkParser() - but this solved not the umlauts problem, it only fixed the missing text. So changing the encoding of the mail template text files solved all of our problems. Maybe it's useful for other users experience the same problems wink

The column "Assign To" is empty and so you can't assign ticket to a supporter
Yes, I enabled the assign system via department. Take a look on the following line from the /admin/templates/system/tickets/tickets-assign.php:
$q_users      = mswSQL_query("SELECT * FROM `" . DB_PREFIX . "users` WHERE `notify` = 'yes' ORDER BY `name`", __file__, __line__);
As you can see only supporters will selected where the email notification (staff > Other Options > Email Settings > Email Notifications) is enabled but for the assignment of a ticket its irrelevant if the supporter wants to get notifications via mail. Please look into this an try it by yourself ... I think its a bug wink

When catching mails via IMAP blanks in subject are replaced with "_"
Please also take a look into this for the next update. When Maian Support catch mails via IMAP in all of my test the Mail-Subject (e.g. "This is a test") will saved as Ticket-Title with _ instead of blanks (e.g. "This_is_a_test"). The only way to solve this quick and dirty wink was to edit the code as I mentioned.

#4 y3000 10-07-2018 16:43:03

Problems with umlauts in ingoing mails (IMAP)
We experienced problems when incoming mails not encoded with charset UTF-8 (e.g. ISO-8859-1) => all umlauts were missing. I edited the /control/classes/class.imap.php and modified getMessageBody() (comments "//Fix umlauts problems"). I know this is a very dirty workaround but to 99% we receive mails encoded in UTF-8 or ISO-8859-1 (or ISO-8859-2) so this fix will help us for the moment. @Maian-Team: Will you look into this problem?

  public function getMessageBody($msg, $connection) {
	//Fix umlauts problems
	$struct = imap_fetchstructure($connection, $msg);
	if (isset($struct->parts[0]->parts[0]->parameters[0]->value)) {
        $charset = $struct->parts[0]->parts[0]->parameters[0]->value;
    } else if (isset($struct->parts[0]->parameters[0]->value)) {
		$charset = $struct->parts[0]->parameters[0]->value;
	} else if (isset($struct->parameters[0]->value)) {
		$charset = $struct->parameters[0]->value;
	} else {
		$charset = self::UTF8;
	}
	if (strpos(strtoupper($charset), 'ISO-8859')!==false) {
		$charset = false;
	}
	
    $message = '';
    $message = imapRoutine::getPart($msg, 'TEXT/PLAIN', $connection, $charset, '', 1.1);
    if ($message == '') {
      $message = imapRoutine::getPart($msg, 'TEXT/PLAIN', $connection, $charset);
    }
    // If this is a base 64 encoded body, decode it..
    if (base64_encode(base64_decode($message, true)) === $message) {
      $message = base64_decode(chunk_split($message));
    }
    if (strpos($message, ' ') === false && base64_decode($message, true)) {
      $message = base64_decode($message);
    }
    if (!$message) {
      $message = imapRoutine::getPart($msg, 'TEXT/HTML', $connection, $charset);
      $message = str_replace('</DIV><DIV>', "\n", $message);
      $message = str_replace(array(
        '<br>',
        '<br>',
        '<BR>'
      ), "\n", $message);
    }
	
	//Fix umlauts problems
	if ($charset === false) {
		$message = utf8_encode($message);
	}
	
    return strip_tags(html_entity_decode(trim($message)));
  }

Last edited by y3000 (10-07-2018 16:55:49)

#5 msworld 10-07-2018 17:11:12
y3000 wrote::

Thanks four your answer, here are my comments:

Problems with umlauts (ä, ö, ü, ß) and/or missing text in outgoing mails
When the encoding of the mail templates ist not UTF-8 we had the same problem as mentioned by KAVATCH in this post: https://www.maianscriptworld.co.uk/forums/viewtopic.php?id=3718. His solution was to remove the line "$this->convertChar($MSPARSER->mswAutoLinkParser($cont));". But then the links get not parsed, so my first solution was to edit the /control/classes/class.parser.php and add " $data = utf8_encode($data);" at the top of mswAutoLinkParser() - but this solved not the umlauts problem, it only fixed the missing text. So changing the encoding of the mail template text files solved all of our problems. Maybe it's useful for other users experience the same problems wink

The column "Assign To" is empty and so you can't assign ticket to a supporter
Yes, I enabled the assign system via department. Take a look on the following line from the /admin/templates/system/tickets/tickets-assign.php:
$q_users      = mswSQL_query("SELECT * FROM `" . DB_PREFIX . "users` WHERE `notify` = 'yes' ORDER BY `name`", __file__, __line__);
As you can see only supporters will selected where the email notification (staff > Other Options > Email Settings > Email Notifications) is enabled but for the assignment of a ticket its irrelevant if the supporter wants to get notifications via mail. Please look into this an try it by yourself ... I think its a bug wink

When catching mails via IMAP blanks in subject are replaced with "_"
Please also take a look into this for the next update. When Maian Support catch mails via IMAP in all of my test the Mail-Subject (e.g. "This is a test") will saved as Ticket-Title with _ instead of blanks (e.g. "This_is_a_test"). The only way to solve this quick and dirty wink was to edit the code as I mentioned.

OK, thanks I`ve made a note to check all for the next update. I`m not sure about the IMAP subject issue though, in all my tests subjects are saved correctly. There are no underscores. I`ve got over 100 tickets in my test system read in via the IMAP system and none contain underscores.

#6 msworld 10-07-2018 17:12:51
y3000 wrote::

Problems with umlauts in ingoing mails (IMAP)
We experienced problems when incoming mails not encoded with charset UTF-8 (e.g. ISO-8859-1) => all umlauts were missing. I edited the /control/classes/class.imap.php and modified getMessageBody() (comments "//Fix umlauts problems"). I know this is a very dirty workaround but to 99% we receive mails encoded in UTF-8 or ISO-8859-1 (or ISO-8859-2) so this fix will help us for the moment. @Maian-Team: Will you look into this problem?

  public function getMessageBody($msg, $connection) {
	//Fix umlauts problems
	$struct = imap_fetchstructure($connection, $msg);
	if (isset($struct->parts[0]->parts[0]->parameters[0]->value)) {
        $charset = $struct->parts[0]->parts[0]->parameters[0]->value;
    } else if (isset($struct->parts[0]->parameters[0]->value)) {
		$charset = $struct->parts[0]->parameters[0]->value;
	} else if (isset($struct->parameters[0]->value)) {
		$charset = $struct->parameters[0]->value;
	} else {
		$charset = self::UTF8;
	}
	if (strpos(strtoupper($charset), 'ISO-8859')!==false) {
		$charset = false;
	}
	
    $message = '';
    $message = imapRoutine::getPart($msg, 'TEXT/PLAIN', $connection, $charset, '', 1.1);
    if ($message == '') {
      $message = imapRoutine::getPart($msg, 'TEXT/PLAIN', $connection, $charset);
    }
    // If this is a base 64 encoded body, decode it..
    if (base64_encode(base64_decode($message, true)) === $message) {
      $message = base64_decode(chunk_split($message));
    }
    if (strpos($message, ' ') === false && base64_decode($message, true)) {
      $message = base64_decode($message);
    }
    if (!$message) {
      $message = imapRoutine::getPart($msg, 'TEXT/HTML', $connection, $charset);
      $message = str_replace('</DIV><DIV>', "\n", $message);
      $message = str_replace(array(
        '<br>',
        '<br>',
        '<BR>'
      ), "\n", $message);
    }
	
	//Fix umlauts problems
	if ($charset === false) {
		$message = utf8_encode($message);
	}
	
    return strip_tags(html_entity_decode(trim($message)));
  }

To be honest I`ve made these kind of changes in the past only to find they break something else with other languages. I will check though and thanks for posting a possible workaround.

#7 y3000 16-07-2018 10:05:04

Additional we noticed problems with some base64 encoded mails. I had to rewrite the function getMessageBody() to solve this for us. Problems are that the base64 string of the mail body can contain line breaks (CR/LF) and further more the function getPart() do not return the original base64 string in each case (e.g. in the mail the base64 string ends with DQo= but getPart() returns NCg=), so the check if it is a base64 body fails.

Here is my solution for the problem with umlauts and base64 encoded mail bodies:

  public function getMessageBody($msg, $connection) {
	//Fix umlauts problems
	$charset = self::UTF8;
	$struct = imap_fetchstructure($connection, $msg);
	if (isset($struct->parts[0]->parts[0]->parameters[0]->value)) {
		$charset = $struct->parts[0]->parts[0]->parameters[0]->value;
	} else if (isset($struct->parts[0]->parameters[0]->value)) {
		$charset = $struct->parts[0]->parameters[0]->value;
	} else if (isset($struct->parameters[0]->value)) {
		$charset = $struct->parameters[0]->value;
	} else {
		$charset = self::UTF8;
	}
	if (strpos(strtoupper($charset), 'ISO-8859')!==false) {
		$charset = false;
	}
	
    $message = '';
	$message_raw = '';
    $message = imapRoutine::getPart($msg, 'TEXT/PLAIN', $connection, $charset, '', 1.1);
	$message_raw = imap_fetchbody($connection, $msg, '1.1');
    if ($message == '') {
      $message = imapRoutine::getPart($msg, 'TEXT/PLAIN', $connection, $charset);
	  $message_raw = imap_fetchbody($connection, $msg, '1');	  
    }
	$message_raw_nocrlf = str_replace(array("\r\n", "\r", "\n"), '', $message_raw);	
    // If this is a base 64 encoded body, decode it..
    if ($message_raw_nocrlf === base64_encode(base64_decode($message_raw_nocrlf, true))) {
      $message = base64_decode(chunk_split($message));
    }
    if (!$message) {
      $message = imapRoutine::getPart($msg, 'TEXT/HTML', $connection, $charset);
      $message = str_replace('</DIV><DIV>', "\n", $message);
      $message = str_replace(array(
        '<br>',
        '<br>',
        '<BR>'
      ), "\n", $message);
    }
	
	//Fix umlauts problems
	if ($charset === false) {
		$message = utf8_encode($message);
	}
	
    return strip_tags(html_entity_decode(trim($message)));
  }

Please look into it. The fix for the umlauts problems should nothing mess up compaired to the original code (UTF8 remains standard) and the fix for the base64 problem shouldn't do that either (just a workaround with getting the original raw base64 string and remove potential CR/LF in that string).

#8 msworld 16-07-2018 16:06:14

The imap system has been a constant problem to be honest. I`ve made these changes in the past only for them to cause loads of other problems.

I may just remove the option for tickets to be read in by email, not sure. I think if it works 90% of the time, that might be good enough. It`s been a constant headache. sad

#9 msworld 17-07-2018 09:09:20

I`ve been running some tests on my own test setup with umlauts and works fine everytime. This is with the default setup. I know I`ve had issues with them in the past working, then not working. lol.

#10 y3000 17-07-2018 09:51:01

Can you give me a mail adress where I can send you some mails which made problems with our setup (before my workarounds)?

But it was not my intention to bring you to the point where you are thinking about removing the imap feature wink I'll stop here ... incoming mails are now nearly 100% ok. Maybe my workarounds are useful for other user having similar problems. Thank you for your effort and quick responses smile

Last edited by y3000 (17-07-2018 09:51:39)

#11 msworld 17-07-2018 11:17:06
y3000 wrote::

Can you give me a mail adress where I can send you some mails which made problems with our setup (before my workarounds)?

Yes, certainly, can you send an email to each of the following:

imap-test@maianscripts.com
imap-test2@maianscripts.com

y3000 wrote::

But it was not my intention to bring you to the point where you are thinking about removing the imap feature wink I'll stop here ... incoming mails are now nearly 100% ok. Maybe my workarounds are useful for other user having similar problems. Thank you for your effort and quick responses smile

You are welcome. And thank you for the help. Don`t worry, I won`t be removing the imap feature as it`s pretty cool. It just gets frustrating from time to time. smile

#12 y3000 17-07-2018 12:39:27

I send you two mails. If these mails were processed ok, then it would be interessting whats your value for the default_charset setting in php (this value is not set on our server). Thank you smile

#13 msworld 17-07-2018 13:40:43

Great, thanks. I got the emails, so will test in due course and let you know.

#14 msworld 17-07-2018 17:39:41

Ok, I`ve tested it. Everything after the smiley gets cut off. Is that what you get?

2rztc9t.jpg

Obviously in my original tests I had no smiley.

Board footer

Maian Script World - Free PHP Software for Personal or Business Use.
© 2003-2018 Maian Script World & David Ian Bennett.

2Checkout.com is an authorized reseller of goods and services provided by Maian Script World