Hanno

Thank you very much for your reply.

I must admit, this was a rather weird situation that I am neither able nor willing to reproduce because it has to do with a server misconfiguration. Let me try to explain:

It’s all about a directory on a Linux server that was connected to another local server via CIFS. So, the directory had initially been created empty, and then redirected (mount -t cifs). As long as the remote server was in its place, everything was ok. But then that server was replaced by another machine, and the CIFS connection was no longer needed. As the remote machine had changed, that connection became invalid. However, the empty directory was still in its place. If you did an ‘ls’ command on a higher directory level to show the dir structure, it would show up. If you would try to get any details on that specific dir from the command line, it would simply appear as empty. However, the routine SplFileInfo::getSize() that is being used by your software, seems to behave somewhat differently, and it brings forward an error (sorry for the German error messages):

[19-Jul-2024 02:02:55] Komprimiere Dateien als TarGz. Bitte habe einen Moment Geduld.
[19-Jul-2024 02:03:36] FEHLER: SplFileInfo::getSize(): stat failed for /data/web/www.xyz.de/vi
[19-Jul-2024 02:03:36] 2. Versuche, Backup-Archiv zu erstellen …
[19-Jul-2024 02:04:17] FEHLER: SplFileInfo::getSize(): stat failed for /data/web/www.xyz.de/vi
[19-Jul-2024 02:04:17] 3. Versuche, Backup-Archiv zu erstellen …
[19-Jul-2024 02:04:58] FEHLER: SplFileInfo::getSize(): stat failed for /data/web/www.xyz.de/vi
[19-Jul-2024 02:04:58] FEHLER: Schritt abgebrochen: zu viele Versuche!

But this is not the point. I was wondering why your software tries to collect information *at all* on directories which it is configured not to take care of. If it tries to get the size of such a directory, how can I be sure that it does not collect other (more sensitive) data?

Now that I have found the cause of the reported problem (sorry, my mistake), I would like to know how I could somehow permanently activate the GET parameter “admin_mode” in the frontend. When I click on “All events” and then enter a search term for filtering, the software switches back to “My events” and I get no results for that user (because he/she didn’t generate any). I hope I have described the behaviour clearly enough … Thanks.

No it isn’t. If I add a <br> tag, this is just deleted, and the second line is positioned right after the first line.
Do I just have to insert <br>, or any additional things like % or so as well?

Just found out the reason for this misbehavior was the .htaccess file that comes with the update. When deactivated (eg. change file name to 0.htaccess), everything is ok.

If you think answers like “Ask someone else” or “There must be some difference between the two platforms, try to find out the differences yourself” (I read this in another support request) are something that could be called “support”, and if you furthermore *dare* to call those issues solved, then I’ll take it without accepting it.
If you had paid just a little attention to the causes of at least my problem, you would have known that it is obviously about a security feature in ImageMagick, and that there is a possibility that security holes can arise when settings are made to that tool, as they are apparently necessary for your plugin.
After you didn’t even give the slightest hint of a possible cause, I found it surprisingly quickly with the help of Google, and I also saw that this problem is widespread on the one hand side, and that most obviously there are ways for the programmer to circumvent it on the other.
It’s up to each host to decide whether they want to cause themselves problems by changing the ImageMagick settings or whether they generally refuse to make these changes to the setup – I can certainly understand that.
Fortunately, I host my sites myself, and I know everyone else who uses my servers. So I don’t mind changing the ImageMagick setup because I think I can assess the risk. But if large providers don’t want to get involved, that’s understandable. Unfortunately, in this case, your app is completely unusable.

• This reply was modified 2 years, 3 months ago by Hanno.
• This reply was modified 2 years, 3 months ago by Hanno.
• This reply was modified 2 years, 3 months ago by Hanno.

You are absolutely right, and I have to apologize.
I now found out that the reason for the plugin’s misbehavior was a different plugin called ‘Frontend Post Submission Manager Lite’.
I believe that two JS libraries were not compatible with each other. However, I fairly quickly found another plugin (‘User Submitted Posts’) that apparently does its job without causing any problems to PDB, so the problem is solved for me.

I found that the error message will be displayed again and again (even if the error no longer exists), as long as it is not explicitly deleted from the screen. In fact, if the error persists, there is an additional error message, and on and on. I finally started wondering when there were four of those messages. So, actually there is no problem for the plugin to find the path, if it really exists.
I then had a closer look at the source code, and I am pretty sure that the function which creates the upload directory (“_make_uploads_dir”) is not called during install at all. There is a special error message in there which I should have seen if anything went wrong. (But I didn’t.)
Afterwards I tested the debug mode because I found that same function is part of the PDb_Debug class. It IS called immediately after saving the debug mode setting, and the directory was created without any hassle. For people that encounter the same problem and do not have direct access to the server’s file system this could be a workaround.
As for me, this thread can be closed, although I would not really call it resolved right now. Thank you, anyway, for your quick feedback, which has helped me a lot with troubleshooting.