Cloudron Forum

@nebulon I didn't see any warning signs of low memory, but it just started working after I switched from a shared CPU to a dedicated one.

@ServerMan3932 I fixed it! I ended up fixing it with a server-upgrade. Turns out, the crashing was caused by insufficient resources to run all the plugins, but it's working better now.

@nebulon Hey, I took another look at the logs and found that right before it configures compiles the CSS; it's deleting and renaming things related to the plugin. Not sure if that's normal or not but It's worth mentioning.

execute("DELETE FROM site_settings\nWHERE name IN (\n 'codefund_property_id',\n 'codefund_advertiser_label',\n 'codefund_advertiser_short_label',\n 'codefund_through_trust_level',\n 'codefund_nth_post',\n 'codefund_display_advertiser_labels',\n 'codefund_below_post_enabled',\n 'codefund_above_post_stream_enabled',\n 'codefund_above_suggested_enabled',\n 'codefund_top_of_topic_list_enabled'\n)\n")
2023-09-11T14:39:32.000Z -- execute("UPDATE site_settings SET name = 'ads_txt' WHERE name = 'adsense_ads_txt'")
2023-09-11T14:39:32.000Z -> 0.0009s
2023-09-11T14:39:32.000Z -> 0.0012s
2023-09-11T14:39:32.000Z == 20190603112536 RenameSiteSettingAdsTxt: migrated (0.0030s) =================
2023-09-11T14:39:32.000Z == 20190603112536 RenameSiteSettingAdsTxt: migrating ==========================
2023-09-11T14:39:32.000Z == 20200703082449 RemoveCodefundSiteSettings: migrated (0.0016s) ==============
2023-09-11T14:39:32.000Z == 20200703082449 RemoveCodefundSiteSettings: migrating =======================
2023-09-11T14:39:33.000Z ==> Setup OpenID connect integration
2023-09-11T14:39:34.000Z fatal: not a git repository (or any of the parent directories): .git
2023-09-11T14:39:38.000Z fatal: not a git repository (or any of the parent directories): .git
2023-09-11T14:39:40.000Z => Healtheck error: Error: connect ECONNREFUSED :80
2023-09-11T14:39:40.000Z fatal: not a git repository (or any of the parent directories): .git
2023-09-11T14:39:44.000Z fatal: not a git repository (or any of the parent directories): .git
2023-09-11T14:39:47.000Z fatal: not a git repository (or any of the parent directories): .git
2023-09-11T14:39:48.000Z ==> Skip building assets (already built)
2023-09-11T14:39:50.000Z => Healtheck error: Error: connect ECONNREFUSED :80
2023-09-11T14:39:50.000Z fatal: not a git repository (or any of the parent directories): .git
2023-09-11T14:39:51.000Z -------------
2023-09-11T14:39:51.000Z Compiling CSS for default 2023-09-11 14:39:51 UTC
2023-09-11T14:39:51.000Z Start compiling CSS: 2023-09-11 14:39:51 UTC

As far as crashing goes, I meant that the website ceases all functionality and displays this message to users.

Oops
The software powering this discussion forum encountered an unexpected problem. We apologize for the inconvenience.
Detailed information about the error was logged, and an automatic notification generated. We'll take a look at it.
No further action is necessary. However, if the error condition persists, you can provide additional detail, including steps to reproduce the error, by posting a discussion topic in the site's feedback category.

@girish I've faced this issue with a few different plugins unfortunately. I just gave up on trying to run the other quality-of-life type plugins, but the ad plugin is one I really need

Here's a list of the things that I've tried and failed at running so far:

• (Officially supported) The Discourse Ad Plugin. (Crashes server on startup)

