The problem is that Elgg *loads the PlugIns when engine/start.php is executed - in the beginning, but the Profile Type check is done only when a person clicks to view the whatever Profile. At this moment, it is rather very late to go back and tell some other PlugIn that the "context" is now changing for that PlugIn to take notice of ;-( The code's will have to approached from a different angle so that other PlugIns can recognize what The Profile index.php is saying and act according to the "Profile Type" index.php says is the Type to pay attention to... Perhaps a session variable might make it work ;-)

It's true that Elgg loads start.php of all the enabled plugins.  On the other hand, a plugin's start.php often defines functions that get executed later.  From engine/start.php we can see this:

• Loading of engine/lib/*.php
• Trigger of system/boot event.  Much of Elgg's core is initialized this way.
• Loading of plugins, in particular their start.php.
• Trigger of plugin/boot event.
• Trigger of system/init event.  This is when most plugins init function get executed (since their start.php register a system/init handler).

For a page like pg/profile/user, .htaccess invokes engine/handlers/pagehandler.php, which does an require_once(engine/start.php) to do all those above, before invoking profile/index.php.  So perhaps it's not too late to sneak in a last system/init to hack $CONFIG->widgets so that effectively select widgets can be disabled.

True.. Might be "overkill" tho.. I already considered doing another call to re-load plugins directly and forcing their start.php.. but the performance overhead (e.g. if one has got 20 - 30 plugins) makes me back away from doing that. (btw performance *has been a big concern for us anyway, b/c we just last week tweaked our worst case response times down from abt 30 secs to abt 1 - 3,5  secs). Using sessions vars means that the "context" can be "defined" in the sess vars and "dependent" and or related plugins/widgets can then fetch that and go or no go..

Ok the context method will work, it requires an additional field added to the users profile. For some reason the page owners data for profile_manager's custom_profile_type can not be pulled from the page_owner_entity, but if a field is displayed on the profile declairing the profile type I am able to pull this information.

The next thing to do is automaticly populate this field when a profile type is choosen so the user doesn't have to repeat the choice.

Thanks for everyones input, it kept me thinking of different ways to handle the problem.