Server issue Error when creating thread with draft

[Jake B.]

Template Errors: thread_create

1. Invalid argument supplied for foreach() in /home/****/library/XenForo/Template/Abstract.php(265) : eval()'d code, line 892:
   891: ';
   892: foreach ($poll['responses'] AS $response)
   893: {
   
   
2. Invalid argument supplied for foreach() in /home/****/library/XenForo/Template/Abstract.php(265) : eval()'d code, line 900:
   899: ';
   900: foreach ($poll['extraResponses'] AS $null)
   901: {

Steps to reproduce:

1. Go to create new thread page
2. click 'save draft'
3. refresh page

Only happens when you have debug mode on. This happened on a clean XF 1.5.2 install with no add-ons or styles.

 

[Chris D]

Not tested or looked at the code in detail but I have just quickly tested this and I cannot reproduce it.

Can you consistently reproduce this? Or are there any missing steps?

 

[Jake B.]

Not tested or looked at the code in detail but I have just quickly tested this and I cannot reproduce it.

Can you consistently reproduce this? Or are there any missing steps?

I've been able to consistently replicate this on XF 1.5.2 with those steps. It was on our test board with all add-ons disabled and on the default style. I'll shoot you a PM with username/password for an admin account so you can see it

 

[Chris D]

Sorry for the delay in looking at this in more detail.

I believe this to be a server issue which we have come across before, I'll try and find some more details surely.

Specifically, this is what {$poll} looks like under normal conditions after being saved as a draft, on my machine:

array(6) {
  ["question"] => string(0) ""
  ["responses"] => array(0) {
  }
  ["max_votes_type"] => string(6) "single"
  ["change_vote"] => string(1) "1"
  ["view_results_unvoted"] => string(1) "1"
  ["extraResponses"] => array(2) {
    [0] => bool(true)
    [1] => bool(true)
  }
}

This is what {$poll} looks like on your server:

array(3) {
  ["max_votes_type"] => string(6) "single"
  ["change_vote"] => string(1) "1"
  ["view_results_unvoted"] => string(1) "1"
}

Again, I will try and specifically point you in the direction of what is causing this (we've seen it before), but generally speaking something on your server is unsetting keys from $_POST where the value is "falsey".

 

[Chris D]

Ah, that was easier to find than I expected. From a recent ticket which was similar:

The problem here actually appears to be caused by the "suhosin" PHP module. While enabled, by default, it appears to discard empty POST request.

So, as it says, by default suhosin discards vales from $_POST where the value is empty. I have no idea why that would ever be a useful feature, but if you have suhosin you should look into disabling that feature. In the first instance, you might want to just try disabling the suhosin extension completely to see if that fixes the problem.

 

[Jake B.]

Ah, that was easier to find than I expected. From a recent ticket which was similar:

So, as it says, by default suhosin discards vales from $_POST where the value is empty. I have no idea why that would ever be a useful feature, but if you have suhosin you should look into disabling that feature. In the first instance, you might want to just try disabling the suhosin extension completely to see if that fixes the problem.

I've got apache rebuilding now with suhosin disabled. Will reply after that's done

 

[Jake B.]

Yep! That did it

 

[Jake B.]

Could I suggest changing this:

<xen:foreach loop="$poll.responses" value="$response">
                    <li><input type="text" name="poll[responses][]" class="textCtrl" placeholder="{xen:phrase poll_choice}..." maxlength="100" value="{$response}" /></li>
                </xen:foreach>
                <xen:foreach loop="$poll.extraResponses" value="$null">
                    <li><input type="text" name="poll[responses][]" class="textCtrl" placeholder="{xen:phrase poll_choice}..." maxlength="100" /></li>
                </xen:foreach>

to this:

               <xen:if is="is_array($poll.responses)">
               <xen:foreach loop="$poll.responses" value="$response">
                    <li><input type="text" name="poll[responses][]" class="textCtrl" placeholder="{xen:phrase poll_choice}..." maxlength="100" value="{$response}" /></li>
                </xen:foreach>
               </xen:if>

               <xen:if is="is_array($poll.extraResponses)">
                <xen:foreach loop="$poll.extraResponses" value="$null">
                    <li><input type="text" name="poll[responses][]" class="textCtrl" placeholder="{xen:phrase poll_choice}..." maxlength="100" /></li>
                </xen:foreach>
                </xen:if>

It might help save some confusion for people if they happen to have debug mode on

 

[Chris D]

Well, it's not really necessary. There's actually a whole load of places where the specific issue you encountered could cause pretty fundamental issues to the operation of XF. Off the top of my head I can think of a number of places which would more than likely fall over due to this issue. Even things like undefined indexes because we are looking for indexes which should definitely be there, but they aren't because they've been stripped out.

Realistically, it's better to not suppress these kinds of things because they are indicating a much more sinister problem that needs attention.

 

[Jake B.]

Ah yeah, fair enough. Any chance you know the specific suhosin configuration that causes this? I've searched for it but can't seem to come up with anything so I've just disabled it

 

[Chris D]

I'm not certain, but looking at their somewhat vague documentation I would guess it's:

suhosin.post.disallow_nul
suhosin.post.disallow_ws