Category: The Bug Genie 3.0

Non-apache love

As a small heads up for those of you who don’t use Apache, I’d like to bring your attention to our library of rewrite rules. We are often asked by users for help setting up URL Rewriting (which The Bug Genie 3 requires) with their server, and this post is there to point out what documentation we have.

Just right now, documentation for IIS 7 and later was added, meaning we now cover the most popular platforms. However are work is not yet done, with documentation for IIS 6 still unwritten (IIS 6 docs now out!), and apparently issues with the nginx one; on top of no doubt other servers that you wonderful users want to use The Bug Genie on (let us know if there is one you need!) Regardless, we currently support:

  • Apache (auto-generated by the installer)
  • IIS 6 (Windows Server 2003 and 2003 R2)
  • IIS 7 and later (so Vista/WS2008 and Windows 7/WS2008R2)
  • Nginx
  • Lighttpd

Further documentation, as well as the above (except Apache) can always be found in the Recipes section of our documentation.

Debugging The Bug Genie

After talking to many of you, it seems like your missing some good debugging features in The Bug Genie to try and figure out how to solve issues when things go wrong.

The Bug Genie ships in “normal mode”, which means only some of the logging feature and none of our debugging features are enabled. You can see the log in action if things go wrong – it will be shown below the “please report this issue” button. In addition to this, we also have a debugging mode, available if you switch it on inside the TBGContext class. If you’re familiar with PHP, this file is located in core/classes/TBGContext.class.php, and the property you want to change is located around line 34, and called $debug_mode. If you change its value to true, all your pages will now show the debug bar at the bottom.

The Bug Genie debug bar

The debug bar gives you information about:

  • The current route: The Bug Genie uses a routing-enabled MVC framework. The debug bar will tell you which route is currently being accessed
  • How long the page took to load: This includes several other timing details, like how long each template and template partial took to load. Click the time to see more information
  • The current scope: The Bug Genie is built to run on multiple servers in multiple “scopes”, where each scopes lives separate from eachother. This feature has not been completed yet, and as such there is no way to use this yet. It is, however shown in the debug bar.
  • Database information: The database information area shows you the number of database queries performed in this request, including how long it took. Clicking the database information area brings up the SQL log, which lists all SQL statements, including how long each statement took. The statements are numbered, so you can find them again in the full log.
  • Full log: To the far right is the “toggle log messages” link, which will toggle the complete log when clicked. This log includes all information messages, notices and warnings generated by The Bug Genie, including timing information, potential errors and detailed information about the system as it runs.

As you can see, there is much information available for debugging The Bug Genie should something go wrong. We’re using these features all the time, and are continually improving them. One of the things we will add is information about the current configuration in use, which can help us find and solve even more issues.

Do you have comments or suggestions for how we can improve? Let us know!

Status update

So, last three weeks have been pretty busy, with the release of the 3.0 final version, the first bugfix update, and everything that follows with that.

We’ve had a lot more to do than usual – many more people to talk to, several people volunteering to do stuff here and there, and we’ve even managed to get a few people to write up some wiki articles!

We’ve more than tripled website traffic since the release (some days it’s 5x higher than “normal”), and both the forums and our live chat is more active than ever. We’re currently hard at work fixing issues being reported in our tracker, as well as constantly adding new stuff to our new website. We’ve integrated the v3 wiki into our new website (howto coming up), added a few more pages here and there, and in general tried to add more content to the wiki. If you haven’t visited there the last week, you should head over there right now 🙂

We’re not sure whether to go with 3.0.2 for the next update, or go 3.1. The next update will require an update process, so going for a point release might not be such a bad idea. One issue with that is that point releases often bring much new stuff with it, and so far we don’t have that much (host-less configuration – no more “the bug genie isn’t set up for this hostname”, and article commenting are the only two real new features so far), and we will be doing a lot of bugfixing as well. Oh well, time will tell.

PHP optimizers and The Bug Genie – revisited

