DJVG schreef:
[...]
Ik hoop griepd maar aids is nooit uitgesloten natuurlijk
Haha
[...]
Nah is het niet geblurred, vage oude vintage pr0n. Referreres gaan ook naar allemaal vage fora waar ik mezelf niet ga inschrijven
draaiende houden kost geen kut trouwens, storage/traffic kost zo weinig tegenwoordig.
En ja voor een nieuwe site is het design voornamelijk, in al die jaren ben ik daar nog steeds beroerd in. De huidige layout (uit 2008 ) is gemaakt door Remix Design, ben z'n naam ff kwijt...
Ik wist niet dat je kon programmeren eigenlijk, Ik zal eens als ik tijd over heb een opzetje maken. Ik weet wie je bedoelt idd, wel grappig dat ook dat nog gewoon zo draait
Was wel hip in 2008
Also, instellingen pagina lijkt niet te werken (verwijst naar notities). En de link in headers van "Noities" en "Instellingen" gaan beide naar "cp/settings". urlconf dingetje?
nee instellingenpagina is gewoon nog niet gemaakt, heb maar een weekje de tijd gehad om alles te maken
WIlde iig dat de basisdingen werkte en data erin stond. De rest komt wel beetje bij beetje als ik zin/tijd heb
Also! Misschien interessant te sharen over de werking, is dit nog steeds PHP?
Ja zeker! php 8.3 inmiddels. En op het Laravel framework. Kwam ik laatst tegen, werkt echt top. Alles draait nog steeds ergens op een server van die aziaten maar geen idee waar eigenlijk
Maar inhakend op hierboven, die data was nog wel een dingetje. Tering wat een noobcode vroeger man. En dus ook idiote DB/tabellenstructuur. Echt een teringbende
. Dus alles moest worden omgegooid. Er waren gewoon varchar columns met 'ja' of 'nee' als value bijvoorbeeld
Misschien gooi ik die source nog wel op github gewoon voor de grap, kan iedereen ff mee lachen
Ook was veel data gedenormaliseerd. De tabellen met forumtopics en forumcategorieëen hadden bijv. een kolom met laatste_bericht (tekstueel) en een kolom met total_post_count enz. En ook users een kolom met post_count, etc. Maarja dat gaat allemaal out of sync lopen op den duur. Nu gewoon alles gewoon alleen relationeel. Ook de forumindex doet alles live. Met de juiste indexes duurt die query ongeveer 50ms. Best netjes als je je bedenkt dat de oude forumindex daar een paar seconden over deed, terwijl die veel data al in zijn huidige tabel had
Voor de nerds hier de query van de huidige forumindex:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<?php
public static function getAll()
{
return DB::select('
SELECT
f.id AS id,
f.name AS name,
f.crew_only AS crew_only,
f.forum_category_id AS forum_category_id,
t.topic_count AS topic_count,
(SELECT COUNT(*) FROM forum_messages m WHERE m.forum_topic_id IN (SELECT ft.id FROM forum_topics ft WHERE ft.forum_id = f.id)) AS message_count,
ft.title AS latest_topic_title,
ft.id AS latest_topic_id,
fm.id AS latest_message_id,
fm.body AS latest_message_body,
fm.user_id AS latest_message_user_id,
lu.name AS latest_message_user_name,
fm.created_at AS latest_message_created_at
FROM
forums f
JOIN (
SELECT ft.forum_id, COUNT(ft.id) AS topic_count FROM forum_topics ft GROUP BY ft.forum_id
) t ON f.id = t.forum_id
JOIN (
SELECT ft.forum_id, MAX(fm.created_at) AS latest_created_at
FROM forum_topics ft
JOIN forum_messages fm ON ft.id = fm.forum_topic_id
GROUP BY ft.forum_id
) latest_messages ON f.id = latest_messages.forum_id
JOIN forum_topics ft ON f.id = ft.forum_id
JOIN forum_messages fm ON ft.id = fm.forum_topic_id AND latest_messages.latest_created_at = fm.created_at
LEFT JOIN users lu ON fm.user_id = lu.id
');
}
Er zit overigens wel een soort bug in (reeds bekend) waardoor data kan ontbreken. 100 euro voor degene die 'm spot én kan oplossen zonder noemenswaardige performance hit
Mja, lang verhaal kort. Alles is dus eigenlijk opnieuw gemaak. Inclusief die ubb parser, die werkt nu in tegenstelling tot vroeger wel fatsoenlijk