We have like 512mb on our staging server and it never craps out. I think some of the install could be moved to somewhere else. Also I think importing accessibility rules as nodes is a real mistake, that should be imported as something else. Otherwise this is a really nice module.

Comments

Anonymous’s picture

Will 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.

drupalninja99’s picture

its only on the install, i have got it to run on my local box, but 2 other environments we've been unsuccessful

Anonymous’s picture

I'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.

Anonymous’s picture

OK, here's the proposed redesign of the install process:

  1. When user installs, it checks requirements per usual.
  2. After install, it gives a message that test and guidelines aren't built yet. Also throws something in the site status report.
  3. Once user goes to the admin interface to update/install tests, the batch api process for installing/updating tests and guidelines is triggered. Guidelines should only be done on install, so we'll have to use a variable to just check if an install was done already.

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.

Anonymous’s picture

Status: Active » Needs review

Just 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.

Anonymous’s picture

Status: Needs review » Fixed

Latest RC has this fix. Works fine in several slow environments with minimal memory. Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.