@jedafe I think the issue is the selfhost code lives inside the containers (this may not be the case with the talk to dokku install, but it is for the official self-hosted forem install). This permits upgrading the code without needing to manage files on the disk (removing old code, updating changes, creating new files), the software update process is effectively pulling the new image and restarting the service. That's why you see some information in /opt/forem but not the app/ directory you're looking for.
The /opt/forem directory is used for data storage (uploads, for example) while the application code lives inside the image. To run custom code (outside of what's possible using the administrator/customization dialogs), specifically to override the current forem code with custom modifications, would require using a container image including that code (you could build this with docker build . or script/build_containers.sh, but you'd also need to get that image, rather than quay.io/forem/forem:latest installed on the host, i.e. you'd need to look at passing a container or image to /usr/local/bin/foremimg).
I can imagine a "local.css" and or "local.js" files that are present outside the app/ directory (outside the container, on the host), permitting the types of customization you're looking for, however, this might cause unexpected interactions during upgrades (since we can't know what every user has done in their local files, the names could conflict with forem's internal code and cause broken functionality, even if it all worked when you'd added it) - the "safe" extensions/customizations are expected to be added via the admin area.
If there are specific customizations you'd like to add, which you need css/js access for because it's not otherwise possible, we'd definitely be interested to see what those look like, and whether we can support that using admin customizations in the future.
Lastly, this excellent walkthrough from a community member discusses adding customizations in code to forem's software, in a way that minimizes conflict (via a rails engine). You do need to build and load a custom image in this case to load that code - the "upstream" official forem images will not include your local changes so every update would require building the forem image from the source code (rather than pulling a prebuilt image from our process).
Anything involving code changes or local forks is outside of our ability to support (and any customizations not accessible from the admin pages probably fall into this situation).
Thank you very much for your swift response, I appreciate.
I have managed to do some minor customization to my website frontend using cloudflare.
However, I would love to see this implemented in the main forem, specifically in the admin area. Something like "Custom CSS/JS Codes in the Header and Footer" to override some frontend styles if the need arises.
Oh - that's handy that cloudflare provides this! All of the original cautions about scripts outside of the tested codebase interfering with exisitng functionality apply, but that's a nice work-around.
For further actions, you may consider blocking this person and/or reporting abuse
@jedafe I think the issue is the selfhost code lives inside the containers (this may not be the case with the talk to dokku install, but it is for the official self-hosted forem install). This permits upgrading the code without needing to manage files on the disk (removing old code, updating changes, creating new files), the software update process is effectively pulling the new image and restarting the service. That's why you see some information in /opt/forem but not the app/ directory you're looking for.
The /opt/forem directory is used for data storage (uploads, for example) while the application code lives inside the image. To run custom code (outside of what's possible using the administrator/customization dialogs), specifically to override the current forem code with custom modifications, would require using a container image including that code (you could build this with
docker build .orscript/build_containers.sh, but you'd also need to get that image, rather thanquay.io/forem/forem:latestinstalled on the host, i.e. you'd need to look at passing a container or image to/usr/local/bin/foremimg).I can imagine a "local.css" and or "local.js" files that are present outside the app/ directory (outside the container, on the host), permitting the types of customization you're looking for, however, this might cause unexpected interactions during upgrades (since we can't know what every user has done in their local files, the names could conflict with forem's internal code and cause broken functionality, even if it all worked when you'd added it) - the "safe" extensions/customizations are expected to be added via the admin area.
If there are specific customizations you'd like to add, which you need css/js access for because it's not otherwise possible, we'd definitely be interested to see what those look like, and whether we can support that using admin customizations in the future.
forem.dev/andrewbrown/how-to-creat...
Lastly, this excellent walkthrough from a community member discusses adding customizations in code to forem's software, in a way that minimizes conflict (via a rails engine). You do need to build and load a custom image in this case to load that code - the "upstream" official forem images will not include your local changes so every update would require building the forem image from the source code (rather than pulling a prebuilt image from our process).
Anything involving code changes or local forks is outside of our ability to support (and any customizations not accessible from the admin pages probably fall into this situation).
Thank you very much for your swift response, I appreciate.
I have managed to do some minor customization to my website frontend using cloudflare.
However, I would love to see this implemented in the main forem, specifically in the admin area. Something like "Custom CSS/JS Codes in the Header and Footer" to override some frontend styles if the need arises.
Oh - that's handy that cloudflare provides this! All of the original cautions about scripts outside of the tested codebase interfering with exisitng functionality apply, but that's a nice work-around.