<p>Per my earlier comment, the convert_encoding filter is causing this, I think only in newer versions of Twig than what my live site running Craft 2 uses. </p>

<p>I guess that probably somewhere in my site content, one of our content managers somehow inserted a character that convert_encoding is choking on. Rather than figure out where that is, and know that the site would blow up again the next time they did it, I've replaced <strong>bodyText|striptags|convert_encoding('UTF-8', 'HTML-ENTITIES')|slice(0, 200)|default('Read more')</strong> with
<strong>bodyText|striptags|slice(0, 200)|default('Read more')|raw</strong>, and while I have not tested this thoroughly to know that it works as intended in all cases, it's at least not blowing up an index listing of 100 articles because (I suspect) one entry has some weird character in it any longer.</p>

CC BY-SA 4.0
2019-11-24T00:30:47.167Z
2019-11-24T00:30:47.167Z
Sapphireblue
<p>I have been fighting with a Craft 3 upgrade of a Craft 2 site on a local dev environment for a while now, though much of the time the problems turns out to be MAMP Pro 5 and/or FastCGI PHP. I'm not sure what's going on with the latest error, and the exact error returns no Google search results at all, so am at a loss for how to proceed.</p>

<p>The error in full is this:</p>

<pre><code>PHP Notice – yii\base\ErrorException
iconv(): Unknown error (22)
1. in /Users/mydir/Sites/mysite/vendor/twig/twig/src/Extension/CoreExtension.php at line 1000
</code></pre>

<p>where line 1000 is the return line in this function:</p>

<pre><code>function twig_convert_encoding($string, $to, $from)
{
    return iconv($from, $to, $string);
}
</code></pre>

<p>The error only shows up on some pages, not all. Can't figure out a pattern of commonality there. From Googling iconv (where I do see it is a known problem child but couldn't spot anything that shed more specific light) I guess it's a character-encoding utility. We do have some Spanish-language content on the site, but the actual Spanish-language channel displays fine, for whatever that's worth. If it matters at all, all my database tables are encoded UTF8, though collation is sometimes utf8_general_ci and sometimes utf8_unicode_ci.</p>

<p>The whole stacktrace is of core Twig files, no template files where I could go in and flail around with some troubleshooting code to try to narrow down the problem.</p>

<p>Thanks very kindly in advance for any thoughts or ideas. It's begun to feel as if I'll never get this site upgraded (and here's where I'd add the grimacing emoji if this community did not frown-emoji on such things).</p>

CC BY-SA 4.0
2019-11-22T06:02:42.660Z
11 hours later: the error is being caused by the convert_encoding filter. as in bodyText|striptags|convert_encoding('UTF-8', 'HTML-ENTITIES') . when I remove that one filter, it's fine. so it's a Twig thing—maybe just the version 2.12.1 that installed with Craft 3, since the production Craft 2 version of the site, running Twig 1.33.2, had this same template code & same entry and it runs fine. I'll have to dig more into it and come back to close this out with whatever resolution I come up with.
Sapphireblue
<craft3><mamp>
Craft 3 on new MAMP Pro 5 installation: "iconv(): Unknown error (22)" problem in /vendor/twig/twig/src/Extension/CoreExtension.php
# Craft 3 on new MAMP Pro 5 installation: "iconv(): Unknown error (22)" problem in /vendor/twig/twig/src/Extension/CoreExtension.php

(Asked by: username_0 on 2019-11-21)

I have been fighting with a Craft 3 upgrade of a Craft 2 site on a local dev environment for a while now, though much of the time the problems turns out to be MAMP Pro 5 and/or FastCGI PHP. I'm not sure what's going on with the latest error, and the exact error returns no Google search results at all, so am at a loss for how to proceed.
The error in full is this:
PHP Notice – yii\base\ErrorException
iconv(): Unknown error (22)
1. in /Users/mydir/Sites/mysite/vendor/twig/twig/src/Extension/CoreExtension.php at line 1000

where line 1000 is the return line in this function:
function twig_convert_encoding($string, $to, $from)
{
    return iconv($from, $to, $string);
}

The error only shows up on some pages, not all. Can't figure out a pattern of commonality there. From Googling iconv (where I do see it is a known problem child but couldn't spot anything that shed more specific light) I guess it's a character-encoding utility. We do have some Spanish-language content on the site, but the actual Spanish-language channel displays fine, for whatever that's worth. If it matters at all, all my database tables are encoded UTF8, though collation is sometimes utf8_general_ci and sometimes utf8_unicode_ci.
The whole stacktrace is of core Twig files, no template files where I could go in and flail around with some troubleshooting code to try to narrow down the problem.
Thanks very kindly in advance for any thoughts or ideas. It's begun to feel as if I'll never get this site upgraded (and here's where I'd add the grimacing emoji if this community did not frown-emoji on such things).

**Tags:** craft3, mamp

> **Comments:**
> **username_0**: 11 hours later: the error is being caused by the convert_encoding filter. as in bodyText|striptags|convert_encoding('UTF-8', 'HTML-ENTITIES') . when I remove that one filter, it's fine. so it's a Twig thing—maybe just the version 2.12.1 that installed with Craft 3, since the production Craft 2 version of the site, running Twig 1.33.2, had this same template code & same entry and it runs fine. I'll have to dig more into it and come back to close this out with whatever resolution I come up with.  

---

## 1 answers

### Answer by username_0 on 2019-11-24. Score: 2 | Accepted answer

Per my earlier comment, the convert\_encoding filter is causing this, I think only in newer versions of Twig than what my live site running Craft 2 uses.

I guess that probably somewhere in my site content, one of our content managers somehow inserted a character that convert\_encoding is choking on. Rather than figure out where that is, and know that the site would blow up again the next time they did it, I've replaced **bodyText|striptags|convert\_encoding('UTF-8', 'HTML-ENTITIES')|slice(0, 200)|default('Read more')** with
**bodyText|striptags|slice(0, 200)|default('Read more')|raw**, and while I have not tested this thoroughly to know that it works as intended in all cases, it's at least not blowing up an index listing of 100 articles because (I suspect) one entry has some weird character in it any longer.


---

