Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Standardized Plugin Help
That “Badly formed or empty plugin code” error is mostly a limit on the maximum size of a POST request that some webhosts have set to 64kB. That’s why compressing the plugin works. It doesn’t change the actual plugin; it only reduces the amount of data that is uploaded.
Not sure the best way to offer plugins that require a library though. Perhaps people should only find out about the library after the plugin’s installed?
I’d list the requirements at the download area. People should read the plugin help; that’s what it’s there for, so if a library is required, that’s a good place to mention it. The reason for having a library is normally to allow other plugins to use the same code, so it should be available separately. Bundling it often leads to old versions of the library being distributed.
And also, what of .js files and .css files and required images etc?
If they are small enough, you could consider making a plugin that self-extract itself within TXP so it auto-installs the static files and the ‘real’ plugin. If a plugin requires anything other than another plugin… is it still called a plugin? I always assumed plugins were self-contained.
plugin (.txt) files by default open straight in the browser window
Can’t that be changed by sending a different HTTP header?
Offline
Re: Standardized Plugin Help
plugin (.txt) files by default open straight in the browser window
In FireFox you can make changes in options. When I click on a plug-in .txt link my browser asks me if I want to view it or download it. Simple one-click choice.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: Standardized Plugin Help
I always assumed plugins were self-contained.
I agree. A plugin should be self-contained. If it’s not it’s more of an add-on and most add-ons are a bit more complex to install then the “classic” plugin.
If 64kB is not sufficient, I’d like to see an example ;)
My advanced search plugin requires an external PDF manual, there’s no way I could have crunched that into 64kB. Maybe if I did a re-write of the code (again) it could be done a bit better. Hmmm … :D
Plugins: ob1_advanced_search 1.032b, ob1_search_score 1.0, ob1_pagination 2.5, ob1_title 4.1, ob1_modified 2.1
“Let your plans be dark and as impenetratable as night, and when you move, fall like a thunderbolt.”
— Sun Tzu
Offline
#28 2008-01-02 23:48:19
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Offline
Re: Standardized Plugin Help
But still, if it can not be self-contained, is it a plugin still or have it evolved into an add-on?
Plugins: ob1_advanced_search 1.032b, ob1_search_score 1.0, ob1_pagination 2.5, ob1_title 4.1, ob1_modified 2.1
“Let your plans be dark and as impenetratable as night, and when you move, fall like a thunderbolt.”
— Sun Tzu
Offline
Re: Standardized Plugin Help
ruud wrote:
That “Badly formed or empty plugin code” error is mostly a limit on the maximum size of a POST request
Ahhh, makes sense. I’ll offer a compressed option as standard from now on, thanks for clearing that up.
I’d list the requirements at the download area. People should read the plugin help; that’s what it’s there for
Agreed, and fair enough. I’ll certainly revisit this as I make updates, and rejig my horrible site and the entries at textpattern.org to make it uber-clear what’s what and what’s needed when. I’m such a slapdash hacker…
If a plugin requires anything other than another plugin… is it still called a plugin? I always assumed plugins were self-contained.
Didn’t realise that was the definition of a plugin, oops. I’d better rename most of mine then to… what is the official TXP nomenclature for plugins that aren’t quite plugins? Add-ons? I don’t want to mis-sell stuff.
The auto-install idea is interesting but probably out of my league right now. Most of my plugins to date require some form of styling and most rely on 3rd party js. Does this mean that anything using jQuery and any of its non-core-included subsidiaries (ui, dimensions etc) isn’t technically a pure plugin either?
@thebombsite
Thanks, and sorry for going OT here. Even though the dialog box with the radio buttons annoys me in FF (why they don’t offer 2 or 3 buttons for direct action is beyond me), where do you set .txt to do something else? In my prefs Content -> File Types -> Manage I don’t have a TXT file type listed and I can’t see a way of adding it in 2.0.0.11. Maybe I’m being thick.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Standardized Plugin Help
obeewan wrote:
But still, if it can not be self-contained, is it a plugin still or have it evolved into an add-on?
Where does the distinction get made?
hak_tinymce is really an interface between TXP and tiny_mce so they can be distributed separately, the plugin is actually quite small, but I’m not sure that it’ the best approach as it would then require users to go and download tinyMCE and the image plugin, and install it all.
That being said I have been thinking about doing that so that i don’t have to keep updating the bundled tinyMCE version (which I am woefully bad at doing in a timely fashion)
Shoving is the answer – pusher robot
Offline
Re: Standardized Plugin Help
Where does the distinction get made?
Just take a step back and “feel” the words. Plugin. Addon. Looking on the meaning of the words this is my opinion what they mean (and do write back if I’m off the charts here).
A plugin; something you plug in to the software and we’re good to go. It’s all there, self-contained, nothing more needs to be added. Like back in the days when Microsoft added plug-n-play to Windows. The meaning of the whole concept was to just plug something in and then you’re ready to play (allthough it didn’t quite work that well out of the box, but that’s a whole different story).
An addon; something you add to the software but might require something extra to work, like for instance an css file, another plugin, a hack into the core or a library not included with the software and so on.
I’d love to hear your opinions on this.
Plugins: ob1_advanced_search 1.032b, ob1_search_score 1.0, ob1_pagination 2.5, ob1_title 4.1, ob1_modified 2.1
“Let your plans be dark and as impenetratable as night, and when you move, fall like a thunderbolt.”
— Sun Tzu
Offline
Re: Standardized Plugin Help
@Stef – actually I was only half right. It depends on the link. If the link points directly to the txt file you simply get a chunk of Base64 thrown at you whereas if the link is a “download” you get the option provided that it is a txt file.
So I suggest that maybe all plug-in links should be downloads?
@Henrik – I’m with you on your definitions but what happens when you have a plug-in that is 2 plug-ins for example, zem_contact_reborn requires zem_contact_lang and there are a couple of others that have library plug-in requirements. So 2 plug-ins for the price of 1 but are they still plug-ins or are they add-ons.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: Standardized Plugin Help
Henrik, I feel the same about those words. But unfortunately in terms of history they mean the same if being precise. Or that history of English and those words says.
something you add to the software but might require something extra to work
Extension – as it’s used commonly with softwares/programs and can be just part of bigger consistness. But because it means many things, it’s quite hard to use. So, word plugin in much better.
Cheers!
Last edited by Gocom (2008-01-03 03:17:12)
Offline
Re: Standardized Plugin Help
@Henrik – Your definitions make sense but I do kind of feel like in the end it’s really just semantics. I’m cool with either terminology but I do think Stuart has a point on the library plugin issue.
Shoving is the answer – pusher robot
Offline
Re: Standardized Plugin Help
Plugin authors don’t seem to be adhering to any standard as to how their help files display – and many are using inline CSS which should be discouraged.
To that end, I’ve rewritten this document to an extent in order to direct authors better. Let me know if you see any problems within it.
I think we also need another CSS rule or two in the core themes (Classic and Remora) so that plugin authors have all the display tools they need in order to get their help documents looking good. For example we need better display of code tags and pre tags like so:
code, .code {
font: 1.1em Monaco, "Courier New", monospace;
}
code {
border: 1px solid #e3e3e3;
padding: 0 .2em;
background: #f7f7f7;
}
pre {
overflow-x: auto;
border: 1px solid #e3e3e3;
padding: 1em;
background: #f7f7f7;
}
pre code,
.code code {
border: 0;
padding: 0;
background: none;
}
code.body,
code.excerpt {
border: 0;
padding: 0;
background: none;
}Offline