Posted by kiamlaluno on May 15, 2009 at 12:31pm
3 followers
Jump to:
| Project: | XML sitemap |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
Having different database tables causes some problems to the project code.
- Two different tables needs to be updated. I.e., this is true when a node is deleted; it's data should be removed from the database table used by the module, and from the table containing all the links that populate the sitemap.
- Having different tables that contain the data for the links to be put in the sitemap constrains the code to use a custom hook to get the central table populated. This is normally done when the sitemap is requested, and causes the code to start a long task (get all the links from the modules, print the links in the sitemap cache files) that could cause a PHP timeout.
- Different modules implement similar code to calculate the link priority (verify if a priority override is definited for the link, and calculate the priority in the case there is not a priority override) that should be put in xmlsitemap.module.
For these reasons, I think that a single database table that contains all the required fields would simplify the code.
Comments
#1
Removing the central database table is the better solution; this would allow to have database tables that contain only the required fields for the specific module.
node/<nid>for the nodes,user/<uid>for the users, etc...).The only problem one could object about this idea is that there could be links with the same URL. As long as the single modules handle different objects (nodes for xmlsitemap_node, users for xmlsitemap_user, taxonomy terms for xmlsitemap_taxonomy), the canonical relative URL they are adding are differents (
node/<nid>for the nodes,user/<uid>for the users, etc...); if then there are links of different objects that have the same alias, then that is a problem of configuration that XML sitemap is not able to resolve (and it should not).I already removed xmlsitemap_menu.module, and implemented a different way to add additional links.
If then, one of the additional links is a link to a node, that should be removed from the administrator user that added that link in the additional links (in other words, the additional links should be never links already handled by an existing module).
#2
I am assigning this task to myself.
#3
Kiam, you are a never ending changing machine. There is no goal for you but to create differing methods of doing something. I find no end goal for you. Let's not focus this for 1.x.
#4
That is not true; it's from a lot of time that I am thinking that passing data from a database table to another doesn't make sense, and it just slows down the process of creating the sitemap content.
I don't think that we should create a 1.0 version that still does this silly thing to move data from tables, and then output them to the browser.
As far, the only thing I am doing is to find the way to fix the main problems with XML Sitemap, which are PHP timeouts, and memory exhausted problems.
#5
This has been implemented, and the new code has been committed in CVS.
#6
#7
Automatically closed -- issue fixed for 2 weeks with no activity.
#8