From reading the code, the block is only displayed during adding/editing (not when the node is being viewed). From playing around in Drupal 7, it does not appear that any blocks (of any kind) are displayed on these pages. I tried two different sites, both with and without the overlay module.

(In my custom module, my node add form is on a non-standard path, which causes blocks to be displayed. This confused me for a while.)

If this is indeed the situation in Drupal 7, then the whole block UI and codebase can be removed.

If I am mistaken, the configuration checkboxes for the widget and block need, uh, refinement.

CommentFileSizeAuthor
#5 uniqueness-string-cleanups-1893808-4.patch2.81 KBbforchhammer

Comments

bforchhammer’s picture

bforchhammer commented
Category: bug » support

Blocks do work on node-add/edit pages. Note that the block layout is theme-specific, i.e. if your site uses an admin theme (which it does by default), you need to configure the uniqueness block on that theme instead of the default one. The overlay also uses the admin theme by default.

Alternatively you can disable the option to "Use the administration theme when editing or creating content " on admin/appearance.

Does that fix it?

danchadwick’s picture

danchadwick commented
Title: Block is never functional. » Block not displayed by default for admin users; needs documentation in UI
Category: support » feature
Priority: Major » Minor

Ahhh, thanks!

I will write a tiny patching putting that tidbit of info into the configuration page in a '#description', since the out-of-the-box experience is that you configure the block, place it in an appropriate region and don't see it.

danchadwick’s picture

danchadwick commented
Title: Block not displayed by default for admin users; needs documentation in UI » Misleading and/or poor word choice in option descriptions / default choices
Status: Active » Needs review

Rather than submitting patches (because I'm out-of-sync right now), I thought I'd address three wording issues:

1. Instead of (uniqueness_default_description appears twice, once in .module and once in .admin.inc):

Help us increase the signal to noise ratio! If we find content that's related or similar to what you're posting it will be listed here.

I suggest:

Avoid duplicate content! Similar or related content:

2. Instead of existing uniqueness_widget (in admin.inc):

Display related content inline, embedded on the "node add" form.

I suggest:

Display related content embedded within the create or edit content form.

With a #description of:

Note: administrators may not see blocks on the create or edit content form. See the [a href="/admin/appearance"]Administration theme[/a] settings.

3. Instead of the #description for uniqueness_default_title of:

Note: when using the widget as a block then this title can be overriden[sic] by the block title on the !block_settings_page.

I suggest avoiding the non-standard term "widget":

Note: When displayed in a block, this title may be overridden on the !block_settings page.

Note that I removed "page" from the link.

If these suit you and you don't mind, perhaps you could just makes these changes and commit them. If you want a patch from me, it will need to wait until I can get back in sync with you. Thanks much!

bforchhammer’s picture

bforchhammer commented
Status: Needs review » Active

I've committed the attached patch.

Not sure about the note on the block/admin theme thing; I don't feel like that's something that needs to be explained explicitly as it's standard drupal behavior; maybe rather put it onto a handbook page or possibly into the readme file?

bforchhammer’s picture

bforchhammer commented
StatusFileSize
new uniqueness-string-cleanups-1893808-4.patch2.81 KB

Mentioned patch (already committed).

danchadwick’s picture

danchadwick commented

My thoughts. Feel free to accept or reject as you see fit.

1) I suggest "Display related content embedded on within the create or edit content form." I think the within is the proper preposition for embed.

2) The theme setting option to hide blocks on the form editing pages is almost guaranteed to confuse the administrator. Creating a block this is invisible to the admin by default warrants a warning. Given that I was confused despite having worked extensively on the module I think is proof either of my incompetence or the need for a warning. I prefer the later explanation. ;) I never saw those options because I never scrolled down below my theme previews.

3) You have "Help us avoid duplicate content! If we find content that's related or similar to what you're posting it will be listed here." This is anthropomorphizing the site. There is no "we". If someone wants a chatty / informal site, they are free to customize this setting, but the default should be succinct and professional in the Drupal (particularly Drupal 7) style. I prefer "Avoid duplicate content! Similar or related content:". Also, shorter instructions will more likely be read and followed.

4) The path for administering the block seems to be wrong. I get it as "admin/structure/block/manage/uniqueness/uniqueness/configure". That's the path the "configure" button gives, although "configure" seems to be optional. Odd. Unless I'm missing something?

5) I suggest "Note: When displayed in a block, this title may be overridden by setting the block title on the uniqueness block settings page." It's shorter and just as informative.

bforchhammer’s picture

bforchhammer commented

You have obviously thought about this more than me. I'm okay with the proposed changes in #6 apart from the block settings one.

2) The theme setting option to hide blocks on the form editing pages is almost guaranteed to confuse the administrator. Creating a block this is invisible to the admin by default warrants a warning. Given that I was confused despite having worked extensively on the module I think is proof either of my incompetence or the need for a warning. I prefer the later explanation. ;) I never saw those options because I never scrolled down below my theme previews.

I don't mind adding a note and a link, but I'm not sure it should point to the admin theme section. I don't think that you would want to just disable the option to "Use the administration theme when editing or creating content" for this module, because it will move those forms out of the overlay for your users and thereby completely change the user experience for editing and creating content... Also, frontend themes are often not perfectly adapted to display those forms nicely, so things may even appear unstyled; in short, this is not something I'd advice anyone to do unless they know what they're doing.

So instead, maybe we can just add a link to the proper block configuration page... which would be the default theme one if the setting mentioned above is disabled, and the admin theme one otherwise. This should at least make it clear on which theme you need to configure the block. Would that work for you?

4) The path for administering the block seems to be wrong. I get it as "admin/structure/block/manage/uniqueness/uniqueness/configure". That's the path the "configure" button gives, although "configure" seems to be optional. Odd. Unless I'm missing something?

Right, I simply used the existing path which has obviously changed since D6; admin/structure/block/manage/uniqueness/uniqueness/configure looks like the correct one.

danchadwick’s picture

danchadwick commented

Re 2: I should preface this by saying that I don't have a horse in this race, so I'm not really invested in any particular solution. Following your logic, in the default situation, you would be directing them to the Seven theme, which has no side bar in which to put the block. Now you could put it in the content region, but this would be -- as far as I can imagine -- in every way less preferable than the in-line widget.

On the other hand, if the admin theme is not enabled (and it probably isn't), then (surprisingly) you cannot add the block to the admin theme's region inside the block's general (non-theme-specific) settings page. You instead need to go to the theme's tab, then configure the block.

Of the two solutions, I think pointing them at the theme admin page is still preferable. It is very likely that the user knows how to configure blocks -- or at the very least they are about to learn if they are to use the block option. OTOH, you could go forever and never see that checkbox to use the admin theme for content add/edit.

Maybe the most bang for the least work:

Note: administrators may not see blocks on the create or edit content form. See the [a href="/admin/appearance"]Administration theme[/a] settings and/or the [a href="admin/structure/block"]Blocks[/a] page.