EE 3 dp 2 Channel Form errors for logged out users and logged_out_member_id both

The issue here is that in EE 3.x you prevent the resetting of a variable on the ee()-> object once its already been set, so when the session override tries to do ee()->session = new [session] it fails.

I know this probably falls under “We’ve thought about this already and are final on the decision” but preventing the resetting of objects on ee()-> is going to break a lot of functionality. I’ve done it more than once to be able to extend a built in class that didn’t have any hooks but the result provided a very nice increased function for the addon used.

I should note that a couple of those times were private addons for end clients and a couple were for publicly released addons. I know for the private client we could just override the __set() function in core, but that would prevent safe updating for them and goes against the new EE structure thats supposed to make that easier.

Thanks, Greg, we’ll get that fix in for the query, and look into the overloading in Channel Form.

Yes, we decided not to allow overwriting things on the super object. There are sometimes unintended side-effects when add-ons do this, as we’ve seen in support, so in the end it’s better for stability and security not to allow breaching the contract those objects have with the rest of the application.

Maybe we can find another way to accommodate the functionality you’re losing, just let us know what you need.

Something I found out that did work, and am hesitant to use because its not advertised, but is this a ‘supported’ way to do things?

$old_functions =& ee()->functions;
​
ee()->remove('functions');
​
ee()->set('functions', new myExtendedFunctions());
​
//do some work that requires my extended class

ee()->remove('functions');
​
ee()->set('functions', $old_functions);

​

I guess the issue i usually have when i need to do this is that so much functionality in EE is locked behind a CP controller or something with a redirect or ee()->output at the end of the function.

I know the real answer is to send an FR to you guys to abstract the function i need for the next release of EE but that doesn’t work fast enough for us for client work. For third party customers, we have been going a long while with customers that do not update any addon or EE itself because they don’t want to ‘fix what isn’t broken’ and they just update the one addon they want the new feature from.

Between those two things, very often we have to work with what EE can currently do instead of being able to wait for a new version to get our FR.

(edit: I see your point about support, and its a rough edge for us both in that regard when doing trickier features)

Since you’re essentially doing the same thing we’re disallowing in that workaround you found, we cannot officially support it. But it may continue to work for a while if you’re in a bind and want to use it at your own risk. It’s good that you set the old Functions class back though, one problem with the approach in general is that many folks don’t do that kind of thing and the rest of the application has to use the class for the remainder of the request. That’s also why we get “bugs” about things like package path errors, they’re really due to an add-on altering the package path stack and not putting things back when they’re finished.

Anyway, your point is understandable. Hopefully now, though, you’ll be finding more logic outside of controllers and in places like services and models. And if not, we’d like to know what’s missing and I’m sure we’d be glad to try to abstract away if it’s generally not in a proper place. There’s probably quite a few things still like that in general, we didn’t have time to rewrite EE entirely (we wish!), but you can help inform the priority we tackle those things.

Yeah i figured it was the same thing but thought that possibly it was some other way you guys were doing some class checks with it before you did something critical maybe and it would be possible to work a little then jump back out.

I’ll be more diligent with my FRs then and do my best to avoid this.

Thanks Kevin!

Just closing the loop here, the next build should have a fix for the session overloading in Channel Form. Thanks again for the report!