As we are seeing more issues with php optimizers interfering with the core functionality of The Bug Genie, we’d like to post a little clarification.

First of all, we do not have an issue with optimizers. They exist for a reason, and we will do our best to not have our code break when optimizers are used – for whatever reason issues may occur ( phpinfo() can confirm if you are using an optimizer – look for “eaccellerator” or “optimizer”).

However – and this is important – not all optimization techniques are valid, and not all optimization techniques are non-intrusive. One of the techniques used by php optimizers (e.g. eaccellerator) is to remove php docblocks before the php compilation step. This optimization “feature” is highly controversial, and it is intruding on a core php feature – php docblocks are a part of the php language. Removing php docblocks will cause applications to malfunction.

There are several php projects other than The Bug Genie already relying on this php language feature (the ability to read php docblocks at runtime):

  • Doctrine 2
  • Zend Framework
  • PHPUnit

To read more about this “optimization” technique controversy, I recommend having a look at these two links:
http://wildlyinaccurate.com/eaccelerator-and-doctrine-2/
http://blog.feryn.eu/2010/12/zend_soap_autodiscover-eaccelerator-causes-trouble/

The last blog post also contains information on how to disable this particular eaccellerator “feature” for certain files, and how to disable eaccellerator php docblock removal completely.

Unfortunately, we cannot do anything about this issue, as it is out of our control.

Version 3.0 issues and solutions

There have been a few issues reported with the installation and usage of the 3.0 version released recently. Most of the issues that have not been related to an issue in The Bug Genie itself relates to one of the two following system issues:

  • Outdated pcre (perl-compatible regular expressions) libraries
    On most platforms, PHP does not ship with its own set of pcre libraries, but will use system libraries where available. We’ve seen a number of issues where users trying to install The Bug Genie 3.0 on systems with outdated pcre libraries are experiencing problems with core functionality. These issues will be triggered by the regular expression searches in geshi (our included syntax highlighter) and in our own wiki parser. If you see errors regarding regular expressions, make sure you are using pcre libraries version >= 8.0 (f.ex.: some CentOS and RedHat server seems to ship with 2006 version 6.x, which will not work).
  • PHP optimizers
    Some servers are running PHP with optimizer modules such as the zend optimizer. One of the optimizing techniques used by the zend optimizer is to remove comments inside php files before they are compiled and ran on the server. Because The Bug Genie depends on docblock metadata for some operations, this kind of optimization will cause The Bug Genie to malfunction. This error can be noticed if you get error messages about missing class definition for foreign properties. The error also sometimes manifests itself as errors about trying to call methods on non-objects.

None of these errors are something we can fix. If you’re experiencing weird errors like the ones above, please try and disable any php optimizers running on your server, and / or update your pcre libraries, then try again.

The Bug Genie 3.0 Final RC

Just minutes ago, we uploaded what we hope is the final Release Candidate to our sourceforge.net download area. A huge number of issues has been fixed from RC1 -> RC4, and just RC3 -> RC4 has seen over 50 bugfixes and changes.

Luckily, most of the changes were minor and really not all that “important” from a functionality point of view – but we’ve put all our effort into making the 3.0 release a top-quality release. We’ve been using it on .com since RC3, and so far it has outdone even our most ambitious expectations. Stable, (relatively) fast and a lot easier to use than our 2.1 tracker, the 3.0 release has shaped up to be what we all hoped it would: A top-notch, more polished than ever release. Unfortunately, we haven’t been able to keep our promise about non-backwards-compatible changes between the RCs. To be sure that you’re running smoothly, please contact us for information on how to upgrade your installations, wait for the separate news item, or pop by the live chat. We’re here to help.

On a related note, we’ve received well over 200 bug reports and enhancement requests since we started publishing the release candidates, and the testing effort done by our dedicated testing team has been outstanding (more on that in a separate news item)!

The Release Candidate we’ve put up now – RC4 – is good to go. Really – this should be stable enough to release as a final version. Prove us right.