Thanks again for your continued help, Nikolai.

Yes, all but one (Vroom, on which a couple of 1.9 plugins still depend) of around 100 plugins has been updated. Most are by (or updated by) Matt Beckett, and most of the rest are by Coldtrick or iionly, so they come from people who know what they are doing. There are a few plugins from less experienced developers but, as far as I can tell, none of those provide or affect content types, or do anything with notifications at all: they just affect the interface. We have a catch-all plugin (again, mainly written by and updated for 1.9 by Matt) that does mess a bit with many things, including notifications (only to add a line or two to the content), so it tends to be my prime suspect when things go wrong, but disabling it before or after upgrade does not solve the problem. If it is the cause, then it already caused the problem in 1.8.

The site has been running since 2006 and, in the early 2010s after we moved to 1.x, we tried a lot of plugins over the course of a few years that we abandoned or replaced, some of which have left relics of themselves in the DB. There are also those like the Poll plugin, that has been through at least 3 significantly different versions from different developers, that have left stray bits of orphan data in the upgrade process. I don't *think* they should be harmful - they've not caused problems in 1.8 beyond a tiny number of missing posts from pre-2013, and I see no logical reason they should do so in 1.9 - but I have eliminated a lot of other options so the improbable begins to look possible. The fact that this has not (apparently) been seen by anyone else makes me strongly suspect it to be the result of one or more plugins doing something unusual.

I'm intrigued, though, by the upgrade history you shared in your first reply. Why did you always go to x.x.0 before moving to  x.x.[lastVersion]? That's something I've not tried, and neither the docs nor other advice I've seen in discussions say it is necessary.

I'd still like to know what is supposed to happen to existing notification messages during the site upgrade: whether they are meant to stay in messages or move to site notifications. Also, I don't know enough about how they are stored, and in particular whether there is anything about them that would identify them as notifications as opposed to other message types. If there were, then I could at least write a plugin that moved them out of the message inbox, and might be able to render them harmless in the process.

From the error, it appears to me that the messages in question might not be objects of the type \ElggEntity, which would explain why they have no owner, even though they do have content (the messages themselves are displayed intact) and were clearly associated with someone in 1.8 (maybe through \ElggRelationship?). The 'deleted user' message comes from mod⁩/messages⁩/views⁩/default⁩/ ⁨object⁩/messages.php and is triggered if there is no fromId in the message object that has already been identified by its toId.  I have a very vague recollection that, at some point in the distant past, we had to do something to allow non-friends to send messages to anyone (a very common use-case on our site), but I cannot for the life of me recall what it was or why it was needed. Was it/is it that messages is not meant to work between unconnected users?

My best idea for a workaround at the moment is to write a plugin that trawls through messages, identifying those without a fromId and either giving them one (no idea how yet, but it must be possible or 1.8 would not do it) or, worst case, getting rid of them altogether. If necessary, I will do that, but it would be 100% better to stop it happening in the first place!

Jon

Why did you always go to x.x.0 before moving to  x.x.[lastVersion]? That's something I've not tried, and neither the docs nor other advice I've seen in discussions say it is necessary.

Please learn this: 1, 2, 3, 4, 5

In addition, we've a lot of experience with such updates and it's the order I mentioned that works best.

I'd still like to know what is supposed to happen to existing notification messages during the site upgrade: whether they are meant to stay in messages or move to site notifications.

You may be interested in this: 1, 2, 3, 4, 5, 

Also, I don't know enough about how they are stored, and in particular whether there is anything about them that would identify them as notifications as opposed to other message types. 

Elgg 1.8 uses a function register_notification_object() to register an entity type and subtype to be eligible for notifications.

In Elgg 1.9, site notifications are separate objects: 

type: object
subtype: site_notification
class: SiteNotification

Hope this helps you.

Good luck!

Thanks again Nicolai

I've read those upgrade docs many times! I'm still puzzled about why you would want to use a potentially buggy minor release to do the upgrade than a patched one with all the fixes, but I gave it a try just in case a new bug had popped up in the more recent version. Alas, it made no difference.

Thanks for the rest too - useful to have this in one place.

I have figured out which notifications cause the problem: it's entirely coming from group notifications. In Elgg 1.8 the messages show a group icon but 1.9 needs an explicit sender. That gives me a clue about how to write a plugin to migrate/remove them, but it would still be good not to have the problem in the first place. Again, if anyone knows or can think of a way around this, please share!

Jon

Following up -

The problem is fixed. I disabled all non-bundled plugins, enabled the plugin on its own, it worked. I re-enabled the plugins and it still worked. I can't make it fail any more.

I am mystified.

The only thing I can think that it must have been is a cache issue, but caches are disabled via developer tools plugins. Unless there's a cache on the webserver, perhaps, but the server has been restarted since the problem occurred, so that seems unlikely.

Jon

RSS Import uses Simplepie library which creates cached RSS requests and stores them in the /data directory.

So...

The only thing I can think that it must have been is a cache issue, but caches are disabled via developer tools plugins

This could be the reason of your issue