Latest update crashes Blocks UI and Views UI

Did you run update.php after upgrading? Most importantly, did you review the changes in CHANGELOG.txt? There are two recent refactoring commits that require action for most existing migrate module users:

#552928: Strip "destination" from hook and function names
#557436: Refactor map and message table names

It sounds like you may have created views using the message tables, which have been renamed.

I can confirm having the same problem with the beta3 as well as with the -dev version downloaded today. Fresh install.

Are you getting the same precise errors, on the same pages, as in the original issue? What versions of Table Wizard and Views are you using? I can't reproduce this in my environment...

Does this appear related to #558094: Table Wizard appears to make other views disappear? I.e., do you have tables in an external database potentially conflicting with tables in your Drupal db?

Went quickly to issue #558094 but that's not what I'm facing.

Errors come when I access the 'blocks' configuration page and on the Views UI list page.

Drupal core: 6.14
Table Wizard: 6.x-1.1
Views: 6.x-2.6

I've got the problem on two sites, one of them vanilla. Any time I want to access Views or Blocks I have to disable Migrate.

Sorry, I created a fresh environment with the same versions and I can't reproduce any problem. The block connection seems odd - are you creating any blocks from views including migrate-related tables? I tried a simple one, still didn't get a problem here.

There's not much I can do without being able to reproduce the problem - can you try debugging it in your environment? The most likely places to trigger this would be migrate_schema_alter() and migrate_views_default_views_alter() - a few well-placed dsm()'s might narrow it down.

Thanks.

I'll go for it asap, right now I'm out of time. Perhaps the problem is due to another module getting in the middle. As a reference, I could print the list of the modules of the site I'm getting the error on. Do you know of any tool to print all the enabled modules on the site?

Cheers.

drush statusmodules

Great question in #6, above. I am now getting this error as well. I'll try to debug it. I don't think it is related, because I've now written a fix for #558094 and this is still happening. Ok, it looks like the fix that I made for #558094, making the view name have a tw_ in front of the table name has caused this bug to happen.

So, the good news is I've got some more leads on why this message might come up, but the bad news is that I don't know why exactly it is happening.

I've found that one of the migrate set's default view for its message table is being updated, but the remainder of the view information isn't present in the array which is why the getPath function isn't available in this object. I'm thinking that for the bug fix I've made in 558094 , we need to change some stuff in hook_views_default_views_alter so that we get the right viewname made with the 'tw_' at the front of it.

@ #10: I can't run drush - XAMPP

FYI: I also get: "Call to undefined method stdClass::init_display() in [...]\sites\all\modules\ctools\views_content\plugins\content_types\views_panes.inc on line 47"

@arielon - In a client environment on Windows, I'm using drush with XAMPP. It does work...

It finally happened to me! Happy day, I've reproduced it and know the cause - it happens if the message table for the view does not exist, which will happen if you create a content set but don't then save it on the mappings page (the map and message tables aren't created until this point).

So, minimally, the default_views_alter() hook needs to verify the message table exists (done, not committed yet). I'll look at creating the map/message tables on the original content set creation - the reason that isn't done is because the user hasn't selected the PK yet, but I think the defaulting code may be good enough to go ahead...

Thanks.

OK, I'm not messing with the content set creation workflow for now, I've bulletproofed the default_views_alter() hook and added a regression test...

great, I'd like to try that out on my sys if you drop a patch....

By the way. I'm sure the complete work-flow and/or interface with Table Wizard could be retouched a bit. I've found this bug just by tinkering my way around to make the complete setup to work.

And... Migrate is a great module!

It's already committed, just pick up the latest dev release.

that's quick answer! will do right now.

Ok. This seems working for me (-dev). Tested import and views/blocks/pages.

Cheers~!

This error is resurfacing for me. I went from views-6.x-2.6 to views-6.x-2.7 and I got the error codes described above on Administer>Blocks and Administer>Views.

I got the latest migrate release & tried to revert to the previous views (2.6) to no avail. I cannot remember whether I used the ViewsUI in this Drupal instance, though - so the error may have been there before I moved to the latest views.

I'll see about replicating the behaviour in other Drupal instance based on a WAMP. This is running on Ubuntu Hardy Heron 8.04

inigo

@eneko1907 did you use migrate-dev?

@mikerayn This issue could use a proper patch file.

I don't know if this will help, but the same error just happened to me.

I cleared the table migrate_content_sets ( I only had one cs yet) and cleared cache_views and the problem was gone.

thanks

joreg

Me too, deleting the Content sets solved the problem.

I confirmed deleting my content set fixed the problem as well. I think it is related to view module and migrate module. Could be some events fired from view module to trigger migrate module code and crashed within the migrate module? I am not familiar with Drupal's code and don't let me mislead you if my statement doesn't make any sense.

i really thought i'd decked the live site proper, there were no problems on staging. i disabled migrate and i can get in ok thanks.

the bug only manifests when you try to list all (the default local task) so if you know the view name you can call it in the url no problem:

admin/build/views/edit/reward_category_grid
and this
admin/build/views/add

the same for blocks

in essence you can still import, delete and do all sorts with migrate enabled, you just can't list.

I am seeing this error with Migrate 1.x.dev 2010-Jul-26. If I go to admin/views/build/list, I get

Fatal error: Call to undefined method stdClass::get_path() in (path)\modules\views\includes\admin.inc on line 134

The migration is working, but the module always says that it cannot analyze the content set, Could not analyze migrate_map_(nameofset)
and if I remove the content set, I can get back into my views list.

How to debug this?