Support Forum

wet · Tweet

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.

the_ghost · Tweet

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.

net-carver · Tweet

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.)

graeme · Tweet

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)

net-carver · Tweet

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.

wet · Tweet

net-carver wrote:

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.

r2991

net-carver · Tweet

Thank you Robert. And for r2990 too.

Last edited by net-carver (2008-11-07 18:50:39)

Manfre · Tweet

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)

wet · Tweet

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…

graeme · Tweet

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

Txp Network Links

Textpattern Support Forum

2008-10-20 10:44:07

Plugin developers' wish list

2008-10-20 10:49:39

Re: Plugin developers' wish list

2008-10-20 13:25:23

Re: Plugin developers' wish list

2008-11-06 22:34:30

Re: Plugin developers' wish list

2008-11-07 00:29:52

Re: Plugin developers' wish list

2008-11-07 18:37:09

Re: Plugin developers' wish list

2008-11-07 18:41:03

Re: Plugin developers' wish list

2008-11-08 13:54:33

Re: Plugin developers' wish list

2008-11-10 07:04:28

Re: Plugin developers' wish list

2008-11-10 19:34:54

Re: Plugin developers' wish list