Plugin standards, etc

zem · 2005-08-22 02:22:00

Now that 4.0 is out, it’s time to start thinking about stability in the plugin interface.

Our intention all along has been not to break plugins within a stable branch (i.e. 4.0.x). We’ve discovered this puts the dev team in something of a catch-22 situation though.

Currently, plugins have access to basically every aspect of the Textpattern code: all of its functions, tables, global variables and internal state. That means any change we make, even a nice clean bugfix that has no other behavioural changes, could break a plugin. (A good example is the 404 code I checked in recently. I fixed a number of bugs and inconsistencies in URL parsing; as it turns out, at least one plugin relied on those bugs, and thus no longer works properly).

Now and then people talk about “the plugin API”, which is really a mythical beast. The only published standards sofar have been the tag handler interface ($atts, $thing), the admin-side register and privs functions, and the plugin template itself.

So, I thought I’d ask for input from plugin developers as to what their expectations are for stability in the Textpattern source, ~~what the API might contain~~ which parts of the existing Textpattern code might be considered part of the API, if there was one, that sort of thing. That’s not a promise to implement everything (or indeed anything) – after all, we need to be able to change the core code in order to fix bugs. But hopefully we can come up with some kind of realistic proposal that sets out a few basic expectations and guidelines.

tranquillo · 2005-08-24 06:38:12

> zem wrote:

>what the API might contain, if there was one, that sort of thing.

List of predefined events (similar to <a href=“http://docs.nucleuscms.org/blog/13”>Nucleus CMS</a>) and other of the features there, i.e. Plugin dependency check. One could then define, i.e. what happens at the installation event (i.e. creation of db tables or adding new language strings to db) etc.

zem · 2005-08-24 07:01:03

what the API might contain

Let me rephrase that:

Which parts of the existing Textpattern code could be considered part of the API.

(We’re talking about a stable branch here, remember)

greenrift · 2005-08-24 17:36:40

The global and constant names should be frozen. The way to register an adminside plugin. All the /lib/txp_* function names, inputs, and output (unless the output is incorrect, like wrapTag isn’t wrapping) shouldn’t change. If some convention for additional installation of plugins exists, then those shouldn’t change (or, eventually added, but not at this time), same goes for checking if a plugin is active or not.

zem · 2005-08-24 23:25:35

The global and constant names should be frozen. The way to register an adminside plugin. All the /lib/txp_* function names, inputs, and output (unless the output is incorrect, like wrapTag isn’t wrapping) shouldn’t change.

All fair enough, though the notion of “incorrect” is a bit vague. Usually it’s the edge cases that change, and without some kind of spec it’s not always clear what the correct behaviour should be.

Also, with respect to globals (and the individual members of certain global arrays like $pretext), we might have to mark some as “documented” (and thus frozen), and others as “internal” (and subject to change).

Freezing the lib function names and inputs should be high on the list, I think; that’s nice and concrete, easy to measure.

If some convention for additional installation of plugins exists,

Can you elaborate? I’m not sure what you mean by this.

greenrift · 2005-08-25 23:45:13

> zem wrote:
> If some convention for additional installation of plugins exists,
> Can you elaborate? I’m not sure what you mean by this.

I don’t know if there are plans to make some formal installation procedure, like a function that is ran after the plugin is activated. If there are, then something like that probably shouldn’t change.

Mary · 2005-08-28 10:05:06

I’d say something, but I really don’t know what I’d be after. Why is it no one wants your opinion unless you don’t have one? ^pondering…

hakjoon · 2005-08-28 18:18:16

Greenrift kind of hit on everything I was thinking of.

igner · 2005-08-29 14:30:19

Not to sound like too much of a me-too, but I’d concur that the most critical would be the lib functions, and the globals, though I’m completely OK if not all of either makes it into the official API. To that end, documentation is probably the most critical piece of the equation (and arguably the most time-consuming as well).

Regarding greenrift’s question about an installation procedure – I think this is really going to need to be the responsibility of the individual plugin developers. Not every plugin has a need for “setup” functionality, and plugins aren’t loaded on the plugin page (with good reason), so it’s not like you can simply call a function from the plugin when it’s installed and/or activated. But all that’s really tangental to the original question, since any install process would be a part of the function library…

Textpattern CMS

Textpattern CMS support forum

#1 2005-08-22 02:22:00

Plugin standards, etc

#2 2005-08-24 06:38:12

Re: Plugin standards, etc

#3 2005-08-24 07:01:03

Re: Plugin standards, etc

#4 2005-08-24 17:36:40

Re: Plugin standards, etc

#5 2005-08-24 23:25:35

Re: Plugin standards, etc

#6 2005-08-25 23:45:13

Re: Plugin standards, etc

#7 2005-08-28 10:05:06

Re: Plugin standards, etc

#8 2005-08-28 18:18:16

Re: Plugin standards, etc

#9 2005-08-29 14:30:19

Re: Plugin standards, etc

Board footer