The design of a structured backups module is being made complex by the structure of the existing stuff but i have found by writing down how everything communicates things become more clear.

Whenever a hook is called as a parameter it takes a variable it calls $data. $data is often used in the frontend for user information and logical actions. In effect you have multiple data variables at once, one solely used in frontend code but one which is used for all hooks that are called. Clearly it is useful for a frontend hook if it calls the variable data and receives the frontend’s $data variable (which is a reference by the way) so it the frontend data can be modified by the hook or whatever other variable was given to the hook.

The problems at the moment are that functions in the backup module seem to have little use and need replacing perhaps entirely by more structured functions to be called by other modules from the backend as a response to a call_hook. However in keeping modules structured modules should probably leave functions in other modules enitirely alone. Although this does not make sense for modules like backup which provide functionality to other modules, and since unix users is also something which perhaps provides shared functionality modules should have access to each other’s functions.

For now i will start by improving the backups_create function and initiating a commit call in the frontend code temporarily to remove the jumping around between functions. I think it is unwise to use $data as a variable in the backend code when we have something similar hanging around in the frontend code. At least i now know that $data is not actually sent to backup.php when it forks on behalf of the backend. So many variables floating around