GitLab

The only reliable way to prevent it is a condition on the database. In postgres, we add a unique constraint on views with type = 'profile'. MySQL doesn't support this, so we do nothing.
(cherry picked from commit ac7b45c3)

Conflicts:

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

(cherry picked from commit fdb2db27)

Conflicts:

	htdocs/lib/web.php

(cherry picked from commit f73ec305)

Conflicts:

	htdocs/lang/en.utf8/mahara.php
	htdocs/lib/web.php

Old query was running count(*) thousands of times on a table. New way uses multiple queries, but at least they're all in the order of a few milliseconds.
(cherry picked from commit 18107961)

Per report in the forums from Michael Schwab:
http://mahara.org/interaction/forum/topic.php?id=893

This won't work if there's tags between the <a> and the <img> - but possibly
the regex can be tweaked to allow that. In my testing, it handles his case at
least, which should hopefully be good enough for 95% of image linking usage out
there.
(cherry picked from commit e37347e6)

This gets rid of the PluginNotificationInternal::update_notification method,
which was way overkill for what it actually needs to be. We only actually need
to update the notification if it needs to be marked as read or its URL needs to
change.

Noticed as part of the previous commit. This variable doesn't need to exist on
the object, we can just pass it around where needed.

This was happening because a variable ($userdata->internalid) was being used
for two purposes - one to hold the ID of the notification as put into the
notification table, and also to see if the notification needed to be updated
after having been inserted for any reason (either the notification was sent by
another method successfully so it needed to be marked as read, or the URL set
in the table needed to change post-insert).

The particular method this bug is in is called repeatedly in a loop, once for
each user who is getting a notification. Unfortunately, $userdata->internalid
comes from converting the object to a stdclass, and the previous internalid is
set on the class too. So if the notification didn't need to be marked as read
or have its url changed (e.g. it's a forum post notification going straight to
the activity log), then it would still be updated - this would have been
harmless, but the update would ovewrite the user who owned the notification.

Will make a few more patches to make the code more consise and limit the chance
of more damage. This problem took me hours to debug...