On our site, which uses Domain Access, we want to display a view as the splash, if and only if the view returns results. We were able to get the contents of the view to display easily, by creating it as a page with a path.

However, since it isn't practical to crowd the "When" or "Where" forms with specialized controls for views (at least not for me, at this time) this represents a use case when running arbitrary PHP to determine visibility is useful.

I have prepared and tested a simple patch against the latest 7.x-1.x dev build.

CommentFileSizeAuthor
#6 splashify-n3002616-6-php_visibility.patch3.59 KBmw4ll4c3
#3 splashify-n3002616-3-php_visibility.patch3.41 KBmw4ll4c3
#2 splashify-n3002616-2-php_visibility.patch2.97 KBmw4ll4c3

Comments

mw4ll4c3 created an issue. See original summary.

mw4ll4c3’s picture

mw4ll4c3 commented
StatusFileSize
new splashify-n3002616-2-php_visibility.patch2.97 KB
mw4ll4c3’s picture

mw4ll4c3 commented
StatusFileSize
new splashify-n3002616-3-php_visibility.patch3.41 KB

Two minor additions in this patch:

  • check for the PHP module before evaluating the code
  • remove the new "splashify_when_php" variable when uninstalling
ivnish’s picture

ivnish
he/him
commented

"PHP filter" is evil :)

ivnish’s picture

ivnish
he/him
commented
Status: Needs review » Closed (outdated)
mw4ll4c3’s picture

mw4ll4c3 commented
Status: Closed (outdated) » Needs review
StatusFileSize
new splashify-n3002616-6-php_visibility.patch3.59 KB

Thank you for doing issue queue triage, but I disagree 100% in this case.

PHP filter is evil... if you allow random users to execute arbitrary code during content creation. But allowing priviledged users to enter PHP for a visibility check, deep in the admin section, is done by the Blocks module, too. If it's safe enough for Core, it's safe enough for contrib.

However I did miss something: checking user_access("use PHP for settings") to make sure the current user is allowed to do that. (I also changed the use of NULL to an empty string. That's more in line with both Blocks' implementation, and with the other Splashify variables.)

I don't expect this patch will get committed to 7.x-1.x, but "Closed (outdated)" is a misleading status for a feature request with a working patch and no other existing solution. I understand if the maintainers want to set it to "Closed (won't fix)" but I'd rather see it get RTBC'd or even just stay as "Needs Review" for all eternity, in hopes that it can help even one other person who needs it.

astonvictor’s picture

astonvictor commented
Status: Needs review » Closed (outdated)

D7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.