[pmwiki-users] Something (possibly the sqlite recipe) seems to have trouble with UTF-8 in wikilinks
alexeftimiades at gmail.com
Wed Aug 22 00:06:27 CDT 2012
Thank you very much for your advice. It turns out the problem was with
$EnablePathInfo = 1;
When I removed that, Selim Kuçi's page showed up just fine.
So, that begs the question: what is going on with $EnablePathInfo = 1;
that it messes with UTF-8 encoding? I will be looking into this.
On Aug 22, 2012, at 12:29 AM, Petko Yotov wrote:
> On Tuesday 21 August 2012 18:16:25 Alex Eftimiades wrote:
>> The reason I suggested the sqlite recipe might be at fault was
>> because I remember the utf-8 characters working fine before I
>> installed the sqlite recipe. Then a lot of characters got converted
>> �. This however might have been because of a bad conversion process
>> rather than the sqlite recipe.
>> My only solution was to manually edit the pages as they came up. I
>> did not
>> bother mentioning
> I'm sorry to hear that -- but if your site was already working fine
> in UTF-8,
> and running a recent version of PmWiki, the migration to SQLite
> shouldn't have
> caused the lost characters.
> I say it shouldn't, but if it did, I'd want to experience the same
> problem and
> fix it. And if you haven't deleted your original wiki.d files, it is
> certainily possible to recover your characters.
>> I tried enabling diagnostics, and there seems to be a problem in the
>> sqlite.php recipe at line 162. That is where extra attributes are
>> deserialized during the page read process, so it seems to suggest
>> there is something messed up during the deserialization of the extra
>> page attributes.
>> I also realized that the messages
>> were warnings on wrong datatypes in the foreach() statement at the
>> deserialization stage, so I would not be surprised if a lot of people
>> have that warning message due to type juggling.
> What extra page attributes do you have? No other people have come to
> tell me
> that they have this problem, but probably not many admins use the
> If your pages have extra attributes and the unserialize() function
> returns an
> error, I'm not sure how to fix that. Are your extra attributes just
> key=>string pairs ?
>> So after switching the include statements, my problem has become
>> disappearing page actions.
> In your Site.PageActions you have many (:if auth XXX:) blocks. I
> only see the
> actions "print" and "logout", but probably my username doesn't have
> permissions to see the other actions.
> I would love to help you better, but on the servers where I can test
> it, it
> works fine, I don't see the bug. If you can give more information
> about your
> installation (other recipes, config.php, Pmwiki version...),
> hopefully I'll be
> able to reproduce the bug and investigate it in real time.
> OTOH, it seems that you are using some of the most complex recipes
> WikiSh, WikiPublisher and AuthProfile. I must admit that I wouldn't
> have the
> time right away to review those recipes if there is/was some
> conflict there.
> Here is how I operate when I search for a bug:
> - I try to disable all recipes and settings one after another, and
> every time
> I check to see if the problem has gone away. If it goes away, it is
> that the setting I just disabled had some conflict.
> - If I didn't find the problem, I'll try the other way around -- I
> PmWiki in a clean directory of the server, and I gradually enable
> settings and
> recipes, while testing if it works or not. When it breaks, it is
> likely that
> the last enabled setting caused the conflict.
> - Then, in order to understand the problem, I edit the scripts and
> test them
> in real time -- interrupting and interrogating the program with such
> die("MyVariable: '$MyVariable', should be 'AB.CD'.");
> And hopefully, at some point I understand the bug/problem, then I
> can fix it.
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
More information about the pmwiki-users