The settings page shows a list of preset search engines, but the settings page for each search engine is too generic: it doesn't show some preset values for the options it shows.
Being this the case, you could remove the preset list of search engines, and let the user insert the search engines he wants to have support for. The only difference from now is that the user would probably insert the name of the search engine in a form field that now is not present.

An alternative would be a wizard (multistep form) that would help the user in giving the correct informations (Which search engine? Google; which method do you want to use? File; What is the name of the file Google will look for? google3a55634fg.html; Done! Thank you; You are welcome).


Title:Add a wizard to help the user to enable the support for a specific search engineChange the settings page
Component:Code» User interface
Category:feature» task

Let me reformulate the report. The module offers already the possibility to have verification data for more than 4 search engines; still, the settings page is confusing for the users who would probably assume the module allow to insert data for only 4 search engines, 3 of which are already decided.
The setting page should show only the search engines the user has enabled the support for; when the user would add the support for another search engine, he would see a form where the first field ask him which search engine (Google, Yahoo!, etc...), and the verification data for that search engine (the required data doesn't change from search engine to search engine).

EDIT: the assumption that the module allows to set the data only for 4 search engines is taken also reading the project page that lists only 4 search engines; if the project page would list more supported search engines, then the user would at least ask how he can add the verification data for more than 4 search engines.

Status:Active» Postponed

This is pretty much what I wanted to do originally with a multi-step process:
1. Select engine type
2. Select verification type (could be both)
3. User enters details.
4. Verification is saved.

So if a user wants to edit an existing verification should the admin/build/site-verify/edit/x page look like? Should it go to step 3? Step 2? I think right now the general procedure is just fine. It's simple and it works. There's still some cleaning up to do on the verification listing page (admin/build/site-verify). So I'm going to mark this as postponed.

For an example of how the user interface should be, see admin/build/path.
Multistep forms are not required in a case like this, and my initial propose was not correct; that is the reason I changed the issue title, and I gave a different description for what I meant.

As I already reported, a list with four static item that are not even enabled is ugly.
To make a user interface like the one used for the path aliases would not take too much time, especially because the code of the module is not that much.

call me stupid, dumb and a noob,lol, but i can't even find a settings page for the module.. it shows a simple test check box in the xmlsitemap config page, but that's all i can find..

I found no ability to add more then 1 google verifications and my custom meta!

So agree with @KiamLaLuno module should give another tab to add new standard/custom verifications!

Module provides api to write own implementations but it seems like over-engineering because better to support 1 module not a bunch.

Assigned:Unassigned» Dave Reid
Status:Postponed» Active

I see your point about only being able to add one Google verificaiton, but you can still accomplish this with the module. You can add as many 'Custom verifications' as you need, and you enter the meta tag that Google asks you to add.

I've tried 6-dev version but both my meta tags added as plain text into head, example below

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="shortcut icon" href="/sites/all/themes/mgc/favicon.ico" type="image/x-icon" />

So whats about usability - this is not intuitive, suppose better to separate area with "Add actions" and list already added tags. The way to choose a style (meta or file) should be on 1 form not multi-step!

I *UNDERSTAND* that this needs work, thanks. Your point has already been made, so there's no use in repeating it.

Are you *SURE* that it's site_verify.module that's adding plain text in the head section? Because there's nothing in the module that *could* possibly do that:

* Implementation of hook_init().
function site_verify_init() {
// Add the verification meta tags to the front page.
if (drupal_is_front_page()) {
$query = db_query("SELECT meta FROM {site_verify} WHERE meta <> ''");
    while (
$meta = db_result($query)) {

Status:Active» Needs review
new3.27 KB

Sorry for noise, it was not clear to me...

Here patch:

1) Add comment field
2) reorganize administration: Add new at top with a list of available engines
3) changed edit form to support comment field

new3.28 KB

Changed "Add new" to "Add new verification"

Let's keep the 'comment' field part separate in #524408: Add field for description of "Custom verification".

Committed basic 2-step verification addition form and revised verification listing. Please review the latest code in CVS.

Status:Needs review» Fixed

Committed some cleanups to the multi-step form code and menu loaders today. I'm considering this fixed now. Thanks everyone for your help.

Status:Fixed» Needs review

Why not replace Add link with this form on listing page? And 2 Add links on page could confuse users (one in tab and another at the bottom of table).

From other side having add at top and at bottom of list is useful when list is large, but suppose it is not this case.
Anyway let's review

We don't add node forms on our content listing pages. We don't add a user form on the user list pages. This is the pattern set by core and should be followed by contrib.

I removed the bottom 'Add' link since yes, it's most likely not going to end up as a long list. Not sure what else needs review here...

I guess we could review splitting this into a 3-step form with the proposal in #3. But then if the user wants to add a meta tag to an existing file-only verification, they have to go through two steps again. I guess we could just add some JS magic on the 2nd step in the form to either show or hide the meta and/or file verification settings based on what type of verification the user wants.

I guess after reviewing things, what might make this easier is to split the list and form into two different tables/forms. One for meta tags, one for files. I'll try and come up with some mockups so we can decide how to proceed.

@Dave Reid Agree exactly with #17

But strongly against using 3-step wizard! JS solution like admin/user/settings for avatars but select list looks more usable if there's more then 2 options.

This moment needs review (maybe not a good word... discussion) because current form is not intuitive for users

Status:Needs review» Active

@Dave please, keep in mind about #524408: Add field for description of "Custom verification"
Listing should inform users about what each line for.

Status:Active» Needs review
new27.13 KB
new23.38 KB

Ok here's two quick mockups for the admin page.

1. All in one table, but styled rows for the separation.
Pros: All in one table. No difference in the 'Operation' columns like in #2.
Cons: A little more code, but that's a *minor* con. Not as separated as #2.
admin option 1.png

2. Two separate tables for meta and files.
Pros: More separation between the two so it's clear that they are different types.
Cons: The columns between the two tables can vary in width depending on contents, so it just looks odd. Doesn't look as natural.
admin option 2.png

First screenshot seems better; seeing the columns all aligned seems better than seeing them as in the second screenshot.

+1 for first screen but I still prefer using comment not a contents which is less informative

I understand that you prefer using comments, but I do not want to mix the patches. We can look ahead and plan a solution that will work with comments, but your point has been made already.

I'm voting for option 2 :).
The additional data for files and meta tags can be different.

I can't even find in the settings page.

Not in the menus, and following /admin/build/site-verify takes me to the main site settings page with the list of all the other modules' controls

@agharbeia: Are you sure you enabled the module?

Yes, I have. And just double checked and tried again to be sure

And when it didn't work, I uninstalled it (along with Nodewords) and started from scratch, to no avail.

I have to mention that I had a problem with nodewords 6.x-1.2 because I had upgraded from 1.1 and it didn't work at first, but once I uninstalled them both and reinstalled, Nodewords worked as expected, while Site Verification have not.

@agharbeia: I want to be sure. There is a module called "Site verification" that's included with the nodewords module package. This is not this module. You'll notice that this module is enabled under the 'Other' group of modules at admin/build/modules. The nodewords version is under the 'Meta tags' group of modules. This was an unfortunate case of someone naming a module after an existing module. It should be changed in the next version of nodewords.

Oh my! Stupid me.

My modules list is so long, I use page search and I stopped on the first occurrence.

I found it and it's working as expected. Sorry for the confusion and for wasting your time.

On a side note, I was just thinking that module grouping may require rethinking and/or central advice/control since many of them go in the most unexpected, redundant, or irrelevant groups.

new32.07 KB

Here's a test screenshot for possible interface on the D7 version. I'd like to get feedback on this direction as its probably my favorite.

new31.86 KB

Actually here's the one I'm leaning towards since I will probably want to keep these separate.

The second is better, indeed.

+1 for #35

Cool, I'm going to go ahead and split up files & metas in the schema, backend and UI then like this.

google webmaster tools tells me this way:

<meta name="google-site-verification" content="hugecodexptozyzyzyyzyzyzyzyzzyyzyxyzxcz" />

for meta tags, while you don't decide on which engines to support, id suggest having 2 text boxes:
meta name
meta content
then have the module create the meta tag with the info from the boxes.


@LPCA: The problem is that Google gives you the entire HTML to copy/paste and not those individual strings. If we have two text fields, users have to go in and manually delete characters, copy, paste, delete more characters, etc. How exactly is that easier for end users? We should just prefer they paste in the entire tag, but validate it.

As users would get a single string to copy, it is better for the module to require a single input; it's easier to copy a single string than to copy two different parts of a string in two different textfields.

ok, but users can get confused (ix, if you just input the string content (in my example, hugecodexptozyzyzyyzyzyzyzyzzyyzyxyzxcz), it gets printed in the site at the top, and doesn't go obviously in the header

a better explanation or 2 text boxes could solve confusion.

Category:task» feature
Status:Needs review» Needs work

documentation needed- perhaps a description above the field, stating what to copy?