Sorry for all the consecutive posts. But this will be my last here.

I was correct about the problem being in relation to the BBCode parser. This parser is, in some way, bugged. Where can I file a bug?

I have tried several ways of rewriting the functions that evoke the SSHTMLBBCode class methods without any resolution. I am not going to spend any more time debugging someone else's code. I have opted for HTML, as I prefer to use that in my blog over BBCode anyway. This workaround was revealed to me by the very helpful community member who replied to the question located here: http://www.silverstripe.org/blog-module-forum/show/251397.

In /blog/templates/Includes/BlogSummary.ss, I replaced

<p>$FirstParagraph</p>

... with ...

<p>$Content.FirstParagraph</p>

This circumvents invoking the FirstParagraph function in /blog/code/BlogEntry.php, which calls the BBCode parser functions. It is a workaround because I cannot use BBCode, but I prefer HTML anyways (fortunately). It will probably need to be applied to other template or includes (.ss) pages as well, if the call for BBCode-evoking functions such as FirstParagraph.

I would be very interested in discovering why the BBCode parser is acting up like this, and (apparently) only for some people. It required a lot more work to diagnose the problem than it should have, as there are no errors output by this parser, which is a real problem. Can someone please point me to where I can file a bug report? This has to do with Sapphire and the PEAR BBCode parser class; it is not related to the blog module directly.

Thanks,
Jona

@Jona: Thank you a thousand times. I'm amazed that you're gone to such lengths to find the reason to this issue.

I've had the same problem and I bypassed it. It had nothing to do with the BBCode parser. I even embarked on debugging the code (SilverStripe 2.4) with Eclipse. I've come close to pinpointing the very source of the problem. I stopped, in sapphire/core/control/Director.php (function handleRequest) at line 282 (which is the line in the "try" below)

try {
	$result = $controllerObj->handleRequest($request);
} catch(SS_HTTPResponse_Exception $responseException) {
	$result = $responseException->getResponse();
}

I suspect that $controllerObj is null or invalid or something of the kind.

I came close because I ended up using another web server package. I went from WampServer 2.2 to EasyPHP 12.0 and lo and behold, the same pages that I couldn't display with WampServer were fine with EasyPHP. With both servers running and listening on distinct ports, I could in one tab of my browser see the page that never displays in a second tab.

Please note that just changing the server solved the problem. I didn't change any files or duplicate anything. The two servers were actually running alongside, listening on different ports and serving the same files from my hard drive. So I suspect the set of controllerObj's that the Director.php code actually sees is somehow changed by the environment the code is running in. It's not just the files in your website project. It's not even just a bug in SS although what causes the issue could be taken into account in Director.php