I ran into an issue where I entered two view arguments on separate lines, but I was getting a blank PDF because the argument string was not converted to the array properly. I traced the issue to the fact that on a Mac [Not sure if this is the case elsewhere] a new line is entered w/ a carriage return character and a new line character, thus, the explode string would need to be "\r\n".

I know that would break it for systems w/out the extra character in a new line, so I cam up w/ the attached patch to strip out carriage returns [and tabs and spaces, just in case], before setting the argument.

The attached patch works on Mac, haven't tried it on PC. If someone else could that'd be great, not sure when I'll be able to.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

vegansupreme’s picture

Works for me. I haven't tried it on a PC though, only Mac.

killua99’s picture

Actually this code need to have PHP_EOL .. I'll try to fix it.

@whoisinkus maybe you can try it, use PHP_EOL instead the " \r\n" etc ...

killua99’s picture

Status: Needs review » Needs work
vegansupreme’s picture

@Killua99 I tried replacing the "\r\n…" with PHP_EOL, but it didn't work. I could replace the explode("\n", $arguments) with explode(PHP_EOL, $arguments) but it still seems to leave the extra \r.

Here's a patch that uses PHP_EOL, but I don't know if it's functionally any different from whoisinkus' original.

killua99’s picture

+++ b/views_pdf.rules.inc
@@ -66,7 +66,14 @@ function views_pdf_rules_action_save($views_pdf, $arguments, $path) {
+    $args[$k] = trim($v, " \r\n\t");

$args[$k] = trim($v, PHP_EOL . "\t"); doesn't work?

Where did you tried to replace it?

vegansupreme’s picture

Oh I had tried $args[$k] = trim($v, PHP_EOL);
hopefully I can test $args[$k] = trim($v, PHP_EOL . "\t"); on Monday.

vegansupreme’s picture

$args[$k] = trim($v, PHP_EOL . "\t"); doesn't work. I don't' know if it's because I'm using MAMP for dev environment…

It seems odd to have arguments separated by newlines in the first place. Could arguments be separated by "/" instead, as they are in the URL? Or would that cause some other problems? Maybe someone wants a "/" as part of their argument—it would have to be escaped. That said, whoisinkus' patch does solve the problem on Mac. I haven't been able to test on other platforms.

killua99’s picture

I just saw something

When you explore with PHP_EOL is remove the "\n" or "\r\n" from each array. So what exactly doesn't work with the $args[$k] = trim($v, PHP_EOL . "\t"); ? maybe you should do $args[$k] = trim($v, " \t"); ( I see a space in " and \).

Tell me if I'm wrong.

vegansupreme’s picture

Issue summary: View changes
FileSize
492 bytes

trim($v, PHP_EOL . "\t") still leaves a carriage return in the argument, so does trim($v, " \t") and trim($v, PHP_EOL." \t"). I've tried every permutation I could think of.

The only options that worked were trim($v, PHP_EOL."\r\n\t" ) and trim($v, "\r\n\t" )

Just found a different way to do it that seems to work. Using preg_split() instead of explode()
http://stackoverflow.com/questions/1483497/how-to-put-string-in-array-sp...

This patch works on Mac, but haven't tested on PC. If someone else could test on PC that would be great. I'm not sure when I'll be able to.

vegansupreme’s picture

Status: Needs work » Needs review
killua99’s picture

+++ b/views_pdf.rules.inc
@@ -66,7 +66,7 @@ function views_pdf_rules_action_save($views_pdf, $arguments, $path) {
+    $view->set_arguments(preg_split("/\r\n|\n|\r/", $arguments));

Why don't use \R then ? looks a better solution for me use preg_split weird we can't use PHP_EOL. Did you try it? "/" . PHP_EOL . "/". The reason I'll like to use PHP_EOL is for the support for multiples S.O and we don't have to write one by one, just that.

vegansupreme’s picture

Here's what I've tried:
$args[$k] = trim($v,"/".PHP_EOL."/"); NO
$args[$k] = trim($v, PHP_EOL); NO
$args[$k] = trim($v, PHP_EOL."\R"); NO
$args[$k] = trim($v, PHP_EOL." \R"); NO
$args[$k] = trim($v,'/'.PHP_EOL.'/'); NO

$args = explode(PHP_EOL, $arguments); NO

Nothing with EOL works. It would be a great if it did, but I haven't been able to get it working. It seems to be interpreting PHP_EOL as /n only. /n would probably work just fine when outputting a string, that is, it would be rendered as a newline just fine.
When I export the rule it says "arguments" : "5\r\n25",

I did some research:

Most textual Internet protocols (including HTTP, SMTP, FTP, IRC and many others) mandate the use of ASCII CR+LF ('\r\n', 0x0D 0x0A) on the protocol level

When entering text into the browser, it uses CR+LF, I suspect this is true on Mac and PC. But PHP is running on Linux (or Mac OS kernel) which uses LF only.
Therefore PHP_EOL can't work in this situation because it's only looking for LF—leaving behind the CR, and causing the argument not to validate.

vegansupreme’s picture

Did a quick test on a PC with IE. It also uses \r\n.

vegansupreme’s picture

FileSize
1.57 KB

How about we take an entirely different approach? It seems strange to use return separated arguments in the first place.

I took a look at how Views Field View handles contextual filters. They use commas or forward slash to separate values.
from the UI:

Use a comma (,) or forwardslash (/) separated list of each contextual filter which should be forwared to the view. See below list of available replacement tokens. Static values are also be passed to child views if they do not match a token format. You could pass static ID's or taxonomy terms in this way. E.g. 123 or "my taxonomy term".

vegansupreme’s picture

FileSize
1.57 KB

reroll patch from #14. If no objections I'll commit this soon.

vegansupreme’s picture

Actually I don't like this solution, because it wouldn't work well with multi-value arguments; a comma separated list of NIDs for example. I'll commit patch #9 if there are no objections.

  • vegansupreme committed 3be31ee on 7.x-1.x
    Issue #2289779 by vegansupreme, whoisinkus: Exploding Arguments in Rules...
vegansupreme’s picture

Status: Needs review » Fixed

Committed to dev.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.