Closed (fixed)
Project:
Accessible Content
Version:
6.x-1.0-beta2
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
25 May 2010 at 16:06 UTC
Updated:
3 Jul 2010 at 18:40 UTC
Jump to comment: Most recent
Comments
Comment #1
Anonymous (not verified) commentedWill look into moving the install process into a bulk operations process in the admin interface; however, I haven't seen this memory issue occur on my test instances - could be something else expensive attaching to the nodeapi save process. Could you provide a list of modules you have running? Maybe something is being fired on every node creation. Regardless, I agree it should be moved to a bulk process.
On the question of making each test a node: that was an architectural decision made early on for several reasons. First, we want people to be able to edit tests, add screenshots, and customize test error messages to fit their particular environment. For instance, we use the Insert module and CKEditor and showing folks how to insert alt text is a different process than someone with a wiki markup filter. Second, tests can have access control applied to them like any other node and have additional CCK fields or taxonomy if an admin wants to extend them.
In D7, we'll be making tests Entities (with a capital 'E'), but for D6 the only way to get all the free stuff mentioned above was to make tests a node.
Comment #2
drupalninja99 commentedits only on the install, i have got it to run on my local box, but 2 other environments we've been unsuccessful
Comment #3
Anonymous (not verified) commentedI've tested memory consumption on a stanard drupal install with no other modules and it never spiked over 10MB... I'm wondering what else could be causing this. In the meantime, I'm working on making the bulk admin update page also act as a last-resort install; however, I'm still not convinced that this is not just a function of your environment. It's a usability issue if we move the installation process to require a whole other screen after enabling the module. I wish modules could introduce a batch API call on installation, but unfortunately we can't.
Comment #4
Anonymous (not verified) commentedOK, here's the proposed redesign of the install process:
I should be getting this committed within the next few days. Should really help with memory, and after second thought, shouldn't be a big issue for site admin.
Comment #5
Anonymous (not verified) commentedJust committed a change that moved the instllation process to a batch api call in the admin screen. Please download latest dev version and see if this fixes your problems. I am now updating the test files to support this change.
Comment #6
Anonymous (not verified) commentedLatest RC has this fix. Works fine in several slow environments with minimal memory. Fixed