When I was writing the xmlsitemap_engines.module in 6.x-2.x, I took a look at the current 6.x-1.x module and I frankly think it is way too complex for it's own good.

1. Why are users allowed to change the submission URLs of search engines? If users want custom submission URLs, give them a textarea to put them in.
2. The verification code/interface is jumbling things up and frankly is not *required* in order to submit the sitemap to search engines. In the case of Google Webmaster Tools, you only need to verify ownership to see advanced crawling statistics.

As I've done in the 6.x-2.x engines module, I propose cutting this stuff out. I have already started a general search engine Site verification module. So it can be re-used by people and when they have verified their sites with all the desired search engines, they can simply disable the module.

To show how simple I think this module's interface should be, I have attached a screenshot of the current 6.x-2.x engines interface (ignore the security warning and the development teaser). Compare that to the current 6.x-1.x interface. Yes, I still need to implement the 'submit every x' setting, but you can see the difference in simplicity between the two.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

apaderno’s picture

The purpose of allowing the user to change the submission URLs is to allow them to update it when the search engines would change it.
That is code that has been developed before I became co-maintainer, and I left it there. Actually, I think that the possibility that the search engines would change the submission URL is remote, and that part can be probably removed.

About the verification data fields, I agree that they can be removed, if the user get the right informations about what to do, and which module install. Until the module you are talking of does not have an official release, I would prefer to keep those form fields.
Take in mind that maybe the search engines will ask more than once for the verification file (at least that happened to me more than once, without adding a new sitemap), and maybe the user will keep the module installed.

Dave Reid’s picture

I just created the first official release of site_verify.

In response to #1, I'd say that if search engines change their URLs, we can always make sure we update the module. Easy as that. :) Yeah, and users can decide when they want to disable/remove the search engine verification module.

apaderno’s picture

The module is well done, and it has more options that XML sitemap could not offer, like the possibility to upload the verification file.

The only thing I can report is that the module is too generic in the settings page; the page for the settings for Google shows the same options, and default values shown for any other modules. As I reported in #467582: Change the settings page, you could remove that list of predefined search engines, and let the user add to the list any search engine he wants.

If the module shows the same form fields for any search engine, to say that it supports Google Webmaster Tools, Google Apps, Live Search Webmaster Central, and Yahoo! Site Explorer is not exact; it would support any search engine without the need to add new code. The only code to change in the module should be the part that shows a static list of 4 entries, and remove the limitation of 4 search engines.

Dave Reid’s picture

Status: Active » Needs review
FileSize
7.13 KB

Here's the patch to remove all the verification code from xmlsitemap_engines for review.

Dave Reid’s picture

The only code to change in the module should be the part that shows a static list of 4 entries, and remove the limitation of 4 search engines.

Kiam, you did see that the site_verify has the 'custom' engine to add verifications for any other engines right? And that the custom engine can be added over and over again?

apaderno’s picture

I saw that; still that static four entries are not required.
Just to make an example of what the Drupal core code does, does path.module have a static list of four or more path aliases that still need to be enabled from the administrator user?

apaderno’s picture

Status: Needs review » Postponed

As I already explained, this task is postponed.

Anonymous’s picture

Assigned: Unassigned »
Anonymous’s picture

Status: Postponed » Postponed (maintainer needs more info)

I've disabled the user being able to modify the search engine ping using [#disabled] = TRUE for 1.0. Should I bother with the verification code removal; seeing that 2.x is looming close?

Dave Reid’s picture

I think it's worth removing since we already have Site verification module.

Dave Reid’s picture

I would suggest removing all the verification stuff from hook_menu() and the interface, but don't delete the variables (but still delete them on uninstall however). I'm writing an "import" path in site_verify to import any of the variables if xmlsitemap_engines.module hasn't been uninstalled:

function site_verify_import_xmlsitemap(&$ret = array()) {
  if (!db_result(db_query("SELECT 1 FROM {site_verify} WHERE engine = 'google'"))) {
    if ($google_file = db_escape_string(variable_get('xmlsitemap_engines_google_verify', ''))) {
      $ret[] = update_sql("INSERT INTO {site_verify} (engine, file) VALUES ('google', '$google_file')");
    }
    variable_del('xmlsitemap_engines_google_verify');
  }
  if (!db_result(db_query("SELECT 1 FROM {site_verify} WHERE engine = 'bing'"))) {
    if ($bing_file = db_escape_string(variable_get('xmlsitemap_engines_bing_verify', ''))) {
      $bing_content = db_escape_string(variable_get('xmlsitemap_engines_bing_verify_string', ''));
      $ret[] = update_sql("INSERT INTO {site_verify} (engine, file, file_contents) VALUES ('bing', '$bing_file', '$bing_content')");
    }
    variable_del('xmlsitemap_engines_bing_verify');
    variable_del('xmlsitemap_engines_bing_verify_string');
  }
  if (!db_result(db_query("SELECT 1 FROM {site_verify} WHERE engine = 'yahoo'"))) {
    if ($yahoo_file = db_escape_string(variable_get('xmlsitemap_engines_yahoo_verify', ''))) {
      $yahoo_content = db_escape_string(variable_get('xmlsitemap_engines_yahoo_verify_string', ''));
      $ret[] = update_sql("INSERT INTO {site_verify} (engine, file, file_contents) VALUES ('yahoo', '$yahoo_file', '$yahoo_content')");
    }
    variable_del('xmlsitemap_engines_yahoo_verify');
    variable_del('xmlsitemap_engines_yahoo_verify_string');
  }
}

I'd also add this update to xmlsitemap_engines.module:

function xmlsitemap_engines_update_nextnumber() {
  $ret = array();
  if (function_exists('site_verify_import_xmlsitemap')) {
    site_verify_import_xmlsitemap($ret);
  }
  return $ret;
}
Dave Reid’s picture

Status: Postponed (maintainer needs more info) » Fixed

Search engine verification settings have been removed in 6.x-1.x CVS (http://drupal.org/cvs?commit=259918). Upgrade path is provided:

/**
 * Deprecate verification functionality in favor of the site_verify.module.
 */
function xmlsitemap_engines_update_6111() {
  $ret = array();
  if (function_exists('site_verify_import_xmlsitemap')) {
    site_verify_import_xmlsitemap($ret);
    if ($ret) {
      // Only show the success message if there were any settings migrated.
      drupal_set_message('XML sitemap search engine verification settings were successfully migrated to the Site Verification module.');
    }
  }
  else {
    drupal_set_message('The search engine verification settings in XML sitemap have been deprecated in favor of the <a href="http://drupal.org/project/site_verify">Site verification module</a>. Your settings will be migrated when you install and enable the Site verification module.', 'warning');
  }
  // Set the menu rebuild flag to remove the XML sitemap engine paths.
  variable_set('menu_rebuild_needed', TRUE);
  return $ret;
}

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

AlexisWilke’s picture

Dave,

Could you put a link on the home page of this module to the Secure Verification module?

That way, silly people like me can find the module really quick! 8-)

Thank you.
Alexis

Anonymous’s picture

@AlexisWilke: Good suggestion but please open a new issue.