I've created a small but useful patch for your wondercraft module. It makes the following:
1. Add a module settings page (menu item) and appropriate permission.
2. Allow optionally enable "Description" field, as proposed in Issue:#699546. I decided it shouldn't be an optional submodule, since it doesn't add any separate functions like "node create placeholders" or "path autocomplete". But the field is disabled by default to confirm with current behavior.
3. Allow to fine-tune "Title" and "Path" fields width to use page width in the most efficient way.
4. Remove "Delete" checkbox labels: there is no need to leave them due to the table header, and they consume the precise page width.
5. Add an option to select how many empty rows to add at the form end (8 by default, as it's now).
6. In the function menu_editor_get_path_for_placeholder() hook call replaced with the menu_editor_get_placeholders() function call. It makes the module invoking menu_editor_placeholders hook just once instead of two times (one for each of the two functions mentioned above).

Attached are both patch file and the complete module files, since it seems not every drupaller has some tool to apply patches (BTW, I don't have one for Windows :( ). I'd be glad to help with the patch and with the module development any further.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

donquixote’s picture

Title: Module settings page / Several changes proposed for dev branch » Several changes proposed for the development branch

Nice!
I would like to publish a stable release before adding new features, but at the moment I lack the time for testing. If you can help test the dev snapshot, we can move on :)

-------

Regarding your proposed changes:
Most of my design decisions so far there were motivated by some usability tradeoff considerations. These are not perfect, but I think they deserve some discussion.

1. module settings page.
I knew this would come some day, but for now the lack of module settings makes upgrade and downgrade easier ..
An alternative to module settings is to have controls on the menu editor page itself, such as some javascript to collapse and expand table columns, or switch the description field on and off.

I think a settings page makes the most sense if different sites have different requirements. For this module I rather think that on a typical site there can be all types of requirements in a mix. Some settings would make sense to do per menu (system nav does not need descriptions), other settings would be per user or per theme, but a lot of them would be completely dynamic: One time you want to see the delete checkboxes, another time you don't.

I'm not totally against settings, just would like to invite a bit of brainstorming :)

2. description field setting.
see above.

3. column width setting.
Should this be per theme? Or per menu? Or completely dynamic? Or should it depend on the length of text in these fields?

4. Remove "Delete" checkbox labels.
The reason to have them was to remind people to "be careful, this will actually delete the item!", because we have other checkboxes that look the same. Maybe the same could be achieved with a delete icon, or a strikethrough effect. And a confirm page for deletion!

Another possibility would be to have this column collapsed by default. If you want to delete an item you first have to expand the column, then you see the checkboxes with labels.

5. Option for number of empty rows.
I think there are two use cases: (i) Build a huge menu tree from scratch. (ii) add a few items to an existing menu tree. Both can happen on the same site, so I don't think there should be a permanent setting.

Instead, I would prefer to have a "+" button, or automatically add fields by javascript when the existing ones are full. The problem is that we need to tell the forms api about the added fields. Usually this is done with AHAH callbacks, but these tend to be slow. Another thing we could try is to add the fields in the validation handler.

EDIT:
Maybe you also noticed this piece of text on the module page, which is another approach for adding a lot of items:

Textarea for new items: This would allow your client to write a menu structure (consisting of page titles) in a text editor of his/her choice, structured by indentation, without ever touching the admin backend. You (the admin) paste that thing in a textarea, and the new structure is merged into the existing menu tree.

6. menu_editor_get_placeholders() refactoring.
Makes sense.

donquixote’s picture

Title: Several changes proposed for the development branch » Module settings page / Several changes proposed for dev branch

Let's make the title more inviting and meaningful for other readers!

marrch_caat’s picture

Title: Several changes proposed for the development branch » Module settings page / Several changes proposed for dev branch

Most things you tell make great sense. Well, probably I should start with building efficient JavaScript-powered interface with collapsible (and resizible) columns etc. But it'd take much more time. And it would partially break the general idea to retain most of functional and design requirements even if JavaScript isn't working in client's browser.

1,2. Yes, there could be all types of requirements mixed up on the same site and the proposed solution isn't ideal. But it's still better than nothing :) I mean, the main idea as I got it is to make all or most of changes on the same page without zounds of page reloads, submits, redirects etc. And this mean that the description field should obviously be there as well. But on the other hand, sometimes site admins just do not care for SEO and readable titles - mostly on the stage of development and testing - and the field would just consume space. So in most cases it'd be good to have this column disabled during development etc, and enable it afterwards for site editors. And if it's needed, it's no problem to change it, work, then change it back.
As I told, it's still better to be able to do this than being unable to change the behavior you do not like. And it's even worse when I use the wonderful PoserEdit mode, one-two-three-bang! - it's all there, the menu is changed... and then I go to built-in menu editor and start editing menu items one by one to add or change descriptions. Don't you think it's just silly?..

