ianstormtaylor
commented
10 years ago Nice, thanks for all that info. I think we can leave this one out for now, since I haven't heard any users ask us about it. I think for these kinds of more "logging" things we usually recommend against using us. I could see a user-facing use of it in the future, which would then make it something that could be tracked with us, but let's cut scope here for now.
astorm
So, this one is a little complicated, and I need a judgment call on whether we want to include these features.
There's a few Magento error pages that fall outside the normal request/response flow, which means adding that standard bit of tracking code with an event listener doesn't work for them. I dropped a extra-error-pages.mp4 screencast in our shared dropbox, and this article I wrote about the problem should be enough context.
The main challenge here is these pages are displayed without a fully loaded and bootstrapped Magento (depending on how they're pulled in and/or when an exception is thrown) This means they don't have full loaded configuration information, or a standard instantiated database object. It's possible to work around this (see above code checking), but the result is a lot of extra code, some of it less than elegant, and much of it duplicating functionality in Magento.
I'm reasonably confidant the solution I've coded is robust and functional — but I know you've had problems with less than elegant code from contractors in the past. From my point of view having Segment track these pages is a major win -- right now there's not a lot of visibility into these errors and having Segment report of them is a win. However, because of the code gymnastics involved, I'm not sure if it's worth it to you to have this feature here.
Thoughts?