I read what you told me to read and I tried switching the order of the
includes around and that did not help. I had tried that before, but I
decided not to mention it because it was based on the advice of a page
that said it needed updating, and the fact that that advice
contradicted the more recent and specific advice on the sqlite recipe
page. 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 to
�. This however might have been because of a bad conversion process
rather than the sqlite recipe. I had already tried all the suggestions
on both the pages you suggested reading. My only solution was to
manually edit the pages as they came up. I did not bother mentioning
this problem because it seemed like a one time thing that could be
fixed and forgotten. I probably should have mentioned that problem in
this question to back my suggestion that the sqlite recipe might be at
fault here.
I did look at the sqlite code, and it looks like it takes care of
utf-8 fine. I also looked at the database and saw everything stored as
it should be. In any case, I tried following the advice of each of the
pages you suggested (one of them needs updating because those pieces
of advice contradict each other) and neither has fixed the problem.
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 that
there is something messed up during the deserialization of the extra
page attributes.
I am going to continue to try to debug this.
Thanks for your suggestions,
Alex
On Aug 21, 2012, at 3:16 AM, Petko Yotov wrote:
Alex Eftimiades writes:
The page here: <URL:http://icare.org/wiki/index.php/Researchers/SelimKu%25C3%25A7i
>
There is indeed something wrong with your installation, this is not
a right URL to the page: the %25 pieces should be just %, not %25.
Something is causing a double encoding of the % symbol.
The correct address to the "SelimKuçi" page should be
http://icare.org/wiki/index.php/Researchers/SelimKu%C3%A7i
but as you noticed, it doesn't work. This link, and a pagelist works
perfectly with international page names on my own wiki with SQLite,
including a page named SelimKuçi.
Here is what you should try:
1. Read the section "Order of the commands in config.php" here:
http://www.pmwiki.org/wiki/PmWiki/LocalCustomizations#configphp-order
notably, the custom page store class should be defined before UTF-8.
Or, you may also re-read the installation instructions at Cookbook/
SQLite, notably "The code above should be placed before including
other recipes and scripts, notably before ... UTF-8."
You have included the UTF-8 script before defining the SQLite page
store, just try to move it after the sqlite/$WikiLibDirs block.
If you have other things out ot the recommended order, move them.
2. If that doesn't help, see if you can disable some other recipes,
for example those here: http://www.pmwiki.org/wiki/Category/CustomPageStore
and other, one by one, to see if it doesn't start to work at some
point.
The fact is, this international page name works perfectly well with
PmWiki,
- with SQLite, and
- without SQLite,
so the problem likely comes from something completely unrelated to
the SQLite recipe. I wouldn't speculate that it comes from *this*
recipe in a mailing list subject, without at least *some* evidence.
You will need to login with uersname: demo password: demo to see
the problem.
Please enable remote diagnostics on that site, $EnableDiag=1; to
config.php.
Petko
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
