Posts: 51
Threads: 17
Joined: Jun 2011
Reputation:
0
Hi Ben,
Do you plan to upgrade the Mass Edit Module to be compatible with 2.1.0?
This add-on is really useful for, well... mass editing ;-)
- Mark
Posts: 2,456
Threads: 39
Joined: Dec 2008
Reputation:
6
Hi Mark,
haha, yeah I agree - thanks for the reminder! 
I started to upgrade it last month but it turned out to be a lot more work than I thought, so I bumped it down the list. Now the Data Visualization module is finally done (whoo-hoo!), I'm playing catch-up with other stuff.
I'll try to get to it in the next week or so.
All the best-
- Ben
Posts: 51
Threads: 17
Joined: Jun 2011
Reputation:
0
Hi Ben,
We can't wait :-)
- Mark
Posts: 2,456
Threads: 39
Joined: Dec 2008
Reputation:
6
Hey Mark,
Noted! I'll be working on the new Form Tools demo for a few days more, then I'll be getting to this and some other smaller things.
So, soon! Honest! 
- Ben
Posts: 51
Threads: 17
Joined: Jun 2011
Reputation:
0
No worries Ben! I understand, priorities first and all that ;-)
- Mark
Posts: 2,456
Threads: 39
Joined: Dec 2008
Reputation:
6
Hey Mark,
So... bad news with the Mass Edit module: it's going to be further off than I thought.
Today I got things working locally to the point where the fields were being displayed on the Mass Edit page, but the generated markup wasn't valid. The problem is that each of the field type's markup was written for the (single) Edit Submission pages only. So things like labels and IDs were being output multiple times for each row, causing errors in the JS and browser. In the old version, I had more control over the generated markup - but now it's handled by each field type, which means a core change.
This is definitely something I want to solve, but I need to get it all worked out in my head first.
A little more explanation. So, the design for the field types is GREAT. I really like it: it gives total power over customization. I worked in the option to define "contexts" for each field type, so it can be told where it's being called from (e.g. "edit submission", "xml export", "submission listing page" etc. etc.), and then change what's outputted accordingly. So it can easily handle a new "mass edit" context to get around the problem I encountered today.
What was short-sighted of me was not to go all in and make each and every field type a separate module, like the Google Maps, file upload & WYSIWYG modules. -or even just write a single module to group all the common field types. So now anytime I need to update one of the Core's field types, it needs a Core update. That was dumb. I'd still stand behind the original design, it's just that the implementation has problems.
I'll have to continue to give this some thought.
- Ben
Posts: 51
Threads: 17
Joined: Jun 2011
Reputation:
0
Hi Ben,
Sounds like a headache.
Fortunately though, I have the solution! I've sent you $20... Go and have a few drinks or grab a bite to eat (something tasty!) and wallah, I guarantee the idea will pop into your head ;-)
Take care,
- Mark
Posts: 2,456
Threads: 39
Joined: Dec 2008
Reputation:
6
haha Thanks, Mark!
Posts: 2
Threads: 0
Joined: Oct 2011
Reputation:
0
Hi Ben,
I m using 2.1.3 but Mass Edit Module does not compatible with this version. Is it possible to downgrade to 2.0.6 so i can use this module?
This module can save me a lot of time to update submissions .. really need it
tqvm
Jacob
(Sep 27th, 2011, 3:39 PM)Ben Wrote: Hey Mark,
So... bad news with the Mass Edit module: it's going to be further off than I thought.
Today I got things working locally to the point where the fields were being displayed on the Mass Edit page, but the generated markup wasn't valid. The problem is that each of the field type's markup was written for the (single) Edit Submission pages only. So things like labels and IDs were being output multiple times for each row, causing errors in the JS and browser. In the old version, I had more control over the generated markup - but now it's handled by each field type, which means a core change.
This is definitely something I want to solve, but I need to get it all worked out in my head first.
A little more explanation. So, the design for the field types is GREAT. I really like it: it gives total power over customization. I worked in the option to define "contexts" for each field type, so it can be told where it's being called from (e.g. "edit submission", "xml export", "submission listing page" etc. etc.), and then change what's outputted accordingly. So it can easily handle a new "mass edit" context to get around the problem I encountered today.
What was short-sighted of me was not to go all in and make each and every field type a separate module, like the Google Maps, file upload & WYSIWYG modules. -or even just write a single module to group all the common field types. So now anytime I need to update one of the Core's field types, it needs a Core update. That was dumb. I'd still stand behind the original design, it's just that the implementation has problems.
I'll have to continue to give this some thought.
- Ben
Posts: 2,456
Threads: 39
Joined: Dec 2008
Reputation:
6
Hi Jacob,
I'm afraid you can only downgrade if you have a backup of your old 2.0.6 database (+ files, ideally - but not strictly necessary).
Sorry about that. I'd love to make the Mass Edit module compatible with 2.1, but it's a great deal of work and has to be lower priority than the other stuff we're working on right now.
- Ben
|
