Fix PHP warnings when a View path 404/3's

I have the same problem (trying to find a solution for the same reason like you: #1432230: Prevent duplicate content (because Views returns 200 instead of 400) )

In current 7.x-dev, common.inc line 2575 is this:

         print theme('maintenance_page', array('content' => filter_xss_admin(variable_get('maintenance_mode_message',
           t('@site is currently under maintenance. We should be back shortly. Thank you for your patience.', array('@site' => variable_get('site_name', 'Drupal')))))));

Does that mean your site is in maintenance mode when this happens?

Since you may not actually be running the very latset Drupal 7 you may want to look at the line that it says sent the output to see exactly what was output.

In my case (Drupal 7.12; Views 7.x-3.1; site not in maintenance mode) the warning is:

Warning: Cannot modify header information - headers already sent by (output started at /…/includes/common.inc:2607) in drupal_send_headers() (line 1243 of /…/includes/bootstrap.inc).

Line 2607 of includes/common.inc is in the following function:

/**
 * Performs end-of-request tasks.
 *
 * This function sets the page cache if appropriate, and allows modules to
 * react to the closing of the page by calling hook_exit().
 */
function drupal_page_footer() {
  global $user;

  module_invoke_all('exit');

  // Commit the user session, if needed.
  drupal_session_commit();

  if (variable_get('cache', 0) && ($cache = drupal_page_set_cache())) {
    drupal_serve_page_from_cache($cache);
  }
  else {
    ob_flush();
  }

  _registry_check_code(REGISTRY_WRITE_LOOKUP_CACHE);
  drupal_cache_system_paths();
  module_implements_write_cache();
  system_run_automated_cron();
}

(line 2607 is ob_flush();)

I am getting the same issue. when i tried to download private files.

Recent Log messages:

Type php
Date Thursday, March 29, 2012 - 09:46
User admin
Location https://example.com/drupal7/system/files/admin_menu-7.x-3.0-rc1.tar_.gz
Referrer https://example.com/drupal/content/test-private-files
Message Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/drupal/includes/common.inc:2607) in drupal_send_headers() (line 1243 of /var/www/html/drupal/includes/bootstrap.inc).
Severity warning

The handling of the 404 is done here.

in views_plugin_display_page.inc

  /**
   * The display page handler returns a normal view, but it also does
   * a drupal_set_title for the page, and does a views_set_page_view
   * on the view.
   */
  function execute() {
    // Let the world know that this is the page view we're using.
    views_set_page_view($this->view);

    // Prior to this being called, the $view should already be set to this
    // display, and arguments should be set on the view.
    $this->view->build();
    if (!empty($this->view->build_info['fail'])) {
      return drupal_not_found();
    }

    if (!empty($this->view->build_info['denied'])) {
      return drupal_access_denied();
    }

    $this->view->get_breadcrumb(TRUE);


    // And now render the view.
    $render = $this->view->render();

    // First execute the view so it's possible to get tokens for the title.
    // And the title, which is much easier.
    drupal_set_title(filter_xss_admin($this->view->get_title()), PASS_THROUGH);
    return $render;
  }

in views.module

/**
 * Page callback entry point; requires a view and a display id, then
 * passes control to the display handler.
 */
function views_page() {
  $args = func_get_args();
  $name = array_shift($args);
  $display_id = array_shift($args);

  // Load the view and render it.
  if ($view = views_get_view($name)) {
    return $view->execute_display($display_id, $args);
  }

  // Fallback; if we get here no view was found or handler was not valid.
  return drupal_not_found();
}

and inside class views_plugin_display_feed extends views_plugin_display_page which i dont think is relavent here they are all handled the same way " return drupal_not_found();"

Might be the fact that drupal_not_found() is used, although I'm not even sure about that. The api doc says that the MENU_NOT_FOUND constant should be returned in a page callback that wants to return a 404, so the attached patch might probably fix the headers not sent message. Note, haven't tested this at all, but it might help.

This is the correct fix.

While I was clarifying the @return docblock, I noticed it still uses array_shift and phantom parameters, which aren't as obvious as fully documented ones.

