I've just updated to the latest 6.x-1.x-dev version (datestamp of xmlsitemap.info is 1230380230), and all content entries (book page, page, story...) present in sitemap up to now have disappeared (taxonomy entries are still there). There is nothing logged nor in Drupal nor in Apache log.

Comments

avpaderno’s picture

luti’s picture

I can confirm xmlsitemap table contains only entries displayed (taxonomy terms), but no node (book, page, story...) ones. xmlsitemap_node table is empty, but also xmlsitemap_term table is empty (I am not using all extra modules, only those two...). Both last tables were empty also before (while everything seemd to work well), but xmlsitemap table contained also all node entries (159 entries in my case before, now only 27).

avpaderno’s picture

The xmlsitemap table is cleared before xmlsitemap.module invokes the implementation of hook_xmlsitemap_links(). The problem is the other's modules tables to be empty.

As I had already to introduce it, I will add the code that allows to fill the modules table when Drupal core tables contain data XML Sitemap modules can use. This is also required for when the project modules are first installed in a web site which already has content, or taxonomy items.

avpaderno’s picture

The code I was talking of has been added in CVS.
Going to /admin/settings/xmlsitemap/tools/update, a page will show the modules which allows the administrator to update its own database tables.

avpaderno’s picture

Status: Active » Fixed

As the most of the project modules give the possibility to update their own database tables, I set this report as fixed.

bwooster47’s picture

Status: Fixed » Active

I updated to latest code datestamp = "1230855496"

But I still see the problem reported here - when I go to the sitemap page, all I see is a single entry for the root of the site, and not a single node is reported.

I have the xmlsitemap_node enabled, and I see no errors in the drupal log entries. If there is any other information needed, let me know.

I did do a 4.7 to 5.14 to 6.8 upgrade.
I had gsitemap in 4.7, did not have it in 5.14, and now installed xmlsitemap in 6.8. I did run update.php, and it did show xmlsitemap in the update list (version 6000 if I remember correctly).

avpaderno’s picture

That explains all.
Run again the modules update, but select the higher number you see for XML Sitemap: Node.
This should fix the problem you are having.

Effectively, the direct upgrade from gsitemap 4.7 to xmlsitemap 6.x is not supported.
I must add a warning into the project page.
Thanks for pointing out this.

bwooster47’s picture

Component: xmlsitemap_node » xmlsitemap_node.module

No luck. Here are all the things I tried:

1) I re-ran update.php, selected 6102 for xmlsitemap node module - it showed some db updates, no errrors.
2) tried visiting q=sitemap.xml, still only root shown.
3) re-ran the xmlsitemap Tools, tried again, still same result.
4) then uninstalled xmlsitemap and re-installed it. This this update.php showed no updates (not sure how the module install works, maybe this is fine?)
5) even after uninstall/reinstall, same result.

avpaderno’s picture

When you uninstall, and re-install a module the update page correctly reports that no updates have been executed (when you install a module, it is supposed to be updated).

May you check content of the database tables used by XML Sitemap (their names contain xmlsitemap_ right after the prefix you set for your Drupal installation), and see if they are effectively empty? If you find some database tables that are not empty, can you report which those are?

I need also to know which XML Sitemap modules you enabled.
Thank you.
-- Kiam
Kiam la luno renkontas la sunon

bwooster47’s picture

Enabled:
XML Sitemap
XML Sitemap Node

phyMadmin shows 1 record in "xmlsitemap" and 0 in "xmlsitemap_node"

The xmlsitemap record has:
--loc (module type-empty) id sid lastmod changefreq priority
values are:
http://www.mysite.com/drupal 0 0 1231084797 1 1

xmlsitemap_node table shows this structure, and 0 records:
--Field Type Collation Attributes Null Default
nid int(10) UNSIGNED No 0
last_changed int(11) Yes NULL
previously_changed int(11) Yes NULL
last_comment int(11) Yes NULL
previous_comment int(11) Yes NULL
priority_override float No -2

zakjan’s picture

Also having this problem. Any solution? Thanks

whytewolf’s picture

I'm also having this issue.

however a bit more info about the issue.
I uninstalled the xmlsitemap, and ran the drupal uninstall {removed the xmlsitemap part of the database} after reinstalling the old nodes won't show.
ran the "tools" node update. and it acts like it's running 2 updates. but looking into the code for xmlsitemap_node.module shows

return array(
'file' => 'xmlsitemap_node.batch.inc',
'add function' => 'xmlsitemap_node_update_database_01',
'update function' => 'xmlsitemap_node_update_database_02',
);

however these two functions and that file are no where to be found.
also there does not seem to be any functionality to add old nodes to a new xmlsitemap install.

bwooster47’s picture

Any hope of a quick update for this? xmlsitemap dev version is totally unusable because of this, and based on the previous comment http://drupal.org/node/351570#comment-1187507 someone may already have the fix which seems to be called but missing functions?

avpaderno’s picture

