Well, what Erik Frèrejean says here
is not very rational to me.
As an emergency toolkit, the stk should
be the one to try to lower the dependencies impact. To me it should first try the common.php file in use, and eventually use the untouched one optionally. Because common.php is the place to start classes that are required everywhere and it's just not thinkable nor desirable to always wrap every mods code into isset tests.
In this matter, problem finally come from uninitialized class in page_header() (since common.php was not included). To me this particular function would be a good candidate to clone (better than common.php) since the STK does only need very few of it and certainly not the mod's additions.
The clue about poor mods that could mess with STK is not very relevant, because such mods could also mess with phpBB alone, and likely too mess with the stk even if it does not load common.php.
It's funny to notice that he seems to perfectly understand the matter and its origin ("its due to some core changes we've made") and fails totally to come up with something useful to actually fix your issue.
It would have been as simple as
telling that, with the new option taken (by him) in the stk, you could have to add mod's includes into stk/common.php. No need to say that this would also be a way to provide with something useful for all mods adding includes in common.php, not only the phpBB SEO ones.
This being said, we don't pretend to change other's minds. Since this particular case can indeed be handled by isset calls (that would be a totally different story if we where talking about heavy loops), here is the commit that will close this discussion : http://phpbb-seo.coda-cola.net/projects ... isions/292