PHP filter for views

sure, you could do that. is equivalent to creating a new filter and filter handler in a small module. you just have to work out the UI issue of where to input the code. UI is a big challenge for views, as big as code. somre reasonable features get neglected because noone has thought of a way to cleanly present it.

All filtering is done through SQL; a PHP filter is basically impossible unless you can find a way to make SQL run PHP code.

It is indeed possible, as long as one understands the the "filter" ability the poster wants doesn't actually have to be a strict "filter": PHP can be used to post-process the filtered results.

UI-wise, probably within the "Filters" dropdown, a "PHP post-process" textbox, or something like that (with the caption: "Don't use unless you know what you're doing") :-)

Implementation-wise, I imagine the following would be feasible: views.module, line 576, change db_query()s to db_query_temporary. The user's PHP code would then be responsible for db_query()ing the temp table, and that result object from the user's code would be the one used subsequently.

And as I type this, I realize this is actually possible even by actually making a "filter" for the PHP: the mod creator's comment that "unless you can make PHP run SQL" gave me the idea :-)

The PHP code could simply return a string which would be a SQL WHERE clause, and it could get add_where()ed in views_query.inc as a filter handler.

This might actually be a better solution than the above, in that it's much easier to explain to an end-user, and less likely to break anything. (For that matter, one could even go the extra mile and syntax-check that, since WHERE syntax is pretty straightforward.) However, it would probably be a bit more difficult to implement. We'd need a Views-native "Views: SQL WHERE string" filter, not tied to a particular table. (Or, I suppose, tied to a views table and all field descriptors left out?)

I wish I had time to look at this, because the original poster is right -- this would be fantastically useful. (At the very least, we'd have a whole new world of Views code snippets which could be thrown in the Handbook, and which would mean fewer feature requests in the future.) My plate is filled through the next few months, though. Hopefully someone will get a chance to look at this.

If you use it as a postprocessor, it becomes useless with a pager. Sure, you could force the pager to be turned off, and then you have to load every node, run it through the PHP filter...and probably run out of memory. I have no interest in this.

Like I mentioned halfway through, there's not even a need to do it as post-process; it can be done as an inline filter just like everything else.

I think it's a pretty solid idea, which would be massively useful to anyone who can use PHP, and I actually started working on something along those lines. I won't have tons of time to devote to it, so I'll mark postponed instead of active so that if anyone else wants to go for it, they can, but it's at least gotten started.

Perhaps I should specify more precisely the tack I'm currently taking:

It's clear that for this to be a filter, it would have to be made into a WHERE clause. But I didn't want to abandon the flexibility of dynamically created criteria. So I figured that we could use PHP after all, let folks handle arbitrary criteria to their heart's content, and make the PHP return a node ID list.

So, we implement a Node: Node ID filter, which has as its options "PHP" or "Specific ID" (really just to clarify in the UI whether PHP is to be used; I don't see much use for the "Specific ID" option, but it's in there right now; I might take that out later), uses the operator_or set of operations, and as its value can take a PHP code string and eval() it. It assumes an array of integers returned; I have a little checking in there to make sure that's the case, but it's not as robust as I'd like.

Though I don't imagine people let just anyone on their site create arbitrary views, I figure just in case there's probably going to need to be some way to permission-control that. I'll get to that after it's all working. ;-)

Alpha 1 of the patch, I guess you could say. Base functionality is working (actually using it on my production site right now -- how dumb am I?), but error checking is sparse at best.

What remains to be done:

1) The options have changed slightly from my description above, to "PHP code" and "ID list." ID list should work fine, but is untested. The PHP code handling has gone through some testing, as I considered that the "real" primary functionality, but could use a trial by fire.

2) As can be seen from the code, bad PHP is trapped, but not handled. Nothing breaks, but the filter will fail silently and do nothing. User warnings should be returned instead.

3) If anyone wants to be nitpicky, the few other form elements that use a #process function in their value key break out the value key into its own function. I did not do this; someone may want to.

Alpha 2.

Added "cacheable=no" to the nid filter. PHP that doesn't update dynamically seems a little silly, in retrospect. Oops on my part.

I will not consider this for Views. If you want to do this, take this to another project.

What you're writing is completely unrelated to what the original person was asking for, so at least you win in the "Ok, what you're doing works" but you also lose because it's Yet Another Place to put PHP code" and I keep rejecting those. There are other ways to do what you're doing and I'm not littering the Views UI with PHP code snippets. Views has way too many of those already. They are confusing and difficult.

Understood. I'm sorry you disagree with the concept. I personally have already found a dynamic customizable filter to be of great use. And I have found no other way to do what I'm doing, as you mentioned. I find this intuitive and powerful. But I understand that it is your module, of course. I don't wish to cause any problems with something you don't want in your module. Thank you for your consideration.

As you asked, I have put this in another project.

http://drupal.org/project/viewsphpfilter

Thank you for your efforts with the Views module. It is an excellent module.

Hoorya for modular design! I respect that the dynamic filter can be useful, and I'm glad that the design allows you to have this filter in a separate module. I suspect that for Views, some percentage of the user base that is less than 1% will even be able to do anything with such a filter, and I'm perfectly fine with suggesting they use another module to do it. I think that's an effective solution.