MDKAOD
-
Posts
3 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by MDKAOD
-
-
7 hours ago, ich777 said:
Can you give me a little bit more background how MultiUp.org works?
Is this some kind of CutCaptcha? CutCaptcha also doesn't work in my container because it needs an instance of some browser running with the jDownloader plugin.
Also you can write mi a PM for this and i will look into it.
You can also grab the links from your Windows/Mac/Linux machine, solve the captcha, right click on the links in jDownloader, make a DLC file, put this file into your jDownloader directory and then load it in the container.
I'll be honest, I'm not sure exactly how MultiUp works in detail, but maybe you're right. When i went through the motions a few times, I didn't solve any captchas, but eventually I had to "Verify" reCaptcha, so maybe you're dead on with the browser.
The DLC file seems(?) to work okay though, so maybe that's my ticket. Thanks for your help.
- 1
-
Having some trouble with your jDownloader container, but I think it's the way I use jDownloader. I've tried all 4 of the jDownloader containers and three of the four have this issue. When trying to decode MultiUp.org links, I get an error in the linkgrabber window "Wrong Captcha!(filename)". aptalca's implementation works as intended just like my Windows install. I'm not sure exactly why this is happening, and I don't really know what to do to combat it.
I would prefer to use any other container than aptalca's, and I really would rather not sign up for a my.jdownloader account.
Any thoughts?
(Note, screenshot isn't from your container, but the experience is the same--I captured this while testing)
[Support] Linuxserver.io - Dokuwiki
in Docker Containers
Posted · Edited by MDKAOD
Hi all, after reading through the issues, I have found a solution. As others have said, and some additional reading has confirmed, the issue is related to incompatible plugins from the "Greebo" 2018 release and the 2020 "Hogfather" release. It seems that the core issue is that the 'plugins' directory in the linuxserver docker implementation is part of persistent storage--rightly so, because, well it needs to be persistent. However the problem with new platform releases of Dokuwiki is that they bundle new versions of the "core" plugins, this creates the incompatibility. The extension manager does not currently support updating core plugins (and may never according to the devteam due to various technical limitations). So when the image updates, the persistent plugin storage is stuck with the old plugins leading to a version mismatch triggering an Error 500 in nginx.
So, if you're running a barebones install with no additional customization, the solution (on Windows) is as easy as making sure your appdata share is accessible, navigating to your dokuwiki appdata folder, then to where the plugins directory is located (\appdata\dokuwiki\dokuwiki\lib in my case). Rename the "plugins" directory to literally anything else, and then redeploy the container. Linux and shell users can grasp what needs to happen from the above.
Once the container is re-deployed, it will recreate the plugins directory with the correctly versioned core (bundled) plugins and the wiki will come up.
I don't have a complex setup going on here, but I could make a guess that if someone has a bunch of plugins, they could try the following:
I hope that's helpful!