Hello @otm33, I had also looked at your package admidio_ynh, when looking for good examples before looking how the mobilizon_ynh configs could be migrated. And I might have noticed something, at least when installing to the domain (root_path):
Seeing double slashes appearing in the URL (e.g. redirections to sub.domain.tld//route/within/app), I could manually work around that by removing the trailing slash from $g_root_path in /var/www/admidio/adm_my_files/config.php.
However, that would seem not to work with __PATH__ in that template, so instead maybe add something like #root_path_only rewrite ^/(.*)$ $1
to the nginx template, next to the #sub_path_only line? (if that works)
A fix would be to remove the trailing slash from $g_root_path creating another var with ${domain}${path%/} as value or using a condition but is it worth it since, afaik, there is no issue with the double slash in admidio and nginx merge_slash setting?
Hm, I think your right, my quick rewrite idea may mangle correct URLs (but not tested).
I can’t say for sure if it was the real cause, because it was one thing among others like altering the install order etc. and I also switched to a subdir install in the course of testing plugin installs, on the way to get rid of some access denied errors.
Independent from that, I saw translations failing during plugin “install” (their first direct call from the browser, rather than later executions from within the app.) That, I imagined might be due to the “o-r” permissions on files like /var/www/admidio/src/Infrastructure/Language.php? If you agree that could be the reason, then I could re-check, that seems specific enough to test.
I think a doubled slash in the visual URL always gives a bad impression.
Tested this now: The admidio plugin install translation file error does not happen after chmod -R o+r /var/www/admidio, and it’s dependent on the full path, i.e. the error still occurs with just: chmod -R o+r /var/www/admidio/* (Guess, with o+r permission, special care (permission) has to be used for confidential config files etc., never applying it as global as in this example. Maybe ynh_config_add does or should handle that.)
For mobilizon I think the admidio package holds some interesting points:
The explicit permission setting can be removed from the package scripts (now handled by _ynh_apply_default_permissions). The “other users” permission problem does not apply to mobilizon, because it’s a standalone app behind reverse proxy.
The config file is managed by the package (config.exs) directly (written by ynh_config_add). So it should be possible to ship a templated mobilizon package file that does an import_config of a local admin file (which is not templated, and never overwritten, merely initialized once if not existing).
It uses [resources.system_user] allow_email = true which can be used to test emails with that user. (@rodinux do you remember particular problems with the old system user?)
@otm33 Second thought: I think that is an upstream admidio issue: They should support plugin installs by calling them internally. No app should require hosting with public read/php-file execution rights for every file, correct?
I have not found yet a reason why the newer [resources.system_user] allow_email = true would not work.
+ It does not interfere with (list as) regular user accounts.
+ It’s a configurable app setting: Customizing an app's email-address with new "resources" app-install-system? - #10 by tmb
Sending is authenticated with username and its auto-generated password, and gets dkim signed.
It seems to be set up only for sending by default (‘noreply’ bounce), but users can set it as alias and then mails are accepted (they can send and will receive).
Or do you really know about a still current, or future (e.g. trixie) blocker? Doesn’t seem like mobiizon actually needs an own inbox imap account.