Todo List
wascore
- there is someting not right with buffering the tabledefs. If an error occurs, we get FALSE instead of an array. Mmmmm....
- should this routine be moved to an acl-object? Hmmm....
- do we need a link rel="shortcut icon" type of header too?
- do we really need more meta-headers?
- is it really wise to add a base header? It interferes with the session cookie whenever you login at another URL than the base+'admin.php'... Comment it out for now
- add a 'funnel mode': disable all distracting links that could seduce the user to leave and leave locked records (eg. nodes)
- carefully check if we need more headers in html-head section of document, see AdminOutput().
- refactor/change the way the default node and area are calculated from the requested node and area. We now go the the database too often.
- we probably need to get rid of this file because it is not used (2010-12-07/PF)
- we need to take care of spurious spaces in inputs (or do we?)
- should we also require the user to delete any files associated with the area before we even consider deleting it? Or is is OK to leave the files and still delete the area. We do require that nodes are removed from the area, but that is mainly because of maintaining referential integrity. Mmmmm... Maybe that applies to the files as well, especially in a private area. Food for thought.
- since multiple tables are involved, shouldn't we use transaction/rollback/commit? Q: How well is MySQL suited for transactions? A: Mmmmm.... Which version? Which storage engine?
- should we add a paging function to the list of areas? Currently all areas are shown in a single list...
- should we make two categories: 'public' and 'private' in the list of areas? Maybe handy when there are many manu areas, but it would be inconsistend with the page manager menu which simply lists the areas in the sort order. Easy way out: the user is perfectly capable to set the sort order in such a way that the sort order already groups the public and private areas. Oh well....
- should we acknowledge the changed default to the user or is it enough to see the icon 'move'?
- should we send alerts? If so, can we use the routine to queue messages from pagemanager? A reason not to send alerts: the alerts will be sent as soon as a page is added to the new area, so why bother?
- repairing a node doesn't really belong here, in this routine. we really should have a separate 'database repair tool' for this purpose. someday we'll fix this....
- what if we need the trees of two different areas? should the static var here be an array, keyed by area_id?
- refactor into two different functions: one for specified node, other for unspecified node
- split into two separate routines, one to set the tree, another to construct the list of anchors
- how about making all nodes under embargo visible when previewing a page or at least the path from the node to display?
- should we turn to ereg() instead of a simple str_replace() for {VARIABLE} highlighting?
- 'enum' type equivalent with varchar, enum_values[] array is not used at all, only as a form of documentation
- should we allow both int and integer?
- perhaps extend this function to accept more than 2 strings?
- weigh pros and cons of persistent database connections, perhaps add as config option?
- perhaps change the possible values of $type to full strings rather than 'cryptic' single letter codes. Furthermore: what do we do with invalid dates, times and date/times? For now it is a stub, returning $value as-is. Oh well.
- document correct link for documentation of generic table definition 'tabledefs.php'
- document correct link for documentation of generic table definition 'tabledefs.php'
- find a way to deal with the enum values: where do we keep them? Or do we keep them at all?
- perhaps add postgresql in a future version
- should we do something with locking the session record from dbsession_open() until dbsession_close()? For now, the session record is not locked in any way, so the latest call gets to keep its changes Mmmm....
- should we also record the IP-address of the user in the session record? In a way this is a case of information leak, even though it is only between authenticated users. Mmmm...
- should we also require the user to delete any files associated with the area before we even consider deleting it? Or is is OK to leave the files and still delete the area. We do require that nodes are removed from the area, but that is mainly because of maintaining referential integrity. Mmmmm... Maybe that applies to the files as well, especially in a private area. Food for thought.
- since multiple tables are involved, shouldn't we use transaction/rollback/commit? Q: How well is MySQL suited for transactions? A: Mmmmm.... Which version? Which storage engine?
- if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
- we could manipulate the title attribute of input strings like "please enter a number between {MIN} and {MAX}" based on the various value properties instead of just displaying the title. oh well, for a future version, perhaps...
- we now only cater for buttons via input type="submit" without the option to visualise the accesskey. Using the button tag could solve that, but button is not defined beforde HTML 4.01. What to do?
- if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
- should we do something with an um-empty $value? If so, waht? The browser ignores this...
- if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
- if we let the hotkey from the label prevail and add it to the input tag, why add a hotkey to the label too?
- bailing out on non-array is a crude way of error handling: this needs to be fixed
- do we really want to 'leak' a link to the main site?
- a nice filter for JOB_IMAGEBROWSER and also an alternative user interface for browsing/selecting images
- should we add additional text to the address, e.g. prefix 'URL: ' or something? now it is just a plain old URL without any commments whatsoever.
- should we make the defaults in this routine configurable? (I'm not convinced they should)
- handle the related information in this dialog
- handle the related information in this dialog
- try to figure this out: when the delimiter in $name was a dot '.' $_POST contained a '_' instead. WTF? (it seems that a colon works... for now)
- how about adding a title to the items? or do we do that already?
- this list here is hardcoded: we do not expect to be adding or removing editors to/from the CMS soon. However, it might be cleaner to do this elsewhere.
- also deal with Bazaar Style Style Sheets at node level in this routine
- should we check to see if the area is empty before showing delete icon? Or is it soon enough to refuse deletion when the user already clicked the icon? I'd say the latter. For now...
- should we display trash can icons for sections with non-empty subsections? there really is no point, because we eventually will not accept deletion of sections with grandchilderen in task_node_delete. Hmmmmm..... For now I just added the condition that access is denied when a section has grandchilderen. Need to refine this, later. Also, how about readonly nodes? Surely those cannot be deleted... should it not show in the icon?
- move permission check to a separate function permission_edit_node()
- if this is a public area, the user can see every page, except the expired/embargo'ed ones should we take that into account too? I'd say that is way over the top. How about pages in an intranet where the user has view privilege? Complicated. KISS: only show preview to those that can edit or edit content.
- should we take path_info into account here too???? how about /area/aaa/node/nnn instead of /aaa/nnn???
- there is room for improvement here: the code in step 1 and step 2 is largely untested
- we need to clean up this code and properly implement the funnel mode (2009-12-18)
- should we return an error for an invalid specific language?
- should we take Apache's PATH_INFO feature into account to create friendly links?
- Perhaps this class should be merged with the UserManager class because there is a lot of overlap. Mmmmm.... maybe in a future refactoring operation.
- should we also require the user to delete any files associated with the group before we even consider deleting it? Or is is OK to leave the files and still delete the group. Food for thought.
- since multiple tables are involved, shouldn't we use transaction/rollback/commit? Q: How well is MySQL suited for transactions? A: Mmmmm.... Which version? Which storage engine?
- maybe we should find a more elegant way to check a field for uniqueness
- should we delete the datadirectory if something goes wrong?
- should we merge this with html_a() and/or rename this routine to html_href()?
- we should refactor and combine install_theme() and install_module()
- we should refactor and combine install_theme() and install_module()
- this function also 'repairs' circular references. This should move to a separate tree-repair function but for the time being it is "convenient" to have automatic repairs...
- this function also 'repairs' circular references. This should move to a separate tree-repair function but for the time being it is "convenient" to have automatic repairs...
- fix permissions for backup tool! perhaps another bit?
- should we add a paging function to the (perhaps looooong) list of languages?
- do we need a 'force lock' option to forcefully take over spurious locks?
- perhaps we can save 1 trip to the database by checking for something like UPDATE SET locked_by = $session_id WHERE (id = $id) AND ((locked_by IS NULL) OR (locked_by = $session_id)) but I don't know how many affected rows that would yield if we already had the lock and effectively nothing changes in the record. (Perhaps always update atime to force 1 affected row?)
- we need to resolve the problem of crashing browsers and locked records
- should we make this configurable and maybe log directly to syslog (with automatic logrotate) or do we want to keep this 'self-contained' (the webmaster can read the table, but not the machine's syslog)?
- should we normalize the remote_addr everywhere? We now rely on the remote_addr being equal to some stored value (in the database) but with an IPv6 address there are several possibilities to have different representations of the same address (e.g. '::dead:beef' is equivalent to ::0:dead:beef' or even '::DeAd:BeeF' or '0000:0000:0000:0000:0000:0000:DEAD:BEEF'. This problem also exists with IPv4: '127.0.0.1' is equivalent to '127.000.000.001'. *sigh*
- should we suppress the username in the laissez-passer routine? We _do_ leak the the username in an insecure email message. This does require making the laissez-passer code unique in the database (currently only username+code has to be unique and that's easy because the username itself is unique).
- should we add another 'powered by' link to '/program/about.html'?
- this routine needs some cleaning up
- should we cater for a special 'print' button + support for a special style sheet for media="print"?
- the check on '/../' is inconclusive if the $path is encoded in UTF-8: the overlong sequence 2F C0 AE 2E 2F eventually yields 2F 2E 2E 2F or '/../'. Reference: RFC3629 section 10.
- cleanup login/logout-code
- add the performance results in a HTML-comment if not CFG->debug, in sight otherwise
- we probably need to get rid of this file because it is not used (2010-12-07/PF)
- we probably need to get rid of this file because it is not used (2010-12-07/PF)
- should we pass the area_id at all? What happens when a node is moved to another area without informing the module? Questions, questions, questions...
- should we pass the area_id at all? What happens when a node is moved to another area without informing the module? Questions, questions, questions...
- what if the module is not found? Currently no alternative is loaded but FALSE is returned.
- should we sanitise the modulename here? It is not user input, but it comes from the modules table in the database. However, if a module name would contain sequences of "../" we might be in trouble
- should we sanitise the modulename here? It is not user input, but it comes from the modules table in the database. However, if a module name would contain sequences of "../" we might be in trouble
- we probably need to get rid of this file because it is not used (2010-12-07/PF)
- maybe we should get rid of this $PERFORMANCE object, because it doesn't do that much anyway
- we should also take the readonly flag into account (or should we?) when determining delete permissions
- should we change the code to accomodate the canonical newline CRLF in the input?
- maybe optimise this routine to let pure ASCII-words through unencoded (in a later version)
- how about UTF-8 hostnames? Mmmm...
- should we check for overlong UTF-8 encodings: C0 AF C0 AE C0 AE C0 AF equates to /../ or is that dealt with already by filtering on letters/digits and embedded dots/dashes/underscores?
- fix the crude error check on dialogdef === FALSE here
- there is something wrong with embargo: should we check starting at parent or at node? this is not clear: it depends on basic/advanced and whether the embargo field changed. mmmm... safe choice: start at node_id for the time being
- this routine could be improved by refactoring it; it is too long!
- should we bring the Capi-Tali-Sation of $name in line with the default capitalisation in the list above?
- This routine is way too long, it should be split up into smaller subroutines
- it is a pity I cannot reference $this->sort from within the 6 cmp-functions...
- should we allow for fancy selection mechanisms on the logfile or is that over the top?
- should we display trash can icons for sections with non-empty subsections in treeview? there really is no point, because we eventually will not accept deletion of sections with grandchilderen. Hmmmmm.....
- the check on permissions can be improved (is PERMISSION_XXXX_EDIT_NODE enough?)
- there is an issue with redirecting to another site: officially the url should be fully qualified (ie. $CFG->www). I use the shorthand, possibly without scheme and hostname ($CFG->www_short). This might pose a problem with picky browsers. See calculate_uri_shortcuts for more information.
- about 'sort_order': do we insert nodes at the end or the beginning of a parent section?
- how do we alert users that an embargo date has come around? Do we schedule alerts via cron?
- should we massage the directory and file names of the included theme?
- what if the theme is not found? Currently no alternative is loaded but FALSE is returned.
- Should we take care of the race condition in this routine? Should we already create an empty file or is that clutter?
- maybe extend this routine to actually store more statistics information in a separate table
- Perhaps this class should be merged with the GroupManager class because there is a lot of overlap. Mmmmm.... maybe in a future refactoring operation.
- should we also require the user to delete any files associated with the user before we even consider deleting it? Or is is OK to leave the files and still delete the user. Food for thought.
- since multiple tables are involved, shouldn't we use transaction/rollback/commit? Q: How well is MySQL suited for transactions? A: Mmmmm.... Which version? Which storage engine?
- maybe it is better to call this routine with $user_id as a parameter? that allows for moving vrom adduser() -> savenew() -> edituser($user_id). Mmmm, food for thought
- maybe we should find a more elegant way to check a field for uniqueness
- shouldn't we end with the edit-user dialog rather than the users overview? that might make more sense...
- the check on '/../' is inconclusive if the $path is encoded in UTF-8: the overlong sequence 2F C0 AE 2E 2F eventually yields 2F 2E 2E 2F or '/../'. Reference: RFC3629 section 10.
- maybe use MIME for sending alert if not 7bit message?
- This routine is quite *nix-centric. I'm not sure how this would work other server platforms. Should we do something about that?
- should we handle the option of a better compression level (eg. level 9) in gzcompress()? we could check to see if CMF equals 0x78 and FLG is either 0x01, 0x5E, 0x9C or 0xDA the latter 4 values might have an effect on general purpose bit flag bits 2 and 3. for now we'll just keep it simple, but there might be a little something to improve here.
- should we handle the possibility of an additional 4 bytes for DICTID (RFC1950, reference [2])?
wasinstall
- add more tests, e.g. for gd, safe_mode, memory limit, etc.
- get rid of the $wizard kludge!
- should we append an underscore to the userpaths to make sure we don't clash with the first user account?
- should we check the program version versus the stored program version here?
- there is something wrong with the default for $cms_www; FIXME (commented out for now)
- should we promote language and high_visibility to function parameters instead of using $_SESSION directly?
- how prevent third party-access to install.php after initial install? .htaccess? !exists(../config.php)?
- we should make sure that autosession is disabled in php.ini, otherwise was won't work
- we should make sure that register globals is off
- we should make sure that we can actually set cookies (necessary when logging in).
- should we save the config.php to the datadir if the main dir fails? Mmmm.... security implications?
- this routine badly needs refactoring
- also take safe_mode into account? Should that be a requirement for succesfull installation?
- can we suppress even more fields here in case of a Standard installation?
- more tests to perform here: safe mode, memory limit, processing time limit, register globals
- automatically create appropriate sequence name for serial fields??? or add seqdefs too?
- should we make the filemode (hardcoded at 0400) configurable/customisable?
wasmod_htmlpage
- change this stub into a real cron function.
- change this stub into a real search function, with limits on the number of results, an offset where to start and perhaps even a time limit. for now this always returns an empty array
Documentation generated on Wed, 11 May 2011 23:45:49 +0200 by phpDocumentor 1.4.0