currently log_clear & dblog_clear duplicates functionality
dblog_clear is just a rewrite of log_clear to additionally support dblog_filters (which relies on dblog_ext)
if dblog_ext is not used, then dblog_clear behaves exactly the same as log_clear
if any sub-module of dblog_filters is used then log_clear won't behave properly (it doesn't supports dblog_ext),
which is the reason for dblog_clear to exists
these two module should be merged
I named dblog_clear after log_clear, but using the more clear prefix for the dblog_* suit
Comments
Comment #1
nancydruActually, I think we just need properly document dblog_ext for the project page, including that DC and LC are mutually exclusive. I do have a site where I use LC, but not any of the dblog_ext functions. Also LC is available on D5, so it would be nice to be forward-compatible.
Comment #2
arhak commenteddblog_cleardoesn't requiresdblog_extprecisely it is a rewrite of
log_clearI renamed it to
dblog_*for consistency with the other dblog modules.please, consider it a whole proposed patch for current
log_clear(the only extra code would be supporting
dblog_extin case it is detected)the only reason it depends on
dblog_commonis for using the auxiliary functiondblog_common_format_minutes(thedblog_commonmodule was intended just to gather auxiliary function, like human-readable format of minutes)PS: for 5.x the proposed changes for
log_clearwould be some CSS changes (for consistency with core) and auser_accesscheck to enable the clear button (which should be handled on separated issues, but those would be backport of this one if DC & LC get merged)if #582622: provide hook for dblog_filters gets committed for 7.x
dblog_clearwould be the upgrade path forlog_clearanywayComment #3
arhak commentedalso, dblog_ext/dblog_filters might be backported to 5.x, but, since D7 is already there..
Comment #4
nancydruThe project page already lists 5.x as frozen.
Comment #5
nancydruI removed log_clear from the package.