XML Sitemap Port to 6.x (HEAD)

This module is actively being developed. I woudn't expect a Drupal 6 update until one of two things happens. 1) Drupal 6 is released as RC or Full 2) someone produces a patch for testing.

aplologies, The above should read actively being developed for Drupal 5. There was a new release as recent as yesterday.

@Darren: Are you working on this task? XMLSitemap is the only outstanding module i need for D6 production... what is the estimated time lane?

Re-commenting since drupal 6.0 is out now. Really need this module. When will it be ready ? Thank you for this module.

Very good module!

Only: I want it in D6 What is now the state of it? Developping, or won't????

Tnx,

Thom

Willing to help test if this patch is made. Thanks :)

Now testing...

Bug found:

----------------------------------------------------------------------------------------------------------------------------------------------------------

Line 11, Column 5: element "body" undefined .

✉

You have used the element named above in your document, but the document type you are using does not define an element of that name. This error is often caused by:

* incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Frameset" document type to get the "" element),
* by using vendor proprietary extensions such as "" or "" (this is usually fixed by using CSS to achieve the desired effect instead).
* by using upper-case tags in XHTML (in XHTML attributes and elements must be all lower-case).

--------------------------------------------------------------------------------------------------------------------------------------------------------------

Ok,

Thom

Ok,

Thanks,

Thom

Any hope that someone who knows PHP is going to get this to work???

This is one of the most important modules to getting traffic to your site - without it - you may as well not install Drupal 6

I don't use this module, but I stumbled over this thread and thought I'd help out, using schema isn't as difficult as it looks!

xmlsitemap.install

<?php
// $Id: xmlsitemap.install,v 1.4 2007/12/11 22:57:45 darrenoh Exp $

/**
 * Implementation of hook_schema().
 */
function xmlsitemap_schema() {
  $schema['xmlsitemap_additional'] = array(
    'description' => t('Stores the sitemap for the XMLSiteMap module.'),
    'fields' => array(
      'path' => array('type' => 'varchar', 'length' => 128, 'not null' => TRUE, 'default' => ''),
      'pid' => array('type' => 'int'),
      'last_changed' => array('type' => 'int'),
      'previously_changed' => array('type' => 'int'),
      'priority' => array('type' => 'float'),
    ),
    'primary key' => array('path'),
  );
  return $schema;
}

/**
 * Implementation of hook_install().
 */
function xmlsitemap_install() {
  drupal_install_schema('xmlsitemap');
  db_query("DELETE FROM {url_alias} WHERE dst LIKE 'sitemap%.xml'");
}

/**
 * Implementation of hook_enable().
 */
function xmlsitemap_enable() {
  global $base_path;
  $xsl = file_get_contents(drupal_get_path('module', 'xmlsitemap') .'/gss/gss.xsl');

  $css_start = strpos($xsl, '<link href="') + strlen('<link href="');
  $css_length = strpos($xsl, '" type="text/css" rel="stylesheet"/>') - $css_start;
  $xsl = substr_replace($xsl, $base_path . drupal_get_path('module', 'xmlsitemap') .'/gss/gss.css', $css_start, $css_length);

  $js_start = strpos($xsl, '<script src="') + strlen('<script src="');
  $js_length = strpos($xsl, '"></script>') - $js_start;
  $xsl = substr_replace($xsl, $base_path . drupal_get_path('module', 'xmlsitemap') .'/gss/gss.js', $js_start, $js_length);

  if (file_check_directory(($path = file_directory_path() .'/xmlsitemap'), FILE_CREATE_DIRECTORY)) {
    file_save_data($xsl, "$path/gss.xsl", FILE_EXISTS_REPLACE);
  }
}

/**
 * Implementation of hook_disable().
 */
function xmlsitemap_disable() {
  $path = file_directory_path() .'/xmlsitemap';
  if ($dir = @opendir($path)) {
    while (($file = readdir($dir)) !== FALSE) {
      if ($file != '.' && $file != '..') {
        unlink("$path/$file");
      }
    }
    closedir($dir);
    rmdir($path);
  }
}

/**
 * Implementation of hook_uninstall().
 */
function xmlsitemap_uninstall() {
  drupal_uninstall_schema('xmlsitemap');
  db_query("DELETE FROM {variable} WHERE name LIKE 'xmlsitemap_%'");
  cache_clear_all('variables', 'cache');
}

Note that I've no idea about whether the enable/ disable code works alright - I just know how to pass a schema test ;o) I haven't done anything with the module other than to make sure the db tables install correctly. If you've already installed the module before then you'll need to uninstall it before you reinstall it to recreate the db tables. This is normal behaviour with Drupal modules.

Pobster

Here is my patch. As good as everything is converted, but there is only an issue with displaying everything :).

The admin/settings/xmlsitemap/additional link works fine, but all the others give this error:
Fatal error: Unsupported operand types in /var/vhosts/www.denraf.be/htdocs/includes/common.inc on line 1265

grep -n ' url(' xmlsitemap.xml saids,
753: $result = url($path, $alias, array(), $path_language);

This may cause 'Unsupported Operand Types in Code in common.inc:1265' with blank page.
Because of changing url() in drupal6, It should be changed to fit new api like;

753: $result = url($path, array('query' => $alias, 'absolute' => $path_language));

It also seems be good practice change common.inc:1265; url()
from
$option += array(...) ;
to
$option = array_merge($option, ....);

If module is under porting to Drupal 6, this change helps developers of 3rd party module to find a problem
forgetting replacement of url();

Just to note, take a look at my hook_uninstall above - perhaps you could re-post your patch with the url fix and flushing the variables cache as well.

edit: I've just noticed that you've made a mistake in hook_menu as well with access arguments. Perhaps this is why your links are failing?

You need to specify access and access arguments correctly, change these lines;

   $access_config = user_access('administer site configuration');
   $access_content = user_access('access content');

To;

   $access_config = array('administer site configuration');
   $access_content = array('access content');

And then format the menu item access like this;

  $items['sitemap.xml'] = array(
    'title' => t('Site map index'),
    'page callback' => '_xmlsitemap_output',
    'type' => MENU_CALLBACK,
    'access callback' => 'user_access',
    'access arguments' => $access_content,  // or obviously just use array('access content') and lose the vars above
  );

Pobster

DenRaf,

