Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
There are both closing tags present now, but I have only the front page listed (previous 6.x-0.x listed much more - haven't checked precisely, but probably all it should - addresses, as well as 5.x-1.6 does).
I have a Drupal 6.6 test site (where the previous version was working without that issue) and the latest 6.x-1.x-dev version of XML-sitemap (1.20.2.13 - 2008/11/20 10:38:35).
Development shapshots tarballs are re-created every 12 hours, so you will not be able to see any changes until Drupal doesn't recreate xmlsitemap-6.x-1.x-dev.
You report the issue has not been fixed after two hours I report it to be fixed. I would guess that after two hours Drupal HAS NOT re-created the tarball.
You marked the other issue fixed at 6:24 and this at 7:01 - the current snapshot has a time stamp of 8:17. Does that mean that if it's not fixed yet, we can complain again? I understand your point about this being a development snapshot, but this is such an important module, there's just no way to run a site without it.
I am testing the last version I uploaded on Drupal, and it works. I mean that now the ending tags are present, and a browser is able to show the site map like it appears transformed by the XSL file.
There is now the problem that the site map doesn't get populated with data, but that is another issue that still needs work (that part of code didn't get my attention, yet).
I know exactly what means to have XML Sitemap which creates problems, as I am using it on my web site; understand that porting the code from 5.x-2.x, and back is not an easy task. We are trying to synchronize different versions of the module which runs on different Drupal versions.
Kiam, don't misunderstand me, a appreciate your efforts. But I still think it is better to report all of the issues observed than be quiet and let you proceed in maybe not the right direction.
This issue (initial post) is about both incomplete sitemap AND missing closing tags, so you shall not blame me if I didn't consider it as fixed (if only one part of the issue was resolved).
What is behind (the code, what still has to be done etc.) mainly knows only a developer, so probably you can be the only one who treat this as 2 separate issues.
In any case, you are the chief, so I agree to simply close this issue, if the remaining (unresolved) part of the issue is followed somewhere else (probably in #336982: sitemap.xml is empty (except the general tags), or?). But it would help us if you clearly say it is so, so we know exactly where to follow it in the future...
And, just about my too early post - I've clearly stated in #3 that closing tags are present, as well as I've put the module version number (1.20.2.13 - 2008/11/20 10:38:35). Based on this, it should be clear to you which version I am talking about, and you could not discuss about timings, but simply said that we agree the "tags" part of this issue is resolved and that the other part is moving to #336982: sitemap.xml is empty (except the general tags) (or, somewhere else). Would make things much more simple to track... ;-)
By the way, I've just downloaded the latest version (1.20.2.14 - 2008/11/20 13:55:32) - which shall be the one you've made AFTER you've declared this issue as fixed (so in #3 I was probably referring to the same version you've considered in #1, unless there are different times set on your system and Drupal server, what may also be possible...) - and I see no differences.
If you notice, I changed the issue title, and I did for a good reason; issue reports should describe a single issue, not many not related issues. In the case, the fact the tags where not closed is caused by something different of what causes the site map to not get populated; the first was caused by a function name which has been mis-written, the second is caused by xmlsitemap_node.module not being re-written from code taken from 5.x-2.x-dev. The first issue is fixed from the code I wrote when before to change the status of this issue, the second is being resolved by re-writing the second module as planned.
Anyway, if you find the problem of the tags to still be present, fell free to re-open this issue. I have tested the code in a local server, and the site map is being presented complete.
The problem you have may be caused by Drupal (or the web server) which present a cached version of the page; the module uses a Drupal function to cache the page it outputs (this happens, i.e., also with the gss.xsl file).
On my test site the module works, but maybe it's because I uninstalled the module, and reinstalled it.
Talking about the date of the comments, I reported the issue has been fixed on November 20, 2008 - 12:01, and you replied it was not fixed on November 20, 2008 - 14:56. The time showed is based on my local time, which is CET, so you can see different times, but that is not important; the important is the difference in hour betweens the two times (which doesn't change both for me and you). You reported it was not fixed almost 3 hours later my comment; being that the case, Drupal has not updated the tarball, and you could not have had the latest tarball.
Again, no problem - tags seem to be OK since my initial post here!
About the functions, do you - as an average user - know (and/or care) about what exacly each part within your printer does, or do you simply look at it as a complete "package"? Would you be able to report 2 different issues, if you would just observe that a page is only partially printed?
I believe you shall expect much less "in depth" contributions from people not involved in the module development actively as you do. You - as the one who knows much better what is going on - should probably "come down to our level", I don't believe I am able to match yours (the doctor also discusses with me about something on a very basic and primitive level, if he wants me to understand, as I simply am not able to follow him when he discusses professionally about something... as he is probably not able, when we come to some topic from the field I am working into).
I also don't see the reason why so much discussion about times... I've reported the module version, and you could simply say it was not that one (but some other) you were considering 1 hour ago... Altough even in the version I was referring to tags were not an issue anymore, and we don't discuss about the other issue here apparently (and, which still doesn't seem to be resolved).
BTW, I am also in CET zone, so at least our times shall more or less match... :-)
To understand to report just one issue per report it's nothing technical; it's like to make a list of things: if in your list there are two items or more, than the issue report contains too much issues.
The first report said "sitemap gets truncated, and doesn't contain data". Apart that if the sitemap gets truncated, it cannot obiusly contain the data (therefore the report repeats itself), I changed the report title, and I warned to report just an issue; being the "sitemap gets truncated" the probably cause of the second issue reported, I used it like title, and proceeded to fix the issue.
Nobody pretends others must be at the level of the developers, and that is why developers reply to issue reports: to help, and make people understand what the code does, or simply how to resolve the issue, or ask esplanations to understand better the issue reported.
The discussion was born when you said (twice) that the issue was not fixed, after I declared it fixed, and after I explained/remembered that development snapshots tarballs get recreated every 12 hours.
I could have just replied that it was not the right one, but you would have not understood what I meant.
Now we can back to the important thing: the issue has been fixed; no more words are needed on this.
Comments
Comment #1
avpadernoIt has been fixed, as a result of fixing #336823: Undefined function xmlsitemap_frequency().
Comment #2
avpadernoComment #3
luti commentedThis issue doesn't seem to be fixed yet...
There are both closing tags present now, but I have only the front page listed (previous 6.x-0.x listed much more - haven't checked precisely, but probably all it should - addresses, as well as 5.x-1.6 does).
There is no error logged (nor in Drupal nor in Apache log). Missing function #336823: Undefined function xmlsitemap_frequency() doesn't seem to be an issue anymore.
I have a Drupal 6.6 test site (where the previous version was working without that issue) and the latest 6.x-1.x-dev version of XML-sitemap (1.20.2.13 - 2008/11/20 10:38:35).
Comment #4
luti commentedOooops, I've forgotten to set the issue to active...
I hope it is OK like that (to prevent this issue to be considered as fixed)
Comment #5
avpadernoDevelopment shapshots tarballs are re-created every 12 hours, so you will not be able to see any changes until Drupal doesn't recreate xmlsitemap-6.x-1.x-dev.
You report the issue has not been fixed after two hours I report it to be fixed. I would guess that after two hours Drupal HAS NOT re-created the tarball.
Comment #6
eagereyes commentedYou marked the other issue fixed at 6:24 and this at 7:01 - the current snapshot has a time stamp of 8:17. Does that mean that if it's not fixed yet, we can complain again? I understand your point about this being a development snapshot, but this is such an important module, there's just no way to run a site without it.
Comment #7
avpadernoI am testing the last version I uploaded on Drupal, and it works. I mean that now the ending tags are present, and a browser is able to show the site map like it appears transformed by the XSL file.
There is now the problem that the site map doesn't get populated with data, but that is another issue that still needs work (that part of code didn't get my attention, yet).
I know exactly what means to have XML Sitemap which creates problems, as I am using it on my web site; understand that porting the code from 5.x-2.x, and back is not an easy task. We are trying to synchronize different versions of the module which runs on different Drupal versions.
Comment #8
luti commentedKiam, don't misunderstand me, a appreciate your efforts. But I still think it is better to report all of the issues observed than be quiet and let you proceed in maybe not the right direction.
This issue (initial post) is about both incomplete sitemap AND missing closing tags, so you shall not blame me if I didn't consider it as fixed (if only one part of the issue was resolved).
What is behind (the code, what still has to be done etc.) mainly knows only a developer, so probably you can be the only one who treat this as 2 separate issues.
In any case, you are the chief, so I agree to simply close this issue, if the remaining (unresolved) part of the issue is followed somewhere else (probably in #336982: sitemap.xml is empty (except the general tags), or?). But it would help us if you clearly say it is so, so we know exactly where to follow it in the future...
And, just about my too early post - I've clearly stated in #3 that closing tags are present, as well as I've put the module version number (1.20.2.13 - 2008/11/20 10:38:35). Based on this, it should be clear to you which version I am talking about, and you could not discuss about timings, but simply said that we agree the "tags" part of this issue is resolved and that the other part is moving to #336982: sitemap.xml is empty (except the general tags) (or, somewhere else). Would make things much more simple to track... ;-)
By the way, I've just downloaded the latest version (1.20.2.14 - 2008/11/20 13:55:32) - which shall be the one you've made AFTER you've declared this issue as fixed (so in #3 I was probably referring to the same version you've considered in #1, unless there are different times set on your system and Drupal server, what may also be possible...) - and I see no differences.
Comment #9
avpadernoIf you notice, I changed the issue title, and I did for a good reason; issue reports should describe a single issue, not many not related issues. In the case, the fact the tags where not closed is caused by something different of what causes the site map to not get populated; the first was caused by a function name which has been mis-written, the second is caused by xmlsitemap_node.module not being re-written from code taken from 5.x-2.x-dev. The first issue is fixed from the code I wrote when before to change the status of this issue, the second is being resolved by re-writing the second module as planned.
Anyway, if you find the problem of the tags to still be present, fell free to re-open this issue. I have tested the code in a local server, and the site map is being presented complete.
The problem you have may be caused by Drupal (or the web server) which present a cached version of the page; the module uses a Drupal function to cache the page it outputs (this happens, i.e., also with the gss.xsl file).
On my test site the module works, but maybe it's because I uninstalled the module, and reinstalled it.
Talking about the date of the comments, I reported the issue has been fixed on November 20, 2008 - 12:01, and you replied it was not fixed on November 20, 2008 - 14:56. The time showed is based on my local time, which is CET, so you can see different times, but that is not important; the important is the difference in hour betweens the two times (which doesn't change both for me and you). You reported it was not fixed almost 3 hours later my comment; being that the case, Drupal has not updated the tarball, and you could not have had the latest tarball.
Comment #10
luti commentedAgain, no problem - tags seem to be OK since my initial post here!
About the functions, do you - as an average user - know (and/or care) about what exacly each part within your printer does, or do you simply look at it as a complete "package"? Would you be able to report 2 different issues, if you would just observe that a page is only partially printed?
I believe you shall expect much less "in depth" contributions from people not involved in the module development actively as you do. You - as the one who knows much better what is going on - should probably "come down to our level", I don't believe I am able to match yours (the doctor also discusses with me about something on a very basic and primitive level, if he wants me to understand, as I simply am not able to follow him when he discusses professionally about something... as he is probably not able, when we come to some topic from the field I am working into).
I also don't see the reason why so much discussion about times... I've reported the module version, and you could simply say it was not that one (but some other) you were considering 1 hour ago... Altough even in the version I was referring to tags were not an issue anymore, and we don't discuss about the other issue here apparently (and, which still doesn't seem to be resolved).
BTW, I am also in CET zone, so at least our times shall more or less match... :-)
Comment #11
avpadernoTo understand to report just one issue per report it's nothing technical; it's like to make a list of things: if in your list there are two items or more, than the issue report contains too much issues.
The first report said "sitemap gets truncated, and doesn't contain data". Apart that if the sitemap gets truncated, it cannot obiusly contain the data (therefore the report repeats itself), I changed the report title, and I warned to report just an issue; being the "sitemap gets truncated" the probably cause of the second issue reported, I used it like title, and proceeded to fix the issue.
Nobody pretends others must be at the level of the developers, and that is why developers reply to issue reports: to help, and make people understand what the code does, or simply how to resolve the issue, or ask esplanations to understand better the issue reported.
The discussion was born when you said (twice) that the issue was not fixed, after I declared it fixed, and after I explained/remembered that development snapshots tarballs get recreated every 12 hours.
I could have just replied that it was not the right one, but you would have not understood what I meant.
Now we can back to the important thing: the issue has been fixed; no more words are needed on this.