Plugin filtering for admin list pages

etc · 2012-07-26 20:38:04

Gocom wrote:

The $criteria parameter doesn’t actually have any need, does it? It’s not like you can use it for anything or alter it.

Suppose (as per mrdale request) we want to hide some section’s articles from the list, unless this section is searched for. How a plugin would make the difference without $criteria: with gps('crit')?

Gocom · 2012-07-26 20:52:19

Bloke wrote:

Is the plugin stack even cumulative or does each plugin get the “vanilla” value

When using callback_event(), each callback function gets the vanilla value, a (new) copy of the passed parameter. There would need to be a new callback event handler that appends callback member’s returned results to the callback parameter. If that’s even realistically possible. That’s pretty niche case after all, and locks the number and the position of parameters.

You could potentially use callback_event_ref(), but that does plain referencing. Works only if callback functions actually use the argument instead of returning statements, and members will actually be overwriting the same variable. If *_ref() is used, you would also have to create a new copy variable of the original $criteria that is then passed to the callback_event_ref(). Otherwise members will be referencing the vanilla variable and overwriting the whole SQL clause as whole.

etc wrote:

Suppose (as per mrdale request) we want to hide some section’s articles from the list, unless this section is searched for. How a plugin would make the difference without $criteria: with gps('crit')?

Well, yeah. Using the HTTP GET parameter is much more viable than the raw SQL statement. The raw SQL statement is just that; a string. It’s not very viable to use it to detect if something was searched. Unless you are going to somehow parse it or result in hackish regex.

Last edited by Gocom (2012-07-26 20:56:27)

etc · 2012-07-26 20:59:47

Gocom wrote:

Using the HTTP GET parameter is much more viable than the raw SQL statement.

Agree. Then $criteria = ... is probably more natural than $criteria .= ...?

Bloke · 2012-07-26 21:46:34

Mrdale, your pony is in the lobby

Plugin mrd_cull_section:

register_callback('mrd_cull_section', 'admin_criteria', 'list_list');

function mrd_cull_section($evt, $stp, $crit) {
	return " AND Section != 'articles'";
}

Plugin mrd_for_your_eyes_only:

register_callback('mrd_for_your_eyes_only', 'admin_criteria');

function mrd_for_your_eyes_only($evt, $stp, $crit) {
	global $txp_user;
	$user = doSlash($txp_user);

	if ($stp === 'list_list') {
		return " AND AuthorID = '$user'";
	} else if (in_array($stp, array('link_list', 'file_list', 'image_list'))) {
		return " AND author = '$user'";
	}
}

:-)

(although they probably won’t work well together, so you’d have to combine them into one plugin if you wanted both bits of functionality). You may choose to employ some extra logic to permit the Publisher to see everything.

Last edited by Bloke (2012-07-27 13:03:47)

Gocom · 2012-07-26 21:55:57

Sweet, nice. Thanks, Stef :-)

etc · 2012-07-27 11:39:16

Thank you, guys, also for having associated to your discussion someone who otherwise respects the “Experienced users only” sign. Ten-lines asv_auth_articles – wow!

But as “plugin author” I have some doubts.

I would not like my where clause be concatenated with something I even do not see (debugging nightmare). Of course, I can issue something like AND 0 OR ..., but prefer avoid hacking.
On the other hand, $criteria is needed in search queries, and I would not like to reconstruct it based on GET parameters (that I will forget to escape).

So, would it be possible to pass $criteria to callback_event, and let plugin authors decide what where clause should be?

Bloke · 2012-07-27 12:29:48

etc wrote:

I would not like my where clause be concatenated with something I even do not see (debugging nightmare). Of course, I can issue something like AND 0 OR ..., but prefer avoid hacking.

This crossed my mind as I was writing it last night. For that reason I’d started out passing $criteria as the 3rd param, then removed it after the most recent exchange above.

For searches, as you say, the criteria will be something other than ‘1’ so under these circumstances, yeah, perhaps it’d be nice to know if a search has been performed so you can either append to what is already present, or just ignore search criteria (at your users’ peril!). It can’t hurt to include it so plugin authors can stay informed. Leave it with me.

Last edited by Bloke (2012-07-27 13:05:37)

etc · 2012-07-27 12:48:15

Many thanks! and I can’t stop thinking that you’d have less modifications to do if it were implemented at some safe_*_like level, maybe in some future version?

Bloke · 2012-07-27 13:03:24

There you go. I’ll update the code above to cater for the new function signature.

etc wrote:

I can’t stop thinking that you’d have less modifications to do if it were implemented at some safe_*_like level

Not exactly much work, and I’m with Jukka on this at the moment.

etc · 2012-07-27 13:20:26

Bloke wrote:

Not exactly much work, and I’m with Jukka on this at the moment.

Fine, me too, it could rather be something like $criteria = get_user_criteria($criteria, ‘admin_criteria’, ‘image_list’, ... ); function, which only does

$out = callback_event('admin_criteria', 'section_list', 0, $criteria);
return( $out === '' ? $criteria : $out );

but let us forget it. Nevertheless (^{hiding myself under the table}), my suggestion was to replace $criteria .= callback_event(...) by $out = callback_event(...); if($out !== '') $criteria = $out; like for other callbacks. “$criteria AND …” is more natural for me (plugin author) than “ AND …” as where clause.

Last edited by etc (2012-07-27 13:40:06)

Textpattern CMS

Textpattern CMS support forum

#25 2012-07-26 20:38:04

Re: Plugin filtering for admin list pages

#26 2012-07-26 20:52:19

Re: Plugin filtering for admin list pages

#27 2012-07-26 20:59:47

Re: Plugin filtering for admin list pages

#28 2012-07-26 21:46:34

Re: Plugin filtering for admin list pages

#29 2012-07-26 21:55:57

Re: Plugin filtering for admin list pages

#30 2012-07-27 11:39:16

Re: Plugin filtering for admin list pages

#31 2012-07-27 12:29:48

Re: Plugin filtering for admin list pages

#32 2012-07-27 12:48:15

Re: Plugin filtering for admin list pages

#33 2012-07-27 13:03:24

Re: Plugin filtering for admin list pages

#34 2012-07-27 13:20:26

Re: Plugin filtering for admin list pages

Board footer