xmlsitemap_node_update_database_01(), and xmlsitemap_node_update_database_02() cannot be found because they should be in a file I was not able to add into CVS. To resolve the problem I created a different branch that I am developing, and that is not associated to any public releases.

When I will have added all the code I need, I will create a new release (6.x-2.x-dev).

Anonymous’s picture

Assigned: Unassigned »

I installed into a fresh DB and I find that no older nodes are being presented in the sitemap.xml report. Is there a method for updating the xmlsitemap tables with older entries? I'm thinking that updating of new data for xmlsitemap should be a cron process instead of an implementation of hook_nodeapi or rather both and give the admin an option to only update with cron. Similar to the way pathauto works its cron process where old or missed data is added via the cron process.

avpaderno’s picture

hook_nodeapi() is the only hook that is possible to use to update the content of a site map without to cause any excessive resource consuming. It's the only hook that is called when a node is being changed, and it permits to operate in a one node at time basis. Differently, if the code would make the changes in hook_cron(), it would require more resources to keep track of the changed nodes, and would change a database rows batch all in the same moment (with the consequence to consume the time resource, that is the other issue I want to avoid).

Anonymous’s picture

I'm actually testing the hook_cron idea now. I'll have a patch up for review sometime next week. I'm grabbing all the node.nid not in xmlsitemap_node, then doing a node_load/node_save combination. The stink of that though is I had to check if nid is in xmlsitemap_node in the nodeapi update operation and recall with insert instead. I don't like this and will do something else.

Anonymous’s picture

I've created #366197: hook_cron() support for populating the database tables for the patch as a feature request. The request does resolve this issue.

yhzsailor’s picture

This also seems to be an issue with the 5.x-2.x Dev version. I deleted the xmlsitemap_node table and it doesn't get recreated.

avpaderno’s picture

@#20: What do you mean? Usually modules don't recreate deleted database table; the only way to make them recreate a deleted table is to uninstall, and re-install them.

The module is not called Phoenix. :-)

Anonymous’s picture

@Kiam: I take @yhzsailor to mean he truncated the table.

@yhzsailor: Yes, it should be the case that old node data isn't represented in the xmlsitemap_node table in previous versions. This is the reason for my feature request of #366197: hook_cron() support for populating the database tables. My concern though is for 6.x since 5.x should eventually become a dead version.

avpaderno’s picture

I don't understand what he is saying, in that case. Why would he truncate the table on Drupal 5? Drupal 5 doesn't implement the batch operations, therefore XML Sitemap doesn't implement the code to rebuild the table data from core table data.

Using hook_cron() or a different hook, the modules table could be updated in background in Drupal 5 too, anyway.

yhzsailor’s picture

I upgraded to 5.x-2.x-dev version and started getting grief in terms of error messages (database timeouts on which I opened another ticket).

So, in an effort to ensure I'd done the install right I wiped out the xmlsitemap tables in my database (I have a backup). So essentially it should have been a clean install. Then I installed the modules and renabled them. The xmlsitemap table was created, but not the xmlsitemap_node table. After playing around for a while, trying to get the table created by reenabling and disabling the module, I gave up and created the table myself after finding the SQL code in the module.

Then I found out that the table didn't get repopulated with data from the site. Quite frankly if the normal functionality is that nodes will only be added after the module is installed then that's crazy! There at least should be an option to populate the sitemap with all existing nodes.

Honestly I never should have attempted to upgrade to a dev version, but I have 14k nodes in my sitemap and it had begun timing out when generating the sitemap and I wanted to try and use the version that said this issue was resolve.

Finally do not drop the Drupal 5.x support. I and many others won't be upgrading right away as not every module we depend on has yet to be migrated completely to 6!

avpaderno’s picture

My first task is to develop the code for Drupal 6 branch, but I can assure you that the code that can be back ported to the Drupal 5 branch will be back ported.

I don't think the maintainer has intentions to drop the Drupal 5 branch.

yhzsailor’s picture

