i just installed the Version 2.0 of NextGen Gallery, which seems to work well.
I do only get one (massive) problem:
As soon as I load an article including a Gallery the whole encoding of my website is messed up:
“ä” will be displayed as “Ã¼”, etc.
I guess there’s a minor modification necessary to solve this problem, but where? I can’t find where the problem comes from.
Anyone an idea?
I can not find the lightest hint, where this error is coming from. 🙁
If you load the startpage (http://www.chalkonrock.com) you can see an correct displayed umlaut in the header (“Mühlschlegel”), but as soon as you open any article or page with an NextGen-Gallery (e.g. http://www.chalkonrock.com/publications/) the whole site, including header, will be messed up (“MÃ¼hlschlegel”)
please, has anyone an advice?
Reinstall the previous version following the instructions at the top of this forum. Follow them exactly and then wait a few days, I think there is overload at the developers!!
I guess so. Still hoping for a (fast) solution and trying to dig deep.
What I found out now is that If I change following option:
Gallery Settings/NextGEN Basic Thumbnails/Template (comment says "Use a legacy template when rendering (not recommended)." Default value: empty New value: "NextGEN: gallery.php"
all the umlauts are back, but the gallery is a bit messed up and as soon as I use the pagination to move to page 2 (e.g.) i get following error message:
“Default Gallery Type Template
This is the default gallery type template, located in:
If you’re seeing this, it’s because the gallery type you selected has not provided a template of it’s own. ”
Axel – the default gallery template problem is a known one we’re working on. We haven’t had anyone else report the issue with characters (and we’ve had a lot of reports), so I suspect it’s something local to your instance.
Any chance you could quickly deactivate all other plugins but NextGEN for a brief moment and see if the issues goes away? If so, you can just immediately reactivate them all and then try one by one until you find the culprit.
Obvious NG is partly the culprit, we’re just trying to understand why this would be happening for you and not others, and we’re seeing a lot of plugin conflicts.
i did as you suggested, but no change to the problem.
I deactivated every plugin, except “NextGEN Gallery by Photocrati” (v 2.0.0) but still the encoding is messed up.
I guess I need to dig deeper, but in the moment I’m having no idea where to dig.
I also created a thread because of encoding problems. Strange enough, that I have the false encodings only on Wptouch mobile posts with galleries on them. The desktop view and post without galleries are ok.
I also have the same encoding problem.
All was fine with WP 3.6 and NG 1.9.13.
When I updated NG to version 2, the page where the gallery is located appears with broken accents (also WordPress header, not only image captions).
Waiting for a solution…
Just to let you know.. I tried deactivating all other plugins and then I found that one of mine caused the problem. A tab was shown in the headers prior to page start.
So… NG 2 is perfect for me.
Hey all – we did not get to the encoding issue in 2.0.7, but it’s at the very top of this list right now. If anyone is still running 2.0.0 or 2.0.7 and has this problem, can you consider submitting a bug report with any login credentials?
As a lesser issue, please consider posting a link to an example in this thread. I’ve linked our thread to this issues so the developers will be here looking for details.
It may be that this is a simple fix once we dig into, but I just want to be sure we have as much information as possible to look at.
Unless there’s something wildly difficult to resolve, this will definitely be in the next update, which should be about a week away.
yes with 2.0.7 it’s still the same issue.
I did as you asked and submitted my login credentials via the bug report form.
thanks in advance!
Hi all: we are working on this issue right now. If anyone else is willing to submit a bug report with WordPress and FTP credentials, I’ll look for your report and get the details over to the developers immediately:
Thanks Erick/photocrati for the fix.
No more Encoding Problems at all, they found the bug. 🙂
@axel: You bet. You were extraordinarily patient and gracious in helping and allowing us to work through that. Much appreciated.
Oh, for everyone else: we believe we’ve solved the encoding issues. There were actually several causes. The fix for this will be include in the next informal release, possibly tomorrow at:
It’s not in 2.0.10, but should be in everything after that. It’ll also be in the next official release, probably next Monday.
- The topic ‘v2.0 Encoding Problem’ is closed to new replies.