Self-hosted instances

[Taeir]

Is your feature request related to a problem? Please describe. When attempting to set up a self-hosted instance of QPixel for the Delft Univeristy of Technology, a number of issues popped up.

The key ones:

• Some things which seem configurable in the application actually do not work when configured in a way that is different from how things are hosted on codidact.com.
• A lot of values are hardcoded to point to codidact.com (links to subpages, email sent from addresses, links in email addresses, etc.).

For the latter point, of course we would expect some mention and attribution of Codidact ("hey we made this" "come help us"), but for many other things we would expect these to be configurable instead.

Describe the solution you'd like Additional configuration options to be able to change many of the places where Codidact is currently hardcoded.

Additional Context The main question is how codidact sees the future of QPixel. We have made/are making the required code changes to make it work as a self-hosted instance under a domain of our own. We could keep these changes separate, but this will provide difficulties in keeping up to date with changes made by the codidact team, and the changes we are making may also be useful to other users.

On the other hand, adding the required configuration requires additional work. For now, we just replaced a lot of the hardcoded values in the code. Of course, other institutions can do the same, and we could argue that this is the "intended" way to create a self-hosted instance. This does however raise the bar for difficulty on setting up such an instance, and may lead institutions to other platforms.

[cellio]

See also https://github.com/codidact/qpixel/issues/770 and https://github.com/codidact/qpixel/issues/747 . It wasn't our intention to force other instances to link to us all over the place; it kind of grew like that and we haven't fixed it yet. I would rather have this be in configuration, not code forks.

Since you've just gone through and changed them, can you share your list for where you found hard-coded assumptions? The ones I know about are:

• page footers: Codidact project links, and "other Codidact communities" (you probably want the name of your network in that string, not ours)
• links in seeded help topics
• email addresses and links, including the link in the confirmation email for new accounts
• the "Codidact" block in the right column and its outbound links
• donate button

Thanks.

[Taeir]

Sorry, I didn't find #770 when looking for this problem in the issues list. I think that is pretty much it indeed. This is a full table of the items and their locations that we currently adapted:

Page / component	File	What	Variable suggestion	Importance
Account confirmation instructions email	app/views/devise/mailer/confirmation_instructions.html.erb	Welcome to Codidact	Network name	Low
All account related emails	app/views/devise/mailer/_friendly_footer.html.erb	Your friendly neighborhood codidactyl	Account Email greeting	Very low
Registration page	app/views/devise/registrations/new.html.erb	Shared account details on other codidact sites (2x)	?	High (confusing)
Footer	app/views/layouts/_footer.html.erb	The Codidact Project, About Us, Contact Us, Other communities	Unsure, we override the whole footer with one of our own	High (all pages)
Head (page meta information)	app/views/layouts/_head.html.erb	Meta description: sitename on codicat - open, community-run Q&A knowledge sharing	Application meta description	Low (SEO only)
Sidebar	app/views/layouts/_sidebar.html.erb	This community is part of the Codidact network	Network name	High (most pages)
Advertisements	app/views/advertisement/index.html.erb (en.ads.yml)	advertise this Codidact community	Network name	Medium
Account related emails	app/views/layouts/devise_mailer.html.erb	Copyright, Codidact foundation and address, email address	Email footer	High (all account related emails)
All other emails	app/views/layouts/mailer.html.erb and mailer.text.erb	Copyright, Codidact foundation and address, email address	Email footer	High (all other emails)
Mod message	app/mailers/admin_mailer.rb	From (+to) [email protected]	Moderators email sent from address	Low (moderators only)
Donation emails	app/mailers/donation_mailer.rb	From [email protected], reply-to [email protected]	Donations email sent from address, Support email address	High (if they enable donations, support email is important)
Flag notifications	app/mailers/flag_mailer.rb	From [email protected]	Default email sent from address	Low (privileged only)
Subscription emails	app/mailers/subscription_mailer.rb	From [email protected]	Subscriptions email sent from address	High (users see these a lot)
All other emails/notifications	app/mailers/application_mailer.rb	From [email protected]	Default email sent from address	High (users may see these relatively often)
2FA related emails	app/mailers/two_factor_mailer.rb	From [email protected], Codidact in subject	Default email sent from address, Network name	High (for 2FA users, see this often)
Error 422	app/views/errors/unprocessable_entity.html.erb	Link to meta.codidact.com	?	Low (page should not appear normally)
Tour more	app/views/tour/more.html.erb	Mention of codidact and communities, extensive text.	Network name + ?	High (users will see it)

I think only a few additional configuration settings are necessary to filter out a lot of those words. I think most make sense to be put in the Global Site settings category. If your admins can be trusted with these settings, then I would put them there.

It depends a bit on the instancing model used by codidact. It looks like all your communities are run in the same instance at the moment, but I heard about a migration you are currently doing which may necessitate them being disconnected from each other (with shared database?).

[cellio]

PR 840 fixes part but not all of this issue, so this issue should remain open.

[luap42]

Thank you for compiling together the list and starting PRs to make this more configurable. Regarding the footer, I have been thinking for a while (but not had any time, unfortunately :[ ) to make it fully configurable from within the UI, instead of just adding variables for a few instance-specific things. I might look into that in about a month from now, unless someone else takes an attempt at it before me.

[ArtOfCode-]

The other way to do a lot of this, particularly for things that aren't likely to change often (or at all), would be to add a config file in the repo that can be filled in as part of the initial setup for a self-hosted instance. That could have things like email sender addresses, bug report addresses/links, etc. Somewhat easier than adding site settings to an interface that's in dire need of an overhaul.