Introduction
The purpose of this page is to give an overview of the fundamental things that need to change in the BW code.
Changes
Double user tables
We're STILL using both members and user tables - this is downright masochistic! The user table should be cut out and burned ASAP.
Password storage
Currently, passwords are stored using MySQLs password function. This is ... plain wrong. Needs to change. An MD5 hash using a salt is the way to go.
Framework
We made a huge mistake going with Platform PT back in the day. This is hampering our work. We should switch to another framework soon.
Old code vs. new code
Some features are still using old BW code - we should get all code switched to the rox codebase
Translation system
We're loading each and every translated word as a single SELECT query from the database. It's a huge resource waste, as you can easily have 50-100 of these per page load.
jy important comment:
Since the beginning the idea is to have it fetched from a memory cache, used by the MOD_WORD functions.
Currently, this doesn't produce a lot of disk access since in 99.9% of the cases the data are fetched for mysql cache. In other words, the 50-100 of these per page load are only mysql Cache. It is already in some way memory cached but this invove mysql server and cost CPU. Even if we don't have any problem with it for now, this is not to forget. The use of memcache will do miracles here.
The things to put in memcache are :
- data from words table (used on every page)
- data from translation table (used by forum for example)
- data from members trads (used on profiles relative data)
The words table is the most important
This would be half a solution. Better would be to devise a system where we can load all of the translations on a page in one go, instead of querying a cache for one word at a time. While it matters a lot where you get it from, it also matters that you don't try to get it one word at a time but all of the words for a page at a time. This would be doable with a template system for instance.
Session vars
Using the global $_SESSION variable for session variables is NOT a great idea. Furthermore, chucking everything you could ever think of into it is even worse. It would be a much better idea to work with a session object that we tell to store things and which can track changes as needed.
