huge memory requirement for view with editable fields.
| Project: | editablefields |
| Version: | 6.x-1.1 |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
I've created a view of nodes (Views 2.2) with an image field displayed (using imagecache) and an editable select textfield called "weight" for ordering the nodes in a gallery. Even when I restrict the view to displaying 30 nodes Firefox takes an age to load and ends up using in excess of 200MB. IE7 shows a slow script warning.
I can change the value of individual fields but if I attempt to reload the page, Firefox hangs, growing in mem size until "end process" is required.
With Simplemenu enabled the simplemenu at the top of the page is displayed multiple times at the top of the page. Could there be a namespace clash here ?? When I click on a menu item in Simplemenu it is shown 20 or times in a massive dropdown.
With Simplemenu disabled the view still takes an age to load, and navigating away is also very slow. If I reload the view it adds 100MB or so to Firefox mem usage in task manager.
Is there an option to switch off the Ajax edit in D6 and just use a big form?
best regards
Marcus
#1
I can supply a URL to see this issue in effect, please pm or email marcus at brightonart.co.uk - i don't want this url published on the web.
thanks
Marcus
#2
At a guess, the editable field you have pulls in a load of javascript for each field....
As a work-around - have you tried marking the fields as 'click to edit'?
Cheers
Mark.
#3
Thanks for the quick response.
It's a drop-down select with integer values from -99 to +99 - would that pull in loads of javascript?
Where can I mark them click to edit? The display format in the view offers the normal types and "Editable".
#4
Ahh, yes, you should probably update to the -dev version - but, not, you need dev versions of cck etc :-(
the -99 - 99 shouldn't have much effect.
Cheers
Mark.
#5
Can you be more specific about what is required? I'm happy to try this out on my dev version of the site and help with debugging if you can point me in the right direction.
I have installed the latest dev editable_fields and latest dev cck.
I can't see a click to edit option. Where should it be? Anything else needed?
cheers
Marcus
#6
Maybe you need to update,php or clear your caches?
But, you should get two options for a field now - 'Editable' and 'Click to Edit'. These should be available for view fields, or content fields display settings....
Cheers
Mark.
#7
Click to Edit seems to just about work on a View of 400+ nodes (using the latest DEV versions of CCK, Views and editablefields). I reduced the View down to <100 nodes and the Editable nodes works (just - although you have to wait a bit for the editable boxes to be generated). But this is only on my Dev machine, which has 6GB of RAM - I'm also using Safari 4 to create my site content, as it seems a lot faster/stable than Firefox on the JS front (no - please don't start a flame war over browser speeds). I think I'll probably limit the use of Editable fields on the production site for the moment, but think it's a fantastic UX improvement.
#8
I'm having the same issue, and unfortunately click-to-edit won't work for my use case based on how we need the UI to look. My use case is almost exactly the same - a CCK content type with 7 fields - one imagecache image, four content taxonomy fields (three drop-down, one freetag), and two text. My view currently is set to display a total of 5 nodes on a single page. When I load the view, it hangs the browser, consumes huge amounts of memory, and just about kills the system. In my case, at the moment I have all Drupal performance options disabled. I am on D6.13 with the latest 6.x release version of the module since that had a later date than the development release. I am using CCK 6.x-2.5.
I did try this with the Firebug console open and saw tons of interesting things - the console log grows until it hit 844 messages and then told me it could not take any more messages. It seems to first loop through the nodes and loads all of the javascrpt, but it does this multiple times. I see it loading all of the javascript for each node so the same script has a GET request issued 5 times on load. The same is then true for each field - it loops through each of them and loads up /editablefields_html/NUMBER/field_myfieldname/0 for each field in each node. This seems to continue to loop forever which is why firebug runs out of message space. I managed to get the Firebug net console up at the same time, and I see hundreds of "GET 0" requests. If I open up the request, they are XMLHttpRequest type and what comes back in "content" looks to be the contents of the fields. For example, my field "color" has about 20 different names of colors, and I see them in the response. If I look in the same response in "scripts" I see all of the various .js files.
The end conclusion I have is this seems to be looping somehow, and even when the content on the page stops loading and appears 'finished' to the end user, the GET 0 and XMLHttpRequest stuff keeps going in the background until the browser dies. I have no idea why, but I'd really like to figure it out if anyone has a suggestion.
I have screenshots of all of the above, but I would prefer not to post them publicly. Let me know if you are interested and I'll e-mail them.