Even if you could do that, you'd still with the terrible performance penalty of the EE engine. Everytime a node is rendered, it has to load and eval dozens of perl code snippets.

While this brings a lot of flexibility in theory, modern distributed source control (like git or mercurial) has the same benefits. For example, in my PageCamel framework, the code (and static assets and template files) are loaded at startup once, then running at full speed without having to recompile it at every single webcall.

Startup takes a few seconds, depending on the size of the preloaded data and if precompression (for HTTP transport) is enabled. Static assets (excluding templates at the moment) can also be marked as "dynamic" and will be loaded from disk every call (which still gives near-instant access for the most-used files due to OS caching).

There are still a few SQL calls for every URI requested, but it doesn't have to recompile code and can use a lot more "tricks" to cache data and optimize operations in other ways.

Mastodon¹ uses similar concepts. Assets are precompiled, preparing feeds and other heavy lifting is done in background processes. The webserver does as little as possible, mostly grabbing some prepared data from the database, pushing it through a template engine, and thats it.

I'm sure we could teach the EE engine all this tricks modern web applications can use. But, at least in my personal opinion, it's far easier to expand a modern engine to work as a PM forum with all the features we want.

And, as i said in other posts, it wouldn't even be to hard to import all the existing posts into the new system. EE is the perfect rendering engine for EE nodes, and depending on the internal format/markup of the new rendering engines, it might be trivial to convert HTML into that format. For example, my web framework uses a DIY fork of the old CKEditor 4, which is a WYSIWYG editor for HTML, so this should work fine.

We still can support multiple different "source" markups, because some people might prefer, say, a Wikipedia markup style. In this case, the post (the row in the database) would store the source markup and the rendered HTML snippet. (As a bonus, if we choose multiple markup languages that all also support converting HTML into the language, we could also transpile one markup language to another, to suite whoever is editing a post, you know TIMTOWTDI for writing your posts).

¹ Very nice software. Such a shame it's written in Ruby...

I mean, yeah, we could do a copy of the database but exclude certain rows... but then a lot of stuff would be broken. It simply was not designed for that kind of separation. Quite the opposite, in fact (for better or worse). That's why it was called "Everything". ("Everything is a node.")

And it's not that there is code which is as sensitive as, say, passwords, but it's used for administrative purposes so it's better that potential hackers not know how it works.

Then there are also settings nodes which are even squirrelier, as they contain multiple values, some of which might be sensitive, and some or all of which are necessary for the engine to function.

Please:

Let's keep this thread focused on ideas for the (hypothetical) new, replacement site! Discussion of what's wrong with this site and how we might fix this site should go over in Ideas for "fixing" PerlMonks 1.0. Thank you!