Not sure quite where to post or how to submit.. but, here it is...

I thought the menu edit function of the existing (4.7 and 5.0) menu.module kinda sucked.. so i fixed it (for 4.7).

you can check out this post: http://drupal.org/node/97482

And i will attach screenshot and new module files here. Haven't done too much testing.. just whipped it up since I was whining about it.. so figured i would fix it.

sorry can only attach one file here.. silly... so screenshot is here: www.liquidcms.ca/menu.jpg

Peter Lindstrom
www.LiquidCMS.ca

CommentFileSizeAuthor
#18 menu.0.4.zip9.03 KBliquidcms
#16 menu.0.3.zip9.04 KBliquidcms
#10 menu-0.2.zip9.04 KBliquidcms
menu.zip8.5 KBliquidcms

Comments

marcoBauli’s picture

marcoBauli commented

+1

rearranging menu items is pretty painfull specially when configuring a site for the first times ("could you move -automotives- before -gadgets- ?.. oh, sorry, i think is better to sort them alphabetically..") or when you have to add a new item in between other two "4" weight items, and you have to rearrange all the others to make it fit in.

These are just couple of itchy bits, and bulk editing would be very handy imo.

@palindstrom: looking at your screenshot, where has the "disable" link gone? :o

the discussion is also going on at http://drupal.org/node/97482

liquidcms’s picture

liquidcms commented

disable isnt gone... (or was that just a request?) the menu i have changed is the "menu edit" fucntion.. which has NOTHING in it now but being able to change the menus name;

the main reason for my quickly throwing this together (took me a couple hrs), was for exactly what you mentioned.. i needed to re-arrange some items... i also wanted to do a checkbox for mass delete (i have half the code in place now but commented out)

i will likely add a few things in the next couple days:

- disable (as you mentioned) - maybe with a checkbox for each row and a pull down for bulk function to do (delete, disable, ???)
- path
- expanded

others???

ALSO - if anyone could hint at why when i return to the menu edit form from doing an action like "edit menu item" - selected from that form" - the changes arent shown (although they have been done)

dman’s picture

dman commented

First - the hint is that menu_get_menu caches intensely (it bloody well needs too) but this means that
- the menu structure is loaded and cached every visit to each page
- your edits get processed successfully
- your display retrieves the menu to display, and gets the results that were valid at the beginning of the page (but have changed).
... I can't recall if there's an easy cache clear. Try invoking _menu_build() after you've made your updates and see if that helps.

Second - I'd be behind this if I could see what I've been missing for ages - bulk operations. like the checkboxes on content management screen with a 'do this action' - delete or disable - for many items at once.
I looked at doing it myself, but was daunted by the total conversion to forms API that seemed to be needed. And the curious tag/table structure used by the original menu manager.

.dan.

chx’s picture

chx commented
Version: 4.7.3 » 6.x-dev

Feature requests are against 6.x

Concentrate on the frontend. Menu backend will change dramatically in D6.

RobRoy’s picture

RobRoy commented
Status: Active » Needs work

ptalindstrom, can you post a patch for HEAD using the guidelines at http://drupal.org/diffandpatch? That will give this the best chance of getting looked at.

liquidcms’s picture

liquidcms commented

dman:

- thanks , i figured it might be a caching thing; i'll take a look.
- also, i might look at adding bulk operations today

chx:

- not sure i get your reply?? are you suggesting i should just put up with existing menu module until sometime next year when 6 comes out? I guess part of this is i havent become a part of the real decision making team here (yet)... for example, i dont get the "minor" tweaks done for 5.0 - seems more like 4.8 to me?? and i don't have visibilitty of what is on the way for 6 (or, more important, input into this) - although i am sure this is just because i havent gone looking for it
- perhaps if i make a very good menu improvement, and it becomes widely used - it will be pulled into core? although that hasnt worked for i18n for example.

robroy:

- never done a patch although started looking at it for something else a few days ago - i'll look at throwing one up

ALSO - not sure it matters too much - but perhaps someone could push someone into setting up my drupal cvs account??? i applied for it over 2 weeks ago.

liquidcms’s picture

liquidcms commented

hey dman,

yes, it was a caching thing - adding this when updating an item fixed the problem:

cache_clear_all("menu:1:", true);
liquidcms’s picture

liquidcms commented

BTW

since i am having trouble gettng a CVS account here... updates to this module can be found on my site at:

http://www.liquidcms.ca/node/111

Crell’s picture

Crell commented

ptalindstrom:

- Drupal 5 is already frozen against new features, and will probably go into release-candidate phase soon. No matter how good your new menu alternative may be, it's not going into Drupal 5 because Drupal 5 is prepping to ship. :-)

- The number versioning system was changed with Drupal 5, so there will be no more three-digit-releases. What comes after Drupal 5 will be Drupal 6, and after that Drupal 7, regardless of how much has changed.

