Developer Support Required Please!

Hi Sue / John,

Mark, we do have a development forum.. moving there so you can continue the conversation.

Yep I’m aware of that 😉

The reason I posted in Tech Support first though was due to what I believe to be an error in the documentation which caused me to not get any work done for over a day and a half.

If someone could please please please look into this as I’ve posted above what I believe to be the correct code and perhaps get that page either fixed or made more clear then that would be much appreciated thank you.

As mentioned this cost me a day and a half messing around with code from the documentation which simply doesn’t work and I really could have done with it working first time.

Thanks.

Best wishes,

Mark

What I believe to be a bug in the form of incorrect documentation has now been reported.

Mark, the change in the naming form for the constructor is because of the change from PHP4 compatibility to PHP5-only – in other words, it’s a PHP-based change.

I’m not sure why no-one thought to put it to you this way, but there it is.

I agree that example code should as much as possible be maintained up-to-date – am just thinking that the team has obviously been under a pretty good load turning out EE updates along with the other things going on in the Ellis house. I think they’ve been working pretty hard internally to improve how they work, to alleviate the problems and keep everything on track.

Documentation, especially for development, is very often the one to slide a bit when this sort of thing happens. For the more experienced developers, this is probably a reasonable choice, as they will be used to imperfect information and will use their depth knowledge of frameworks to delve out a solution. That guys like _rsan are generous is the big help here.

Regards, Clive

p.s. good on you for putting a bug report in on it, so fix will be in the queue.

Hey Mark,

The constructor bug is fixed and will be out in the next release, which is coming this week, so sorry for that. As Rob said, you need to set $this->return_data if you’re writing a plugin that only utilizes a constructor, since constructors can not ‘return’ anything.

Other than the bug in the template parser which didn’t take PHP5 constructors into account, are you set?

-greg

ETA: and note, $this->return_data is something the template parser looks for. So it’s not a PHP thing, per se, but a specific variable we look for in the template parser. Poke around system/expressionengine/libraries/Template.php in the process_tags() function to see. It’s rather mind numbing to see what’s going on at first, but spending a bit of time seeing how it works will help you to see exactly how ExpressionEngine is parsing your templates. Since you know some PHP, there are a few things you can gain from it. a.) There are some things to be learned about PHP in there, and b.) You’ll start to see what is involved behind the scenes to make your templates render! :D

The constructor bug is fixed and will be out in the next release, which is coming this week

Sweeeeeet.

Yes, good, and I have to apologize – I had this backwards about PHP 4/5 and constructor styles.

Too much ancient depth knowledge about C++ in the culverts, probably 😉.

Nice they have added __destruct also.

Cheers, Greg, Mark, Rob et al.

Clive

If I might chime in here, I’d recommend keeping support for the plugin constructor bug for a little while if you don’t mind a little extra code.

I say this because while 2.1.4 should be out this week, any 2.x version prior to that will still have this bug. Therefore you add-on would require 2.1.4. I know it’s not the end of the world to require someone perform an upgrade - but if an upgrade isn’t 100% necessary (ie a feature requires it or it’s security related) I typically am not quick to perform it.

Keeping your code in the __construct() and adding something like this has been my approach thus far:

<?php

public function Plugin_name()
{
     $this->__construct();
}

?>

I’ve seen a lot of developers do this, and honestly I don’t understand why. If you’re looking to maintain backwards compatibility from the next release, why not just use the PHP4 style constructor? __construct() seems to be extra cruft, especially when the other works just fine.

Hi Greg,

Hey Mark, The constructor bug is fixed and will be out in the next release, which is coming this week, so sorry for that. As Rob said, you need to set $this->return_data if you’re writing a plugin that only utilizes a constructor, since constructors can not ‘return’ anything. Other than the bug in the template parser which didn’t take PHP5 constructors into account, are you set? -greg ETA: and note, $this->return_data is something the template parser looks for. So it’s not a PHP thing, per se, but a specific variable we look for in the template parser. Poke around system/expressionengine/libraries/Template.php in the process_tags() function to see. It’s rather mind numbing to see what’s going on at first, but spending a bit of time seeing how it works will help you to see exactly how ExpressionEngine is parsing your templates. Since you know some PHP, there are a few things you can gain from it. a.) There are some things to be learned about PHP in there, and b.) You’ll start to see what is involved behind the scenes to make your templates render! :D

Thanks for the information and the update. Much appreciated.

Best wishes,

Mark

Also, to close the loop here, the 2.1.3 and 2.1.4 beta builds released today have that __construct() issue in plugins fixed. 😊

-greg