This is a follow up to my previous post here - https://programming.dev/post/46041021 - For those that want a tldr: I'm making a php site for myself writing nearly everything by hand. The only external library I'm using is Parsedown.
After a good time working on my site, I'm happy to announce that I've officially shared it with my friends^[I won't share it here as the site is tied to a different online persona of mine]! The site isn't really "ready" yet, but it's very usable and readable, so that's good!
As for code quality? Well... It's kinda awful. Instead of this:
class User {
$login = new String();
$email = new String();
...
}
I'm using named arrays (hashes)^[Kinda funny how associative arrays have soe many different names in other languages: hash, dictionary, map] everywhere:
class User {
$columns = array( 'login' => '',
'email' => '',
...
}
"But WHY???", you might be asking. Well, to facilitate the creation of the database from zero! Here's an example of my trick:
abstract class Common {
/**
a bunch of different, generic select and update functions
*/
}
class Users extends Common{
$cols = array('uid'=> 'primary key auto_increment',
'vc1_login'=> 'unique not null',
'vc1_display_name'=> '',
'vc2_password'=> 'not null',
'dat_created_at'=> 'not null',
'bol_enabled'=> 'default 1',
...
}
With this, the $key part of the hash doubles as the column name and their default/new values are always the details needed for the creation of their respective columns. I also treat the ::class as part of the table name. With a few functions, I can easily recreate the database from zero, something which I've tested a few times now and can confirm that it works great! Also, with key pairs, making generic SQL functions becomes very easy with foreach() loops of the $cols hash. Example:
abstract class Common {
public function selectColumns($columns, $table = '', $where='1', $orderby = '') {
$conn = connectDb(); //static function outside class
if ($table == '') {$table = $this::class;}
$coll = '';
foreach ($columns as $cols) {
$coll .= $cols.', ';
}
$coll = substr($coll,0,-2);
$stmt = $conn->prepare("SELECT ".$coll." FROM `T_".$table."` WHERE ".$where." ".$orderby.";");
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_ASSOC);
//Fetch_Assoc is used so I'm forced to always use the $key in the returned array
}
// This function will attempt to update all non-empty pairs of a given object
public function updateColsUid(){
$conn = conectaBanco();
$sql = "UPDATE `T_".$this::class."` SET ";
$keys = array('uid' => $this->cols['uid']);
foreach ($this->cols as $key => $value) {
if (($value != '') and ($key != 'uid')) {
$sql .= " `". $key. "` = :" . $key . " ,";
$keys[$key] = $value;
}
}
$sql = substr($sql,0,-1);
$sql .= " WHERE `uid` = :uid;";
$stmt = $conn->prepare($sql);
$stmt->execute($keys);
return $stmt->rowCount();
}
The biggest problem with this is that if I ever remove, add or rename any of these $keys, it'll be a fucking chore to update code that references it. I'll look into using proper variables for each column in the future, especially as a database creation is something you usually only do once. On the plus side, this is the most portable php site I've ever did (1 out of 1, but whatever)
Anyway, current functionality includes creating an account, modifying some aspects^[I want to note that there was a bunch of validation that I initially didn't think of doing, but luckily had a couple of "Wait, what if..." moments. One of those was to properly escape a user's username and display name, otherwise, when echo'ing it, <b>Bob</b> would show as Bob. While the fields probably wouldn't be enough to fit anything malicious (fitting something malicious inside a varchar100 would be a real feat, ngl), it's better to close this potential hole.] of it (profile description, display name (which is html escaped, so no funny business here), signature), logging in, letting the admin make new posts, letting anyone logged in comment on existing posts, comment moderation.
I also keep track of every page visitors are going to, saving these to the database (user agent, IP, page visited) - this will be the table that will fill up faster than any other, but might also allow me to catch eventual bots that ignore robots.txt - supposing I can figure them out.
Initially, I was planning on having each post select from a list of existing categories (category N -> N posts), but after some thought, decided against that and came up with a working alternative. Posts now have a single column where categories are manually written in, separated by commas. I later retrieve them with select distinct, explode() the string into an array and finally remove duplicates with array_unique(), making it easy for visitors, and for me, to get all the unique and valid categories.
One thing I'm doing that I'm not sure whether it's good, neutral or bad design/architecture, is using the same site that has the form to also validate/insert data, as in: instead of having newpost.php and validate_and_insert_post.php files doing separate jobs, my newpost.php is the page has the form and also receives the form in order to validate and insert into the database.
The whole thing's currently sitting at 220kb, unzipped, counting the leftover files that I'm no longer using. The fact that I can deploy this literally anywhere with a working php 8+ server without typing any terminal commands makes me very happy.
Lua figured that out back in '93, their main data structure is the table