Modalframe is not being developed for D7 since Overlay is in core, so we need to remove Modalframe support. (However, Overlay is not a replacement because it is admin-only; see http://zgadzaj.com/how-to-open-standard-content-pages-in-drupal-7s-admin....) Other similar modules (Popups API, Colorbox) also appear to not support overlays in D7.
For anyone viewing this thread who still wants an overlay for status edit/delete links, Lightbox2 may be able to perform the same functions without direct support from Statuses by attaching itself to the DOM classes on those links.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | remove-modalframe-integration-1591586-1.patch | 10.32 KB | mathankumarc |
Comments
Comment #1
mathankumarc commentedDropping the integrations like these is a good idea. As you said we can easily implement this functionality without the support from statuses like using ctools modal(personally I don't like lightbox)
However to let other users implement this functionality, we should provide an option to enter custom class for edit/delete link in views field handlers(for example to enable lightbox we will add lightbox class to the links). Currently we are not providing this functionality.
In simple words "Allow users to customize the views field handlers extensively". Is it worth to implement?
Anyway here is the patch for removing modal integration, but I have one question, Is fbss_comments_views_ahah.js needed? cause its not been ported to D7 and I think its not having any effect on comments (May be a separate issue)
Comment #2
icecreamyou commentedI sure hope not. It exists to solve a problem in D6 core that has been solved in D7. If we remove it and status comments still work on the second page of ajax-powered views, then all is well.
Comment #3
mathankumarc commentedCommitted to dev. Will create a followup issue for fbss_comments_views_ahah.js.
What 's your opinion on this?
Comment #4
icecreamyou commentedViews already lets people add custom classes if they want, and that often wouldn't be enough because you'd usually want to theme individual statuses too (statuses-item.tpl.php). But the edit/delete links (and all status links) already have distinctive classes, and for 95% of use cases it should be enough to use those; the other 5% may need to do a little theming but not too much. I don't think we gain much functionality/flexibility by making classes even more configurable, and we add complexity. That said, I like the idea of supporting ctools modal.