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.
Thanks again,
Alex
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
to
�. 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
that
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
recipe.
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
the
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
like
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
likely
that the setting I just disabled had some conflict.
- If I didn't find the problem, I'll try the other way around -- I
install
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
snippets:
die("MyVariable: '$MyVariable', should be 'AB.CD'.");
And hopefully, at some point I understand the bug/problem, then I
can fix it.
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
