I just replied on this in the French speaking section : http://www.phpbb-seo.com/fr/premod-phpb ... tml#p48084
Short version : While the stk is a great idea to begin with, some questionable design choices have been made since 1.03 (The problem with STK
). IMHO, there are two proper ways to design such a tool :
- Dev from scratch, do not use any phpBB code. This may result in a simpler interface and a higher need to protect it independently from phpBB, but it should never fail, even without any phpBB files
- Fully integrate it with phpBB, with the risk to see it fail when phpBB would be corrupted. This was the option before 1.0.3 and worked with any mod as long as these mod where not destroying phpBB
Problem is, they have chosen an in between way which result in stk failing with valid mods (your example, even if, read bellow, there is actually no relation with our code and this failure, it's a genuine unmodified phpBB function call to be problematic).
To me, this "c" option makes absolutely no sense (sorry), it can work of course, but there is need to very carefully pick in phpBB's code since it can be modified by mods (and really, do you know any user needing the stk with no mods installed ?).
Coming back to the original thread where your issue was reported (http://www.phpbb.com/customise/db/offic ... r_-t_88162
), you can see that at first, the error really has nothing to do with phpBB SEO (we never use utf8_case_fold_nfkc being the only function to call utf_normalizer::nfkc).
This error comes from the fact phpBB attempts to support both php4 and php5. Early php5 version did not complain about static call to methods that where not explicitly declared as static (doing this would break php4 compat). Later ones started to issue a strict notice to warn the user about good php5 coding practice. And yes, this is a notice, not a blocking error.
phpBB itself does handle this situation and this is why you never see this "error" with phpBB. Now the stk uses a custom error handler which does not properly address this matter (while phpBB's own error handler does perfectly).
Reading further this thread, you can see that this was later "fixed" in the stk, but as a matter of fact, it must not have been a real fix, but rather a work around (like not using utf8_case_fold_nfkc at all in the stk), because then we discover that this exact same issue (blocking strict notice) happens on boards using our code.
This time, the "guilty" call is utf_normalizer::nfc called from utf8_normalize_nfc, and indeed used by our code. Since it's the exact same matter as the previous, it's a proof that the original matter was not actually fixed. This error was introduced by a deficient error handler, deficient in the sense that it's really not consistent to use part of phpBB in stk if your code is not able to actually handle it, which is the case here.
I frankly have nothing against the stk and phpBB in general (actually it's the opposite), but I'm kind of tired to see us blamed for choices that weren't ours and that actually do not have any relation to us or our code. This is a pure stk/phpBB inconsistency, period.
Now in practice, why did you want to use the stk in the first place ? what was the problem you where trying to solve ?
Is there any chances that the stk could provide with a more detailed error message if you try the same operation with phpBB's debug activated