Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Plugin developers' wish list
As a plugin developer, you are apparently affected by both the core’s backend markup, event messages and API library. This thread serves as a collection of proposals from plugin developers for changes to the core to ease a plugin developer’s life.
Preconditions:
- Try to keep things intact, balance the benefit of any proposal for the whole Texpattern audience against the impact on existing platform contributions.
- Try to be precise. Deliver pointers into the existing core code with understandable suggestions for additions or changes (it need not be in the form of a patch, but stand a geek’s judgement).
- Avoid picking on others’ suggestions. We will judge each entry for ourselves and open a dedicated thread for items worth discussing, and we will eventually purge unrelated posts from this thread.
Offline
Re: Plugin developers' wish list
I’d like admin-backend allways to send no-cache headers to avoid rewriting prefs or some texareas with old values. This occured with me several times – i one browser i made changes in, for example, Page. But when i opened this Page in other browser it openes cached version of Page without latest changes. This happens usually with Opera browser.
Providing help in hacking ATM! Come to courses and don’t forget to bring us notebook and hammer! What for notebook? What a kind of hacker you are without notebok?
Offline
#3 2008-10-20 13:25:23
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: Plugin developers' wish list
Robert
Thanks for starting the thread.
The first thing I’d like to see are the radio button routines in txplib_forms.php extended to avoid the need for plugin authors to write their own radio button handlers when the yes/no or on/off buttons don’t fit the bill or if you need more than two options. This would of course, allow more flexible radio options in the core code too. I’ve a patch for this.
How widely useful would this be? I can’t tell but I have needed either different labels, or more than 2 options, a couple of times (in sed_section_fields and some custom preferences.)
— Steve
Offline
Re: Plugin developers' wish list
Robert thanks for this thread.
Here are two things I’ve wanted for a while now:
- Being able to specify conditions when compiling on a plugin which are check when a user tries to install it. For example, if a plugin only works on TxP 4.0.6 with version 1.0 of abc_plugin. If the conditions aren’t fulfilled there should be a warning. Other conditions like ‘must have abc_plugin installed’ or ‘incompatible with xyz_plugin’ would also be useful but versioning is the one I really miss.
- I’ve asked for this before but here goes again… would love to have a callback inside pagelinkurl() just like the
$prefs['custom_url_func']setting used in permlinkurl(). This would make it much easier to provide accurate urls from gbp_permanent_links (which currently renders the page and then tries to ‘fix’ and pagelinks)
Offline
#5 2008-11-07 00:29:52
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: Plugin developers' wish list
Graeme
good to see you posting here again. About time some other plugin writers responded to this great offer from Robert!
You wrote…
Being able to specify conditions when compiling on a plugin which are check when a user tries to install it. For example, if a plugin only works on TxP 4.0.6 with version 1.0 of abc_plugin. If the conditions aren’t fulfilled there should be a warning. Other conditions like ‘must have abc_plugin installed’ or ‘incompatible with xyz_plugin’ would also be useful but versioning is the one I really miss.
I have a patch to do this, but there doesn’t seem to be much interest in it — at least, not is some of its features. I posted about it here.
— Steve
Offline
Re: Plugin developers' wish list
net-carver wrote:
The first thing I’d like to see are the radio button routines in
txplib_forms.phpextended to avoid the need for plugin authors to write their own radio button handlers when the yes/no or on/off buttons don’t fit the bill or if you need more than two options.
Offline
#7 2008-11-07 18:41:03
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: Plugin developers' wish list
Thank you Robert. And for r2990 too.
Last edited by net-carver (2008-11-07 18:50:39)
— Steve
Offline
Re: Plugin developers' wish list
I’ve recently rewrote the plugin compiler for xpattern and just sharing the wealth. Some of the highlights are the ability to compile, decompile and generate new empty plugin files. In addition to the current method of executing the plugin file to compile a pluign, you can execute the compiler to do the compiling or other actions.
A major feature/improvement that I’ve added is the ability to embedded external files in to the compiled plugin file. This was added so that plugin authors do not have to base64 encode files inside the plugin code, which simplifies versioning of these files. On install, these files are placed in to a private, web readable location. Each plugin gets their own sub-folder to avoid naming collisions.
The plugin compiler and other admin side changes can be found at xPattern on BitBucket
Regards,
Manfre
Last edited by Manfre (2008-11-08 13:56:53)
Offline
Re: Plugin developers' wish list
graeme wrote:
I’ve asked for this before but here goes again… would love to have a callback inside pagelinkurl() just like the
$prefs['custom_url_func']setting used in permlinkurl().
I wonder whether adding a third argument to the callback invocation as an indication of article vs. page URI would be “sufficiently compatible” for existing custom URL functions ?
I.e.
function pagelinkurl($parts, $inherit = array())
{
global $permlink_mode;
// $inherit can be used to add parameters to an existing url, e.g:
// $url = pagelinkurl(array('pg'=>2), $pretext);
$keys = array_merge($inherit, $parts);
if (isset($prefs['custom_url_func']) and is_callable($prefs['custom_url_func']))
return call_user_func($prefs['custom_url_func'], $keys, PAGELINKURL);
[...]and
function permlinkurl($article_array)
{
global $permlink_mode, $prefs, $permlinks;
if (isset($prefs['custom_url_func']) and is_callable($prefs['custom_url_func']))
return call_user_func($prefs['custom_url_func'], $article_array, PERMLINKURL);
[...]Please provide a guesstimation…
Offline
Re: Plugin developers' wish list
wet wrote:
I wonder whether adding a third argument to the callback invocation as an indication of article vs. page URI would be “sufficiently compatible” for existing custom URL functions ? Please provide a guesstimation…
Quickly tested and this looks like it’ll work well.
I agree that it would be “sufficiently compatible” – the only thing that will needs changing for gbp_permanent_links is to remove the nasty hack I used to get it working as the code is now. For other implementations there is a chance it may causes a slight problem but I honestly doubt there will be any other plugins using custom_url_func – but just to be safe maybe it would be better to use a different setting for the callback?
Thanks for this Robert
Offline
Re: Plugin developers' wish list
graeme wrote:
… – but just to be safe maybe it would be better to use a different setting for the callback?
I think having a single entry point is worth the slight change, so here we go.
Offline
Re: Plugin developers' wish list
Full Textile in plugin help would make writing and styling help files a lot easier. The only change from a user’s perspective is Textile-help would be previewed as source code with highlight_string in the same way HTML-help is previewed on install. The small patch and discussion from ~6 months ago is here too.
Last edited by jm (2008-11-21 22:19:42)
Offline