Postponed
Project:
XML sitemap
Version:
6.x-2.x-dev
Component:
xmlsitemap.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
5 Jun 2009 at 02:30 UTC
Updated:
14 Mar 2017 at 23:48 UTC
Jump to comment: Most recent
Comments
Comment #1
dave reidThe base code for this feature has been implemented using:
Maybe I should also create a new gz stream using gzopen() and write to both fopen() and gzopen() at the same time. Or give people the option of which one. I'll need to modify the code in xmlsitemap.pages.inc as well to account for the new file. It'll probably have to do something similar to drupal_page_cache_header() that will un-gzip if the current client cannot accept gz-encoded data.
Comment #2
oscarm22 commentedHi Dave,
Has this changed been implemented? I do not see it in the latest version.
Comment #3
cj-a-min commentedI've noticed this feature is commented out in the module. Probably for good reason, ie experimental.
I noticed that even when uncommenting and enabling this feature, it still doesn't create the additional gz. But, that's no problem because I can do my own script to create the gz after cron.
Ok, so now after autocreating them individually (48 of them over 2.4 million nodes) and enabling gzip_static, nginx has no effect (at least on nginx 1.2.6) on serving these gz files, ie sitemap.xml.gz, 1.xml.gz, etc. It serves the original sitemap.xml instead.
So, it seems unless there is a way for the xmlsitemap module to generate a static path to the xml, I don't see how creating an additional gz version will provide any benefit.
Just fyi. The way it was tested was by adding a test line in sitemap.xml, gzipping it to sitemap.xml.gz, undoing the test line in sitemap.xml, and opening it up in browser, ie example.com/sitemap.xml and seeing if test line was there. It wasn't. However, when accessing the file directly, example.com/files/sitemap/my-site-map-location/sitemap.xml, the test line was there.