Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Plugin filtering for admin list pages

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')?

Offline

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

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: Plugin filtering for admin list pages

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)

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Plugin filtering for admin list pages

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 .= ...?

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Plugin filtering for admin list pages

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)


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

Online

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

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: Plugin filtering for admin list pages

Sweet, nice. Thanks, Stef :-)

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Plugin filtering for admin list pages

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.

  1. 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.
  2. 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?

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Plugin filtering for admin list pages

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)


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

Online

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

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Plugin filtering for admin list pages

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?

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Plugin filtering for admin list pages

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.


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

Online

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

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Plugin filtering for admin list pages

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)

Offline

Board footer

Powered by FluxBB