Memory Limit for Admin Users

[willykaram]

In certain instances we need are running in to PHP Memory Limit errors on the back-end of the site (e.g,. on pages such as 'admin/structure/types/manage/session'). Absent scaling back some the architecture on the back-end or optimizing it to make it more efficient, then we likely need solution to increase the memory limit on the back-end for users with site admin role (i.e., users that are dealing with site architecture/site building). The Memory Limit Role module (https://drupal.org/project/role_memory_limit) was used as a quick fix to get around this for the administrator for the last few days, although it didn't work for other user roles, it did work for uid 1 and allowed us in a quick pinch to resolve the issue. For now we should increase the memory limit for site admins in settings.php, which is a reasonable interim solution that we can use for the next few weeks until after the camp (at which time we can revisit the issue with the benefit of more time to address more thoroughly).

[ForestMars]

I say for now we don't mess with it.

Role memory limit is working for user/1. If anyone needs to get to a page that is OOM'ng, they can log in as user/1 after adding a comment to this issue indicating what page it was.

We don't have a lot of extra time here to chase perfection. Let's focus on immediate priorities.

[likewhoa]

I agree with @ForestMars. Also I don't like the idea of introducing yet another module on the site, instead we should try to focus on lowering the resource demand on admin/structure/types/manage/session

[ForestMars]

It's not just the manage/session node type, it's the whole content model we have, or rather the lack of a good content model, which has resulted in too many content types, too many fields, and most all of it added ad hoc, not conforming to a well thought out approach.

This is not a problem we are going to solve before the camp, but we need to clean up the content model both for cruft in general, and to solve specific issues that have arisen as a result.

For example we have both a session node type and an event node type. Only events can have registrations. So when someone submits a session, we can't make it a training without recreating the session node as an event node. UGH.

We need a clean way for people to submit a session that we can then say, hey, this would make a good training, and allow people to register for it.

This is one of the top line items to fix for next year's camp- or rather, after this year's camp when we roll up the distribution profile.