I am starting a new module called Popularity (similar to the WP plugin Popularity Contest) that will be able to rank nodes based on certain factors like comments, statistics, pingbacks, trackbacks, etc. I already use the xmlsitemap module and noticed that you have some similar functionality to give certain factors a higher rating in the sitemap. I was wondering if we could work together and abstract your ranking code from xmlsitemap into popularity. Then, xmlsitemap could simply integrate with the popularity API to help adjust the priority of items on the sitemap. I'm thinking of creating a function like the following:
/**
* @param $node A node object or node ID.
* @param $min The minimum value to scale to, defaults to 0.
* @param $max The maximum value to scale to, defaults to no limit.
*/
function popularity_get_popularity($node, $min = 0, $max = NULL)
This will give the xmlsitemap_node module less code for you to maintain and will help re-use the priority/popularity code elsewhere (ex. views sorting, etc). I've just started this module, so there's not much code to actually look at yet, but it's a work in progress. Let me know what you think!
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 378924-xmlsitemap-node-remove-calcs-D6.patch | 5.77 KB | dave reid |
Comments
Comment #1
avpadernoWe can achieve that by defining a custom hook that xmlsitemap_node.module would call to allow external third-party modules to change the priority of a node. In that way, if popularity.module would be present, it could change the node priority in the site map; otherwise xmlsitemap_node.module would proceed as its usual.
I was thinking to a
hook_xmlsitemap_priority_alter(&$priority, $type, $id), where$typewould be a parameter saying the type of object for which the priority is requested to be changed (node, user, term, etc...), while$idwould be the ID for that object (nid for nodes, uid for users, etc...).I like the idea.
Still, this would not give to xmlsitemap_node.module less code to maintain, as the module must work with, or without popularity.module.
Comment #2
dave reidThe hook_xmlsitemap_priority_alter sounds like a great idea and something I can definately work with.
But what I'm asking you to consider is removing the automatic node calculations currently in xmlsitemap_node. The module will still work just fine without this since users can still assign default priorities for each node type and override the priority on individual nodes. Let me work up a patch to show exactly the changes I'm thinking about.
Comment #3
dave reidPatch attached that shows the changes. Note that the module still works just fine, but if users want 'automatic priority calculation', you would recommend them to install the popularity.module. Anyway, this is still rough, so it's mostly to get an idea for how thing would be changed in xmlsitemap_node.module.
Comment #4
avpadernoThe patch proposed remove one the functionality of automatically calculate the priority of the node links. If the patch would be implemented the administrator of the Drupal site running XML Sitemap would have just two options:
Neither of the solutions are something I would like. xmlsitemap_node.module must work also without any third-party modules; by must work I mean that, in absence of third-party modules, the user doesn't need to manually set the priority of the nodes he wants to appear in the site map.
I would think rather difficult for somebody who is using XML Sitemap (and it's not interested in Popularity) accept that, if he doesn't wants to manually set the node priorities, he must install another module.
The changes I can do on the code of XML Sitemap are:
drupal_alter('xmlsitemap_priority', $priority, $type, $id).Comment #5
avpadernoIf there aren't any further comments, I will change this report to a task to allow third party modules to change the priority assigned to the links added in the site map.
Comment #6
avpadernoAs promised, I am changing the report to a task; this is the only thing I can do, as the feature request cannot be fulfilled.
Comment #7
avpadernoThis will be implemented in the 6.x-2 branch.
Comment #8
avpadernoThe feature has been implemented in CVS. Differently from how stated in my previous comment, third-party modules must implement
hook_xmlsitemap_priority_alter(&$priority, $type, $id, $sid), where$sidis a secondary ID associated to the link from the module that added the link in the site map database table.Feel free to re-open the issue if you think there would be improvements to the code.
Comment #9
avpadernoAfter adding the code in CVS, I thought the code could be made as general as possible.
The required hook should be
hook_xmlsitemap_data_alter(&link), where$linkis an object containing the following properties:loc,module,type,id,sid,changed,changefreq,priority, andurl; of those properties, only the following are inserted in the site map (therefore, are the only that is worth to change):changed,changefreq,priority, andurl.The difference between
loc, andurlis that the first is a relative URL in its canonical form (for nodes, it is in thenode/<nid>form, while for users is inuser/<uid>form), whileurlis the absolute URL that could also refer to a path alias.Comment #10
avpadernoThe code has been changed.
After third-party modules had the chance to change something, the data are validated again; if a module wants to avoid a link is added to the site map, it's enough it sets
urlto an empty string, orchangedto 0, orchangefreqto 0, orpriorityto a value outside the range 0,1 (extremes included).In no cases the modules should remove properties from the object passed to them.
I am not sure if the changes in the data should be written back to the database table (xmlsitemap).
Comment #11
avpadernoAt the moment, the code will stay as it is.