« first day (2026 days earlier)      last day (2926 days later) » 

7:14 AM
@Howdy_McGee why? nothing much happens in between, just, well, plugins load :)
 
 
6 hours later…
1:18 PM
@kraftner What happened to the MeetUp? Is SEO such a big topic? Seems to me like SEO can fill a stadium …
 
SEO is the easy path to attract shitloads of people to a meetup.
We still have issues finding people to speak, topics they are willing to talk about as well as other people are interested in. SEO always worked. Sigh.
 
 
1 hour later…
2:34 PM
@Rarst I wanted to register a shutdown function before the plugins loaded to catch anything that may go awry so I put it in a plugin assuming I could run the muplugins_loaded hook but now realize it's silly, because my plugin has to load to get to the hook and will be too late.
I think in the end ima package a MU file and just move it to the MU directory when my plugin updates / installs
 
shutdown is way way late, why does early timing matter? anyway you can make a plugin that always loads first. Laps does that.
 
As in, do_action( 'shutdown' ) or registering my own shutdown function is way late? I'm trying to catch plugins that may fail on install ( causing anything fatal ) so I figure I need to register my own shutdown function before any plugins are loaded - I.E. MU
Or maybe I misunderstand how the shutdown functionality works.
 
I am not sure if shutdown fires on fatal... it might, but would have to test
anyway if you want to be right after mu-plugins do what Laps does
 
sounds like any plugin that does anything that might fail during plugin code load should not be used ;)
 
2:49 PM
I agree but some of our non-hosted install plugins willy-nilly and we have to manage them :(
 
why not to trust the error log?
 
Well the idea is that should a plugin fatally error on install - it would send me or one of the devs an email that sending went wrong.
 
in theory (going to absurd here) a plugin can remove everything hooked on shutdown
install or boot?
 
Right, but if you register you own I think it may be fine, right?
Well - update has to technically re-install it, right?
 
you are right
 
2:53 PM
why don't you just register error handler instead of shutdown? that would be more reliable and granualr
 
+1
or hook on the upgrade process
if possible for that, not sure myself
 
@Rarst are you referring to this? That seems better than what I'm currently doing, didn't realize it existed
 
anuther problem with active sites is that you might be floaded with messages
 
yeah
there are remote services that collect and aggregate logs, though I hadn't reason to use any myself
 
I think that you should monitor error log in any case, and that will be also a solution to this probem
 
2:59 PM
@MarkKaplun Yeah, we keep logs on for all our sites but the shutdown is just to get a devs attention that something went wrong. A file is created to act as a flag which must be removed upon inspection so they don't get spammed with tons of emails.
All in all it ties back into a monitoring system so we can manage / view it all in one location.
Granted, could have used a remote service for all that but then I wouldn't have learned anything :)
 
so now I double wonder what is that you are trying to do, just because a plugin loads doesn't mean it actually works
and errors you get in any case
 
Well, I'm specifically looking for fatal errors with the register function
Even some fatal errors don't bring down a site though so I've seen false positives from time to time but usually get a chance to report them to the plugin dev.
WP Mailto links just had one that they patched
 
but isn't it reported in the error log, or does WP hides the exceptions?
 
It is but we don't get emails don't get generated from it - so we would have to manually go to each error log to even see if something went wrong ( or a call from a client ).
It's preemptive
 
IMO you should get an email for each error. I am sure there are linux tools that do that. I don't see why critical error is more important after plugin upgrade then in any other time ;)
 
3:11 PM
I feel like if we were to get emails for each error we would get flood with small potatoes. Especially things we don't necessarily have control over like a plugin not verifying an index exists before using it.
If there is a critical error with a plugin we can at least take measures at that point to debug / deactivate it and let the author know - keeps the website up and running ( assuming it's not a critical plugin like Woo or something ).
 
just email conditional on error level
 
I think that's the best solution IMO - thanks for the suggestion
 
in previous life I worked on similar tools. Not floading with emails is kinda basic
if you are hosting on rackspace you should probably use newrelic
 
 
1 hour later…
4:28 PM
Nick Craver on May 3, 2016
The third in a long series of posts on Stack Overflow’s architecture explaining how we deploy code.
 

« first day (2026 days earlier)      last day (2926 days later) »