Css cache compiler problem

[cclaerhout]

Hello,

I'm still having memory problems with XenForo that my host doesn't manage to solve (import addons/activate addons after disable them, etc.). I don't know if the following css problem is linked or not, but here it is:

On some pages css are broken. The css for addons (not the XenForo one) is not generated. I thought it was coming from a coding error of one of my addon. Once I disable the last addon I've installed, it was working again. I've checked my css and found nothing wrong here. I've tried to delete all css in the css template, it didn't work. I deleted then the xen code "<xen:require css="MyTemplate.css" />, it worked... I tried to reproduce this with another template same thing (same addon).

I've tried then with another addon which was not mine BUT which displays on the same page... and I reproduce the same thing.

So to sum up: if I delete all the css, the problem remains, if I delete the xen code, the problem is "solved".

My questions:

1. Is there a maximum number we can integrate css templates per page?
   Which would mean it's a XenForo problem... but I don't think so since I don't have those problems on my other board, but I can't be sure of the number of times the "<xen:require css" command is triggered
2. Is integrating css templates with the xen tag requires a lot of memory? (
   Which would mean the problem comes from my host

 

[cclaerhout]

After shouting in front of my screen, it seems I found where the problem was coming from:
If you use TMS
1) Go to Admin Panel => Options =>Template Modification System
2) Uncheck "Compile templates on modification save and switch"
3) Rebuild manually the cache

=> It fixes a memory problem with addon activation... and for a mysterious reason, it seems to fix also the css problem described above.

 

[cclaerhout]

The problem is still there. I was tired yesterday and didn't check the good thread. I disable one addon at the moment.

The addons css file has only this inside it "@CHARSET"UTF-8";"

 

[cclaerhout]

The problems comes if more than 30 css requests are done (30 ok, 31 breaks)

For example with these css, it will work:

AdvBBcodeBar_TinyMCE
AdvBBcodeBar_css_normal
GoToTop_mini
MarkitUpIntegrator
MarkitUpIntegrator_Tools
MarkitUp_Tools_Color_Picker
Picasa_BBcode
Premium_BBcode
attached_files
attachment_editor
bb_code
bbcm_js
collapsible_sidebar
dark_postrating
dc_smileymanager
editor_ui
magicarrow
message
message_user_info
quick_reply
quoteME
sedo_enhanced_tiny
sedo_website_width_toggle
sedo_website_width_toggle_members_fluid
share_page
thread_view
toggleme_auto
toggleme_manual
waindigo_copyright_hide

29 css

With these it will not work:

AdvBBcodeBar_TinyMCE
AdvBBcodeBar_css_normal
GoToTop_mini
MarkitUpIntegrator
MarkitUpIntegrator_Tools
MarkitUp_Tools_Color_Picker
Picasa_BBcode
Premium_BBcode
attached_files
attachment_editor
bb_code
bbcm_js
collapsible_sidebar
dark_postrating
dc_smileymanager
editor_ui
inline_mod
magicarrow
message
message_user_info
moderator_bar
quick_reply
quoteME
sedo_enhanced_tiny
sedo_website_width_toggle
sedo_website_width_toggle_members_fluid
share_page
thread_view
toggleme_auto
toggleme_manual
waindigo_copyright_hide

31 css

Differences:

inline_mod
moderator_bar

Xen error logs: none
Xen root error_log file: none

 

[HWS]

Thank you for taking a deeper look into that problem!
We can only confirm that there are CSS errors and that there is nothing about it in any error log.

 

[cclaerhout]

Thank you for taking a deeper look into that problem!
We can only confirm that there are CSS errors and that there is nothing about it in any error log.

May be you should edit the CssOutput.php file and modify the function "renderCssFromObjects" and set "$withDebug" to true".

In my case it didn't show any error message, but if I do a dump of the $rendered variable I then see this error (inside the css file) while the css are compiling:

An unexpected error occurred. Please try again later.

Unfortunately an "unexpected error" doesn't tell me much about it

Edit 1: If dump the variable $templates of that function, it's already empty...
Edit 2: The $this->_cssRequested returns an empty value too

 

[Jake Bunce]

The problems comes if more than 30 css requests are done (30 ok, 31 breaks)

That's funky.

Are you running suhosin (hardened PHP)? That extension can mess up input sometimes. Just a guess.

You will need to debug this. I would start by debugging $input['css'] in XenForo_CssOutput:arseInput. Make sure the string outputs what is in the URL. I can do this if you give me FTP and admin access.

 

[Jake Bunce]

Edit 2: The $this->_cssRequested returns an empty value too

Continuing my previous post... $this->_cssRequested is built from $input['css']. Definitely debug that. But it sounds like the input just isn't getting through to the application. Suhosin is a possible cause, or some other server problem.

 

[cclaerhout]

Continuing my previous post... $this->_cssRequested is built from $input['css']. Definitely debug that. But it sounds like the input just isn't getting through to the application. Suhosin is a possible cause, or some other server problem.

I've been trying to debug that variable for 40 minutes now but that's not easy. After dumping this variable, it automatically breaks and stop after the XenForo Css. I've tried to make a global variable to listen this input variable and then dump it... It works but there's not "css" key with the addons css.

For example:
> XenForo css

<pre>array(1) {
  [0] => array(5) {
    ["css"] => string(19) "xenforo,form,public"
    ["style"] => string(1) "2"
    ["dir"] => string(3) "LTR"
    ["d"] => string(10) "1358022382"
    ["xf_session"] => string(32) "1ff058581a03e3965199e6b0b75bde10"
  }
}

>Addons css

<pre>array(1) {
  [0] => array(4) {
    ["style"] => string(1) "2"
    ["dir"] => string(3) "LTR"
    ["d"] => string(10) "1358022382"
    ["xf_session"] => string(32) "1ff058581a03e3965199e6b0b75bde10"
  }
}

I'm going to ask my host for "suhosin".

 

[cclaerhout]

Same results if I dump the variable $_REQUEST of the run function

 

[Jake Bunce]

So it's as if that input variable is being truncated. That is typical of suhosin, where hard limits are imposed on input.

 

[cclaerhout]

So it's as if that input variable is being truncated. That is typical of suhosin, where hard limits are imposed on input.

Thank you Jake I will see that with my host. At worst, it seems the $_SERVER['argv'] has everything needed to make a patch.

 

[cclaerhout]

My host tried to increase the value of :
suhosin.post.max_vars=4252
suhosin.request.max_vars=4252

And the bug is still there. I think the variables that should be modified are:
suhosin.get.max_value_length
suhosin.post.max_value_length

I've just asked him if he could try that. Otherwise I've done a patch that will work:

Search for:

$cssOutput = new self($_REQUEST);

Replace with:

        $fix = $_REQUEST;
       
        if(!isset($fix['css']))
        {
            preg_match('#css=(.*?)&#ui', $_SERVER['argv'][0], $match);
            $fix['css'] = $match[1];
        }
 
        $cssOutput = new self($fix);

 

[cclaerhout]

I confirm the solution was to increase the suhosin.get.max_value_length (=> 1024).
It's working now without the above patch.

Thank you Jake

 

[cclaerhout]

Here's a simple addon to detect if Suhosin is installed on the server. It might help users who are with a share hosting.
http://xenforo.com/community/resources/suhosin-detector.1387/