CUNY Academic Commons

Looking at the database, it appears that all three of these nav menu items were added (or at least last-modified) by your user (post_author 1) and have the same timestamp, 2023-12-11 17:40:16. Do you recall doing any modification to the nav menu on this day? The fact that they share an exact timestamp suggests to me that they were not created by hand, but were copied from somewhere else as part of a script.

Doing a bit more digging, the two nav other nav items ("Course Group (Private)" and "Syllabus") have _wp_old_date entries in postmeta. WP adds this postmeta when the item is being updated and the post_date field is changed. But the nav item corresponding to the 'CUNY Homepage' link doesn't have any such entry, which suggests that it didn't exist prior to 2023-12-11 17:40:16. Matt, does this match your recollection of how the site was originally configured?

I did a brief search around to see whether I could identify any plugin or customization that might be responsible for inserting nav menu items, but I didn't see anything obvious. If we wanted to pursue this, my next step would probably be to write a tool that looks through every site to find those that have a 'CUNY Homepage' item. This might provide some hints as to what's happening. But before I do that, maybe Ray has some ideas about what might have happened, or how we can investigate.

The kinfrastructures2.commons.gc.cuny.edu was cloned from kinfrastructures.commons.gc.cuny.edu. So I checked to see if the original site had the "CUNY Homepage" link and the original site does not have that link.

I wanted to check the access logs to see if a user could have done some type of bulk management in the admin dashboard, but it seems that I am not able to navigate to the access logs directory with my SSH account anymore. Boone, do you have access to the logs? If so, perhaps you can verify if the menu items were modified on the kinfrastructures2 site on December 11th.

Good idea, Ray - this will help narrow things down.

I don't have access to the log directories either. I'll open a ticket to see if we can get it restored.

Thank you both very much for your work on this.

Looking at the database, it appears that all three of these nav menu items were added (or at least last-modified) by your user (post_author 1) and have the same timestamp, 2023-12-11 17:40:16. Do you recall doing any modification to the nav menu on this day? The fact that they share an exact timestamp suggests to me that they were not created by hand, but were copied from somewhere else as part of a script.

I don't remember making changes on that day, but I can't say it's a certainty that I did not make a change. I really don't think I would have had a reason to change the nav bar at the very end of the semester.

Doing a bit more digging, the two nav other nav items ("Course Group (Private)" and "Syllabus") have _wp_old_date entries in postmeta. WP adds this postmeta when the item is being updated and the post_date field is changed. But the nav item corresponding to the 'CUNY Homepage' link doesn't have any such entry, which suggests that it didn't exist prior to 2023-12-11 17:40:16. Matt, does this match your recollection of how the site was originally configured?

Yes, that matches my recollection. I have no memory of seeing this link in the nav bar before now, and I don't believe I put it there.

Thanks again for digging into this.

Unfortunately, our Apache logs don't go back far enough.

I wrote a tool that checks all site in the network for nav_menu_item entries with the post_title 'CUNY Homepage'. Your site https://kinfrastructures2.commons.gc.cuny.edu is the only one on the entire network that has it. So it's very likely not the case that it was copied from some other site, as part of a botched clone or something like that.

Another thought that came to mind is that someone performed an import into the existing site. This could happen, for example, if someone was doing some work on a local version, and then imported back to the production version. Any chance that something like this might have happened?

Given that we don't have the logs necessary for further analysis, no other site seems to be affected, and no other damage ("damage"?) appears to be done to your site, I think we might be at the end of the analysis we can easily do.