- If you want more insight into what is on the horizon, join the development mailing list. The big plans for the menu system were discussed at DrupalCon in person by people there (mostly the big core dev team) and then previewed on the list. Without going into too many details, the entire method of finding a menu entry is getting pushed down into SQL where it's substantially faster. That doesn't mean the UI couldn't stand improvement, of course. But core won't be considering that until Drupal 5 ships and folks start working in earnest on Drupal 6.

- If you want to contribute stuff for core, do it in small bits rather than big chunks. A "new, rewritten menu module" is going to get largely ignored, in no small part because it's too much to swallow at once. However, "a patch that makes the UI cleaner" followed by "a patch that makes the API faster" followed by "a patch that makes the engine faster" are far more likely to get attention and get accepted. "I have great big plans that will change the world" is likely to get you ignored by any open source project if you're not already a proven core team member who has already changed the world a few times. :-)

liquidcms’s picture

liquidcms commented
StatusFileSize
new menu-0.2.zip9.04 KB

sounds good.. thanks for the tips...

but, the bottom line is still.. i needed a better UI since it is pretty much impossible to re-arrange menu items with the current module... Drupal 6 is likely a yr away.. too long to wait; i had to change it..

if no one wants to use this - fine by me (just trying to help out); if it doesnt get put in core for 6 (or something similar that fixes the UI) and i figure there is something else in 6 that i need that has me upgrade... then i guess i will re-write it again for 6...

my hope is STILL.. that possibly enough people will see this post; try it out and find it impossible not to want to keep it since so much easier to rearrange items (plus many other things) - that by the time 6 comes around.. it will be the defacto standard as far as UI goes.. or at least point to how it should be... (actually some ajax inhere would be good; but i'll hold off on that for now)

but, if what you say, that becuase i have said it is much better than what we have now.. means it gets ignored.. well, that would seem silly.. but you could be right.. :(...

all that being said.. i have attached my version 0.2 which adds:

- can set path
- can set description
- disable (can't really do enable though since core menu function i use to pull out menu items [menu_get_menu()] won't pull out disabled ones (which it should be able to do - or i could write my own function to pull them all out - but not today)
- set expanded or not
- add CSS to shrink table a bit to fit things in better - so menu.module is now a folder (and you need to remove the menu.module single file in modules folder

as always, hope it helps .. it sure helps me.

peter...

liquidcms’s picture

liquidcms commented

oh yes.. and, as before screenshot, latest code, and version history can be found at:

http://www.liquidcms.ca/node/111

chx’s picture

chx commented

a) changes this big can't make it into 5.0 , we are way past feature freeze, past beta1 , close to beta2/RC1.

b) I will rewrite the menu backend for Drupal 6.0. I have been pretty vocal about this, on DrupalCon, on development list, my devblog.

liquidcms’s picture

liquidcms commented

sounds great.. i had no idea that the backend for menu needed work; but i'll take the word of people like yourself and Crell that it does.. and if you are on top of that for 6... even more cool

I tend to (almost always) be more concerned about UI... how long it takes me to set up a site or how can it be someting that i can give a client to manage - i am rarely working on a site with 10,000 nodes and hundreds of menu items where core performance is an issue - people performance is usualy more the issue.

I took a look at your blog - didnt really get it; but, then it isn't UI thing - so i will simply assume it is in capable hands :)

maybe if someone could point me to the discussion topic (posting/blog/etc) on what is expected/wanted/planned/etc for menu UI for 6 (not to mention other admin functions) - then maybe i could throw in my $0.02 worth.. and maybe even do some coding...

cheers,
peter...

btw - again... i do get that this isnt going to go into 5 , likely isnt going to go into 6 - but i REALLY needed it and it REALLY is better than current module.. and I just thought some others might find it usefull

chx’s picture

chx commented

No UI work is planned that i know aside from this issue,

That's what I said earlier: please continue this work , it's great someone gives much needed love for the menu UI. You redo the admin interface, I redo the backend :)

Crell’s picture

Crell commented

If you want to get a UI overhaul like this into Drupal 6 (and from the screen shot it looks promising), then starting with a screen shot is probably best. :-) Get feedback on a mockup of what it would look like. It's easier to modify if people have comments and suggestions. Then roll a patch against core that implements this interface (rather than making a new copy of menu.module) and post that. It will go through a few more review cycles. Good patches always do. :-) I don't know if the API for accessing menu data is slated to change, but the engine work I know of that's on chx's todo list probably won't impact the UI too much so you can get started now if you'd like. Be aware, however, that this issue likely won't get much if any attention until after Drupal 5 ships, as all of the big people are busy making that happen first. It will likely get noticed again after HEAD opens up again, especially if you start an issue thread on it (or wake this one up) then, when people are more inclined to look at Drupal 6 changes.

