Cron Improvements and Error Logging

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

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

        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_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

wp-hackers mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: Cron Improvements and Error Logging

Andy Skelton
On 3/9/06, Robert Deaton <[hidden email]> wrote:
> 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

Cron: I like the idea as a plugin but I would not force such a complex
thing as that into software I would encourage my mother to use. I hate
answering her questions with "ignore that feature. It's not for you."
That's not to say I wouldn't value such a thing myself. if you wrote
that plugin I would use it personally.

Logging: interesting. Not my cup of tea, but certainly useful to many.
I think if you kept it to critical problems, such as might cause a
person to show up at the forums, it could be worthwhile. However,
adding an error log viewer to the admin interface doesn't fly in my
mind, and you don't want to expose this kind of log to public access.

The beginnings of a simple solution for core:
function wp_log_error($level = 1) {
 if ($level >= WP_LOG_LEVEL)
  do_action('log_error', func_get_args());
Then go through the code and find all the places where you have your
ugly die() calls and call this instead. I don't know what else you'd
want core to do with errors besides make them available to plugins and
maybe standardize its error messages.

Not that fatal errors are a problem for anyone other than devs or
people installing plugins or themes, but I did have a method of nice
fatal error reporting: ob_start, output the error message, try the
action, ob_end_clean. A fatal error in the middle will flush the
buffered error message to the browser.

wp-hackers mailing list
[hidden email]