| Project: | XML sitemap |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
| Issue tags: | D7 stable release blocker |
Issue Summary
We have been having trouble getting the xmlsitemap to work in a WAMP setup. We were trying the latest beta version but it was hanging on cron so I tried the most recent dev version (as of yesterday).
I ran xmlsitemap with just one content type included to see if it would generate the sitemap. The cron no longer timed out, but I found errors like those below in the watchdog logs. The key one is the openUri error as all the other errors stem from that one.
I updated the code in xmlsitemap.xmlsitemap.inc to change:
$this->uri = xmlsitemap_sitemap_get_file($sitemap, $page);to
$this->uri = $_SERVER['DOCUMENT_ROOT'].'/'.xmlsitemap_sitemap_get_file($sitemap, $page);and then I no longer got the openUri error and the sitemap was generated properly.
Perhaps there is some system setting that needs to be set for the xmlwriter to be able to find the file properly? I do not normally develop on Windows but this site was put on Windows on the request of the client. Please let me know if you have any idea of how to update the server/settings so as to get the xmlwriter code to understand where the xmlsitemap files live.
Btw, the only post I found that may be related is: http://bugs.php.net/bug.php?id=49051
Thanks in advance for any help you may be able to provide!
Kristen
=====
Errors:
=====
XMLWriter::openUri(): Unable to resolve file path in C:\cv-svnroot\trunk\src\www-drupal\sites\all\modules\xmlsitemap\xmlsitemap.xmlsitemap.inc on line 37.
Could not open file sites/default/files/xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM/1.xml for writing. in C:\cv-svnroot\trunk\src\www-drupal\sites\all\modules\xmlsitemap\xmlsitemap.xmlsitemap.inc
XMLWriter::setIndent(): Invalid or unitialized XMLWriter object in C:\cv-svnroot\trunk\src\www-drupal\sites\all\modules\xmlsitemap\xmlsitemap.xmlsitemap.inc
Comments
#1
I've attached a patch file that we are using to get around this issue for now.
#2
Thanks for the patch.
We had the same error on a Windows / Multisite-Installation with the latest dev-Version and with 6.x-2.0-beta2
#3
I'm guessing that since this is Windows related the issue has to do with multiple drives and which drive contains the httpd/php binaries and which contains the DOCUMENT_ROOT. No one says here whether Apache or some other brand of httpd is being used. Also shouldn't the fix go to xmlsitemap_sitemap_get_file() instead of prefixing its current result?
#4
We have the problem on a installation with the apache / php binaries and DOCUMENT_ROOT on one drive.
#5
So, based on the php bug report listed by the OP this is related to PHP 5.3 and higher. It appears to be related to relative paths in the openURI() function.
[2010-06-13 01:35 UTC] dandandare at yahoo dot es
PHP Version: 5.3.1
OS Version: XP SP3 32bit
$xml->openURI('file.xml'); -> ok!
$xml->openURI('../file.xml'); -> ok!
$xml->openURI('xml/file.xml'); -> DON'T WORK!
$xml->openURI('../xml/file.xml'); -> DON'T WORK!
Don't work when you tries to access to a directory, why?
[2010-10-04 12:11 UTC] ekschperte at mysc dot de
I have the same problem...XP SP3 32bit
$xml->openURI('data/file.xml'); -> DOES NOT WORK!
The code works on 5.2.9. :-(
#6
We get the error with PHP 5.2.13, but i'll try 5.2.9 and give you a feedback
#7
thank you very much! it helped solve my problem. the links were generating, but cache file was empty, now it's working ok.
#8
I confirm the error on a Windows 2008 box. I don't tested the patch that uses the $_SERVER variable since the values of this superglobal are not entirely safe to use.
My patch uses the getcwd() function. Tested in Windows 2008 (PHP 5.2), Mac OS X (PHP 5.2) and Ubuntu 10.10 (PHP 5.3).
#9
The last submitted patch, xmlsitemap.xmlsitemap.inc_920062.patch, failed testing.
#10
Aside from the testbot issue which has nothing to do with this patch in particular, the resolution needs to go in xmlsitemap_sitemap_get_file() and not as a prefix of the return value so that anyone else deciding to use the function gets the correct results without needing to worry about it.
Is the use of getcwd correct here? The getcwd function can return false. Not to mention the fact that the CWD could change unbeknownst to xmlsitemap and cause the file to not be found.
#11
It could be in xmlsitemap_sitemap_get_file() but since just XMLWriter::openUri() needs the full path it's ok to be in the return value (fopen() in xmlsitemap_output_file() works with the relative path correctly in Windows and *Nix).
A check in the return of getcwd() is better than using directly. You're right, Drupal never changes the CWD but a contrib or custom code can change it. We can't use base_path() and (seems) Drupal does not have this data anywhere. Thoughts?
#12
subscribing (And FYI: had this problem on my dev machine: Win 7, Aquia DAMP stack, PHP 5.2.17) Patch fixed it. Yay!
#13
subscribed
#14
this patch on #8 works and fix my xmlsitemap problem on my win7pro system. many thanks.
#15
Made #1168456: openUri doesn't understand the path returned from xmlsitemap_sitemap_get_file. a duplicate of this issue.
Changed title to better suit both issues.
#16
This is my patch.
That code replace the drupal "public://" special string with the drupal_real_path()
#17
Setting for testbot review.
#18
It works on Debian testing/unstable with PHP 5.3.6. My only beef with this is a stylistic one. Why the need to create a variable? You can do this without any variable using a functional style:
<?php
function xmlsitemap_sitemap_get_file(stdClass $sitemap, $chunk = 'index') {
return drupal_realpath(xmlsitemap_get_directory($sitemap) . "/{$chunk}.xml");
}
?>
there's no need to create a variable. Just nest the calls and concatenate before calling the outer function.
#19
I agree that the variable usage is unnecessary; marking "needs work" for that reason.
#20
Ok, you'll can change the style.
Was for a better debugging.
#21
Took a look at this and discovered that I'm using trigger_error() on failure which *does not* actually stop operation of the process even though I thought ahead and added a try/catch block to generation process using XMLWriter.
Further, the only time we have to use drupal_realpath() is with XMLWriter. All other Drupal functionality should be able to handle it just fine so it doesn't make a lot of sense to have to do it from the API function.
Please test the following patch for 7.x-2.x which uses exceptions proper.
#22
I like throwing exceptions because it helps narrow where the issue really is with the call stack display. I haven't tested it since I don't have a xmlsitemap on D7 yet but this patch looks good to me.
#23
Yesterday's 6.x-2.x-dev still throws the same error, and the sitemaps are not generated (returns a 404, as per #789026: sitemap.xml returns "page not found"). I'm using it with the latest domain_xmlsitemap dev, but it still throws the error even with domain_xmlsitemap disabled.
#24
+1
#25
The patch at #21 does in fact eliminate the error in 7.x-2.x, and the sitemaps do not return a 404.
However, the sitemaps contain only one URL (the front page in the default language).#26
#25: Did you enable xmlsitemap for any content types? See the admin/structure/types and edit each content type you want to include in sitemap.xml to enable it.
#27
Yikes. Thanks earnie—I've installed and uninstalled the module so many times I'm surprised I forgot that part.
#28
Now… any chance for this fix to be backported to 6.x-2.x?
#29
Fix committed to 7.x-2.x and 6.x-2.x:
http://drupalcode.org/project/xmlsitemap.git/commit/fc45a5c
http://drupalcode.org/project/xmlsitemap.git/commit/77632d8
Everyone please give this a test if you can in about 24 hours.
#30
Problem still present in 6.x-2.x (both in beta 3 and the latest dev, which I assume are the same). When I do a sitemap regeneration, first I get
then the old
#32
7.x-2.x-beta3 works like a charm.
#33
I worked a bit on 6.x-2.x, and realized that realpath() was still returning FALSE with download method set to 'public', since the file system path is relative to the Drupal root folder. On the other hand, it works well with the download method set to 'private'.
So I added a condition by which, in case of public download method, the $uri is appended to the absolute path of the Drupal root. Maybe it's just a workaround and it can be done more elegantly (plus, I've tested it only on LAMP, thus have no idea if it would work on other kinds of servers), but it works on my side.
#34
This patch solved my problem. The sitemap could not be found. I use IIS.
#35
Since this isn't really fixed for 6.x-2.x, and no one has given feedback about my patch, I'll change the version number to this issue.
#36
I'm using version 6.x-2.0-beta3 in combination with patch #33 and it's working fine for xampp and windows. Without the patch I got exceptions and cron did not end correctly.
Thanks
#37
Hi,
I have 7.x-2.0-beta 3 and it doesn't generate a sitemap even if file permissions are double-checked and set correctly. I had the same problem when was on version 6.x-2.0-beta 3. I had to downgrade to 6.x-1.2 to have it work properly.
Both 6.x-2.0-beta 3 (on drupal 6) and 7.x-2.0-beta 3 (after I migrated to drupal 7) do not work. They both return the same error:
"Warning: XMLWriter::openUri() [xmlwriter.openuri]: SAFE MODE Restriction in effect. The script whose uid is 10003 is not allowed to access /var/www/vhosts/taxibusteni.ro/httpdocs/sites/default/files/xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM owned by uid 48 in XMLSitemapWriter->openUri() (line 40 of /var/www/vhosts/taxibusteni.ro/httpdocs/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
Warning: XMLWriter::openUri(/var/www/vhosts/taxibusteni.ro/httpdocs/sites/default/files/xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM/1.xml) [xmlwriter.openuri]: failed to open stream: Success in XMLSitemapWriter->openUri() (line 40 of /var/www/vhosts/taxibusteni.ro/httpdocs/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
Warning: XMLWriter::openUri() [xmlwriter.openuri]: xmlNewTextWriterFilename : out of memory! in XMLSitemapWriter->openUri() (line 40 of /var/www/vhosts/taxibusteni.ro/httpdocs/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
XMLSitemapGenerationException: Could not open file public://xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM/1.xml for writing. in XMLSitemapWriter->openUri() (line 42 of /var/www/vhosts/taxibusteni.ro/httpdocs/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc)."
#38
@carusen: This message is coming from your server. See http://php.net/manual/en/features.safe-mode.php and the links contained in the page for more information. This is not an issue with xmlsitemap. It also has nothing to do with the entitled subject so please in the future, if you have an issue that doesn't match exactly the subject then open a new issue. If it is a duplicate, someone will let you know. Hijacking an issue is worse than having a duplicate, IMO.
#39
Then how come older versions of the same module work? Also, I did not make any settings on the server to have it working in safe mode.
#40
I edited .htaccess to make sure php safe mode is set to turn off. Now the error message is:
Warning: XMLWriter::openUri() [xmlwriter.openuri]: Empty string as source in XMLSitemapWriter->openUri() (line 40 of /var/www/vhosts/taxibusteni.ro/httpdocs/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
XMLSitemapGenerationException: Could not open file /var/www/vhosts/taxibusteni.ro/httpdocs/sites/default/files/xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM/1.xml for writing. in XMLSitemapWriter->openUri() (line 42 of /var/www/vhosts/taxibusteni.ro/httpdocs/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
#41
Does admin/reports/status give you a clue?
#42
It just says:
"XML sitemap Cached files have not been generated yet.
The XML cached files are out of date and need to be regenerated. You can run cron manually to regenerate the sitemap files."
If i try to run cron, it crashes with the error shared in the previous post.
#43
Maybe you've done all this, but have you tried disabling and uninstalling the module(s)? If you haven't, I recommend doing that, then restarting by deleting the xmlsitemap directory and redownloading 6.x-2.x-dev and repatching it. Sometimes using a fresh copy helps.
#44
I had this issue after upgrading to 6.x-2.0-beta3 (on a test environment).
Tried patch #33 and it solved the problem --> hope this will be commited soon.
Thank you antiorario !
#45
@antiorario - i tried that multiple times. Unfortunately i now migrated to drupal 7. I cannot revert back to 6. On Drupal 6, patch #33 fixes things. Can't someone take a look at what that patch fixes and submit it to the drupal 7 release too?
This module is vital to any website. It is a pity it doesn't work. It must cause issues to many webmasters. :(
#46
@carusen I assume it's too late now to advise you never to upgrade a website without making a copy of the database and all the files first.
In any case, 7.x-2.x-beta3 and 7.x-2.x-dev already work as expected. My patch to 6.x-2.x-dev provides the necessary changes to make the D6 version work like the D7 version. The fact that you're still getting the error makes me think that something else is wrong on your installation.
I suggest you try with a clean install and see for yourself.
#47
@earnie I (and others too, I imagine) would really appreciate it if my patch were properly tested and, possibly, committed.
#48
@antiorario: Dave Reid will need to make the commit and the final decision for the properness of the patch. The comment though is a bit long and needs to be broken into multiple lines, IMO.
#49
Patch in #33 worked for me, thanks antiorario
#50
Dave the patch in #33 has been tested by community members. You need to review it and apply, please.
#51
Why do we need realpath() to run twice? Can't we just prepend './'? Also the comment is too long and needs to be wrapped at 80 characters.
#52
If I do
<?php$uri = realpath('./' . $uri);
?>
it returns FALSE, which makes my patch useless. As far as I understand, the only way to make it work is to find the real path of the Drupal root first, then find the real path of the whole directory. We could avoid running realpath() the second time for public downloads, but then we wouldn't be sure that the path is symlink-free.
#53
I stand by my patch. Here's a new one with the comment broken in two lines.
#54
Any updates?
#55
This patch worked for me on 6.x2.0-beta3. I had no idea this was crashing my production server previously every time cron was called, so thanks for the fast fix.
Also, when enabling the node piece, I can "file not found". I looked through the bug reports and see a lot of "blow off" on this error, even though everyone's rewrites are working fine and so on.
#56
Leave the Version alone.
#57
Will this be committed to dev and main soon? Thank you
#58
#53 works.
At first, only home was at sitemap, i noticed that this beta adds a "include/exclude" option, so all already created nodes need to be saved again and the content type needs to be updated also.
#59
#53 works for me!
Cheers
#60
#53 worked for me too on 6.x-2.0-beta3.
#61
#53 Doesn't work for me... :(
I still get:
warning: XMLWriter::openUri() [xmlwriter.openuri]: Unable to resolve file path in /var/www/vhosts/<mydomain>/httpdocs/sites/all/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc on line 56.user error: Could not open file ../httpdocs//var/www/vhosts/<mydomain>/httpdocs/sites/default/files/xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM/1.xml for writing. in /.../httpdocs/sites/all/modules/xmlsitemap/xmlsitemap.generate.inc on line 158.
line 56 of my xmlsitemap.xmlsitemap.inc file is:
$return = parent::openUri($uri);in the known openUri function...
#62
#53 worked for me.
#63
#64
This issue still exists in 6.x-2.0-rc1.
After applying the patch of #53 it is fixed.
#65
#53 also works for me, using 6.x-2.0-rc1
#66
The issue still exists in 7.x-2.0-rc1
#67
If the problem exists in 7.x-2.0-rc1 version which is released on 2011-Dec-16 , when can we expect the new fixed version?
#68
#69
@gridbitlabs: #53 has been reviewed and tested for version 6.x-2.x let's get that committed to the repository.
#70
#53 worked for me. Please can you release the patched module?
Windows XP, Apache (Wamp) server, PHP 5.3 (I know, 5.2 preferred)
Thanks.
#71
LEAVE THE META DATA ALONE. The patch is for 6.x-2.x-dev.
#72
@earnie: Not sure if your comment was aimed at me - but since it followed mine I assume so.
1. My post was polite and, as we were asked to respond with our test results, I did so.
2. You may be an old hand at this - I am not. There is no need to SHOUT.
3. I had no idea I was changing the META - how have I done that?
4. When I applied the patch I did what others before me had done with success (see #65, #64). If you go back further it was applied to various versions by various people (perhaps because it does not state which version it is for - unless you view the 'details')
5. I have tried to find our what is different between 6.x-2.x-dev and 6.x-2.0-rc1 (since they were released only 2 days apart) and cannot find the information. I'm not saying it isn't there - I just cannot find it.
Since it worked for others and because the patch 'fits' into 6.x-2.0-rc1 (this is currently the 'stable' version - see the project page) I don't want to introduce other instabilities if I can avoid it - hence using rc1.
If I could find out what had changed to between 6.x-2.0-rc1 and 6.x-2.x-dev I would be happier about using it and applying the patch to it. Perhaps you would advise and educate on how one goes about finding out?
Finally, my thanks to whoever is working on this. Are we any nearer to getting a released module which includes #53?
#73
I must have had to revert more than one or other parts of my life had me frustrated to the point of shouting, I do not apologize for doing so though since you'll tend to remember it now. You changed the "Version" which is a piece of meta data for the issue. The 2.0-rc1 version is a tagged and released code set based on a state of the code in VCS at the time of the release. The 2.x-dev version is an untagged code set based on the current state of the code in VCS for the branch. As for Dave's time to commit patches, he'll need to answer that.
#74
#53 worked for me, running 6.x-2.0-rc1, Windows 7, XAMPP, PHP 5.3.5.
#75
Patch #53 Reviewed and tested with 6.x-2.0-rc1. This is broken in 6.x-2.0-rc1 and will stop cron from working properly. It is a major problem if cron can't run.
#76
I confirm the problem for the version 7.x-2.0-rc1.
Any news?
#77
The patch is reviewed and tested for 6.x-2.x-dev.
#78
Earnie,
you mention that the patch is reviewed and tested for 6.x-2.x-dev and I guess it is for Drupal 6.x (as I learnt so far for Drupal modules version names scheme, but I admit I am using Drupal for just about a month), but what about those who are using Drupal 7.x?
Should we open a separate bug (I would happily do it if you say so, but I will have time only this evening CET)?
#79
Normally I would say no but in this case I'm going to say yes.
#80
Ok, I will.
Thank.
#81
I have the latest 7.x-2.0-rc2 installed and it still has the problem. Interestingly the problem doesn't occur on my local development windows copy but does on the production LAMP server.
My cron tasks won't fully complete because of the issue and the XML sitemap doesn't create any sitemaps on the server.
Here's my log:
•Warning: XMLWriter::openUri() [xmlwriter.openuri]: SAFE MODE Restriction in effect. The script whose uid is 10002 is not allowed to access /var/www/vhosts/example.com/httpdocs/sites/default/files/xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM owned by uid 48 in XMLSitemapWriter->openUri() (line 40 of /var/www/vhosts/example.com/httpdocs/sites/all/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).•Warning: XMLWriter::openUri(/var/www/vhosts/example.com/httpdocs/sites/default/files/xmlsitemap/NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM/1.xml) [xmlwriter.openuri]: failed to open stream: Success in XMLSitemapWriter->openUri() (line 40 of /var/www/vhosts/example.com/httpdocs/sites/all/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
•Warning: XMLWriter::openUri() [xmlwriter.openuri]: xmlNewTextWriterFilename : out of memory! in XMLSitemapWriter->openUri() (line 40 of /var/www/vhosts/example.com/httpdocs/sites/all/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
#82
I confirm #81
Using latest 7.x-2.0-rc2 and getting
Warning: XMLWriter::openUri() [xmlwriter.openuri]: Empty string as source in XMLSitemapWriter->openUri() (line 40 of /home/barisder/public_html/sites/all/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
PHP Version => 5.2.17
#83
See comment #79.