So I’ve been doing a bunch of updates to the FeedIron plugin over the last few months, as I’m sure anyone could guess based on the age of the plugin there is a fair bit of clean-up to be done. Currently there is an issue with POD exceptions when attempting to do background logging with log to sql set in TT-RSS config.
The logging in FeedIron is the same as the old auth_radius plugin found in the attic from pre-POD days: trigger_error($msg, E_USER_WARNING);
And using _debug() only shows on the cmd line (unless I set something up wrong)
At the moment I’m not sure if FeedIron is doing it’s logging correctly but I haven’t found any examples within the active plugins (or I am blind and missed them). Have I missed any obvious examples?
i think this happens because logger SQL adapter forces $pdo->rollback().
this is not ideal but i think it’s done this way because otherwise we wouldn’t be able to log any SQL-related errors when inside the (aborted) transaction. maybe there’s better way to implement this, i’m open to ideas.
i’ve looked over logger class and noticed that there’s a stub (logger->log(…)) which could be used for general purpose messages (including plugins) which leads to an unimplemented adapter function. i’ve fixed the implementation so this function should now be usable:
next step should be eliminating transaction-related problems. my best idea so far is using a separate database connection exclusively for logging so that rollback() wouldn’t be necessary, and log output wouldn’t mess with active PDO transactions (or depend on a successful commit):
so, in summary, plugins should now be able to use SQL logging freely, and a shortcut method which generates a E_USER_NOTICE is also available via Logger::get()->log(message, optional context).
e: additionally, something like touch() failing on a read only file is no longer going to interrupt a feed update because of a log message breaking PDO transaction. that was pretty dumb, all things considered.