Your patch cause error on PostgreSQL backend.
Because 'MAX(column)' returns NULL if no value exist in the column.

pg_query() [<a href='function.pg-query'>function.pg-query</a>]: Query failed: ERROR: null value in column &quot;pid&quot; violates not-null constraint： /var/www/osm/includes/database.pgsql.inc on line 138.

query: INSERT INTO xmlsitemap_node (nid, pid, last_changed, last_comment, previous_comment) SELECT n.nid, MAX(ua.pid), n.changed, s.last_comment_timestamp, MAX(c.timestamp) FROM node n LEFT JOIN node_comment_statistics s ON s.nid = n.nid LEFT OUTER JOIN comments c ON c.nid = n.nid AND c.timestamp &lt; s.last_comment_timestamp LEFT JOIN xmlsitemap_node xn ON xn.nid = n.nid LEFT JOIN url_alias ua ON ua.src = 'node/' || n.nid WHERE xn.nid IS NULL GROUP BY n.nid, n.changed, s.last_comment_timestamp ： /var/www/osm/sites/all/modules/xmlsitemap/xmlsitemap_node/xmlsitemap_node.module on line 387.

please remove NOT NULL constrains for columns; 'pid' and 'previous_comment' .

@miurahr: cannot find this in the patch code. looks like a different bug. please open a new case for this pgsql bug.

Thx for the reactions.

As you can see I applied a new patch, and updated to the status to "code needs review". For me everything works now.

The changes suggested by miurahr did the trick for the administration pages, while pobster suggestions made the access to the sitemap.xml possible.

(The changes suggested by miurahr for the common.inc are not applied.)

The error from miurahr should also be solved now. @hass, this error was caused by the null settings in the xmlsitemap_node.install file, so it was for this patch. :)

Update: the url's listed in the sitemap are correct now. As you can see in the patch, I just disabled the url function part, and now everything seems working just fine.
Here is the link of my drupal 6.1 blog sitemap: http://www.denraf.be/sitemap.xml

I'm not sure, but isn't head not older then 5.x-1.4? I think there are some changes that are not in HEAD, so patching against 1.4 makes more sense...

1. You don't need to specify + 'access callback' => 'user_access', in menu. This is the default function called.
2. title and description in menu's shouldn't be surrounded by t().
3. Why are you removing the weight? - '#weight' => -1,
4. code style... 2 blanks... not only "one"

-        return $base . $path .'?'. $query . $fragment;
+       return $base . $path .'?'. $query . $fragment;

5. About custom_url_rewrite changes see http://drupal.org/node/114774#custom-url-rewrite
6. i would disable or remove i18n module parts. I'm not sure, but they are no more used as i think - and there is no i18n module yet.

if (module_exists('i18n')) {
     i18n_get_lang_prefix($result, TRUE);
   }

7. +version = 6.x-1.0-dev should be +version = 6.x-1.x-dev
8. Why have you added so many AS to the sql statements? We should focus on the upgrade only... not fixing such minor sql style issues.

-      FROM {node} n
-      LEFT JOIN {node_comment_statistics} s ON s.nid = n.nid";
+      FROM {node} AS n
+      LEFT JOIN {node_comment_statistics} AS s ON s.nid = n.nid";

9. removed code like 'disp-with' => 11,. This has been added by MySQL Query and is not related to the schema.

Have you run coder.module to validate code and schema.module to verify schema consistency. Very helpful!

k, check new patch.

disp-with was a suggestion of the schema module, since the orginal create table query used int(11).

It ain't that much work to just add the AS when you go through the code ...

1. Help texts should be surrounded with t()

-      return t('Configure behavior for search engines.');
+      return 'Configure behavior for search engines.';
-      return t('Set up additional links for your site map.');
+      return 'Set up additional links for your site map.';

2. You are killing translatable strings... this is wrong (only a few examples) inside forms. Only remove t() from menu, watchdog texts

-    '#title' => t('Submission settings'),
+    '#title' => 'Submission settings',

-  $header = array(t('Delete'), t('Path'), t('Priority'));
+  $header = array('Delete', 'Path', 'Priority');

-    drupal_set_message(t('Unable to load site map. Make sure that there is an xmlsitemap directory in your files directory and that it is writable by Drupal.'), 'error');
+    drupal_set_message('Unable to load site map. Make sure that there is an xmlsitemap directory in your files directory and that it is writable by Drupal.', 'error');

3. why are you breaking?

-  if (function_exists('custom_url_rewrite')) {
-    $result = custom_url_rewrite('alias', $result, $path);
-  }

4. Please rollback your "AS" changes in SQL. It is hard enough to review such a big patch and we should split this to have an extra patch that applies to D5 branch, too. Focus on the D6 upgrade only, please.

hass: for the custom_url_rewrite look at post #3 and #5. Just took that.

New patch attached.

1. Why are you deleting - '#weight' => -1,?

2. Wrong:

-        '#title' => t('Submission URL'),
+        '#title' => 'Submission URL',

3. a few bug examples

 -    SELECT xa.*, ua.dst AS alias FROM {xmlsitemap_additional} xa
+    SELECT xa.*, ua.dst alias FROM {xmlsitemap_additional} xa

-      SELECT n.nid, n.type, n.promote, s.comment_count, n.changed, xn.previously_changed, s.last_comment_timestamp, xn.previous_comment, xn.priority_override, ua.dst AS alias
+      SELECT n.nid, n.type, n.promote, s.comment_count, n.changed, xn.previously_changed, s.last_comment_timestamp, xn.previous_comment, xn.priority_override, ua.dst alias

Please reviewing your own patch before posting. Needs work.

- Fixed queries
- #weight tags are back in place
- most of the t() - tags fixed.

Against which release where those patches diffed? I tried applying them to xmlsitemap 6.x-0.x-dev and xmlsitemap 5.x-1.0 (both from Nov 9, 2007), but they always failed at one point.

I'd be happy to apply them against a version from CVS too, but which one should I check out?