Another update. I now have data in the xmlsitemap_node table (no idea how that happened.) I hacked together some sql to update and populate the xmlsitemap table with all of the nodes in my database. But I still get the database errors (http://drupal.org/node/367619) whenever I enable the node... now I'll start investigating that.

Anonymous’s picture

Assigned: » Unassigned

This issue should be resolved even without #366197-16: hook_cron() support for populating the database tables but those of you with a large node database may wish to test my patch and give feedback.

matb’s picture

I am missing all old nodes after database update, too (only root node is shown in sitemap.xml).

I applied the patch from http://drupal.org/node/366197#comment-1242064 to current version with xmlsitemap_node.info: datestamp = "1234138817" , but it doesn't work for me.
Also running /admin/settings/xmlsitemap/tools/update doesn't work to bring back the old items on sitemap.xml.
There are no errors in apache.log. It seems, that table xmlsitemap_node is updated correctly (46 records, should be correct for my site), but table xmlsitemap has only the one record for the root page.

Enabled:
XML Sitemap
XML Sitemap Node

Anonymous’s picture

@matb: Have you executed cron.php after updating the xmlsitemap_node table?

avpaderno’s picture

If the module database table contains the right number of rows, then it's just the site map file that must be updated. The content of the site map is cached, so it can happen it doesn't show all the URLs it should.

matb’s picture

@earnie: yes, I did a cron run.

@kiam: I restarted apache, cleared caches, reran update tool, remains the same.

Meanwhile I think, I should have posted this issue rather to http://drupal.org/node/366798, since the xmlsitemap_node table seems to be updated correctly. But the xmlsitemap table just contains the record for the root page.

When creating a new page, I get those errors in the database:
2009-02-10 11:47:47 CET drupal_abanq ERROR: function concat(unknown, integer) does not exist at character 361
2009-02-10 11:47:47 CET drupal_abanq HINT: No function matches the given name and argument types. You might need to add explicit type casts.
2009-02-10 11:47:47 CET drupal_abanq STATEMENT: SELECT n.nid, n.type, n.promote, xn.changed, xn.previously_changed, xn.priority_override, s.comment_count, s.last_comment_timestamp, xn.previous_comment, FIRST(ua.dst) AS alias FROM abanq_node n
LEFT JOIN abanq_xmlsitemap_node xn ON n.nid = xn.nid
LEFT JOIN abanq_node_comment_statistics s ON n.nid = s.nid
LEFT JOIN abanq_url_alias ua ON ua.src = CONCAT('node/', n.nid)
WHERE n.status > 0
AND n.type NOT IN ('')
AND (xn.priority_override = -2 OR xn.priority_override >= 0)
AND n.nid <> 0
GROUP BY n.nid, n.type, n.promote, xn.changed, xn.previously_changed, xn.priority_override, s.comment_count, s.last_comment_timestamp, xn.previous_comment

I don't hink, there are caching issues. I made the following tests on another site, that I have left untouched since the problems arised on the first site.
Now also updated this database to the last available *and* patched xmlsitemap module. While updating there were basically the same errors (I am on postgres) on calling /admin/settings/xmlsitemap:
* warning: pg_query() [function.pg-query]: Query failed: ERROR: function concat(unknown, integer) does not exist at character 221 HINT: No function matches the given name and argument types. You might need to add explicit type casts. in /var/www/drupal-6.9/includes/database.pgsql.inc on line 139.
* user warning: query: SELECT n.nid, n.type, n.promote, xn.changed, xn.previously_changed, xn.priority_override, FIRST(ua.dst) AS alias FROM node n LEFT JOIN xmlsitemap_node xn ON n.nid = xn.nid LEFT JOIN url_alias ua ON ua.src = CONCAT('node/', n.nid) WHERE n.status > 0 AND n.type NOT IN ('') AND (xn.priority_override = -2 OR xn.priority_override >= 0) AND n.nid <> 0 GROUP BY n.nid, n.type, n.promote, xn.changed, xn.previously_changed, xn.priority_override in /var/www/drupal-6.9/sites/all/modules/xmlsitemap/xmlsitemap_node/xmlsitemap_node.module on line 248.

After the update all items but one vanished from sitemap.xml. After restoring table xmlsitemap from the old database, I got them immediately back. So there seem to be at least no caching issues.

IIRC the problems with vanishing sitemap records appeared with the version from 29.01.09.

avpaderno’s picture

If I understand well, the problem is caused by the SQL functions called by the SQL queries used by the code.

Anonymous’s picture

I think the concat() and postgres issue is documented well via http://www.google.com/search?q=concat+function+postgresql+site%3Adrupal.... I haven't reviewed enough links to determine what should be done.

avpaderno’s picture

The part of the SQL query that retrieves the path alias of the node URL should be removed because it doesn't get the correct value in multilingual sites (it uses the first path alias, indifferently from the language for which the alias has been created); the correct code would use url() to get the correct path alias for the language current used from Drupal.

Unfortunately, that means to change other things in the code (including to correct the default values used for the database fields); that is the reason I kept a different branch I created for the code.

Anonymous’s picture

So the proper fix will be in the next version 2.x release. For version 1.x we could do the nasty hack using $db_type filtering and for 'pgsql' use 'node/' || n.nid instead of CONCAT('node/', n.nid).

avpaderno’s picture

That can be done. Actually, the code already checks the value of $db_type to adapt the query to the database engine being used; it will be not difficult to change the code to use the proper operator for the PostgreSQL engine, even if the correct fix would be to not make the query dependent from the database engine.

I will make the correction suggested by earnie as soon as possible.

avpaderno’s picture

The PostgreSQL queries have been changed to use the correct operator; the change has been submitted to CVS.

matb’s picture

Latest version from 12-02-09 works for me, thx a lot!

avpaderno’s picture

Issue tags: +SQL queries

The need of the string concatenation operator has been removed from the last commit made in CVS.

avpaderno’s picture

Status: Active » Closed (duplicate)

I am setting this report like duplicate of #376032: How to insert old nodes into the sitemap?, because that report explains how to have the content of the site map updated.