Thanks for the quick fix

I wonder how we could possibly improve testing process. We have lots of unit tests already, but I wonder if smb tested how much of actual code they cover? Should be doable with xDebug. This would help to find places that possibly require writing some additional tests.

Also question, about nightly builds, are they tested automatically, or they're simply extracted from repository to zip packages and that's it?

We could even think of making separate list on trac with tasks for writing specific tests and prioritize it properly.

Evan is working on Travis integration for 1.9: https://travis-ci.org/Elgg/Elgg

That will open up a lot of doors for better (read: "some") automated testing, though we will have to actually write tests at some point.

That would be really nice. As it tests even pull requests.

Testing without writing tests make little sense, that's why I'd like to make current tests coverage analysis to than look at not covered parts and think what should be tested first or to enhance existing tests. I'll look into it in free time if noone did it already?

We have little coverage in PHPUnit because the goal, I think, is to refactor and keep the new test suite free of code that's too tightly coupled or which has hidden dependencies, which is a lot of Elgg today.

Of course, Travis can support a DB, so at some level it may be worth translating existing tests over just so Travis can take over more responsibility.

In the short term it would be Really Nice if the test suite ran on its own DB/dataroot (or at least on separately prefixed tables and a nested dataroot). 

I forget to mention, functional tests that actually log in and do various interactions could help catch bugs like this one. No one is going to walk through every single operation possible in Elgg when testing PRs, but we could have WebTestCases run through a bunch of them in seconds.

Another option: make a better effort on testing. Make a chart of operations to test whenever some set of files are changed.

I think manual testing is not an optin in the end. We'd need to test most features on 3 access levels (admin/user logged in/logged out) and even hoping to cover core plugin functionalities with manual testing seems like not viable option.

We might do sort of compromise solution by using i.e. Selenium and making some chart of operations necessary to run saved tests. It may be useful in situations where it would be too complex to write WebTestCases.

I also think that we maybe need some sampe installation as reference for testing to make tests simplier and cover testing of existing data manipulation (ex. upgrades between versions). So it would be kind of core installation with all core plugins enabled and filled in with some data for every plugin

Elgg 1.8.9

Elgg 1.8.11

 Some performance figures.... 1.8.11 gives us up to 10% more speed ... nice work team :))))

@Tom ~10% matches what I saw on my test server, though I expected more by the number of queries reduced.

When there are two tabs open if the user logs in again and reload the page the session is still open