liquidcms’s picture

liquidcms commented
StatusFileSize
new menu.0.3.zip9.04 KB

I noticed that the path "url aliases" were not being maintained in the menu edit form. Discovered this is due to (a bug in) menu.inc function menu_get_menu() that i was using to retrieve menu structure. I redid my routine using basic db_queries and we now have path aliases in tact.

Although new routine is quicker than what i had - it would be quicker if menu_get_menu() was fixed and i called it just once (i.e. set as global in recursive routine). I didn't want to edit menu.inc though since it is part of the core (althuogh i guess so is menu.module - but i can still distribute as a module if i don't need to modify menu.inc)

new code and info at: http://www.liquidcms.ca/node/111

liquidcms’s picture

liquidcms commented

BUG - just noticed that pagination screws up the first entry at the top of each page; will need to look into this; but ver 0.3 also has paging at 40 rows; so need a reasonable menu before this will come into play.

liquidcms’s picture

liquidcms commented
StatusFileSize
new menu.0.4.zip9.03 KB

fixed pagination bug - but not sure i really like the idea of paging this; why not just have REALLY long pages... even if 200 or more menu items???

anyway, left paging in; but increased rows per page to 50.

Crell’s picture

Crell commented
Status: Needs work » Postponed

Please don't post complete modules in the issue queue. That's not what it's for. If you want to maintain a 4.7-targeted alterna-menu module, please do so off-site. If you want to target new functionality for core, then as we've said submit patches to the existing module in chunks, once work begins on Drupal 6. Thanks.

liquidcms’s picture

liquidcms commented

are you suggesting i don't post info about my menu module changes on drupal.org or just that i don't post code for it under issues?

I agree i do not need to post code for it here - and won't anymore - sorry about that.

if you are suggesting i shouldn't let people know that there is a menu module replacement (for 4.7) that lets them do their work much better when administering drupal sites.. well.. i'll assume that isn't what you meant.

perhaps this should have been better doucmented in the forums - which, i did originally do; but someone sort of redirected them to this issue (which i did at same time as forum post since i wasnt sure best place to advertise this)

so, i'll go back to forums... but... also.. just wanted to point out that i found a bug in my last code attached here.. and it is now fixed in my ver 0.5 which can be found at:

www.liquidcms.ca/menu

and from now on.. any updates will be mentioned on posting (oh if only we had a real fourm here and could get email when posts are replied too... :(...):

http://drupal.org/node/97482

signing off...

Crell’s picture

Crell commented

I'm saying that the issue queue is not the place to post complete rewrites of core modules. If it's something you're going to maintain long-term, and it's stable, then you may be able to get it in as a contrib module. (Although I'm sure others here will tell me I'm a fool for suggesting that. :-) ) Announcements about a module you're hosting yourself elsewhere are probably forum material. The issue queue is for bug reports, feature requests, and patches to Drupal.org-hosted code only.

The issue queue would be the right place for patches to the core menu.module to make its interface nicer, which chx and I have both said are welcome and encouraged, but won't get much attention until after Drupal 5 ships.

sime’s picture

sime
any/any
Location Melbourne
commented

Also, it might be worth the OP reading up on "Drupal Enhancement Proposals"
http://drupal.org/node/39407

marcoBauli’s picture

marcoBauli commented

Ptalindstrom, the latest version of your menu module is just IMPRESSIVE and looks sssoo usefull, thank you for working on that!

Only problem :P i installed it replacing core menu.module, cleared caches, reloaded /admin/menu a dozen of times.....nothing. The menu page looks as it always did....how can that be? where am i wrong? :o

help apreciated! cheers

catch’s picture

catch
he/him
Primary language English
commented
Version: 6.x-dev » 7.x-dev
Status: Postponed » Active

not really a patch, and menu has changed loads.

liquidcms’s picture

liquidcms commented

yes, i think back in the 4.7 days when i created this module the plan was that i would do a patch to get pulled into 5 or maybe 6.. but i was pretty new into patches and drupal for that matter - so it didnt happen right away.. and then of course other things came up and it got dropped on the floor before 5 .. and now likely not to make it for 6...

hopefully i'll get a chance to revisit this at some point.. but it isnt likely to be too soon.. sorry.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Closed (won't fix)

Sorry, but I'm marking this won't fix.

If you want to attempt this once again, then I highly recommend you to do the following:

1) Create a "meta issue" or DEP or g.d.o page or whatever that explains the high-level goals of what you want to do, and most importantly, contains screenshots of the envisioned functionality.

2) Before any code is written, 1) is discussed - most importantly with the UX team.

3) When a consensus is reached, the overall effort is split into atomic tasks, and each patch can be tackled separately in an own issue.

This approach will ensure that at least something of your ideas well get into core and that the right people are involved in the high-level design process.