[wp-hackers] Cron Improvements and Error Logging

[Robert Deaton]

Mark Jaquith and I had some discussion on IRC tonights about some
thoughts I've been mediating on for a while, and so I've finally
formalized a list of various stuff I'm going to code, hopefully for
inclusion into WordPress (it'll be coded regardless). The first one is
a GUI for the new cron code (this will go in a plugin if it doesn't
make the core), the second is an error logger (and a generic db table
for logging information, this is shooting for core inclusion as it
requires some mods that plugins just can't do). Here's a quick and
dirty outline of my ideas, I'm looking for constructive criticism,
improvements on ideas, and maybe even downplaying the ideas if you can
provide some other argument than "I don't like it". In case this gets
screwed up in the mail, plaintext doc is
http://somethingunpredictable.com/tmp/ideas.txt

Cron
	Ensure future publishing works
	Finalize API
	Clean up code
	Work on GUI:
		The GUI should have a list of the currently scheduled hooks, which includes:
			-A short description of what they do
			-The last time it ran
			-The next time its scheduled to run
			-A link to remove non-essential crons (Future posting shouldn't be removed)
		The GUI should allow you to schedule hooks to be run by:
			-Showing a table of the possible events that can be scheduled, with
descriptions of what they are,
			recommended running times, and a link to schedule that hook
			-The page to schedule should remind the user what they're
scheduling, provide a dropdown list of how
			often to schedule this event (perhaps, since its such a simplistic
form, we could find a way to
			integrate this into the table, up for thoughts)
		The GUI should recommend a few of the default actions to run,
specifically the cleanup cron
		should be run on a regular basis, things like spam purging and
backup are pretty important as well.
		We should have a few base crons:
			1) Backup. (recommended)
			2) Publish E-mail Posts. (put under recommended if this has been
set up, add links to scheduling it
			from the options page on this.
			3) Check for updates (When the new plugin manager is integrated,
this could fire
			occasionally to see if there is a WP or plugin update.
			4) Check for blogroll/link updates
			5) A generalized cleanup cron that should include:
				Purging spam
				Ensuring that the post and comment counts are correct
				Repair/Optimize MySQL tables
				Clear the error log (see below)
		Obviously, the whole thing must be pluggable, the GUI itself may end
up in a plugin if it doesn't make the core
Error logging
	Make the formal $wpdb->log table schema, which should be a table
suitable enough for generic logging by
	other plugins, brainstorm:
		log_id
		log_type (error for the error logger)
		log_subtype (subtype for the actual logger to store its type)
		log_data (a big text or blob for whatever data the logger needs to store)
		log_message (to log the error message)
		log_count (the count of number of times this error has occured)
		log_date_gmt (the last occurance of an error)
	Obviously, for plugins, these fields could be unused depending on purposes.
	For error logging, the log_subtype should include SQL for SQL errors,
PHP for PHP Warnings (notices, stricts
	are too frequent to log in the WP codebase), 404s (I believe these
should be logged by default). log_data could
	be a serialized object or array of all the data, file, line, etc.,
and a constant for developers could make the
	logging code store var_dumps and backtraceswhere necessary.
	This whole thing is API'd out for custom log types and messages that
plugins can display in the viewer.
	The viewer could potentially, as part of the messages, recommend
fixes or links to documentation on the problems.
	We move most of the nasty die()s and such to calling trigger_error so
that these problems can be logged and
	dealt with properly.



--
--Robert Deaton
http://somethingunpredictable.com