EPrints Technical Mailing List Archive
See the EPrints wiki for instructions on how to join this mailing list and related information.
Message: #10411
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
Re: [EP-tech] sitemap generation in EPrints
- To: David R Newman <drn@ecs.soton.ac.uk>, "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>
- Subject: Re: [EP-tech] sitemap generation in EPrints
- From: Tomasz Neugebauer <Tomasz.Neugebauer@concordia.ca>
- Date: Tue, 11 Aug 2026 14:51:16 +0000
|
CAUTION: This e-mail originated outside the University of Southampton.
Hi David,
Thanks for the detailed answer!
The reason I was concerned about the sitemap is that it is out there in the open, so I've become cautious about giving bots access to a request URL that is dynamic and computationally resource heavy, requiring a lot of CPU / RAM / database queries to complete
each and every time it is requested. The "id/dump" part of the sitemap seems to fall in that category. What is it for? When I ask for it, the server takes a long time to dump out a whole bunch of IDs. If we can't rationalize why it's there, then it shouldn't
be there, for everyone, by default, with the only way to override being changing EPrints core perl apache module code. Having said that, in the meantime, I appreciate knowing that is what I need to do. What about those other parts of the sitemap (id/repository
and id/subject), are they also dynamic and computationally resource heavy? Are they needed if a sitemap is being generated with generate_sitemap script?
Tomasz
________________________________________________
Tomasz Neugebauer
Tel. / Tél. 514-848-2424 ext. / poste 7738
Mailing address / adresse postale: 1455 De Maisonneuve Blvd. W., LB-540-03, Montreal, Quebec H3G 1M8 library.concordia.ca
From: David R Newman <drn@ecs.soton.ac.uk>
Sent: August 11, 2026 2:59 AM To: eprints-tech@ecs.soton.ac.uk <eprints-tech@ecs.soton.ac.uk>; Tomasz Neugebauer <Tomasz.Neugebauer@concordia.ca> Subject: Re: [EP-tech] sitemap generation in EPrints Attention This email originates from outside the concordia.ca domain. // Ce courriel provient de l'extérieur du domaine de concordia.ca Hi Tomasz, sitemap-sc.xml is very much a legacy thing, which was implemented well before my time. I have been loathed to remove it, in case it served some important purpose for which I was unaware. Feel free to add Apache configuration that sits above EPrints to either 404 this or maybe just redirect to sitemap.xml. If you want to add this as an issue on GitHub [1], then we can consider what should be done about sitemap-sc.xml and maybe also access to /id/dump. I wrote the generate_sitemap script. Originally, this was just for EPrints repositories I helped maintain. I then rolled this into the main codebase [1] at a later point, when I had seen it was useful. In particular, using it on Google's search admin console to make sure publications in EPrints were as indexed as comprehensively as possible. I agree that use generate_sitemap could be better documented, (i.e. you need to setup a cron job for the sitemap to be generated / regularly regenerated). As it grew quite organically, there was not a tipping point where I thought this is now standard functionality and therefore needs to be documented as such. I will look into updating the wiki in suitable places. You made an allusion to customisation. I was not sure if that was just a reference to sitemap-sc.xml and removing /id/dump or if you wanted to be able to also customise sitemap.xml, as you wanted links other than to abstract pages in your sitemap. If it is the former, then I think unfortunately, you would need to edit perl_lib/EPrints/Apache/SiteMap.pm either in place or a copy in site_lib/plugins/ to remove /id/dump. If it is the latter, as sitemap.xml links to secondary files to avoid having more than 1000 entries per file, (as preferred by Google's search admin console), then it would not be too difficult to customise to get the script to detect a file called something like extra.xml. You could then maintain your additional sitemap links in this file (under the archive's cfg/static/sitemaps/ directory) and this would be made available with the numbered sitemap files. I would be happy to create a GitHub issue to look into such customisation. Regards David Newman
[1] https://github.com/eprints/eprints3.4 On 10/08/2026 22:04, Tomasz Neugebauer wrote:
|
- Follow-Ups:
- Re: [EP-tech] sitemap generation in EPrints
- From: David R Newman <drn@ecs.soton.ac.uk>
- Re: [EP-tech] sitemap generation in EPrints
- References:
- [EP-tech] sitemap generation in EPrints
- From: Tomasz Neugebauer <Tomasz.Neugebauer@concordia.ca>
- Re: [EP-tech] sitemap generation in EPrints
- From: David R Newman <drn@ecs.soton.ac.uk>
- [EP-tech] sitemap generation in EPrints
- Prev by Date: Re: [EP-tech] sitemap generation in EPrints
- Next by Date: Re: [EP-tech] sitemap generation in EPrints
- Previous by thread: Re: [EP-tech] sitemap generation in EPrints
- Next by thread: Re: [EP-tech] sitemap generation in EPrints
- Index(es):
