Make non-dynamic pages static

[headquarter8302]

In an effort to ease #417

For every "static" page on the site, the site needs to rebuild the entire template, which means re-evaluating all logic, data, and preprocessing done by PHP, then serve the request back. This is understandably inefficient.

A few solutions to this are:

• to render these pages ahead-of-time and cache them with a very long life, or (even better),
• make static HTML files of these pages, and have the site serve them instead

[tresf]

Linking the last time this was discussed: https://discord.com/channels/203559236729438208/371750027938365440/1372556915879444512

Quoting:

Last we discussed @liushuyu wanted to keep around some translation features however in @liushuyu 's absence, the server's overall health may force us away from any back-end translation features.

With regards to helping #417, my belief is that most of the performance issues actually stem from slow and maxed-out database sessions, so this may help prevent the main website from breaking, but I'm uncertain as to the overall "fix" it would have on things like LSP and forums as they seem to be the source of the resource and -- by very nature -- can't be (easily) be served as static.

[headquarter8302]

I see, I had completely forgotten about that matter. With the way the website is structured right now, a static page for each existing translation must be generated or provided before the locale system can serve pages appropriately.

One may even consider ditching this idea, as a site-wide caching solution may be a lot better, because we don't need to change anything fundamental about the site, and we can add a cache adapter on top of the existing serving code

[tresf]

I see, I had completely forgotten about that matter. With the way the website is structured right now, a static page for each existing translation must be generated or provided before the locale system can serve pages appropriately.

One may even consider ditching this idea, as a site-wide caching solution may be a lot better, because we don't need to change anything fundamental about the site, and we can add a cache adapter on top of the existing serving code

I personally use the browser-translate features for websites that are not in my language and I find them to work well, but I can understand why some people may not find this to be ideal. Due to the uncertain nature of our translations in general, I believe removing complexity by removing website translations would help simplify and improve overall maintenance efforts of the website. When this was last proposed, @liushuyu was the maintainer of most of the website portions and didn't want to revert this hard work, but due to availability (well, lack thereof -- or more specifically, insufficient access where @liushuyu currently resides), we have to step up and take this task over, so I'd be fine merging a static-only website.

I think the most challenging effort would be refactoring the downloads page to generate the download buttons as static content.

I do NOT believe this will help the overall CPU issues we have, so I still believe this to be an adjacent task.

[headquarter8302]

I think the most challenging effort would be refactoring the downloads page to generate the download buttons as static content.

We have an option to leave the Downloads page as-is. I'm not comfortable with doing a lot of GitHub API access on the frontend, but if it's preferable, we can do it.

I do NOT believe this will help the overall CPU issues we have, so I still believe this to be an adjacent task.

It's a step in the right direction. Static pages means leaving just LSP for the really-important optimizations

[tresf]

I think the most challenging effort would be refactoring the downloads page to generate the download buttons as static content.

We have an option to leave the Downloads page as-is. I'm not comfortable with doing a lot of GitHub API access on the frontend, but if it's preferable, we can do it.

Not JavaScript, but rather a static page generator, probably a cron.

[tresf]

Static pages means leaving just LSP for the really-important optimizations

Both the LSP and the forums are suffering as a result, so an effort to analyze and fix phpBB may also be in order.

[sqrvrt]

With the way the website is structured right now, a static page for each existing translation must be generated or provided before the locale system can serve pages appropriately.

I don't see how that would be a loss, pretty much all wikis do it this way. In any case you can have a template and then generate the pages with relevant text.

I'm not comfortable with doing a lot of GitHub API access on the frontend, but if it's preferable, we can do it.

How about sort of an API proxy that just puts a link to the artifact in a predictable location, and point the website to that? Sort of what nightly.link does basically.

Having download pages be updated frequently is important for PR testing.

[tresf]

How about sort of an API proxy that just puts a link to the artifact in a predictable location, and point the website to that? Sort of what nightly.link does basically.

This would certainly help with nightly links.

Having download pages be updated frequently is important for PR testing.

Hmm... well, PR testing is where services like nightly.link start to fall short... we can't serve PR downloads in dedicated pages without building them out.