We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 22640
    • 44 Posts
    Hi everyone,

    I’m hoping someone may be able to help me out with this problem. I’ve tackled finding a solution through other avenues, including my server admin and PHP forums, but I have narrowed the problem down to be related to MODx. Here is goes:

    I have some PHP code. It is designed NOT TO WORK. It will produce an error. Here it is:

    <?php
    
    // file name: test.php
    
    echo "hi";
    header("Location:index.php");
    
    ?>
    


    OK, obviously I will get the following error:
    "Cannot modify header information....blah blah blah" because of the output before the header() function.

    Now, I have run this test script on the following:

    1) a web site on a server not using MODx. No account on that server runs MODx.
    2) a web site on a server not using MODx but other sites on the same server are using MODx, and
    3) a web site using MODx.

    I get the "Cannot modify header information..." error on the first 2 situations above, but not when testing it on a MODx managed site. Follow? The page actually redirects to "index.php" without any indication that an error occurred and no error is written to the error log.

    I am therefore wondering, does MODx suppress these errors? It is obviously very important that these errors be displayed so I can fix them.

    Does anybody have any ideas what is causing it????

    Glenn
    Panorama Internet Publishing


    PS. the only pre-packaged snippet I’m using is "DropMenu" if that helps.
      • 22640
      • 44 Posts
      Sorry...also using "WebLogin" snippet.
      • I’m sorry but I don’t quite understand the scenario where this is being suppressed, how are you calling this test from MODx?
          • 32241
          • 1,495 Posts
          Hi,

          How do you run those script? I mean, did you save it on another file, let say test.php, and you put the file on the root directory for MODx, together with index.php, manager folder, assets folder, and htaccess file?

          If you run it under plugin or snippet, than of course that error won’t occured, due the output buffer/caching. So basically the ob_something (I can remember the function), it will cached the output, and return it at the end of execution, by calling the oporite function on ob_something again. So whichever you put your header, it won’t break the script.

          Hope this clear up something to you.
            Wendy Novianto
            [font=Verdana]PT DJAMOER Technology Media
            [font=Verdana]Xituz Media
            • 22640
            • 44 Posts
            Quote from: Djamoer at Jan 27, 2006, 08:22 PM

            How do you run those script? I mean, did you save it on another file, let say test.php, and you put the file on the root directory for MODx, together with index.php, manager folder, assets folder, and htaccess file?

            Yes that is exactly how I run it. Its a totally separate file in the root. It was not created nor is it managered by MODx. Just a simple PHP file.

            For example here is a link to a test.php file on a site with MODx: WARNING: music on the home page!
            www.mystyleprofile.com/test.php

            That file should not forward to the Home Page.



            If you run it under plugin or snippet, than of course that error won’t occured, due the output buffer/caching. So basically the ob_something (I can remember the function), it will cached the output, and return it at the end of execution, by calling the oporite function on ob_something again. So whichever you put your header, it won’t break the script.

            I think I understand. Somebody suggested a similar solution on SitePoint before I figured it was related to MODx.

            Glenn
            • Hmmm, I’m curious now. MODx only handles virtual requests in the space it lives. In other words, if a test.php file exists on the filesystem, MODx is bypassed and the file is handled as usual by the web server. So I’m not seeing how this can be related to MODx. But I may still be missing something? huh
              • Of course, when I test the same thing myself, I’m seeing the same behavior. This is not supposed to be happening, so I’m off to see what’s up... embarrassed
                • Ok, I figured it out. The issue is the if any content handler is set for the PHP configuration, output buffering is automatically turned on. So, you are not getting the warning because the default MODx .htaccess file has the following directives uncommented by default:

                  php_flag zlib.output_compression On
                  php_value zlib.output_compression_level 5


                  These lines establish a PHP content_handler and turn on content_buffering by default. Comment them and you’ll get the error.
                    • 22640
                    • 44 Posts
                    Quote from: OpenGeek at Jan 27, 2006, 09:51 PM

                    Ok, I figured it out. The issue is the if any content handler is set for the PHP configuration, output buffering ...

                    Excellent! I actually thought it may be related to the .htaccess file, but I don’t know enough about the PHP directives to know if any were causing the problem.

                    Thanks a million!
                      • 22640
                      • 44 Posts
                      Quote from: OpenGeek at Jan 27, 2006, 09:51 PM

                      These lines establish a PHP content_handler and turn on content_buffering by default. Comment them and you’ll get the error.

                      One last question. If I comment these out, will it affect any other part of a MODx Web site?

                      Glenn