Add drag and drop to Profile
Rob Loach - November 21, 2007 - 00:37
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | profile.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
This is a proof of concept made to port the profile module's profile page into a form. The benefits of this are that you'd be able to change the way the Profile module's elements appear to the user without having to manually edit each item's Category or Weight. And of course, it would look much cleaner.
The end result will be similar to the Blocks administration page, where you can drag items region to region. In this case, however, you'll be able to move items from category to category. If you take a look at the attached screenshot, you'll get an idea of where it's at right now. The screenshot is of where the patch is right now.
Todo
- Query all profile categories and display them as combo boxes for the category header
- Implement
profile_admin_overview_submitto save the data - Remove old code from
profile_admin_overview - Display all profile categories as headers for the drag and drop (like regions in the blocks administration)
- Rename the "Edit" and "Delete" heading to "Operations", and combine the two cells using a colspan
- Clean up the "Add new field" section
- Do we need to display the Name of the profile item?
- Fix the drag and drop so that it actually works
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| profile_drupal_get_form.patch | 4.68 KB | Ignored | None | None |
| profile_drupal_get_form.png | 27.46 KB | Ignored | None | None |
#1
No time to review anything now, but subscribing for later. Nice one taking this up!
#2
Adding to the list of things to look at. Rock on!
#3
Made some progress with it. It now includes select boxes for the weight and categories. Clicking on Save configuration saves the fields correctly. Needs much more work, help is greatly appreciated.
#4
Just an update of the things left on this:
#5
Here's an updated version with better management of the form fields. Still requires separation of the categories and fixings with the drag and drop. Any help appreciated.
#6
So maybe we have time for another drag and drop patch?
I took a stab at this tonight and as Rob has indicated, this is about the same complexity as the blocks page. Fortunately, since we've already figured out the blocks page, this was easy to duplicate. This patch takes the same approach, adding a special javascript file to fill in the additional functionality needed to display a message in an empty region. In this case, if the region is left empty it will be removed automatically upon form submission.
Thanks Rob for getting this rolling. The biggest caveat I encountered with the initial patch was the HTML ID "profile-admin-overview" was already in use for the form on the page. Since the table was also using this ID, none of the javascript was working because it was finding the form instead of the table on the page. I changed the table ID to "profile-fields" and a lot more things started working.
I think this patch is fully working and well documented. Ready for review.
#7
This is a nice example of how the ordering of node-edit/add fields should look like.. :-)
#8
With no categories/fields enabled I get this:
* notice: Undefined variable: categories in drupal6/modules/profile/profile.admin.inc on line 34.* warning: array_unique() [function.array-unique]: The argument should be an array in drupal6/modules/profile/profile.admin.inc on line 34.
With one field, I get drag and drop enabled - this should probably be disabled like the vocabulary page follow-up.
With more than one field, and with multiple categories. ooooooh this is nice.
Minor nitpick - in IE7 (and IE6, which still has that shadowing thing going on) the drag and drop icon is a pixel or two too high, and when you mouseover, the yellow bleeds over the blue border of the category. I didn't notice this with the other patches so it's either specific to this form, or just more noticeable due to the extra category row.
Pretty much there, but marking as needs work for the E_ALL, not too fussed about the IE7 pixel but should be trivial either way.
#9
Ahhh, that makes sense. I was wondering why it wasn't working. Your patch was giving some hunk failures, so here's one updated to HEAD. Also was missing the first declaration of
$categories, which resulted in some PHP warnings, and had a call in the javascript toconsole, which I doubt we need anymore. These issues are resolved in the attached patch. Would be good to get a couple more reviewers on it.Thanks a lot for helping out with this, it rocks!
#10
Set to CNW for catch's note on disabling the drag and drop when there's only one field. The other issues you brought up are resolved though (excluding the IE bugs).
#11
Oops, malformed profile.js. This fixes it.
#12
This patch adds the drag and drop only when there is more than one field. I used the vocabulary as a guideline. Ready for review.
#13
That fixes both the notices and the drag and drop on one item bugs. In my view this is ready. Could do with testing on a platform other than XP just in case.
#14
I found 2 small problems corrected in this patch:
- Weight field on the overview page had delta = 10 while on the field form it only had 5. Updating fields could cause an unintentionally changed weight. I set both to 10.
- The profile.js file was still being added when tabledrag.js was not, causing a javascript error on load when only one field existed.
I tested in Opera 9, Safari 3, and Firefox 2 will complete success.
#15
Tested on FF 2 and Safari 3 on Mac, works like a charm!
#16
Maybe a bump to get it on radar.
#17
I can confirm its working too. Nice work guys :)
#18
Just had some time this morning to test this patch. The changes look sensible and the functionality looks great. Having this weirdness with categories (that we need to create categories when adding fields, and that we remove categories when removing the last field) is the sign of how denormalized this category feature is implemented. Unfortunately there was not much interest in normalizing this in D6, so we go with this architecture for now.
Thanks for keeping up this work. Although again, I don't think this is critical - I monitor the RTBC queue, so no need to bump to critical to get my attention.
#19
Note this [related] bug at http://drupal.org/node/198231
#20
Automatically closed -- issue fixed for two weeks with no activity.