Cloudron Forum

@james we already have --token (primarily meant for CI automation). It's not saved in the cloudron.json intentionally because long-lived tokens should ideally not get saved somewhere. With login, you get a temporary token that is stored in the cache file. I think maybe your point is that we should use API tokens to login in general? I wouldn't mind removing username/password based login entirely. The current auth mechanism of CLI bypasses all the OIDC security mechanisms . CLI tools like npm already now require auth on browser. I think we will move to this in coming releases. Technically, the CLI was not built for end users, it was only for app development. Not sure how many people this impacts. https://www.npmjs.com/package/cloudron does say ~400 a week....

Hi @James - Many thanks for this. The changes already looks great and promising. May I make a suggestion ? I think, in this case, Freescout approach offers a greater granularity between email notification and in-app notification, with potential for further development based on the communication channel (Mobile if ever, API ? etc..), leaving the end admin users decide what works best for them Here is the screen I am referring to in Freescout. [image: 1753778253533-e6ab2fb5-e080-4b2e-8443-adde0ee3d332-64145699-7f368480-ce22-11e9-9ead-1ac3ef29ba9b-resized.png] If it is not too late in the development of this, maybe it might be worth considering?

Hello @mononym I have investigated this issue and found the following. According to my understanding after reading the documentation the LocalSettings.php should include the following: # Set the script path to root $wgScriptPath = ""; # Set the article path for pretty URLs $wgArticlePath = "/$1"; # If you're using a different entry point than index.php $wgScript = "/index.php"; # For resource loading $wgResourceBasePath = $wgScriptPath; Just for good measure I also cleared the Main Page cache with: php maintenance/run.php purgePage <<< "Main Page" But sadly, this did also not work. So the only thing now breaking it could be the apache2 config and there it is. By default (not editable) - https://git.cloudron.io/packages/mediawiki-app/-/blob/master/apache/mediawiki.conf?ref_type=heads: ServerName %{HTTP_HOST} <VirtualHost *:8000> DocumentRoot /app/code LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" proxy CustomLog "|/bin/cat" proxy ErrorLog "|/bin/cat" # https://www.mediawiki.org/wiki/Manual:Security php_flag register_globals off ## http://www.mediawiki.org/wiki/Manual:Short_URL/Apache RewriteEngine On RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/index.php [L] RewriteRule ^/*$ %{DOCUMENT_ROOT}/index.php [L] <Directory /app/code> Options +FollowSymLinks AllowOverride All Require all granted </Directory> # some directories must be protected # images/ still has to be accessible since mw references it directly <Directory /app/code/images> Options -FollowSymLinks AllowOverride None <IfModule mod_php7.c> php_admin_flag engine off </IfModule> </Directory> </VirtualHost> I put the app into recovery mode and edited the Apache2 site file and changed the rewrite to the following: RewriteEngine On RewriteCond %{REQUEST_URI} !^/rest\.php RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/index.php [L] and started the app with /app/pkg/start.sh and got a working MediaWiki under sub.DOMAIN.tld/Main_Page. To make this usable for you and everyone else, an app update would be needed where users, like you, could also upload a custom Apache2 site setting file that will be included to overwrite the default one. I am converting / hijacking this topic into a feature request.

@girish Thanks for this - This is a great workaround and fit the bill perfectly for us.

Never heard of them before, and only you mentioned them so far in this forum Implementation might be easy, but the question is, how many would benefit from that. Question about prioritization I would suggest for now using Hetzner.

Since the Cloudron-Team can't force changes upstream, I've made this into a normal topic. I added the feature-request tag tho. Maybe when @mirotalk-57bab571 him - themselves pushed this issue, they might be more inclined to do so. As for now, the feature request would be: Can Cloudron change the /app/code/packages/app-store/mirotalk/config.json to allow all domains for mirotalk or make the file editable by some means?

@pHneutre the best solution at present is to change your update schedule to be every hour https://docs.cloudron.io/updates/#update-schedule then it'll do one an hour until it's done.

@pistou79 This would be great.

@LoudLemur the wording makes sense as-is without the need to clutter the ui. Updates is the logical place to look in if you’re looking for version info. Imagine how cluttered that side menu would look on mobile! Less is better.

Well if you look into the web inspector, you could just utilize the rest APIs just like the dashboard itself does. "New Apps" here is just defined as first published within last n days. But the initial feature request was about a way to find new apps, which is what the menu item is about if I understood this correctly?

@potemkin_ai Thanks!

You can set flags on the email with sieve filters. I think this is only available in roundcube UI though. [image: 1613671026536-bf4f52b4-5648-41a9-aca2-f799daadb640-image.png] Then, in thunderbird, you can highlight them accordingly - https://support.mozilla.org/en-US/kb/message-tags

@girish When will this be exposed in the GUI? Hopefully this can be planned for 7.4 perhaps, along with the many other mail improvements requested?

@DualOSWinWiz it's not there, no.

I've released the new surfer version which has this fixed. The update is currently only available when checked for manually.

@girish Great! Thanks again for your help debugging this and adding more configuration. Huge help for larger backups like mine.

Marking as solved since a feature request is open at https://forum.cloudron.io/topic/3057/consider-improvements-to-the-backup-experience-to-support-long-filenames-directory-names

Thanks @girish Can't hardly expect it

@girish That's awesome news! Looking forward to v6.0 then! Keep up the awesome work

@Stardenver Well I had a customers server that he wanted the mail limit upped from 40Mb to 60Mb... and I thought I had done that, but couldn't send a big enough email to test. I have no idea why they 'need' it, its usually some self-employed boss who doesn't know better, or can't be told. I make the changes they ask for, and charge for my time.