Current constants are:
/**
* @name Menu status codes
* @{
* Status codes for menu callbacks.
*/
define('MENU_FOUND', 1);
define('MENU_NOT_FOUND', 2);
define('MENU_ACCESS_DENIED', 3);
define('MENU_SITE_OFFLINE', 4);
In index.php we using above value to check the status of menu callback, if doesn't exist, render the page using this value.
There is no way to tell the Drupal that we want to render the page by our-self in some special cases.
In example in Panels.
See: #939040: Panels returns NULL from menu_execute_active_handler()
We could add some new constant like:
define('MENU_IGNORE', 0);
Comments
Comment #1
kenorb commentedPatch for 6.x in attachment.
Comment #2
EvanDonovan commentedPatches are made against the highest numbered currently open branch of Drupal core and then backported. This is a bit of a feature request, but I think that in this case it could still make it into 7.x, and possibly get backported into 6.x, since it doesn't affect the normal page rendering behavior, but enables modules that bypass that rendering to indicate that they have done so, and thus that Drupal has not crashed.
See #939040: Panels returns NULL from menu_execute_active_handler() and #717416: Incompatibility with Panels/Page Manager module when panels have "Disable Drupal regions" selected for context.
Comment #3
kenorb commentedI'm not sure how does it apply to 7.x (not familiar with 7.x). But basically there are general changes in router_item(), so I'm not sure if this issue is is valid in 7.x.
Comment #4
moshe weitzman commentedreturn NULL and you get this behavior. new constant would be D8. no changes like this being accepted for d6 either.
Comment #5
kenorb commentedEven it doesn't change any rendering in 6.x and pass all the tests?
Comment #6
EvanDonovan commented@moshe: The only reason I didn't immediately bump to 8.x is because of #717416: Incompatibility with Panels/Page Manager module when panels have "Disable Drupal regions" selected - basically, the WSOD module thinks that you have a WSOD if menu_execute_active_handler() returns NULL. If a module like Panels returns NULL deliberately, since it is taking over page rendering completely (i.e., when "Disable block regions" is checked), then you run into issues since WSOD does a menu_rebuild() to try to recover from the (supposed) WSOD.
In 7.x+, actually Panels probably wouldn't need to return NULL from menu_execute_active_handler() to bypass theme_page(), since there's much more ability to alter.
So perhaps there is no solution and WSOD module just can't make the assumption that NULL == WSOD.
Comment #7
kenorb commentedOk, so hopefully patch will be committed to Panels to fix that issue in 6.x:
#939040: Panels returns NULL from menu_execute_active_handler()
as workaround of this bug/limitation in Drupal 6.x core.
Panels returns NULL, because of Drupal 6.x core limitation and module are not able to pass additional argument into theme('page') to hide the blocks, because parameters are hard-coded in index.php
See: drupal_common_theme()
Additional arguments are available by following the API, but modules can't use it.
So I could say it's a kind of bug core 6.x specific, if this sounds for you better. Because if you want to use theme argument (which should be available, as described in API), you have to HACK the code workflow by passing the empty/NULL value (which is not expected), to cheat the Drupal core (index.php). By this HACK you could break functionality of core or other modules, what's happening now, because their can't follow the API.
It's the right way to do that?
Is there any API that if you don't render nothing, return none?
In 7.x & 8.x probably this bug doesn't exists.
Comment #8
moshe weitzman commenteddrupal core 6 nor 7 will change for this. I have no idea what WSOD module is but it is making a poor assumption.
Comment #9
kenorb commentedIf NULL value is expected by Drupal core and it's not a bug, where it's described?
http://drupal.org/node/224333#theme_page
As I can see:
Drupal 6:
$output - Return page output for Drupal.
Doesn't say that you can output NULL.
There is as well following function:
Question:
It's the proper way of passing custom arguments into 'page' theme callback?
If yes, it does solve my problem.
Comment #10
moshe weitzman commentedDrupal core does this when a page callback returns XML or JSON (anong other examples). For example, the path 'rss.xml' calls into the page callback node_feed() which returns NULL. Another example is user/autocomplete which calls into user_autocomplete(). Feel free to document this somewhere. IMO, the comment at bottom of index.php is decent.
Comment #11
kenorb commentedI think this menu callback example which I found (if it does work) solves the problem of passing custom arguments into 'page' theme in 6.x core:
http://drupal.org/node/939040#comment-3572484
Thank you for your help and time.
Comment #12
kenorb commentedNo, above example duplicate the html code. Example is broken.
http://drupal.org/node/428744#comment-1617886