nolink menu item should not be present in sitemap.xml

Here a patch to not include all special menu item links in XML Sitemap (those whose link_path starts with a "<" and ends with a ">")

It applies to 7.x-2.0-rc2

Forgot to change the issue status

The patch seems correct.

I used the patch to update the 2.0 version and everything works fine!

My question is: Why is this patch against version 7.x-2.0-rc2 not implemented in the final version 7.x-2.0?

Thanks,

JP

I've applied this patch and it too works in the latest 2.0 stable. Reminder to those searching that you need to rebuild your sitemap links for this fix to take effect.

Works. Let's get this patch committed.

Would it be better just to check if strpos($menu_item['link_path'], '<') === 0 rather than running a regex on each individual menu link? Would it also be good to change xmlsitemap_menu_xmlsitemap_index_links() to exclude these from the query?

Here's a patch to move things along; I've also included an update hook to remove existing records for special items.

A remaining task is indicating that the sitemap files need to be recreated afterwards, ideally conditional on any items actually being deleted.

There is also a gap in that if a menu item is changed to a special item, it will not be removed from the xmlsitemap table.

Patch #11 worked for me with current Commerce Kickstart 2.x (and special_menu_items).

Simply need to rebuild the XML sitemap after patching (admin/config/search/xmlsitemap/rebuild).

#11 works fine for me. Merge after review.

#11 works for me.

Hi,

Child menu links are not adding to sitemap. Please give me solution. I already updated this issue at https://www.drupal.org/node/2485337, but not received any update.

#11 not working for me. Using the version 7.x-2.2 of xmlsitemap module.

#11 works as expected.

1. +++ b/xmlsitemap_menu/xmlsitemap_menu.install
   @@ -45,3 +45,13 @@ function xmlsitemap_menu_update_6201() {
   +function xmlsitemap_menu_update_6202() {
   +  db_delete('xmlsitemap')
   +    ->condition('type', 'menu_link')
   +    ->condition('loc', '<%', 'LIKE')
   +    ->execute();
   +}
   

   Update hooks for 7.x-2.x should start with 72XX. This is also missing a flag to regenerate the sitemap if it does delete any records that were visible.

2. +++ b/xmlsitemap_menu/xmlsitemap_menu.module
   @@ -78,7 +78,7 @@ function xmlsitemap_menu_cron() {
   +    $sql = "SELECT ml.mlid FROM {menu_links} ml LEFT JOIN {xmlsitemap} x ON x.type = 'menu' AND ml.mlid = x.id WHERE x.id IS NULL AND ml.menu_name IN (:menus) AND ml.link_path NOT LIKE '<%' ORDER BY ml.mlid DESC";
   

   Does this affect the performance of the query at all? Should it be something that just stays in xmlsitemap_menu_xmlsitemap_process_menu_links() instead?

3. Do we need to document that this means menu links that point to <front> will no longer appear? I assume that's ok since we manually add in the front page.
4. We need tests to confirm that this behavior works. Also needs to test changing an existing valid link to a path to <none> or another invalid value, should affect the state of the row in the xmlsitemap table, which it seems like this patch does not account for. Instead of "skipping" these records, we should likely be setting $link['access'] to FALSE if the link_path is not a valid item.

So.. #19 suggests this patch isn't quite ready.

In the meantime, can anyone see any issues with using this to simply pull links out of the sitemap:

<?php
function MY_MODULE_xmlsitemap_link_alter(array &$link, array $context)
{
    $link = str_replace(array('<nolink>','<block>'),'',$link);
}
?>

It seems to work.

Applied patch #11 on project version 7.x-2.3 and modified query to apply the scape character '\' on NOT LIKE clause query:

SELECT ml.mlid FROM {menu_links} ml LEFT JOIN {xmlsitemap} x ON x.type = 'menu' AND ml.mlid = x.id WHERE x.id IS NULL AND ml.menu_name IN (:menus) AND ml.link_path NOT LIKE '\<%' ORDER BY ml.mlid DESC

Now, rebuild sitemap links and special menu items are excluded from sitemap.

I hope it helps!

Hi folks, better hook for removing element without db query is hook_xmlsitemap_link_alter. I am providing one sample code where element lists are removed by checking the path alias. Though if it can be managed by disabling that specific content type from back-end, that would be best. Suggestions are welcome.

<?php

/**
 * Alter the data of a sitemap link before the link is saved.
 *
 *
 * @param array $link
 *   An array with the data of the sitemap link.
 * @param array $context
 *   An optional context array containing data related to the link.
 */
function hook_xmlsitemap_link_alter(array &$link, array $context) {
  // Get node/[:id] from loc.
  $node_id = $link['loc'];
  // Get node language from $link array of element language.
  $node_lang = $link['language'];
  // Get path alias from node/[:id].
  $node_alias = drupal_get_path_alias($node_id, $node_lang);
  // Condition to check if path alias is set and exists.
  if (!empty($node_alias)) {
    $search_path = 'unwanted-alias';
    $pos = strpos($node_alias, $search_path);
    // Condition to check if path alias contains unwanted-alias string.
    if ($pos !== FALSE) {
      // Status is set to zero to exclude the item in the sitemap.
      $link['status'] = 0;
      // Set to zero to make the element non-accessible by the anonymous user.
      $link['access'] = 0;
    }
  }
}
?>

I am also using a custom module like #20. As far as I can tell it works fine. Thanks.

#20 is not exact hook (&$link is an array). Try this:

function MY_MODULE_xmlsitemap_link_alter(array &$link, array $context)
{
  if (in_array($link['loc'], array('<nolink>','<view>','<firstchild>','<separator>'))) {
    $link['status'] = 0;
  }
}

<nolink>,<separator> - are from Special menu items module
<view> - is from Menu Views module
<firstchild> - is from Menu Firstchild module

also add
<block>

it's from megamenu module

function MY_MODULE_xmlsitemap_link_alter(array &$link, array $context)
{
  if (in_array($link['loc'], array('<nolink>','<view>','<firstchild>','<separator>','<block>'))) {
    $link['status'] = 0;
  }
}

Re-rolling #11 since it doesn't apply to release 7.x-2.7