Module order in install profiles : Undefined property: views_display::$display_options

posted a different scenario of the same issue:
http://drupal.org/node/335822

Because of the specificity of this issue I'm re-opening this, I think there's data here that might help me track this down. This isn't to say that they aren't ultimately the same issue, but the other issue doesn't have enough data to give a place to start.

This may or may not be related, but it's another problem with install profiles, so I'll post it here. I'm trying to install views in the CCK Date Test Site profile and when I do I get the following message:

notice: Undefined property: views_display::$display_options in C:\www\drupal2\sites\all\modules\views\plugins\views_plugin_display.inc on line 36.

Apparently it is trying to initialize views during the install, so my guess is that it is something to do with default views getting processed before there is enough information to do anything with them.

I wonder if there is a way for Views to know this is the installation process so it can abort any attempt to initialize views.

And I can confirm that if I move views ahead of all modules that use the views api I get no errors. I tried just moving it ahead of Calendar, which creates default calendars, but still got the error. I had to move it ahead of Content and Date, too, and they don't create default views but they do invoke the Views api.

No, I misspoke, I forgot that Date does create a default view. I tried moving it after Content (which invokes the API but does not create default views) and before Date (which creates default views) and got no errors that way.

So the key is that views has to be ahead of all modules that create default views in the installation profile.

Renaming the issue to clarify what the problem is.

Karen, can you do a vpr_trace() or vsm_trace() at one of these break points and see what's actually causing this stuff to get invoked before Views is actually installed?

This seems like a bug in core somewhere that Views hooks can even be called prior to it being installed.

I'm hopelessly inept at figuring out ways to trace things like this, especially in profiles and updates where normal functions won't work.

I finally ended up just doing print_r(debug_backtrace()) at the place where it is trying to initialize the view. It timed out before it finished, but hopefully there is enough here to work with. If not, it is pretty easy to create a situation that causes this to debug yourself. It create a 15 MB text file and then died, so I just clipped out the debug info for the first time it was invoked.

It looks like it is related to menu_rebuild(), strangely enough.

The actual error being triggered here is that the schema is not being found when Views is trying to load; Views relies on schema telling it what fields are in a view when loading it, so it fails. There have been a couple of other reports about this as well, but as of yet I can't make a determination as to what is going on. Returning this to duplicate.

I could repeat #4
- which is probably related to, but not identical to #335822: warnings from includes/view.inc. I'll branch this issue active again just to deal with this notice, not the later side-effect (or OP).

My install profile module list looked like:

return array(
   /* core */
    'block', 
    'filter', 
    'node', 
    'system', 
    'comment', 
    'user', 
    'dblog', # watchdog

    'help', 
    'menu', 
    'path', 
    'taxonomy', 
    'upload',
    'search',

   /* contrib - selected for use with the coders_kitset package */
    'content',
      'text',
      'number',
    'views',
      'views_ui',
    'patterns',
  );

And I got several dozen of the notice: Undefined property: views_display::$display_options in ... views_plugin_display.inc on line 36. at the Install profile -> Configure site stage of the bootstrap.

Tracing it shows that the first error was when 'comments_recent' tries to set up a view. However if I shunted my load order around, I found that views only had to be enabled before 'content' to make the message go away.

 return array(
   /* core */
    'block', 
    'filter', 
    'node', 
    'system', 
    'comment', 
    'user', 
    'dblog', # watchdog

    'help', 
    'menu', 
    'path', 
    'taxonomy', 
    'upload',
    'search',

   /* contrib - selected for use with the coders_kitset package */
   /* Enable views before content! */
    'views',
      'views_ui',
    'content',
      'text',
      'number',
    'patterns',
  );

Problem gone, ... so I can live with that. May be just an issue to document? I'll drop the priority to to minor 'coz it's annoying but not painful.

However, just telling PHP to STFU with a @ may be an option:

diff -u -p -r1.27.2.6 views_plugin_display.inc
--- views_plugin_display.inc    30 Nov 2009 19:05:47 -0000      1.27.2.6
+++ views_plugin_display.inc    30 Dec 2009 00:28:08 -0000
@@ -33,7 +33,7 @@ class views_plugin_display extends views
 
     // Make some modifications:
     if (!isset($options)) {
-      $options = $display->display_options;
+      $options = @$display->display_options;
     }
 
     if ($this->is_default_display() && isset($options['defaults'])) {

Everything still seems to work? ... though the later warning may indicate that ignoring this earlier notice is indeed an ignorant thing to do (?) .

I just want to add a note that I just got this notice on a fresh Drupal/Views (6.17-dev (CVS) and 6.x-2.8), and reading the comments above, I'm guessing it might be triggered by enabling Views and Views UI in the same go, and Views UI possibly trying to trigger something before Views is ready? Or perhaps Views is trying to do Views stuff before being ready? Either way, really just wanted to note that it can happen outside of install profiles as well.

Needs review indicates a patch. There is some code here, but not a patch.

Based upon commentary in #12, I suspect what is going on is that 'content' is doing a views_get_view() and now that views is active, it's trying to load default views. But clearly the default views aren't loading properly. The reasons for this are still unclear, but perhaps if I can replicate this I can do some tracing to see why.

I'm not too concerned because there is a known workaround.

Just a note that Openlayers also has this problem when installing Openlayers Views.

It seems that the combination of possibilities that install profiles offer make it quite difficult to pinpoint exactly what will trigger these errors and prevent them for other combinations, and may not be fixable. As both starkos and dman pointed out changing order of the installed modules fixed the issue in their particular cases.

I'm marking this as closed won't fix.