How to modify an old plugin for 2.1

vrijvlinder

So you found and old plugin but it does not work with your version of Vanilla....

There are some modifications you need to make. Some will work others will not due to major changes in framework. These 3 steps cover only the basic changes for a plugin that is 2.0 but 2.1 friendly . This means it requires only minor changes to work.

1.If your old plugin's definition has a lower version requirement. You must remove the entire requirement sentence from the list.

2.If your old plugin says: class OldPlugin implements Gdn_IPlugin you must change that to: class OldPlugin extends Gdn_Plugin

3.If your old plugin contains: &$Sender You must change it to this: $Sender

If these changes still don't make it work there are a couple other changes you can make to the Handlers that render the plugin. These simply tell where it will appear.

If these functions exist , example:

_BeforeDiscussionRender_Handler

or

_AfterDiscussionRender_Handler

or

_BeforeCommentDisplay_Handler

Not every plugin will work for 2.1 even given these changes, just as not every 2.1 plugin will work for 2.0.

Because of extensive changes in the framework and additions to it that do not exist in 2.0, those plugins will only work with their intended versions.

Before you test your fixed plugin, make sure you backed up all your plugins and files. Or test it under a test environment to minimize any potential risk.

[Deleted User]

Hey, I have an idea! Buy a $25,000 Mac Pro Workstation and host it off there. Easiest thing to do on Earth! LOL

Aviram

Good job! It will really help regular users with no coding skills fixing their plugins on their own (and newbie Vanilla coders)

[Deleted User]

Well done, @vrijvlinder

peregrine

2.If your old plugin says: class OldPlugin implements Gdn_IPlugin you must change that to: class OldPlugin extends Gdn_Plugin

I don't know if this is entirely true. implements seems to work on various plugins for me.
But the idea of changing it is not a bad idea.

http://vanillaforums.org/discussion/20192/what-is-the-difference-between-implements-gdn-iplugin-and-gdn-plugin

but a good idea to make a tutorial nevertheless.

vrijvlinder

You are correct, some actually do, however I recall a discussion where Lincoln suggested we used extends instead.

I think it depends on the plugin's purpose and if it uses it's own methods or Vanilla's no?

Have not seen a plugin use Implements since 2010 I think...

hgtonight

Themehooks traditionally implement the IPlugin interface. Like @Todd said in that post, there are times when it is needed.

If a class has a parent class that doesn't extend the plugin class, it will have to implement the interface (due to PHP language construct restraints).

tl;dr: if you see something like class MyPlugin extends MyParent implements Gdn_IPlugin it should be left alone

vrijvlinder

It still is a bit confusing to me... but thanks for correcting me

hbf

@vrijvlinder said:
It still is a bit confusing to me... but thanks for correcting me

basically the difference is between inheritance and implementation

in laymans terms:

implementation means there is a class [Class Gdn_IPlugin] that describes a set of interfaces (in this case an interface refers to public methods or properties that can be accessed by any consumer). This class is referred to as an interface, and generally uses the naming practice of beginning with i or I. Any new class which implements this interface MUST explicitly declare and expose all public methods and properties described in the interface. By doing this and by declaring implements ixxxx in the class declaration, you have told the world that they can cast you to this known interface, and the the public properties defined by the interface will always be present.

the idea of extends means that you are inheriting the behaviors and properties of some parent class. In this case, if the parent class already implements the Gdn_IPlugin then you are golden, since that is the critical interface. However if you extend a parent class which does not implement Gdn_IPlugin, you will need to implement it yourself. Now, with most plugins you will extend a base class Gdn_Plugin which by definition is the most fundamental implementation of IPlugin, but sometimes that won't be the case, and therefore the plugin framework can't cast your object to the interface and thus you dont actually have a plugin.

The inheritance and implementation concepts are pretty fundamental to object oriented programming. I'd suggest doing a lot of reading on them as they are really fun ideas that provide tremendous amounts of power to modern programming.

IMHO PHP does not make these concepts very accessible to the novice, if you are learning OOP you are better off in a managed, tightly constructed and well templated language like C#. you can download the Express version for free from Microsoft. it's pretty killer.

hbf

@hgtonight said:
Themehooks traditionally implement the IPlugin interface. Like Todd said in that post, there are times when it is needed.

If a class has a parent class that doesn't extend the plugin class, it will have to implement the interface (due to PHP language construct restraints).

it's not really a PHP language construct constraint the requires you to implement the interface when declaring an extension class of a parent class which does not implement the interface you need... it's OOP by definition. you just cant implicitly cast an object from one class to another without some declaration and member implementation. Otherwise you'd end up with all sorts of null references and bad pointers.

From a software design perspective, you can get around the extends/implements construct if you wanted to brute force everything as objects. Every class extends object so you can always cast back to object and use reflection to get at the properties and methods that you want. This is a form of late binding that can be useful when you dont have a shared interface contract or cant really know what you are going to get before runtime. but it costs a lot in terms of performance and robustness.

there's a time and a place for everything.

hgtonight

I was more referring to the fact that PHP doesn't have multiple inheritance. Implementing the interface while extending a parent class is kind of the same thing. Not really, I know.

Good posts!

hbf

im not aware of any oop language that allows multiple inheritance (it may exist, i just dont understand how it would work from a CS perspective). you can only really have one parent type, then you can implement as many interfaces you want. the adding of new interfaces is one way to extend the parent class.

peregrine

maybe these will help V. For me, I'm still digesting.

see example #3 re:multiple inheritance in link below.

http://www.php.net/manual/en/language.oop5.interfaces.php

other stuff.

http://www.php.net/manual/en/language.oop5.references.php

http://www.php.net/manual/en/language.oop5.traits.php

http://www.php.net/manual/en/language.oop5.late-static-bindings.php

hgtonight

@hbf said:
im not aware of any oop language that allows multiple inheritance

Not to say it is a good thing, but C++ and Perl support multiple inheritance.

vrijvlinder

Wow thanks for all the info, I think I am understanding it now !

hbf

@hgtonight said:
Not to say it is a good thing, but C++ and Perl support multiple inheritance.

well.. i stand corrected. it would seem that the creation of unambiguous, deterministic constructors and destructors would be a friggin nightmare in that scenario. i like my code managed.

vrijvlinder

Bumping...