Link to related forum thread
From Erik's forum post 05/2/19
Formatting wise, hopefully we can just "borrow" a bunch of the source that's already on the page.
My thoughts on possible implementation in just a off the top of my head lists:
Database
Thread table
* Database has a "thread" table or "topic" table. (Or whatever fits best)
* id - primary key, auto incremented identity column.
* parent_id -value of thread it is a reply of. Top level threads will have a thread_parent_id of 0. (not null)
* title_id - FK Id of title text in title table. (not null)
* body_id - FK Id of body text in body table. (nullable)
* create_date - date of posting. default sys_date/current_timestamp or whatever standard is for DB being used.
* author - who posted, text column (not null)
* email - email of poster. text column (nullable)
* source_ip - source ip address of post... maybe not bother with this...
Title table
* id - PK, auto increment id column.
* text - "click line" text. Smaller width text column (not null)
* This might not be necessary. Might be able to just store the title text directly in the thread table to avoid additional joins.
Body table
* id - PK, auto increment id column
* text - body of messages. Large width text column. (not null)
If we want to do multiple boards, I guess we would also add a board_id column to the above to associate with a message board. And then have a board table to hold each message board info. Then if we want to get even "crazier". Have an prologue/epilogue table to hold header/footer info.
Not sure if we would want to go that far or just make a simple stand alone one.
Message board website
Main message board page
* On page load, pull configured x number of parent threads for the board sorting by create date desc.
* For each thread id, we would have to query for an configured x number of other threads that have the related parent_ids recursively to get the child threads.
ex: start of thread - id 1, parent_id = 0
who has parent_id = 1? Found replies with ids 5, 7
who has parent_id = 5? Found replies with 10, 11, 19
who has parent_id = 7? Found no replies.
who has parent_id = 10? found... etc, etc.
I have a stored procedure laying around somewhere that we used to use at my old job to generate the folder structure of back up accounts that might be helpful to get it working efficiently.
* Take results and load up in a model for the website to render orrrr do like how I think this site might do it and just generate the raw HTML directly based on the results and add to the output body (sort of ugly/hackish though).
View Replies page
* Query string sets the board_id (if being used) and also the id of the thread being viewed.
* Query database for thead/reply information based on board_id and thread id.
* existing replies are done like the main page but only for current thread id and it's replies.
* display on the page.
* if user hits "reply", pass thread and board ids to reply page in possibly hidden field that are used to submit the reply to the correct parent_id and board.
Post reply
* like said above, view reply page will pass the thread id and the board id (if exists) to the reply screen. Other than that, just standard POST input form that posts all fields to the server to generate the new DB entries. (After some input sanitation)
Post new thread
* Just passes in board_id if we're using it.
* Creates new database entries based on input fields entered after input validation and input sanitation.
* Id will be auto generated by database as well as create date. These will be the highest and newest dates so it will automatically show as top thread on the main screen.
Administration
* If we go with having the epilogue and prologue tables as well as some sort of configuration table for each board, we could create a page to manage those database fields for the board.
* If we go a more simpler route, or at least one for now, we can just hard code all things not related to the actual threads and use regular old FTP to update the HTML of the message board page.
I think that's all the rambling I have for now... :)
From Puckdropper's forum post 05/03/19
unordered lists with a margin property. It's been suggested to use DIVs for that, so it doesn't interfere with the side-effect heavy CSS if you actually want a HTML list.
So it's like:
CSS:
div.comment
margin:50px
HTML
div class="comment"
div class="comment"
Etc
] <- Lisp uses that, I think, to indicate you want to close all the parenthesis. < /div > < /div> is truly wonderful.
My HTML/CSS is for demonstration purposes only, it's been a while since I wrote any! I know I left the < and > off, I didn't want the messageboard interpreting my code as code.
\
Does escaping work?
\
FWIW, here's my almost 15-year old idea on threaded comments:
Notes on Comments
+-----------------------------------------------------------------------+
+ Comments are identified by their referral_ID, Thread_ID, and +
+ Comment_ID. The Referral_ID posts to the post in which the +
+ comment is referring, the thread_ID refers to the thread within +
+ the Referral_ID and the comment_ID refers to the specific post. +
+ +
+ This will create a threaded view such as that used on forums, but +
+ does not allow for sub-threads to be formed. Possible updates +
+ include the modification of this structure to allow for that feature. +
+ +
+ Structure: +
+ Referral_ID +
+ Thread_ID +
+ Comment_ID +
+-----------------------------------------------------------------------+
So more thoughts:
Your table structure looks good, but it's been a while since I've done any programming. Blog release 1.0 is pretty close to the last database programming I've done......... Oof, that was 2012-Jun-03! Anything else was just a hack or a script edit.
There's been some interesting changes to how PHP handles MySQL. It's using something called prepared statements now, I guess. They're kinda neat in that they prevent SQL injection by telling the processor the thing you're feeding in is a variable and not part of a SQL statement. I want to say I used them in Perl, but never learned how to do that in PHP.
As far as spam prevention goes, registration usually does a great job. It sucks because everybody makes you register. I don't know if a rotating type of CAPTCHA would be good--UCL uses "enter this number" and it killed off spammy registrations dramatically. You don't even need to add, just match the pictures on the keyboard to those on the screen!
V1. Spam bots can't do math so to post on this website please solve this system of equations.
V2. Ok spambots can do math, and quite quickly. Please take between 5 and 20 minutes to solve this system of equations.
V3. Wow, spambots are now using random amounts of time to solve this system of equations. So please show your work.
V4. Mrs. Buttersworth, I realize you find some pretty nice problems on our site, but could you ask the students NOT to click register when they're done?
V5. Ok, we've added a "check my answer" link.
V6. Well if they're not going to use "check my answer", we'll at least make them show their work.
V7. Added a module to show them where they went wrong. Swapped "Register" and "Check my Answer" buttons.
V8. We give up. Mrs. Buttersworth, here's the code for the Numerical Enput Mathematic Board. We've included three real reviews that say how much better of teacher our software is than you. Oh and if your students solve 20 of these in 20 minutes they get to play Wry until they die. Get used to hearing that theme music! Duh dah da dah duh duhhh duh duhhh
Honestly I don't know what to do with IP addresses when I have them. Yeah, you can maybe track them back and file a complaint but that's a lot of work for something that's best deleted and moved on from. Where it may come in handy--and this is above our pay grade--is to detect an attack and disable the IP-range temporarily--like 24 hours. (Permanent bans caused all sorts of trouble for UCL members. I spent a lot of time unbanning IPs when we rebuilt the site.)
WOW, THAT WAS LIKE A BABEL FROM THE OLD DAYS!