/cvs/drupal-contrib/* is HEAD.

I made the patch against this cvs checkout:

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d xmlsitemap contributions/modules/xmlsitemap

then apply patch:

patch -p0 -d xmlsitemap < /path/to/patch

Please don't set your own patch RTBC. Aside custom_url_rewrite need to be fixed first.

hi,
i made a 6.1 compatible edition by combile xmlsitemap-6.x-0.x-dev.tar.gz and drupal6_7.patch from this thread.
it works fine on drupal 6.1.

but it still not compatible to i18n module as it create aliase to the default language only.

see sitemap demo: http://www.yingyudaxue.com/sitemap.xml

Please check this new patch

- use of custom_url_rewrite_outbound

I did nothing, I just applyed DenRaf's drupal6_8.patch
Works nice - sitemap.xml urls are pathauto urls now (http://www.drupalrs.com/sitemap.xml)

Have someone verified this patch with "domain name" and "path" language switching and if the results are correct, yet?

i tested galeksic's patched edition with "domain name" on one production site that has i18n module enabled, still not working.
as described above, it create alias to default language only.
it should work on sites that does not have multilingual content.

Let me say - i18n module is not required for testing this in D6... domain name and path language switching is build in D6 core.

Undefined index: type in sites\all\modules\xmlsitemap\xmlsitemap_node\xmlsitemap_node.module in Line 166.

@hass: could you tell me when you had that error, cause I'm unable to reproduce that.

for alexcnhz: does the translation work in the menu and settings pages?

D6 code should be E_ALL compliant. See "Testing for error notices" at http://drupal.org/node/34341

With the new patch I don't get any errors anymore on E_ALL level. Please test the new patch.

Some update from #46:
1. Fix the patch creation, so can use "patch -p0" for apply patch.
2. Code cleanup with coder and code-clean.sh.

Patch reroll via cvs HEAD. Function without error message.

Hello I am using the latest patch "xmlsitemap-HEAD-0.2.patch" applied to the cvs version. Everything installed ok and I was updating the user settings and I receive this error.

warning: Missing argument 3 for _xmlsitemap_user_submit(), called in /home/nexgenwe/public_html/gen/includes/form.inc on line 759 and defined in /home/nexgenwe/public_html/gen/sites/all/modules/xmlsitemap/xmlsitemap_user/xmlsitemap_user.module on line 131.

Update***

I just tried to create a new user and I got these errors..

* user warning: Column 'pid' cannot be null query: INSERT INTO xmlsitemap_user (uid, pid, last_changed, priority_override) VALUES (4, NULL, 1207003850, NULL) in /home/nexgenwe/public_html/gen/sites/all/modules/xmlsitemap/xmlsitemap_user/xmlsitemap_user.module on line 206.
* warning: array_fill() [function.array-fill]: Number of elements must be positive in /home/nexgenwe/public_html/gen/includes/database.inc on line 235.
* warning: implode() [function.implode]: Invalid arguments passed in /home/nexgenwe/public_html/gen/includes/database.inc on line 235.
* warning: array_keys() [function.array-keys]: The first argument should be an array in /home/nexgenwe/public_html/gen/modules/user/user.module on line 500.
* user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 query: SELECT p.perm FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in /home/nexgenwe/public_html/gen/modules/user/user.module on line 500.

The problem is very simple: the translate of schema from D5 to D6 is not correct, and come with some extra parameters, e.g. "not null", "unsigned", etc.

Patch update via latest CVS HEAD. Test with disable -> uninstall all xmlsitemap* modules, and reinstall all. Please try the case of #48 and report if bug still reproduce.

I'm using Drupal 6.1 and downloaded xmlsitemap 5.x. I patched it with drupal6_9.patch and installed it. It's working great for me. thanks.

Maybe review the patch and release an updated version of xml sitemap? Would be cool for us noobs..

I patched the CVS version with xmlsitemap-HEAD-0.3.patch (#49) and everything works fine!
I'm using xmlsitemap, xmlsitemap node, and xmlsitemap term.

I think it's time for a dev version.

Some minor coding style update.

Not sure whether this is an issue with drupal 6.x or a generic problem, but my site is multi-lingual.
The sitemap.xml only shows the language of the last edited page, i.e. if I edit a page in french all sitemap.xml
urls are in french and no english/german, then if I edit an english page then sitemap.xml shows just the english pages

That's what i asked for in #42:

1. If you are using domain name based language negotiation you should only get French nodes at "example.fr", "example.es" only Spanish nodes, etc.
2. If you are using path for negotiation, i think you should get all nodes in all languages.
3. For no language negotiation, you should get all, too.

I'm using path for negotiation and I only get the language that I last edited. :-(

Can somebody please post a dev version? I have been trying for days to get patch working with no avail and the version seems to be dev quality by now. Thanks!

Apply the patch against HEAD

The patch applied fine for me and everything seems to work well on 6.1.
Just one point--it only applies to HEAD if you check the module out of CVS. If you download it as a package then one hunk fails (presumably because the packager has inserted a timestamp and changed the .info file).

Okay, so before I was getting the package download. However, downloading the CVS head is still giving me trouble. I am using

patch xmlsitemap.module xmlsitemap.patch

and all the hunks are failing.. Am I missing anything? I read throughly the patch in windows tutorial and couldn't find anything that I am doing incorrectly..
Thanks

patch -p0 < file.patch

Im using patch for windows and that does not work

I tried the --p 0 but that didn't help

@anonimicer: Seems this is not a task review or bug report of this issue, and you may ask in mailing list or IRC. Anyway, give a look to here: http://drupal.org/patch/apply

For people who are unable to apply the patch here is the version I am using ( patch 0.4)

I'm a bit confused, by your comment on #42.
As far as I can see the sitemap.xml should not be using the local stuff in drupal core - otherwise how do you submit sitemaps?
I could see that using http://www.saafpureskincare.com/fr/sitemap.xml and submitting that could work, but if we translate to say 10 languages then that would mean that we would have to submit it 10 times - assuming that google etc. etc. allow 10 sitemaps.
http://www.saafpureskincare.com/fr/sitemap.xml
http://www.saafpureskincare.com/de/sitemap.xml
http://www.saafpureskincare.com/pl/sitemap.xml
http://www.saafpureskincare.com/es/sitemap.xml
etc. etc.

Also http://www.saafpureskincare.com/fr/sitemap.xml doesn't work as it just gives the same as http://www.saafpureskincare.com/sitemap.xml

IMHO the sitemap.xml should contain ALL languages, as they are effectively different nodes.
The strange thing is it's current behaviour, the fact that it doesn't default to the default language as was specified, but to the last language used when editing a page.

Should I raise a separate bug report for this guys?

Cheers,

Malc

I'm very sure the current patch is not working with multilingual websites. So testing for bug freeness in such a case makes *no* sense...

1. If you have domain based detection
1a. http://www.example.fr/sitemap.xml should ONLY give you content marked as French
1b. http://www.example.es/sitemap.xml should ONLY give you content marked as Spanish
1c. http://www.example.de/sitemap.xml should ONLY give you content marked as German
1d. sitemap.xml must contain all url's with full qualified domain name - language specific.

2. If you have path based detection
2a. http://www.example.com/sitemap.xml should return ALL nodes in all languages
2b. You shouldn't use http://www.example.com/fr/sitemap.xml... i don't know how a robots.txt should looks like in such a situation... it may be possible, but i thought you can only add one sitemap line to robots.txt. I think it is difficult to implement this. http://sitemaps.org/protocol.php#submit_robots allows to add more then one line. So we must make sure the hook_robotstxt gives all URLs back. However i think 2c will be the best solution here.
2c. We should block requests to subdirs "http://www.example.com/fr/sitemap.xml" and maybe redirect to the main http://www.example.com/sitemap.xml that contains all languages.

3. no languages detection
3a. Sitemap will become http://www.example.com/sitemap.xml as in past.

There is no need to register at Google except some statistics... because of "sitemap" tag available for robots.txt. As it is impossible to add this robots.txt line automatically in multi language with domain based detection you need to install "robotstxt" module. This modules make sure the correct and full qualified link is displayed to spiders in robots.txt. If you don't have a "sitemap:" line in robots.txt you must register the sitemap manually to all search engines in the world... sounds like a funny and impossible job.

Hass,

I agree with that completely, my comments BTW were aimed purely at path based detection.
I didn't know about being able to add the sitemap: line to robotstxt, that's really nice to know!
I'd agree that 2c would be the cleanest solution for path based detection.

Cheers,

Malcolm

I set this to CNR while i18n is a core feature and therefore we must include this functionality. Without - the module is missing some of the most important new D6 parts and is broken in several ways. Aside i really need this l18n features myself, too. This is critical to me (domain based detection).

I think this patch should be committed. To hold it back because it does not fix every single issue is a misunderstanding about how open source development works. Patches are incremental. This patch at least gets the module functional under D6. It does not fix all the issues, but they are for later patches.
I am tracking (and bug testing) several modules which are being ported to D6 and none of the others are following the "all or nothing" approach. The process of getting a fully functional D6 release usually takes several patches.
So I recommend that this patch be committed, and then further patches can be suggested to fix i18n and other issues.

with the release of 6.2, some items of xmlsitemap were not accessible anymore.
see http://drupal.org/node/244569

I have it working now with the patch attached to this post.
the patch is against http://ftp.drupal.org/files/projects/xmlsitemap-6.x-0.x-dev.tar.gz
The patch has been made based on http://drupal.org/files/issues/xmlsitemap.6.x-0.x-dev.patched.zip from comment #36.

What was really modified is:
- added
'access arguments' => $access_config,
(line 399 from patch)
- added
'access arguments' => $access_config,
(line 408 from patch)

Here is the patched module for 6.2 in case someone needs it.

I agree with i18n. It is a core feature. I wish I could be able to correct it. I'll keep looking..

Ok my test upgrade from D5 to D6 went well. I am English only so this patch works great. No issue. You really should release an alpha version with the notes about internal being broken. I have only one or two modules left to fix up before I can get all the loving of D6.

I installed the version in #74 and it doesnt work at all.

"XML Parsing Error: not well-formed
Line Number 1, Column 1:"

...if you download the XML its just filled with junk.

Regarding #76, does your server have compression enabled?? Try to un-gzip it and see if it stops being junk.

#77 good call. I changed the extension of the XML file to .gz, ran it through 7-zip and its entirely readable. Now I just gotta figure out how to turn compression off just for that file.

Thanks btw.

I am attempting to install the patch from post #74 and a little lost.

Does a patch work in conjunction with the base module or does it work stand alone? This is a new install of drupal 6.2 and thus no prior sitemap modules have been enabled.

I have copied the file xmlsitemap-6.2-0.x-dev.patched into the modules directory but it is not showing up in the modules admin panel.

Thanks,

Keto

The file in #74 is a copy of the module with the patch applied to it.

Extract it completely and you will get a folder named xmlsitemap. Copy that into the modules directory.
(I'm guessing you unzipped it, but didn't untar it.)

Thank you, working now.

I used winrar to decompress the downloaded file. Then changed the file extension to .zip on the extracted file and used winrar to extract one more time.

Thank you!

My drupal installation says that drupal don't work with this module anymore, what can i do about this?

@NuZeilen the module isn't made for drupal 6.x as of now..just wait :)

#82 I am just ignoring the error for now until an official version comes out. Right now you are running pre-alpha software if you are running the patched version. In the end the main developer might look at the patch and make whole changes that make this version incompatible to this version. If you are using this patch you are talking a change.

Thanks
Robert

I'm not sure, but i think there is a bug...

function xmlsitemap_settings_sitemap_submit($form, &$form_state) {
  system_settings_form_submit($form, $form_state['values']);
  ...

that should be:

function xmlsitemap_settings_sitemap_submit($form, &$form_state) {
  system_settings_form_submit($form, $form_state);
  ...

If not - the system_settings_form_submit() function will not receive the correct array structure. But I could be wrong...

I have installed this patched version of xmlsitemap, and it seems to work great. There is one problem, though. When adding a new node (blog entry, in my case), I get the following error after saving a new entry:

* user warning: Column 'pid' cannot be null query: INSERT INTO xmlsitemap_term (tid, pid, last_changed, priority_override) VALUES (71, NULL, 1208970448, NULL) in D:\Web Root\uberclark.us\sites\all\modules\xmlsitemap\xmlsitemap_term\xmlsitemap_term.module on line 206.
* user warning: Column 'pid' cannot be null query: INSERT INTO xmlsitemap_term (tid, pid, last_changed, priority_override) VALUES (72, NULL, 1208970448, NULL) in D:\Web Root\uberclark.us\sites\all\modules\xmlsitemap\xmlsitemap_term\xmlsitemap_term.module on line 206.
* user warning: Column 'pid' cannot be null query: INSERT INTO xmlsitemap_term (tid, pid, last_changed, priority_override) VALUES (73, NULL, 1208970448, NULL) in D:\Web Root\uberclark.us\sites\all\modules\xmlsitemap\xmlsitemap_term\xmlsitemap_term.module on line 206.
* user warning: Column 'pid' cannot be null query: INSERT INTO xmlsitemap_term (tid, pid, last_changed, priority_override) VALUES (74, NULL, 1208970448, NULL) in D:\Web Root\uberclark.us\sites\all\modules\xmlsitemap\xmlsitemap_term\xmlsitemap_term.module on line 206.

After eyeballing the database schema, the solution appears to be to change line 199 of xmlsitemap_term.module from:

      $pid = empty($pid) ? 'NULL' : $pid;

to:

      $pid = empty($pid) ? '0' : $pid;

But I don't have any idea if this is the correct solution or not, as I lack the in-depth knowledge of how xmlsitemap is supposed to work.

subscribing

I'm using a xmlsitemap-6.2-0.x-dev.patched.

I have renamed a role and got this message:

warning: Missing argument 3 for _xmlsitemap_user_submit(), called in /home/.../public_html/includes/form.inc on line 759 and defined in /home/../public_html/sites/all/modules/xmlsitemap-6.2-0.x-dev.patched/xmlsitemap_user/xmlsitemap_user.module on line 131.

I've installed #74 on a localhost v6.2 site and it seems to be working fine. Smooth installation. No errors. Will upload to beta site shortly. Will follow up if any problems in coming days.

Thanks to those who have worked on this. Very valuable capability.

Two questions though:

-How do you adjust/edit the 'frequency' field? It seems to be fairly random what value I get. Shouldn't that be adjustable on each node the same way 'priority' is?

-Why is the default set to 0.1? sitemaps.org indicates the normal default is 0.5. why not use that? having it set to near lowest level means you have to change practically every page - or at least i did. it is good that you can change in the admin panel, but that only affects new pages.

The official 6.0-dev release should really be updated...

Then again, this module should really be in core.

Thanks for working on this guys.

subscribe - thanks for all the work guys

I've installed xmlsitemap as in #73 (using: patch -p1 < xmlsitemap-drupal-6.2.diff) and it seems to work just fine for me.

Coder complains about the following:

• xmlsitemap.module (line 758): In place of custom_url_rewrite(), use custom_url_rewrite_inbound() or custom_url_rewrite_outbound() (Drupal Docs)
  $result = custom_url_rewrite('alias', $result, $path);
• xmlsitemap_term.module (line 191): In SQL strings, Use db_query() placeholders in place of variables. This is a protential source of SQL injection attacks when the variable can come from user data. (Drupal Docs)
  $pid = db_result(db_query("SELECT pid FROM {url_alias} WHERE src = '%s'", "forum/$array[tid]"));
• xmlsitemap_term.module (line 197): In SQL strings, Use db_query() placeholders in place of variables. This is a protential source of SQL injection attacks when the variable can come from user data. (Drupal Docs)
  $pid = db_result(db_query("SELECT pid FROM {url_alias} WHERE src = '%s'", "taxonomy/term/$array[tid]"));
• xmlsitemap_user.module (line 195): In SQL strings, Use db_query() placeholders in place of variables. This is a protential source of SQL injection attacks when the variable can come from user data. (Drupal Docs)
  $pid = db_result(db_query("SELECT pid FROM {url_alias} WHERE src = '%s'", "user/$account->uid"));
• xmlsitemap_user.module (line 211): In SQL strings, Use db_query() placeholders in place of variables. This is a protential source of SQL injection attacks when the variable can come from user data. (Drupal Docs)
  $pid = db_result(db_query("SELECT pid FROM {url_alias} WHERE src = '%s'", "user/$account->uid"));

For the moment, I can live with that (it is a test site...), but it is extremely annoying that Drupal started to complain (throws out a message) about:
"The installed version of at least one of your modules or themes is no longer supported. Upgrading or disabling is strongly recommended! Please see the project homepage for more details. See the available updates page for more information."

At "Available updates", XML Sitemap module is in red as:

XML Sitemap 6.x-1.x-dev (2008-Jan-21)
Project not supported: This project is no longer supported, and is no longer available for download. Disabling everything included by this project is strongly recommended!
Includes: XML Sitemap, XML Sitemap: Engines, XML Sitemap: Node, XML Sitemap: Term, XML Sitemap: User

Can anything be done at my side to get rid of that (in Drupal 5.7, there were settings to ignore certain modules; in 6.2 I just don't find anything like that...)? Or, can you set this project (module) at Drupal server so that Drupal 6.2 will be happy, please.

And, I agree that this module should be already in core.

Can anything be done at my side to get rid of that?

http://drupal.org/project/update_advanced

IceCreamYou, thank you very very much.

My question is however still - how this module can be "declared" as "NOT SUPPORTED"? There are many other modules for older versions of Drupal (and, without any 6.x version yet, only available through patches for HEAD or 5.x-dev), but with "No available releases found" warning "only". Probably it is something different on Drupal server for this module and some other (such) modules...?

I am getting the following error on "/admin/user/settings" when submitting the form ("Save configuration" button):

warning: Missing argument 3 for _xmlsitemap_user_submit(), called in .../includes/form.inc on line 759 and defined in .../sites/all/modules/xmlsitemap/xmlsitemap_user/xmlsitemap_user.module on line 131.

I believe it is due to the mismatch of _xmlsitemap_user_submit(&$form, &$form_state, $form_id) function definition in xmlsitemap_user.module and $function($form, $form_state) function call in form.inc.

Does anyone know how to get the $form_id variable from $form array (I guess $form from function call is that, not the $form_id only...)? I've been looking all around for about an hour, no success... :-(

http://code.google.com/soc/2008/drupal/appinfo.html?csaid=5C74EF3C2E7B0A9A

Output views as XML -- could be relevant here :)

Yeah, I get errors when the sitemap gets submitted. I don't know why any errors are happening, but I do know that the "Not Supported" message is accurate. There's a release of the module in the queue, and the maintainer of this module chose not to support a 6.x release until it's fully stable, which it's not yet.

And FYI, I've added a feature request to get this in core for 7.x - +1 it if you agree.

http://drupal.org/node/252846

Status summary: We seem to be waiting on the language detection problems mentioned in #67.

The problem here seems to be path-based problems. It just so happens that, in the process of trying to fix another bug, I abstracted a lot of the code for working with paths out into separate functions.

http://drupal.org/node/202294

I would suggest that the stuff that does the multi-lingual paths properly will be much easier to implement once this patch is committed.

Can people please review that patch and see if it causes you any problems? Once that gets to the point where it's committed, I might find some time to get onto the path-based stuff here.

The Patch from #74 has been running in my test site and working for several weeks with no problems.

Thanks
Robert.

At another look, I'd guess that this patch already solves the domain-based problem.

(ie. the patch mentioned in comment #100 is the one that I think solves some of the existing problems with this patch)

Robert: I presume you're not using the multi-lingual features? Because that's what seems to be holding the thing up.

Anyone know if the module developer is actively updating this module? It seems fairly critical yet is getting little attention, it seems.

The original developer doesn't seem to be, but one of the CVS committers is interacting with the people developing this patch. Let me reiterate:

Things currently blocking a 6.x release
* Internationalisation

That's it. See comment #67 for details.

How to help us fix this problem:
* Test bug http://drupal.org/node/202294 (test it on a 5.x site)
* When enough people have tested the bug above, then it can probably be committed. When that bug is committed, it will make it quite easy to fix at least half of the internationalisation problems (and maybe more)

Does that help?

#103 Correct I am not using multi-lingual features. Mine is a English only site. Since the question was is everything else except multi-lingual features was working so it can get committed and the author of the patch can work on fixing that issue before a full release is made. I was answering the question and my testing in an English only site it works as well and 5.x for my site.

Thanks
Robert

A well we need the multi-site issue fixed for domain based switching, isn't it?

@hass: I'm not 100% clear on what you're saying in comment #107.

Also, for the domain-based detection one you mentioned (comment 67), how do the multiple sites mentioned work? I only use monolingual sites, but I use the domain module ( http://drupal.org/project/domain ) -- is that what you were thinking of, or is there some other multi-domain multi-lingual thing that I'm unaware of? Also, I had to apply a custom patch to the domain module, as documented in this issue: http://drupal.org/node/216148

I don't know that the maintainer of the domain module is intending to roll that into his codebase, but possibly if we coded it as an option controlled by a checkbox he might roll it in.

Hopefully all this will get us somewhere :).

No, there is a known bug in xmlsitemap that pre-saves sitemap.xml.gz files in files/xmlsitemap folder. If this is the case you will end up with name space conflicts on the file names. We must save the pre-generated xml files with the domain name for e.g. files/xmlsitemap/www.example.com_sitemap.xml.gz. Then we are able to deliver the xml files from example.com and example.de, etc. If we don't change the file names we only have one xml file what will not work on domain based switching (and multi-sites with only one files folder).

Implementing this bugfix was refused for no reasons and now it hurt's back...

@hass: The patch at this issue already does that: http://drupal.org/node/202294 -- are you in a position to be a committer on this, or has Darren vetoed it (and yes, I know it needs more testing :) )

No i don't have access on xmlsitemap in CVS - i only participated on more than one of this multi-site discussions and was not happy that all of them have simply closed as won't fix or something similar... however - now we need this bugfix for good reasons.

No CVS access? Ok, I assumed you would, as you're listed as a developer with already-existing commits at http://drupal.org/project/developers/190839

:)

That's new to me... Maybe from the translations I've committed. Something you don't need access to the project themself

Not sure if this has yet been addressed, but just to maybe give some info for an error I get:

In the drupal 6.2 dev version of the mod (#74), I'm having trouble adding additional links. They're not being added to the database when inputting them via the form.

How is it going which the patch?

Thom

@gangas: See comment 105

Tnx...

Maybe we could get a summary of what needs to be applied to what to get a valid testing copy? There are too many patches, and the comments are all out of order.

I need this module for my Drupal 6 site, which patch shall i apply to which version?
6.x Dev is very old: November 9, 2007.

This is a little confusing for people who are not that familiar Drupal module hacking and patching.

#93 says #74 is the best patch for now? Do I have to apply it to 5.x-1.4?
Can you please release a patched dev 6.x alpha version or something like this?

All the above patches must be applied to HEAD. Not 5.x releases.

Status Update

Just to make it clear, the sequence we appear to need is everyone test patching http://drupal.org/node/202294 against HEAD. Once that has been committed, then work will be able to proceed on this patch. While nothing has essentially changed on the 6.x patch since the last 3 times I've said this, work has proceeded on the other patch, and is now working for the two people who have tested it, but we need more 5.x testers for that patch before we can continue work on this one.

Thanks all.

Is the XML Sitemap module already available for Durpal 6.x? Where can I download it?

Many thanks!

@taccie: no, nothing ready; please read the comment immediately above yours; until people test that, nothing will happen.

wayland76: I think you need to tell us all again that "it isn't ready"; I don't believe three times is enough ;)

wayland76: what about publishing some alpha version, with disclaimer as in other modules, and with all patches applied to the right "source"?

This would probably motivate more people to try it (it is much easier to simply download an archive and try it instead of searching around what exactly to get and what to do with it first...), and provide less chances that we don't know exactly what we test (if it is the latest code as you have it)...

#127 is right! A lot more people would test it if there is a alphaversion for 6.x

Can't wait for the module to be ready for 6.2. This module should definately be core!

Let's not try to add the multi-site capability immediately. Just get it working. I'm planning some performance enhancements that will make the multi-site issue obsolete. I'll post the details in issue 202294.

Once we have a working port, we can deal with other items on the wishlist in separate issues. I appreciate all the work that has gone into this and will make a Drupal 6 release of XML Sitemap as soon as a solidly reviewed and tested patch is available.

+1 for releasing an alpha version with all the patches added so we can test it.

+1 YES

Let me just re-emphasize that this patch must try to do less so that it can be ready to be committed soon. Thanks again for all the work.

I should point out to everyone that Darren Oh is the boss, so what he says is what's happening.

He says we get an alpha when the patch is reviewed and tested patch is available. By this, I think he means one with no outstanding bugs. The multisite issue and internationalisation are on hold pending some other changes that Darren is planning (although hass and I and others hope they can be resolved before the betas of 6.x), but Darren recommends we move ahead with an alpha anyway.

However, it seems to me that the current patch has some outstanding bugs. I recommend the following recipe:
1. Start with the latest CVS HEAD
2. Merge best versions of patch from #53 (which is against HEAD) and patch from #73 (which is not against HEAD, but may have other fixes)
3. Investigate problems mentioned in #85, #86, #87, #89, #90, #93, and #97
4. Create a re-rolled patch. That's a PATCH -- tgz files are not useful.

Under those circumstances, Darren might commit it and create an alpha. As long as it's a tgz file, and/or against 6.x-0.x-dev, I would imagine Darren will continue to ignore it (although I'll be the first to admit that Darren doesn't think like me :) ).

Any takers?

It may not be helpful to patch against HEAD, because it contains just the beginning of a port from an older version, made before Drupal 6 was finalized. I would accept a patch against the Drupal 5 branch for the Drupal 6 release.

Ok, there we go people. Instead of step 1 in comment #134, start with (check me again Darren), the latest version from the 5.x branch.

Also you may delete:
project = "xmlsitemap"
from:
xmlsitemap.info
xmlsitemap_engines.info
xmlsitemap_node.info
xmlsitemap_term.info
xmlsitemap_user.info
sorry, message "This version is incompatible with the 6.2 version of Drupal core." appears then and its impossible to deinstall the module after that. dont know why...

wayland76,

what about to publish a complete patch (or tgz - I would even prefer that) instead of:

2. Merge best versions of patch from #53 (which is against HEAD) and patch from #73 (which is not against HEAD, but may have other fixes)
3. Investigate problems mentioned in #85, #86, #87, #89, #90, #93, and #97
4. Create a re-rolled patch. That's a PATCH -- tgz files are not useful.

Don't you think doing all you suggest above anyone will finish with his/her code, and I bet there is a big chance that not two of us would have it the same at the end. So, what to discuss about later?! Wouldn't it be better all of us to test the same code, so at least we can compare results (and, easier try to reproduce the bugs)?

I presume you (or, Darren Oh) have your own version of this module you "play with". Can we have it (exactly as you want it to be tested), please. To download and see how it works, and to provide a feedback. Call me stupid, but I have to admit I don't understand exactly how to patch all this to different versions, but get at the end one version to test...

I can however always produce a diff (patch) from any 2 versions (from certain 5.x or HEAD, whatever you prefer) for you, if tgz-s are not useful for you... ;-)

The instruction I left out above was that, after doing all the steps above, the patch should be posted here. Those instructions are for someone who wants to provide us with a patch; a working patch that we can all work from.

Basically, I don't have a version of this, and I doubt that Darren does either. Some of the programmers who posted further up will have a version, but most of them haven't commented in a while.

Darren is willing to commit when we have a reviewed and tested patch. Part of the review process is that we have to keep fixing problems that people find with the patch. We have a number of existing problems (see bullet point 3 above), and when someone provides us with a patch that includes the stuff from the patch above and fixes those problems, then it can be reviewed.

I'm working on other things at the moment; eventually I'll probably get to this one, but if someone else pitches in sooner and creates the patches we need, work will go faster.

Wow, great collaborative/team work, I am subscribing to stay current. Thanks

+1 Yes. Subscribing.

Subscribing

Tested the latest version in this thread on my site, and it seems to be working.

Any word on when the alpha will be out?

Please change the status to "reviewed and tested" if it's ready.

My version is working - I think I'm using the tgz from #74 (produced using instructions in #73). Marking RTBC (as requested) because that's at least two people it's working for. Either way a "real" release will allow more people to test for bugs.

I need a patch. Latest 5.x-1.x-dev preferred.

See comments #134 and #139 for what needs to be done.

Please change the status to "reviewed and tested" if it's ready.

I need a patch. Latest 5.x-1.x-dev preferred.

I am quite confused. That seems contradictory to me.

The patch in #73 works for me. I understand what wayland76 wants to do in #134 but it doesn't seem realistic that anyone following this thread is capable of getting that done within a reasonable amount of time. Changes can be merged later, once the working version is established. Right now we have nothing, and no one can do anything about it.

I changed the file extension on #73 to .patch (from .diff) to make the process a little easier.

Well, we shall see what Darren says. But I should point out that that patch has some bugs, even if it appears to be working for you. I'll reiterate comment 134, with all the mistakes corrected:

It seems to me that the current patch has some outstanding bugs. I recommend the following recipe:
1. Start with the latest 5.x dev branch in CVS
2. Merge best versions of patch from #53 (which is against HEAD) and patch from #73 (which is not against HEAD, but may have other fixes)
3. Investigate problems mentioned in #85, #86, #87, #89, #90, #93, and #97
4. Create a re-rolled patch. That's a PATCH -- tgz files are not useful.

I also reiterate that these are instructions for someone who wants to provide us with a patch, and that I don't see what's so hard about it, except that it will take time (which I may eventually have). If you investigated the comments I suggested, you would even see that there are some suggested fixes there which have not been rolled into this patch. That doesn't seem to require inordinate amounts of skill.

I know, I know. My major problem is with your second proposition there. These patches are really long and it would take a long time to go through them both and work on changes. I don't have a problem with fixing the bugs in your third point.

The point I was trying to make was that it's better to have a mildly buggy release that everyone can test and make patches against than to wait until some minor changes are made that will take a very long time. Chances are if there's a release the bugs can be ironed out more quickly individually; right now, no one can even test to see if the bugs exist.

EDIT: Note that by "release" I meant a version of the patch to start from, as opposed to considering both #53 and #73.

@IceCreamYou: Ok, that makes sense. My only problem with #73, then, is that it is against a release version instead of a CVS version. I didn't mention this before, but we need it against a CVS version. So how about instead of step 2, we just look at applying #73 to the branch mentioned in step 1, and then resolving any problems that arise fromt he difference between a release version and a CVS version.

Sounds like a plan. Unfortunately, I'm using Windows Vista and don't have an adequate diff-ing tool available... so I'm still basically stuck because I can't distribute any work I do. :(

That means it might be another two weeks or more before I can contribute anything. And yes, I've tried a couple of diff tools, and all of them have given me problems.

@IceCreamYou: Have you tried some of those CVS tools (ie. TortioseCVS)? I think some of those do diffs. You can check things out of CVS anonymously, and then do your diffs on that. But in this case, you'll have to be sure to get the DRUPAL-5 branch.

I tried TortioseCVS. Maybe I'm just not doing it correctly, but it ran for half an hour trying to create the first checkout before I shut it off and uninstalled it.

I won't have time to try again until the Saturday after next. At that point I'll try downloading the checkout itself from cvs.drupal and starting from there, unless someone gets to this before I do.

@IceCreamYou: The only thing I can think of is to ask whether you had it set to SSH rather than RSH (I don't use Windows, so I'm afraid I can't help much with it).

For me, it should all happen in less than a minute (at least for xmlsitemap), and usually under 20s.

Well, after carefully examining the patches in #53 and #73, I've come to the conclusion that the one in #73 is better (possibly due to relying on the one in #53). So I've updated the patch from #73 so that it patches against the latest CVS of the DRUPAL-5 branch.

I haven't investigated the problems mentioned in the comments above yet, though, and I also wonder why some of the internationalisation stuff has been commented out in _xmlsitemap_get_path_alias -- unless someone can tell me why, I think we should probably restore it.

Anyway, the patch is attached, but the problems still need addressing.

@hass: In response to #85, I concur.

In response to comments #86 and #87, does anyone know why this pid is disallowed by the schema from being NULL? I note that there are quite a number of places in the code where it's set to NULL, so I think I'll remove that part from the patch.

In response to #89, you're right, there's a problem; I'll fix that in the patch too.

In reponse to #97, yeah, there's a problem, as comment #89 said, and I'll fix it.

Anyone wanting to figure out things like this should check out http://drupal.org/node/114774

I'll fix the problems in comment #93 too.

In relation to comment #90, these issues are important, but unrelated to the 6.x port. So I've opened a new issue for one of them, and the other already has an open issue. Here they are:
http://drupal.org/node/213292
http://drupal.org/node/258292

Hope these help.

Ok, I won't fix the problems in #93. It complains whatever you do, so I made the sensible choice.

Ok, everyone try the attached patch. For those able, please review the part where I call custom_url_rewrite_outbound, because I'm not sure this is right.

How to get the HEAD release?

None of the releases doesn't seem to be the right one to apply your patch to it...

It's for the DRUPAL-5 branch. I'll put out a version for the latest stable release in a few hours if no one else does.

Here's the patch for the latest Drupal 5 release.

#165 work fine for me..
For when one dev version of 6.x?

watchdog message at line 364 is stored as translated

should be changed to something like this:

if isset($message) {
  watchdog('xmlsitemap', $message);
}
else {
  watchdog('xmlsitemap', '!sitemap downloaded by @user-agent at @address.', array(
    '!sitemap' => $type,
    '@user-agent' => $_SERVER['HTTP_USER_AGENT'],
    '@address' => ip_address(),
  ));
}

Patch with updated watchdog code.

Hi darren , got a bit confused with the posting here. can you tell me if this patch above (157533-168) can be tested for 6.2?
Thanks

@wolfflow: I'm pretty sure that's the idea.

The patch in #168 applies to the latest stable version of the Drupal-5 branch and is to be tested on Drupal 6, IIRC.

5--2 would be a better choice, but the most important thing is to have a patch that has been reviewed and tested. I will commit the first patch that is ready.

I'm intending to re-roll against 5.x-2.x eventually (if someone else doesn't first), after I've tested 5.x-2.x for its multi-site capabilities and the like (I got the impression that it's supposed to do multi-site, but if not, then I'll work on that first).

@Darren, can we have the dev releases on the XML Sitemap front page now? I know it was a bad idea when all the releases were mixed together, but now that the official releases are in green and the dev releases are red and in a separate section, can we get them there?

wayland76, I was getting a constant stream of issues saying, "6.x doesn't work!" As soon as we have a patch here that is confirmed to work, I'll commit it and put the dev releases back on the front page.

I'm a n00b to testing Drupal patches, but the patch command itself isn't new to me. Could you clarify this for me (sorry if I need it spelled out):

1. I've got "xmlsitemap-157533-168.patch";

2. I've run the patch against the downloaded version I got here:
http://ftp.drupal.org/files/projects/xmlsitemap-5.x-1.5.tar.gz ;

3. Loads of hunk failures, a listing of which I can supply separately.

Shall I try to fix the hunk failures, or am I applying the patch against the wrong version?

Thanks in advance for anyone's guidance - I'm really keen to help any way I can.

Were you applying the patch to a fresh copy, or one that had been patched before?

siliconmeadow is correct; the patch does not apply against 1.5.

I applied the patch by hand to 1.5, however, and have attached the module in case anyone would like to test it.

Yes, I know a patch is needed. But if the attached module works, then the patch will work for a 6.x update against whatever branch it's supposed to be for.

Probably it is the same that happened to me - after looking more closely hunk failures (comparing original files and failed changes), it turned out that there seems to be an issue with info files (it looks like wayland76 has some older info files and not the latest ones included in 5.x-1.5 version).

Just manually edit all info files (also in subfolders!) adding the missing "core" line (even if I would suggest to change also the version and timestamp lines...), and this should be it (all patches of "main" files seem to work fine for me).

And, everything seems to work well for me with this version, at least until now (I have submitting turned off, as it is internal beta site...). No errors at admin / settings pages, site map seems to be generated well...

Thank you, wayland76.

Were you applying the patch to a fresh copy, or one that had been patched before?

A pristine version.

The problem is that the .info files in the downloadable package contain some extra lines that are automatically added when the package is created. Those lines should be removed before applying the patch.

Thanks to LUTi for the review. Patch applied in CVS commit 117122. Thanks to all who helped create the patch. Dev versions will be restored to the project page as soon as the 6.x package is updated.

*subscribing*

subscribing

In other words, apply the patch to a CVS checkout, not to the version on the site.

(Not that it matters any more)

It would be great now (when there is an 6.x development version out) to get rid of the "Project not supported: This project is no longer supported, and is no longer available for download. Disabling everything included by this project is strongly recommended!" error message at Available updates...

Is there any way to output the aliased URLs instead of for example http://example.com/node/43? I really like the search engines to see one version of the URLs, and that should be the pretty URL I guess.

OK, I have a patch to enable URL alias support in XML Sitemap. This patch is pretty simple, and I've tested this on my own site: http://ehsanakhgari.org/sitemap.xml. I hope this can get incorporated in the XML Sitemap module.

I filled a new bug report, see here:
#261853: pid must default to NULL

the patch by ehsan.akhgari works well, thank you!

Please do not add any more to this issue. Frieder kindly posted the correct issue to use.