-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dropdown list with AutoPost Back (instead of "Go" link) #7
Comments
I agree it is not very convenient and I also don't know why it was changed. Anyone @DNNCommunity/module-dev-team has any idea of the reasons behind this change or some reason to not revert back to an autopostback? |
Actually, I just read #8 I just found a reason why autopostback is not implemented, it would prevent selecting a link and editing it. I wonder if we could have the edit button inside the dropdown for each link using something that is always available in Dnn such as jQuery UI. I have to test if we could have a button or link using this: |
Thanks for checking into it! I'm not sure I understand the reasoning, that autopostback would prevent selecting and editing a link, since you can do so using the older version of Links (with autopostback) (whhich I'm still running on our internet site) . I've found a workaround using javascript, so I'm Ok on this, but I do think you're idea is good to restore autopostback to the module. Thanks again. Tom |
If by doing the auto-postback, the user is sent to another page without the links module on it, they will never see the edit button for that specific link. With the implementation you have now (without your javascript workaround) how would you for instance delete a specific link? |
Thanks Daniel, I get your question now. I'm actually getting different behavior on different sites/situations. I have one instance, in which the module instance was created fresh on a fresh DNN 9.11 install (with Links 6.2.3) . In this case, when using my css / javascript workaround, I can select an item in the list and get the desired result of going to the selected link, file or page. In addition, when in Edit mode, the switch does not result in going to the associated link/page, it just changes the list item and then I can select the edit icon and get to the edit page. :) So everything works like the old version of the Links module used to work. In other instances (most were created in Links 4.0, before upgrading the module to 6.2.3,) using my workaround, The functionality works, but in edit mode, I do have the issue you mention, however, if I hit the back button after visiting the specified link, I get back to the module with the link selected, and I can click the edit button to edit (so not ideal, but possible) Another method would be to construct the URL of the Edit page by using the Module and Item IDs to get the edit page for that particular select item. Again, not easy but possible. I hope I'm making sense. Not entirely sure why I'm getting different behaviors, but I think things work better if the modules were created anew after the upgrade to 6.2.3. Tom |
A solution could be to suppress the autopostback JS function when the module is in Edit mode. |
Very good Idea @EPTamminga I think we could do that as the default behaviour: If in edit mode:
Else
|
Thanks. Sounds like a good idea! |
Hi, I used the DNN Links module to create dropdowns on our websites, and when I upgraded the Links module, the dropdowns don't work properly, in two ways.
Number 2 is the real problem. Why was the post back function taken out of the Links module? Is there an easy way to restore this functionality, or if not, should I go back to using the old version of the Links module? It will be a ton of work to recode all my dropdowns if I can't use Links for this anymore.
Here's an example of the proper function of these Links/ Dropdowns (three dropdowns on the top right side of the page):
http://www.co.santa-cruz.ca.us/
Thanks!
Tom
The text was updated successfully, but these errors were encountered: