Closed (fixed)
Project:
Menu Token
Version:
7.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
23 Sep 2011 at 21:40 UTC
Updated:
4 Jan 2014 at 01:11 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
dealancer commentedIn the 7.x-1.0-alpha3 we have updated how menu_items is stored. It should integrate fine with Features. To make this possible for D6 version we must backport this functionality, see http://drupal.org/node/973882
Comment #2
stovak commentedDoing the backport now locally. Will post when complete.
Comment #3
stovak commentedThis patch moves the 6.x branch to the new storage method but it still doesn't export correctly to features. No idea why.
Comment #4
stovak commentedWriting features integration with UUID. If you want to give me commit priv's to the 6.x branch, i'll commit some of this...???
Comment #5
stovak commentedExperimental Features Support
Comment #6
dealancer commentedI have just checked how features works with menu token 7.x-1.0-alpha3. It works ok if there is single menu token item in the menu. This is because of issue of Features module http://drupal.org/node/927566. If this issue will be fixed Menu Token for D7 will have this integration. BTW, this issue does not only affect on Menu Token, it will affects on Internationalized menu; Do you think this issue could be easilty fixed with unique id?
Regarding your patch, it looks ok, and I really apriciate your help. However it could not be commited cause of this reason:
We need to backport changes done in 7.x-1.0-alpha3 to D6 version of this module. Why? Cause we changed the way how menu token settings are stored. We dropped menu_token talbe and now store settings in the options field of menu_links table, it allow to gain the perfromance and to use native Drupal caching. Also this allows not to write exporting/importing functions of this settings.
So IMHO after we will update D6 version of this module, all we need is to patch features to support unique id? What do you think?
Comment #7
dealancer commentedComment #8
stovak commentedUnfortunately, the only way to get everything to work with UUID is to have some table where the UUID is matched up with the NodeID. You can't do a query on the UUID when it's stored in the Options field.
Comment #9
stovak commentedOk, so this patch adds UUID to the menu_links table instead of menu_token and eliminates the menu_token table entirely. Be sure to patch this to the original D6 DEV branch and ignore/disregard any earlier patches in this issue que.
Comment #10
oskar_calvo commentedHello stovak.
This patch works with the 6.1.1 version or we must to go back to 6-dev version?
thanks
Oskar
Comment #11
wizonesolutionsstovak: The patch brings things a lot closer, but it doesn't seem to be there yet.
The first DB update had a bunch of errors (which I'll paste below); the second one succeeded apparently.
Output follows, but keep reading afterward:
The actual integration is also flawed. I have 8 or 10 menu_token-using menu items to featurize, but only 5 show up. Of the ones that show up, 3 of them don't use menu_token and the other two say they are just pointing to (at least in the Features output). A completely unrelated menu item appears in the menu_token component type that's appeared after applying the patch. Hope this test helps and contains sufficient detail.
Comment #12
batje commentedAm just using this module for a day, and took a fresh look. I found a completely new way to make this work. I might have overlooked something, but here is my approach.
Currently, menu_token stores the < front > variable in the path of every menu item. This is pretty convenient, as upon save of the menu item, Drupal checks if you have access to the path. There are very few websites where you dont have access to < front >. Upon rendering of the menuitem, menu_token replaces < front > with the calculated path based on the user_menu path tokens. This is a nice trick. However, the features menu export gives every menu a unique ID based on the name of the menu and the path. So if you have 2 menu_token enabled menuitems in 1 menu, the second one is not exported.
So, here is what i did:
This works for me so far. Without changing features. But its pretty funky, so feedback is welcome.
I will need to test this with the menu_per_role module later.
(fixed some html formatting)
Comment #13
oskar_calvo commentedThe patch need to be review?
Comment #14
kim.le commentedI'm confused. Are these patches for Drupal 6 or 7? I'm using 7.x-1.0-beta and the menu links for features export don't appear when I check the use tokens box in for the menu link.
Comment #15
batje commented#12 is for Drupal 7.
Comment #16
socialnicheguru commented#12 does not apply cleanly to beta1
Comment #17
develcuy commentedWorking on patch at #12
Comment #18
develcuy commentedPatch re-rolled and pushed to 7.x-1289302 branch. Also, added an update hook that fixes current menu items that are using tokens.
Patch attached for your review. Let's make it RTBC!
Comment #19
develcuy commentedComment #20
develcuy commentedIssue #1896834: CTools Export Bonus integration confirms that the patch works. To be committed pretty soon.
Comment #21
lnunesbrPatch created in Drupal Camp Cartagena.
Please, needs work.
Comment #22
develcuy commentedPatch committed and new release published!
Comment #23
a.ross commentedPatch causes issues, see #1899696: undefined constant DEBUG_BACKTRACE_IGNORE_ARGS
Comment #24
a.ross commentedComment #25
a.ross commentedI think instead of doing
debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS), you can just dodebug_backtrace(), as all that this code uses is the function name... if you want to save memory then check first if the constant is set.Besides that, this whole function seems to be a gruesome hack, but I don't know how necessary it is.
Comment #26
a.ross commentedI posted a patch in #1899696: undefined constant DEBUG_BACKTRACE_IGNORE_ARGS
Comment #27
a.ross commented