3. I don't know. But, again, I think it's better to control something than not, if it costs almost nothing. And if there are only a few (and often it means one!) editors on the site, it can be good to fine-tune the width according to his or their monitor width.

4. Hmm, it makes sense... Probably there should be aconfirmation dialog when some menu items are selected for deleting. OK, I'll do that, it's simple. Thanks for the idea.

5. Again, I think there could be many cases on the same site, but mostly only one case at a time. When the site is being built, there could be as many as 20 and even more empty rows at a time to make the work more efficient. When the site is being maintained, there should seldom be need to add many menu items at a time, and there should be 8 or even 4 empty rows to save page size, browsing rendering resources etc. So it's again better to be able to change the behavior according to known usage patterns for specific site, than being unable to do that.

My own opinion is that until we have a good JavaScript-powered interface (which I'll try to create soon), it's good to be able to tune the interface by using settings page. And even when we got one, it could be good to keep at least some setting for fine-tuning default settings and setting for not JavaScript-powered browsers.

marrch_caat’s picture

BTW, I did my best to test the dev version and found no problems, but I can't spend enough time on thorough testing in different environments to be absolutely sure. I'd release the current snapshot as the next minor release, though.

marrch_caat’s picture

FileSize
6.37 KB

ATTENTION: if someone is interested in the patch I provided, there is a bug in it. Attached are the fixed sources based on the current 1.x-dev snapshot!

donquixote’s picture

There is yet another idea that has been floating around in my head for a while:
Different sub-tabs for special use cases.
For instance, one sub-tab with an interface that is tailored to description editing. Another that is designed for adding a lot of items.
Alternatively, we could introduce some url parameters to customize the form. This would all be independent from javascript.

----

For the settings page I think it could be nice to have that in a tiny submodule. If the submodule is disabled, some default settings will be used. If it is enabled, it will override the defaults with values from the database. It can all be done with hook_form_alter, I think. This way the core module remains light-weight and easy to maintain. And, if the submodule causes a bug or incompatibility with something, you can simply switch it off. That was my philosophy for the other submodules as well..

I think the settings should be stored in variable_get('menu_editor_settings'), not as individual items. This way you only need one call to the database, and it's easier to clean up junk settings from older versions - simply overwrite with the new array.

----

Btw, your patch does not look like unified diff format.

----

Testing:
Most important things to test are multilanguage and content creation. I think there are some usability problems:
- The "under construction" text can't be customized or translated.
- The content creation form is irritating for some people. A better description on that page could be a good first step.

donquixote’s picture

2. Allow optionally enable "Description" field, as proposed in Issue:#699546.

Dev snapshot (6.x-2.x) has a description field, that does not need to be optional.

6. In the function menu_editor_get_path_for_placeholder() hook call replaced with the menu_editor_get_placeholders() function call.

Fixed in dev snapshot.

5. Add an option to select how many empty rows to add at the form end (8 by default, as it's now).

I am still thinking about an intelligent solution for this, that works without a settings page.

donquixote’s picture

Status: Needs review » Closed (works as designed)

I mark this as "by design" for now. If you are not happy with this, please have a look which of the suggestions are still relevant today.

5. Add an option to select how many empty rows to add at the form end (8 by default, as it's now).

This will be fixed in 4.x series, with the help of multicrud (which allows to add any number of rows dynamically, all on client side).

Daniel Wentsch’s picture

@donquixote (#6)

I also needed to translate the "Under Construction" String.

I simply hacked the function menu_editor_under_construction() in menu_editor_node_creation.module like this:

  // Make the "Under Construction"-String translatable
  $underconstruction_title = t('Under Construction');
  drupal_set_title("$item[link_title] - $underconstruction_title");

Maybe something like this could make it into the next release?

donquixote’s picture

Is translatable enough, or do we need configurable (also in English)?
Besides, can you open a new issue? This one wants too many unrelated things at once.

Daniel Wentsch’s picture

Okay, I opened a separate issue for this: http://drupal.org/node/1037880