Details and Discussion

Quote# 127166

As many of you know, FSTDT is undergoing a major rewrite this summer and fall and moving to a new host sometime between November of this year and January of the next at the latest.

(I'm calling this version 5.0 of the site, because as far as I know, this will be the fifth rewrite since FSTDT became more than a collection of static HTML files — though please correct me on that if I'm wrong and I'll bump the version number up or down accordingly.)

This post will be gradually be populated with details about the new server-side code and site design, calls for code-monkeys and other folks with technical know how, etc.

I also want the comments thread to be a place to discuss the new site, so feel free to ask questions and post suggestions and general comments even though there's not much here right now.

Some general mostly technical details in no particular order (read "a highly disorganized non-order")

• FSTDT will be moving away from Windows Server and onto a Linux server, and the main database will use PostgreSQL instead of MS SQL Server. A couple of SQLite databases will be used to log errors and store user session information (but not user accounts).

• The aim of the first version of the new site code will be feature-parity with the current code, though there will still be several new features simply as a result of switching to a radically different platform (or the switch thereto making them very easy to implement). Virtually all long-standing bugs will be fixed. The new FSTDT code will also be highly modular and use generic programming as much as possible to make it much easier to add new features and fix bugs. It will also most likely rely substantially less on classes and objects for many things.

• Nearly all of the new FSTDT code will be open source licensed under version 2.0 of the MPL with a "no secondary licenses" clause. (I will discuss the rationale in more detail later, but the gist of it is that it is a fair middle ground between insanely permissive BSD-style licenses and insanely restrictive copyleft licenses like the GPL.) A small part won't be open-sourced for security reasons or for being specific to the server FSTDT is running on. The code will be hosted on GitHub.

• Unless I have a hard time recruiting developers with JavaScript / Node knowledge, or the current code-monkeys overwhelmingly want to use something else, the server-side code for the new site will be primarily written in Node.js. If they go against Node, we're almost certainly using PHP.

• Something non-technical people care about: Using PostgreSQL and SQLite means UTF-8 / Unicode will be supported out-of-the-box with no configuration! However, it will make importing existing quotes into the new database somewhat of a bitch when they contain non-ASCII characters. Unfortunately, a lot of the process of importing old data into the new database will have to be done manually because of this and the point below.

• The database structure in general will have a radically different schema. Most notably, it will use foreign keys extensively. This will make it much easier to fix things like quotes spelling "David J. Stewart" 50 different ways. It will also speed up search times, eliminate redundancy, and decrease database size. User accounts and information will be stored in a separate database from quotes and comments. (Why wasn't this done originally?)

• The current user accounts system is going to be scrapped altogether, meaning you're all going to have to re-register your accounts. (Sorry, guys.) On the upside, the new user-accounts system will have private messages and optionally let you use a secret question + answer to reset your password in addition an email password reset code. Since there's been two documented SHA2-256 collisions and using SHA anything is a terrible idea for hashing passwords anyway, passwords will most likely be slow-hashed using Slowfish (what I call OpenBSD's variant of Blowfish).

• The registration process is going to be reversed: you provide an email address and receive an email verification code first, then you use that code to register a user account. That both throws spambots for a total loop and discourages users that are unlikely to comment from registering. Shy Says already has code for this in place, but it's written in VB.NET (though it uses its own mini-server instead of XSP/IIS and uses very few ASP.NET components — still, a lot of the Shy Says code is applicable to FSTDT and can be straightforwardly translated to Node).

• I'm considering pubadmin a feature of the current FSTDT codebase, so the first version of the new site will have a working pubadmin! (Even though it had to be gutted during the process of me taking over the site from Distind.)

• AJAX / XmlHttpRequests will be used for certain things, such as posting and editing comments, submitting quotes, logging in and out, pubadmin, mod tools, and so forth.

• Half-decent mod / admin tools!

• The general layout and design of the site will be very similar to the current one except substantially more polished and substantially more mobile-device and search-engine friendly. It won't look like something out of the 90s, and I won't be ashamed of it.

• URLs will be user- and search-engine friendly, ex. http://www.fstdt.net/random/cstdt, http://www.fstdt.net/quote/123456. The URL routing code will also likely include code for backwards-compatibility with current URLs, at least for a while. That means the current URLs will still work during that time (but they will display a message saying the site has changed and to use the new URLs from now on).

The New FSTDT Site!, Details and Discussion 8 Comments [5/14/2017 6:35:15 PM]
Fundie Index: 4
Submitted By: shy

Username  (Login)
Comment  (Text formatting help) 

1 | bottom


Fixed and clarified a few points. Also, I'm holding off on the custom blog app for Shy Says until I can get it translated into Node. But notice that I didn't say JavaScript. That's because it won't be written in JavaScript, at least not directly — it'll be using that "Frankenlanguage" thing I've mentioned a couple times before It's essentially a VB-like language that "compiles" straightforwardly into mostly readable JavaScript.

The regular FSTDT code will not be using this, though. It'll be using regular old JavaScript if we go with Node (things are looking good on that front), otherwise PHP. I am neither pretentious or deluded enough to think writing FSTDT in a special programming language I made for myself and my own tastes is a good idea. The code for it will be on my GitHub with the rest of the Shy Says code, though.

5/18/2017 10:34:07 AM

Will it be possible to embed videos in the comments of the new site?

5/19/2017 11:19:39 AM


For YouTube and videos that don't require any special code to embed their videos using <video> tags, definitely, though it most likely won't be in the original release. Unfortunately, most sites require their own different code to embed their videos even when they use plain <video> tags. I'll have to consider other sites that do this on a case-by-case basis.

5/21/2017 10:07:32 AM

Pharaoh Bastethotep

Could it be possible to give a simplified summary of the noticable changes for us lusers?

5/24/2017 2:31:59 AM


Yeah, I'll work on that this afternoon. There will definitely be a few changes on the luser side in the first version of the new site, but probably not too many. Best things IMO will probably be the new paginator and full support for UTF-8 ("Unicode") in quotes and comments without having to use cheap tricks. Also the whole slew of known bugs and oversights (and then some) will be fixed, including on the user end.

(On the modly minion side, the changes will be much more dramatic, but I don't wanna give away too much yet. 😉)

5/25/2017 2:02:09 PM


Here ya go (dealing with another lovely thread delayed this):

(I just threw that together in the Mac Text Edit app and exported it to HTML.)

5/26/2017 1:28:37 AM


• AJAX / XmlHttpRequests will be used for certain things, such as posting and editing comments, submitting quotes, logging in and out, pubadmin, mod tools, and so forth.

Nobody cares if AJAX is used or not. They care if their back button works and if the thing is fast.

If the new version is noticeably slower than the old one, I'll revolt.

5/30/2017 10:01:11 AM


@pyro: I'm deliberately limiting Ajax to submitting HTTP POST forms, e.g. posting/editing comments, submitting quotes, logging in/out, etc. It's practical for them, saves bandwidth, and is and a pretty good deal faster than submitting and reloading the whole page, especially if POSTing just does a postback. Using Ajax for this also doesn't break the back button, nor does it matter that the URL isn't changing for them. (It wouldn't change anyway if the form were a postback.) But going all gung-ho with XHRs and using them literally everywhere is not faster. It's just stupid. It's also an accessibility nightmare and extremely search engine unfriendly. I went through that phase, though. Seems a lot of web developers do. I Got Better.

Oh, and submitting all forms will fallback to regular old form submission if XmlHttpRequests aren't working or JavaScript is flat-out disabled altogether.

5/31/2017 1:27:35 PM

1 | top: comments page