Hi Francesco,
Francesco Potortì wrote:
> >> The necessary change was
> >>
> >> -$conf['savedir'] = '/var/lib/dokuwiki/data'; //where to store all the
> >> files
> >> +$conf['savedir'] = './data'; //where to store all the files
> >
> >Do you remember why this was necessary, i.e. what didn't work without it?
>
> Dokuwiki cannot find the .data directory and says so in the web
> browser. I suppose that an alternative is creating a data link to
> /var/lib/dokuwiki/data. Maybe such link existed and I removed it in
> the past and an upgrade does not restore it?
Hrm, this is something which might be related to running multiple
instances of DokuWiki on the same host. The non-default data directory
should be created by the dokuwiki-addsite.
That's also why that "./data" is relative and not absolute.
Maybe this should go into a separate bug report.
> >> I know nothing about how php is managed on Debian. However, I had to add
> >> these links:
> >>
> >> /usr/share/dokuwiki/vendor/paragonie/random_compat/lib ->
> >> /usr/share/php/random_compat
> >> /usr/share/dokuwiki/vendor/phpseclib/phpseclib/phpseclib ->
> >> /usr/share/php/phpseclib
> >
> >Good catch! This indeed could be something that I oversaw.
>
> By the way, those files are in the php-phpseclib and
> php-random-compat packages.
Dependencies for those libraries are already there, yes. Worked fine
for me without these links. Maybe because I didn't use any function
which needs them. Or because I just haven't noticed the corresponding
glitches.
Added them. Shouldn't cause any harm.
> >> # /usr/share/dokuwiki/vendor/marcusschwarz/lesserphp/
> >>
> >> I replaced all {0} with [0]
> >
> >That's one of the common changes I had to do. I though thought I had a
> >patch for that already in the package on Salsa:
> >
> >https://salsa.debian.org/abe/dokuwiki/-/blob/master/debian/patches/cherrypick_6b6d27d9.patch
>
> I had just downloaded your package, so apparently you missed that one...
Can't reproduce that anymore. Maybe your testing and my fix above overlapped.
> >> Additionally, I get this in the Apache log:
> >>
> >> PHP Warning: Undefined array key "fperm" in
> >> /usr/share/dokuwiki/inc/Search/Indexer.php on line 1070, referer:
> >> http://wiki.potorti.it/egc2018/bilancio
> >
> >Yes. These are IIRC fixed upstream in git, but not in a release yet. I
> >might add them to avoid the warning, but for now I just want to do the
> >minimal thing to get it working again.
Should probably tracked in a separate bug report as well and being
tagged as fixed-upstream.
> >> And unfortunately email sending still does not work: emails are sent
> >> with an empty From: field, so they fail at the sendmail level.
> >
> >Funnily for me it's opposite: I get more mails than before, and also
> >for changes I don't see via web interface. Still unclear why.
Found the cause. Those changes are indeed seen in the webinterface. It
were crawlers triggering restoration of old pages whose ACL was set to
world-writable (on purpose back then, now only for authenticated users).
> I get one email per edit, as expected, but they bounce (and I see
> the bounce) because the To: header is empty. This has happened with
> php8. After I had patched all the places generating an error in the
> Apache log, I had this behaviour, which undortunately does not
> generate an error, so I could not catch it...
Hrm, leaving that out for now. Maybe file a bug report for this, too,
after I've uploaded the new version.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
