[Dokuwiki] No database wiki

Hello @Jaxom99,

I am afraid that you just lost all the data of your second wiki and there is nothing to do about this :sweat:.
Even if you have backup, I am not sure that it contains your data as the backup script used to do the backup was buggy. (Same bug as here https://github.com/YunoHost/issues/issues/1231#issuecomment-436068510)

When an application is upgraded, Yunohost used the backup script of the app already installed. And in this case, it was buggy and did not backup the data properly :confused:

I don’t understand why the upgrade went fine on your first wiki and failed on the second. Could you tell which php file you had to remove to make it work?

On second thought, it might be the same problem as above and used the old restore script instead of the new one …
In the old one, php5 is hardcoded so if you are on php7, it will fail to remove the php files.

Thanks for getting back to me. Fortunately it was a test wiki and no production data was lost :sweat_smile:
The exact file I removed was /etc/php/7.0/fpm/pool.d/dokuwiki__2.conf which contained the faulty line (at the moment) : chdir = /var/www/dokuwiki__2.

What is my course of action now ? Is my first DW instance fully OK and up to date ? What about the new backups ? Are they fonctionnal ?

I may reinstall the previous 2nd instance, while :crossed_fingers: :crossed_fingers: as much as possible…

Good for you for having taken this security ! Loosing data should not happen and I need to think and give feedback to the Yunohost team on this. Beginning of discussion here : https://github.com/YunoHost/issues/issues/1231#issuecomment-437377911

This file is directly linked to Dokuwiki so there might be a bug in the package itself and it should be investigated :eyes:. The previous person to have a similar issue was because of a previous app so I though that the package was ok and out of scope. Which is not the case apparently …

It is still weird to me that the upgrade went fine on the first Wiki (should look a the logs)
I do not have much energy to look at all the logs these days.

My answers sorted by order

  • Not much more I guess. You gave all the logs asked and you are answering quickly to questions Maybe posting in the support section or going to the support chat to get more people involved. (I lack energy these days)
  • Before your answer about the php file, I would have said yes. Now, there might be a bug. All I can say is that “it works on my system” and during the tests made by myself and people who tested the code I made.
  • The “backup” script has been installed and it works. At least while I tested it myself.
  • You can test them too (and you should) and will be interested to get your feedback.

After looking at the logs, I cannot explain why it went wrong on the second wiki :neutral_face: Good news is that your first Wiki is fine and it can be backuped correctly as the script ‘backup’ is fine now.


My troubleshooting went like this:

In the php logs, we have this

[09-Nov-2018 11:20:40] ERROR: An another FPM instance seems to already listen on /var/run/php/php7.0-fpm-dokuwiki.sock
[09-Nov-2018 11:20:40] ERROR: An another FPM instance seems to already listen on /var/run/php/php7.0-fpm-dokuwiki.sock
[09-Nov-2018 11:20:40] ERROR: FPM initialization failed
[09-Nov-2018 11:20:40] ERROR: FPM initialization failed
[09-Nov-2018 13:11:52] ERROR: [pool dokuwiki__2] the chdir path '/var/www/dokuwiki__2' does not exist or is not a directory
[09-Nov-2018 13:11:52] ERROR: failed to post process the configuration
[09-Nov-2018 13:11:52] ERROR: FPM initialization failed
[09-Nov-2018 13:55:59] NOTICE: fpm is running, pid 6764
[09-Nov-2018 13:55:59] NOTICE: ready to handle connections

The file you had to remove can be seen but is is not the root cause of the issue
[09-Nov-2018 13:11:52] ERROR: [pool dokuwiki__2] the chdir path '/var/www/dokuwiki__2' does not exist or is not a directory
It was left by the removal script and it is due to a bug that have been patched by the last Yunohost 3.3.1 (see at the end of the post)

The logs at 11:20 are more interesting and show why php failed to restart. And lead Yunohost to remove then restore your (faulty backuped) data
I cannot explain the failure because both installation used the same helper ynh_add_fpm_config to handle the php configuration.

I leave this into the hands of @Apps people if they have time and energy to look at this. I do not know where to search next.



Continuing the discussion from YunoHost 3.3 release / Sortie de YunoHost 3.3:

Hey, thanks again for all this input ! Don’t worry, I know we’re all volunteers here (for now at least) so energy and motivation come and go. Please, do take care of yourself :wink:

I will restart and retry all of this (2nd instance, backups, …) in a few days, I’ll let you know how it goes.

Hello,
It would be nice to be able to use url rewrite without any configuration tweaking.

Hello @djib,

Good idea to have prettier links. It seems quite simple to implement after looking at your post.

After your modification, do the URLs / links created before your modification still work as before?

URL in the form doku.php?id=wiki:syntax, which is the default, will still work.
I’m not sure about other formats.

1 Like

New stable release available

2 Likes

New testing release :tada:

  • 29 Feb 2020 #55
    • Add URL rewriting (for pretty URLs)
sudo yunohost app install https://github.com/YunoHost-Apps/dokuwiki_ynh/tree/testing --debug
or
sudo yunohost app upgrade dokuwiki -u https://github.com/YunoHost-Apps/dokuwiki_ynh/tree/testing --debug
1 Like

New stable release :tada:

  • 14 Mar 2020 #55
    • Add URL rewriting (for pretty URLs)
3 Likes

I did an update on a rpi where 4 instances of dokuwiki, since the first that was installed is still working but the 3 others have a nginx error as soon i try to navigate in the wiki

And so i have the same problem after the upgrade.
I have an LXC container running my yunohost and after upgrading my 3 dokuwiki install i have an nginx error 404 not found on all pages exept for homepage.
There is an issue opened
It seems nginx configuration has been changed.

I have a friend that solved the problem, he wrote that he informed the maintener, Il will inform him of your message

Sorry to hear that. I didn’t see anything wrong while testing the package.

Could you share:

  1. Nginx config https://github.com/YunoHost/doc/blob/master/troubleshooting_guide.md#application-configuration
  2. Nginx logs https://github.com/YunoHost/doc/blob/master/troubleshooting_guide.md#logs-1

Also, does it works if you install of new DokuWiki instance?

A friend of me find a solutions he wrote to me
"C’est corrigé. Le problème est que la dernière mise à jour active des URLs plus “propres” (sans le “doku.php?id=” en haut) mais ça ne fonctionne pas si Dokuwiki est installé dans un sous-dossier.
J’ai rapporté le bogue chez le développeur.

Une autre raison pourquoi je préfère toujours créer des sous-domaines. Il faut juste le savoir lorsqu’on commence ;)"

"That’s corrected. The problem is that the last update activates “cleaner” URLs (without the “doku.php?id=” at the top) but it doesn’t work if Dokuwiki is installed in a subfolder.
I reported the bug to the developer.

Another reason why I always prefer to create subdomains. You just have to know that when you start ;)"

1 Like

New testing version available :partying_face:

[2018-04-22b~ynh1] - 2020-03-23

Added

  • New DokuWiki version 2018-04-22b
  • Changelog available in CHANGELOG.md

Changed

  • Upgrade content of file pull_request_template.md
1 Like

Following the end of “official apps”, topic has been renamed [High Quality app] Dokuwiki

@pada and @madmaxlamenace, bug identified and fix waiting to be reviewed and tested

See https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/61

1 Like

Thx to you Gofannon. I like dokuwiki and i have several instance for different subjects, it is simple, fast (nosql) and robust.
Thx again for your work.

1 Like