Our media library has been flooded with duplicate event images as well…
@ravanh In order to investigate what might cause this behaviour, could you maybe share the WordPress version you have been using and the Mobilizon group/instance you have been mirroring.
Have all these duplicated posts been really linking to the same event with the same UUID (the part after mobilizon.instance.tld/events/<uuid>)?
Hi André, sorry for following up so late.
The WP version is 6.2.3 linking to mobilizon groups monnaie_libre_ardeche, linux07, mobilisation_resiliente_et_adaptation_en_nord_ardeche et resiliere_en_nord_ardeche on the instance https://mobilizon.linux07.fr
Have all these duplicated posts been really linking to the same event with the same UUID (the part after mobilizon.instance.tld/events/<uuid>)?
Yes, you can see it happening on a test installation on https://larena.infini.fr/events/ (please allow time to load the page, it’s a very low resource server)
Any way to debug this?
Seems like https://codeberg.org/linos/mobilizon-mirror/src/commit/a09fe0661a8ea41c3d88dec8bb2c9c2b97990263/includes/class-mobilizon-mirror-api.php#L354 is not returning all posts on your website.
But at the moment I can think of why, and sadly I don’t have any time to test and debug this further at the moment. I would start by writing some log information during the sync-cycles, this could help to see where things go wrong.
Well, it’s not so much that the number of posts returned is not correct (maybe it is, I have not verified) but the number of posts created is incorrect. They are almost all duplicates of the same two events, from june 12 and juli 10….
I’mm guessing the fetching of events starts at the API method refresh_mobilizon_events? But how do so many duplicates get in there and why are they not pruned in update_mobilizon_events?
Somehow they are getting different UUIDs. Strange…
I notice the post type is hidden in the admin. Is there a way to delete these posts manually?
To edit the mirrored events in the admin user interface, you can change this: https://codeberg.org/linos/mobilizon-mirror/src/commit/a09fe0661a8ea41c3d88dec8bb2c9c2b97990263/includes/class-mobilizon-mirror-post_types.php#L349
Note that I have been working on a v2.0.0 which also had duplication issues. See the alpha releases: https://codeberg.org/linos/mobilizon-mirror/releases
Short summary of what happens and had been the error back then:
The information which events are already mirrored gets stored in a transient called mobilizon_mirror_cached_events_list (like a cache): it is an array which holds information about the mobilizon event UUID, the last known updatedAt and the WordPress post id. In case this transient gets lost it is regenerated in the get_local_mobilizon_events() function. We had the problem that this get_local_mobilizon_events() only returned a finite number of the already mirrored events: like the first page of a pagination. So all events that were on the latter pages got mirrored again.
Another point of failure is the update_mobilizon_events() function. There it does deletions, updates and new creations. Note that if any changes have been made during the sync, the transient gets regenerated by calling the get_local_mobilizon_events() again. So the issue kind of must be there. Or your mobilizon events always come in with a new UUID.
With that limited info it is really hard to debug but my first guesses would be some other code messing with the queries. I see that you are using some heavy plugins like Jetpack and Elementor on that site, where especially the latter is messing a lot with the WP internals.
Also it seems you are using a Redis Cache which might be messing with the transients and cause a version of the issue hinted at above.
I guess to be able to properly debug this disable Redis and all plugins. Check if the issues goes away and if yes then re-enable them one by one to see when it reappears.
OK, thanks for the suggestions! I’ll let you know if I find anything useful 🙂