See #1216758: Add $module and $hook as formal parameters in module_invoke() for the switch made to module_invoke/module_invoke_all.

Awesome, looks perfect. Committed to 7.x-3.x

still getting header errors when calling a url that is wrong and will return "Page not found". Its a view that tages the tid as an argument.

Sample url: http://dev.text2.com/en/taxonomy/term/4762222222222222222/0?page=62

Header errors:

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/includes/common.inc:2575) in drupal_send_headers() (line 1225 of /var/www/html/includes/bootstrap.inc).

Ran into this problem running Views 7.x.3.5 and it's present in 7.x.3.x

views/plugins/views_plugin_display_page.inc execute() is returning drupal_not_found() and should be returning MENU_NOT_FOUND instead.

#11 stopped numerous PHP errors of headers already sent, session_start() [function.session-start]: Cannot send session cache limiter - headers already sent,
Notice: ob_flush() [ref.outcontrol]: failed to flush buffer. No buffer to flush. in drupal_page_footer()

in Views 7.x.3-5.

#11 also prevented the "Warning: Cannot modify header information" for us. We're using 7.x-3.5.

These messages appear if you have a contextual filter with 'Show "Page not found"' set as the 'Action to take if filter value does not validate'.

I notice that that "return drupal_not_found();" also appears in plugins/views_plugin_display_feed.inc, which probably also needs changing.

Finally, there's a "return drupal_access_denied();" in plugins/views_plugin_display_page.inc which should probably be "return MENU_ACCESS_DENIED;"

Glad I found this post... these errors have been driving me nutts...! I totally agree with comment #13:

These messages appear if you have a contextual filter with 'Show "Page not found"' set as the 'Action to take if filter value does not validate'

Looking at the common denominator of my errors, each one is from a view with "said" contextual filter.

I should also note that I have my 404 error page overridden with my own custom node, in-case that helps narrow it down a bit...

This bug also disturbes the varnish cache, at least on the Acquia Dev Cloud.

On views pages, with invalid arguments, and the "Show 404 Page not found" action, the output via varnish is garbled (see attached screenshot). For authenticated users the output of the 404 page is fine.

After changing the file as suggested in the patch from #11 the problem disappeared.

As the patch in comment #8 was comitted already, but does not fix the problem in all places, here is a new patch which basically adds the fix to more places.

Please review.

This look pretty nice and RTBC. Some manual testing by another person would though be really cool!

Thanks you, i applied your patch and all problem was resolved.

the patch works for my site too.
thank you!

Patch in #16 works for me with Views 7.x-3.7 and latest release of Drupal.

Clarifying title.

Another +1 on RTBC on patch in #16.

Fixes the following errors for me, on 4 sites so far:

Warning: ini_set(): Cannot change zlib.output_compression ...
Warning: Cannot modify header information - headers already sent by ....
...
Warning: Headers already sent, session_start()

Please let me know if I have incorrectly used tags.

Will this be committed please? Greetings, Martijn

Another +1 on RTBC on patch in #16. This took some time to trace back to views, but once I did this issue was a direct match to the problem we were experiencing. The patch sorted things out for 2 sites and a quick code review indicates that it's very consistent with the accepted logic of the patch in #8.

+1 for committing this clear fix. It also lead me to fix a similar issue in some custom code.

#16 fixes the php warnings for us as well, using views 7.x-3.7 and drupal 7.23.

#16 is definitely the correct fix. I'll see if I can ping dawehner on IRC.

Pushed and committed to 7.x-3.x

The same thing is just fixed in Drupal core 7.25.

I'd like to add that it also affects Panels (Page Manager) in the following edge case: If you create a page and give it the URL /your/page, and then limit it with a Selection Rule (String: URL path) so that you get a 404 error when you go to /your/page/URLToNothing, (instead of it redirecting to /your/page, which is the default behavior), this problem appears.

When the String: URL Path selection rule is removed, the problem goes away (since it's no longer a 404).

What made the error go away in my case was testing an identical change to Page Manager in modules dir/ctools/page_manager/plugins/tasks/page.inc on line 324 (v. 7.x-1.3). I didn't leave the change in, but it appears that this is a substantial problem in certain cases.