• (Officially supported) The Discourse Reactions Plugin (Installs and shows up as disabled but crashes server with that error message upon enabling, rebooting doesn't help either, it just starts back up with the error)

• (Third Party Plugin) Discourse Custom Wizard (Crashes server on startup, same result as the ad-plugin)

• (Officially Supported) Spoiler Alert Plugin (Crashes server on startup)

Some errors I get on both a normal boot (No ad plugin) and a bad boot (ad plugin installed) are:

fatal: not a git repository (or any of the parent directories): .git

CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.

Not sure why the above issues would be a problem to this specifically, but they may be worth mentioning

As far as a comparison between when the plugin is installed vs when it's not, the difference comes at the very end as NGINX is starting up.

On a bad boot with the Ad-Plugin Installed; the logs look like this,

2023-09-11T14:40:00.000Z ==> Starting discourse
2023-09-11T14:40:00.000Z => Healtheck error: Error: connect ECONNREFUSED :80
2023-09-11T14:40:01.000Z 2023-09-11 14:40:01,334 INFO spawned: 'unicorn' with pid 174
2023-09-11T14:40:01.000Z 2023-09-11 14:40:01,335 INFO spawned: 'nginx' with pid 175
2023-09-11T14:40:02.000Z 2023-09-11 14:40:02,883 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-09-11T14:40:02.000Z 2023-09-11 14:40:02,883 INFO success: unicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

On a good boot it's this,

2023-09-11T14:36:24.000Z ==> Starting discourse
2023-09-11T14:36:25.000Z 2023-09-11 14:36:25,654 INFO spawned: 'unicorn' with pid 718
2023-09-11T14:36:25.000Z 2023-09-11 14:36:25,655 INFO spawned: 'nginx' with pid 719
2023-09-11T14:36:27.000Z 2023-09-11 14:36:27,212 INFO success: unicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-09-11T14:36:27.000Z 2023-09-11 14:36:27,213 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

I also checked my browser java-script console during the error, its completely empty when the error displays.

I've also compared the installed version to the supported version,

The Ad-Plugin Github Repo states the supported version is 1.4. The latest Cloudron package is 3.1.0.

Nothing seems off there because it's officially supported and was just recently updated, so I would imagine that means anything above 1.4 too.

The last thing I can think of is that it could be trying to write to a protected area, because one of the biggest things done differently from the official package is that cloudron makes things immutable, so maybe something has to be symlinked? (Could be totally left field on that, just spitballing)

I think there's likely a broader issue with plugins on the cloudron package of discourse that may need some attention, because official plugins shouldn't be doing anything too weird like a third party/unsupported plugin might; so my biggest guess is that these plugins expect something that's being denied to them.

Hey, I've been checking out discourse and wanted to monetize it with ads. I found the discourse advertising plugin and it had all the features I needed to start configuring advertisements, it's also officially supported so I thought it should be good to go.

I installed it from the GitHub repo linked on their Official Meta Instance using the instructions on the Cloudron Docs and then when I restarted the discourse app; it started back up completely broken (I make backups before I install plugins though, so I was able to restore thankfully)

Upon the server restarting, this is the message I get:

Oops
The software powering this discussion forum encountered an unexpected problem. We apologize for the inconvenience.
Detailed information about the error was logged, and an automatic notification generated. We'll take a look at it.
No further action is necessary. However, if the error condition persists, you can provide additional detail, including steps to reproduce the error, by posting a discussion topic in the site's feedback category.

The site is completely down when this message displays, so ironically, the feedback category is down with the site.

My process consisted of:

• 1. I opened a web terminal for Discourse and did: cd /app/code/plugins
• 2. I did: git clone https://github.com/discourse/discourse-adplugin.git
• 3. I shut down the Discourse app, and turned it back on again
• 4. The website gives out and displays the error.

It's been a headache trying to get working so any help would be appreciated!

Getting a fork started is certainly a start
I haven't really had a look at or even used previous versions of HumHub so I imagine it taking some time to find out exactly what changed with the newer version that broke old themes. My first guess though from the internal error and "It looks like you may have taken a wrong turn" messages in addition to one of the pull requests on github that suggests changing "$canWrite" to "$canEdit" almost makes me think there was a bunch of changes to how data is referenced that causes a mismatch in what the theme is attempting to reference because it's reference point is completely different. Could be wrong though; I'm not terribly experienced in web development.

@girish Oh, That's a bit of a bummer; that's one of the best themes I've seen so far. Either way, I appreciate the patch on your end, I'll try and find some other themes to try as well. Just trying to get the front-end to look slick and more modern!

Thanks for the help!

Hey, I've been using Cloudtron for the past few days; It's made setting up my server a breeze but it seems I've ran into my first issue

So I was trying to create a HumHub server and wanted to add some themes to it but the only theme available on the official repo in the application is a very basic theme called "Clean Theme".

I wanted something a bit more elegant and decided to go and search for additional themes to deck out my server with. The options are slim because the software is a bit niche, but I found a really neat looking theme called "Flathub" That makes the whole website just look better and more modern. I went to go try and install it but realized that the intended installation is to place it in /Themes.

/Themes wasn't showing in the GUI File manager so naturally I took to the command line and an LS showed that /Themes indeed existed. So I went ahead and tried to write a new file into it with nano to test if it was writable, and sure enough, it was read-only. Being curious of how one of the officially listed themes was applied, I went ahead and searched around; finding that the clean theme obtained from the module repo in humhub was placed inside the modules folder. So it seems that some themes are modules and others are meant to be installed as non-modules directly in the themes folder. Considering the themes directory was meant to be a content directory for the user, I was wondering if this was perhaps a mistake on Cloudtron's end to make it part of the protected file system or if there was another way to get this theme installed without writing to this protected area?

Hopefully someone can guide me in the right direction here,

Thanks.