this needs a stylesheet change but is coming up in the dom.

can also be used for when you upload a new file, I guess

they generate activity

so we can bounce the user back over mnet with a better url

Makes it more obvious that you always have access to your views.

the forums.

Related to 7084335d06491cf0a028f45315838d56e4c8f4f8 on 1.0_STABLE but
reworked as the profileicon artefact is now handled by 'file'.

Conflicts:

	htdocs/lib/db/upgrade.php
	htdocs/lib/version.php

Red background means that links shouldn't be green. Red/green colour
blindness is common etc. etc...

created.

This function is now designed to be called just once - on installation
and on upgrade - rather than every time a user needs a new profile view.

This takes the load off the upgrade process, and removes the need for a
user creation event to create them. The cost is that the first time the
user profile page is visited, the view is copied. But the process is
pretty quick for just one view.

The process of copying profile views takes ages. Furthermore, the View
class appears to have some memory leaks that mean the upgrade soon runs
out of memory (tested on a ~2000 user site, the 64M limit is reached
reasonably soon).

After this, the upgrade finishes in a few seconds, rather than waiting
over a minute before dying (on test site).

message when inviting users to groups.

Side effect of the performance work done previously.

I'm not sure if this is the right place to include the lib but it works.

being installed.

Previously, we checked for table_exists, but that means we need DDL
which is very heavy. Now we check by catching the exception and ignoring
it if the system isn't installed.

Now no longer counts SET NAMES 'utf8' as a write. This means most pages
show as doing no writes, which is correct. 0 writes showed up as blank
in the footer, so tweaked the code appropriately.

This ensures the db type is set correctly for adodb when it goes looking
for a driver. It used to work fine, until we stopped including ddl on
every page.