The item numbers are actual ID numbers of real items loaded in the instance. I thought maybe this had something to do with our corrections plugin, but I’ve tested that and it seems to be working fine.
Finally got a little more data-it’s in the http error log and is showing up as a 404. When I try to access that link on our site, it does indeed not exist.
What’s mysterious to me is what’s trying to access this nonexistent link and why. There are very large number of these errors in the log, each with a different identifier:
It looks like something somewhere is trying to access some kind of RRS feed? The only one I’m aware of in the system is the one for search results, and that link works, and has a very different format from this link.
That’s definitely mysterious. The URLs certainly suggest something amiss with the Corrections plugin, but I can see what might be trying to hit all those URLs. Could you give a link to the site’s URL? I’d like to see what happens when I actually try those URLs. It should be an immediate error, but something odd must be happening.
Thanks. Those URLs all give a 404 Not Found, as I expected. I can only guess that a bot somewhere thinks those should be real links. The corrections plugin doesn’t try to make those URLs, so I don’t know what might think they exist. It seems like something outside of what Omeka or Corrections does.
Another oddity I noticed is that the corrections pages consistently give this:
An internal error occurred: 54F3F735E9691.A6BB593.180351AF
just before the submit button. This looks like it might be a problem with Captcha.
This problem has reared it’s head again, and I have some more data: We’ve moved to a different server environment where I have more access to error log data. I’ve been able to track exactly what’s causing this:
Omeka seems to generate RSS versions of all it’s pages by default, and links those via a tag in the header of the document. This feature does not appear to be playing well with the corrections plugin, which allows folks to submit corrections to metadata via an auto-generated form linked from each item on the site. Omeka is trying and failing to generate an RSS versions of those input forms, which makes no sense-those are not pages you’d want or need to subscribe to. Since the plugin generates a form for any and all items in our collections, that means it shows up as a lot of broken links.
Following the provided alternate link results in a 404 error.
It’s a minor annoyance, but it would be great to remove rss links from those pages so our link checking software doesn’t scream at us about having hundreds of “broken” links. I don’t see any way to control where RSS feed links get generated either in Omeka core settings or in the plugin settings. any ideas on how to fix this?
Many thanks for the additional info! That is a curious question…I’m not sure if there’s a way to tell Omeka not to try to produce the RSS/Atom link. Maaaaybe there’s a filter in there somewhere, but I don’t know what it might be. It seems possible that this could affect other plugins’ public-facing pages. @jflatnes, any thoughts?
I also see that the ReCaptcha is barfing because of the old version the plugin uses. I haven’t checked the code yet, but it’s a significant question of whether the Corrections plugin does its own thing to produce that, or whether it depends on Omeka’s ReCaptcha stuff. That looks important to distinguish on my end, and send info along to the Omeka team.
As a side-note, not only was Corrections a side-project of mine, so not officially associated with the Omeka team, but at the time I built it I was part of the Omeka dev team, and no longer am. So, that affects my allocation of time to work on it. But, I’m really quite happy to see that it is in use, and will look for time to resolve this.