Would it be possible to split the current website into “core” (what other people might need) and “plugins” (currently one: the LW and EA specific functionality)? Each plugin could have its own tables, its own pages, and inject some HTML code into specified places in the “core” (or other) pages. The plugin support should not cover all hypothetically possible cases, only what is needed to make the current “plugin” run.
I agree that thinking about how changes might impact other users makes development (and release management) way more complicated. Would probably need separate “stable” (bugfixes only) and “experimental” branches.
But I find it interesting, how many people want to have online debates, and how much the existing solutions suck. I already gave up the idea of hosting my own web forum, because it seems like it would become a full-time job to moderate and fight spam—and the choices are whether the “full-time job” would consist of developing and maintaining my own solution; or learning how to use an existing one, updating it constantly because every two weeks there is a critical security update, and coding my own plugins to fix or add functionality anyway; I am not even sure which option is less work in long term. This is really not good.
It’s possible, but I really expect it to be a lot of work. We have a lot of shared UI and small interleaving pieces of functionality all across the site, and I expect this would cut off a lot of the design space we could explore, or basically just force everyone to run the whole forum anyways.
Like, we modify the code responsible for displaying post-items during the review to display the small “Review” button on the right. I don’t know how to factor that out so that you don’t even get that piece of code shipped, and these kinds of dependencies are all over the place. The comments UI depends on moderation guidelines in subtle ways, the recommendations for the frontpage depend on your view-history, but I would also like it to depend on your comment and vote-history, and this would become harder where everything is plugin-structured.
The visual design philosophy of the site is also very much centered around minimalism and trying to only present you with the information you really need in any given moment, which often leads to small design changes based on context that I find hard to factor out (contrast this with the usual PhPBB forums that tend to just throw small independent widgets everywhere in order to customize your experience, leading to what I experience as massive information overload, but having the benefit of being much more modular and you can easily turn off whether you display the last-commented time of a thread, or the total number of comments, or the total number of contributors, etc.).
we modify the code responsible for displaying post-items during the review to display the small “Review” button on the right.
This is exactly what I imagined. Each plugin would have a function “insert my code” with two parameters: first would be the name of the place (in this case e.g. “article widgets”), second would be an object describing the context (in this case it could provide the article name, date, ID, URL). When a page wants to show an article, it calls this function for all registered plugins, in order they were registered. (There is one source file with hardcoded list of registered plugins.) Each plugin returns a HTML code, or empty value, and the page inserts the returned values.
What places exist? The ones we currently use. What values are provided in the context? The ones we currently use. Later, expand as necessary.
The other cases you mentioned sound more complicated...
Would it be possible to split the current website into “core” (what other people might need) and “plugins” (currently one: the LW and EA specific functionality)? Each plugin could have its own tables, its own pages, and inject some HTML code into specified places in the “core” (or other) pages. The plugin support should not cover all hypothetically possible cases, only what is needed to make the current “plugin” run.
I agree that thinking about how changes might impact other users makes development (and release management) way more complicated. Would probably need separate “stable” (bugfixes only) and “experimental” branches.
But I find it interesting, how many people want to have online debates, and how much the existing solutions suck. I already gave up the idea of hosting my own web forum, because it seems like it would become a full-time job to moderate and fight spam—and the choices are whether the “full-time job” would consist of developing and maintaining my own solution; or learning how to use an existing one, updating it constantly because every two weeks there is a critical security update, and coding my own plugins to fix or add functionality anyway; I am not even sure which option is less work in long term. This is really not good.
It’s possible, but I really expect it to be a lot of work. We have a lot of shared UI and small interleaving pieces of functionality all across the site, and I expect this would cut off a lot of the design space we could explore, or basically just force everyone to run the whole forum anyways.
Like, we modify the code responsible for displaying post-items during the review to display the small “Review” button on the right. I don’t know how to factor that out so that you don’t even get that piece of code shipped, and these kinds of dependencies are all over the place. The comments UI depends on moderation guidelines in subtle ways, the recommendations for the frontpage depend on your view-history, but I would also like it to depend on your comment and vote-history, and this would become harder where everything is plugin-structured.
The visual design philosophy of the site is also very much centered around minimalism and trying to only present you with the information you really need in any given moment, which often leads to small design changes based on context that I find hard to factor out (contrast this with the usual PhPBB forums that tend to just throw small independent widgets everywhere in order to customize your experience, leading to what I experience as massive information overload, but having the benefit of being much more modular and you can easily turn off whether you display the last-commented time of a thread, or the total number of comments, or the total number of contributors, etc.).
This is exactly what I imagined. Each plugin would have a function “insert my code” with two parameters: first would be the name of the place (in this case e.g. “article widgets”), second would be an object describing the context (in this case it could provide the article name, date, ID, URL). When a page wants to show an article, it calls this function for all registered plugins, in order they were registered. (There is one source file with hardcoded list of registered plugins.) Each plugin returns a HTML code, or empty value, and the page inserts the returned values.
What places exist? The ones we currently use. What values are provided in the context? The ones we currently use. Later, expand as necessary.
The other cases you mentioned sound more complicated...