I'm working on updating the audio module's views support and using the import tool to migrate the default views from 1.x. It's been a big time saver but the thing I'm noticing some problems. None are critical but I wanted to report them so there's an issue where people can discuss them.
Here's a simple example
$view = new stdClass();
$view->name = 'audio_random';
$view->description = 'Random audio nodes';
$view->access = array(
0 => '1',
1 => '2',
);
$view->view_args_php = '';
$view->block = TRUE;
$view->block_title = 'Random audio';
$view->block_header = '';
$view->block_header_format = '1';
$view->block_footer = '';
$view->block_footer_format = '1';
$view->block_empty = '';
$view->block_empty_format = '1';
$view->block_type = 'list';
$view->nodes_per_block = '5';
$view->block_more = FALSE;
$view->block_use_page_header = FALSE;
$view->block_use_page_footer = FALSE;
$view->block_use_page_empty = FALSE;
$view->sort = array(
array(
'tablename' => 'node',
'field' => 'random',
'sortorder' => 'ASC',
'options' => '',
),
);
$view->argument = array(
);
$view->field = array(
array(
'tablename' => 'node',
'field' => 'title',
'label' => '',
'handler' => 'views_handler_field_nodelink',
'options' => 'link',
),
);
$view->filter = array(
array(
'tablename' => 'node',
'field' => 'type',
'operator' => 'OR',
'options' => '',
'value' => array(
0 => 'audio',
),
),
array(
'tablename' => 'node',
'field' => 'status',
'operator' => '=',
'options' => '',
'value' => '1',
),
);
$view->exposed_filter = array(
);
$view->requires = array('node');
$views[$view->name] = $view;
Has the following problems:
- Filters are loosing their values. The correct filters are selected but the values are lost.
- Random sorting is lost.
- block_type isn't used to set the Block's style.
- nodes_per_block settings is lost.
Here's another problematic example:
$view = new stdClass();
$view->name = 'audio_feeds';
$view->description = 'Audio XSPF Player';
$view->access = array(
0 => '1',
1 => '2',
);
$view->view_args_php = '';
$view->page = TRUE;
$view->page_title = 'Listening Station';
$view->page_header = '';
$view->page_header_format = '1';
$view->page_footer = '';
$view->page_footer_format = '1';
$view->page_empty = '';
$view->page_empty_format = '1';
$view->page_type = 'audio_xspf_playlist';
$view->url = 'audio/listen';
$view->use_pager = FALSE;
$view->nodes_per_page = '15';
$view->sort = array(
array(
'tablename' => 'node',
'field' => 'created',
'sortorder' => 'DESC',
'options' => 'normal',
),
);
$view->argument = array(
array(
'type' => 'rss_feed',
'argdefault' => '2',
'title' => '',
'options' => '',
'wildcard' => '',
'wildcard_substitution' => '',
),
);
$view->field = array(
array(
'tablename' => 'node',
'field' => 'title',
'label' => '',
'handler' => 'views_handler_field_nodelink_with_mark',
'options' => 'link',
),
);
$view->filter = array(
array(
'tablename' => 'node',
'field' => 'type',
'operator' => 'OR',
'options' => '',
'value' => array(
0 => 'audio',
),
),
array(
'tablename' => 'node',
'field' => 'status',
'operator' => '=',
'options' => '',
'value' => '1',
),
);
$view->exposed_filter = array();
$view->requires = array(node);
$views[$view->name] = $view;
Gives some warnings on import:
* notice: Undefined property: stdClass::$menu in /Users/amorton/Sites/d6/sites/all/modules/views/includes/convert.inc on line 166.
* notice: Undefined index: field in /Users/amorton/Sites/d6/sites/all/modules/cck/includes/views/content.views_convert.inc on line 35.
It's got similar problems:
- Filters don't have values.
- Feed argument handler isn't converted to a feed display.
Some of these problems might be due to the custom page_type.
Comments
Comment #1
merlinofchaos commentedThe converter has been a relatively low priority for me, so I'm not surprised that its best effort isn't a very good one. This is a place where patches would be very welcome.
Comment #2
darren ohI've found three problems:
With these problems fixed, the conversions I have tested work. Patch attached.
Comment #3
darren ohNew patch converts all 'notafield' fields.
Comment #4
merlinofchaos commentedI committed this without particularly looking at it, since you had the guts to RTBC it and I'm all for improving the 1.x upgrade process!
Comment #5
darren ohI see an entry in CHANGELOG.txt, but the patch isn't applied.
Comment #6
darren ohFixed in CVS commits 174856 and 174864.
Comment #8
darren ohFix was incomplete. Values from node filters were lost if there was more than one filter.
Comment #9
darren ohMore fixes:
Need to check on labels and sortable fields.
Comment #10
EvanDonovan commentedLooks like there are still some issues with conversion in the latest dev version. See my issue #415742: Views 1 Importer/Converter Cannot Handle Taxonomy Term Filters.
Comment #11
darren ohTaxonomy filter is addressed in the last patch, which has not been committed yet.
Comment #12
EvanDonovan commentedOh, sorry. I misread the commit messages. I'll flag my issue as a duplicate and give my review here. Changing status to "needs review" accordingly. Thanks for your work on this!
Comment #13
EvanDonovan commentedHere's my initial test results (the first three with the same view as I used in #415742: Views 1 Importer/Converter Cannot Handle Taxonomy Term Filters):
More later, when I get the chance.
Comment #14
merlinofchaos commentedOk, latest patch committed, because it's better than not committing it. Please continue to improve this! (and thank you very much for doing so!)
Comment #15
EvanDonovan commentedThanks, Merlin and Darren. In a week or so, I may get the change to convert a few dozen views from 1.x to 2.x. When that happens, I'll let you know what my latest results are with the conversion process.
Comment #16
darren ohQuick fix for first two problems in #13. I need to go through all the Views 1 filters that use views_handler_operator_andor() and also make sure options are being imported.
Comment #17
EvanDonovan commentedGreat, thanks. I'll be able to test this out tomorrow, most likely.
Comment #18
darren ohLots of updates in this patch. Works for all my views, but still not quite comprehensive.
Comment #19
darren ohAdded better block conversion. Block settings are now preserved (if you convert your views before visiting the block administration page).
Comment #20
EvanDonovan commentedDoes the patch in #19 includes the code from the previous patches? I couldn't get it to apply, because it said "Reversed (or previously applied) patch detected". I was applying the patches from #16, #17, and #19 in order. Also, I got "Hunk $3 FAILED at 271" from the includes/convert.inc code in the patch from #17.
Comment #21
darren ohYes. Only apply the latest patch.
Comment #22
EvanDonovan commentedThe new patches work well, from a cursory review. The only thing I noticed so far is that a User:Uid argument didn't convert.
Comment #23
darren ohConverting a block view caused a pager to appear if the block specified the number of results to return. Fixed patch attached.
Comment #24
EvanDonovan commentedOk, thanks. I will only apply the latest patch then, when I do the actual upgrade of my site to Drupal 6.
Comment #25
darren ohMade page style apply to default view even if there is no URL. Block view replaces default style if no page view exists.
Comment #26
EvanDonovan commentedWhich one of these patches has been committed to 6.x-2.5? That's the release of Views that I went with when I upgraded my live site to Drupal 6.
Comment #27
darren ohThe current patch works on the latest release of Views. You only need the last patch.
Comment #28
EvanDonovan commentedGreat. Thanks a lot! I may have time to test this coming week; been very busy with the site upgrade.
Comment #29
darren ohNew patch to make writing argument converters easier and to convert argument handling code.
Comment #30
darren ohAdded support for empty labels.
Comment #31
darren ohAdded support for date format conversion.
Comment #32
darren ohAccidentally included code for query.inc in last patch.
Comment #33
darren ohFixed the "use more link" setting.
Comment #34
darren ohFinished now.
Comment #35
darren ohAdded case transformation to title argument.
Comment #36
JirkaRybka commentedI've installed latest -dev tarball of views, with this patch applied, to my test site, and going to convert all my views today. I've found (and fixed) two problems till now, but I'm not done with testing yet.
Going to roll a new patch later today.
Comment #37
JirkaRybka commentedOK, I found three small problems while importing my views. Quoting changed code below, so that you can see what's new - all the rest is re-rolled with no change.
--- If a page have menu item, in Views1 the menu title is not necessarily always defined - there's a fallback using page title instead. Views1 views.module code:
After converting such views to Views2, there's an error on menu title, because it's empty. So, I changed one line in includes/convert.inc to reflect that fallback (originally it used only just $imported->menu_title):
$menu['title'] = $imported->menu_title ? $imported->menu_title : $imported->page_title;--- In modules/user.views_convert.inc, there's a typo (three instances of the same) causing Fatal error. I corrected
$views->add_item()to$view->add_item().--- In includes/convert.inc I changed this piece:
Before this change, the second IF wasn't nested inside the first, so it fired on bogus old data where it shouldn't: When a field is not sortable, nothing else should be added for click-sorting on that field.
(I have views, where I was using click-sort (descending) on a field previously, and later changed that to normal fixed sort, removing the click-sort (happened maybe on 5.x, maybe even 4.7.x) The field isn't sortable anymore ($field['sortable'] == 0), but still I had obsolete unused data in $field['defaultsort'] == 'DESC'. The conversion code fired on that, and set the field as default sort (as seen on radios in table settings), without having the field set as sortable (checkbox) and without the default sort (Descending) being there too. The field shouldn't be sortable, this is all just a corpse of my previously removed setting, which takes over normal sort after conversion, and without the field being actually click-sortable, it results in quite weird behavior where fixed "corpse" overrides normal sort.)
I added these three small fixes to the patch, otherwise it's just a re-roll.
Comment #38
JirkaRybka commented...and Drupal.org is playing some weird tricks tonight (or is it my browser?), so I hardly posted the above on second attempt, and incomplete - sorry. The rest:
With latest dev tarball plus this patch, all works fine for me: 30 views converted, both page/block, mostly tables but item-lists too, with simple arguments, various sorts, click-sorts, a lot of exposed filters, a few menu items (tabs), header/footer/empty texts - and nothing broken, except where it should (missing custom handlers), or where it's unrelated/out of scope (I had a lot of trouble with filters on CCK fields, and a bit with grouping values inside these fields, but that's implemented over at CCK project, where I posted my findings to #444276: Finish conversion of fields from Views 1). Some manual tweaks were still needed - I would highlight the need to add sticky table headers to every single view manually - but that's questionable, minor, and probably not a bug. This patch is enormous piece of work :-)
As long as my tiny changes are OK, I would call this RTBC (although I'm not sure how much of the code my data actually tested), also per merlinofchaos' approach to this voiced above.
Comment #39
darren ohLooks good. Whatever my tests missed was probably caught by yours.
Comment #40
merlinofchaos commentedCommitted!
Comment #41
darren ohGreat! Just two files missing somehow.
Comment #42
merlinofchaos commentedWhoops. FOrgot to cvs add them. Done.
Comment #43
darren ohMade the default filter conversion work better by adding filter value.
Comment #44
merlinofchaos commentedCommitted! THanks Darren. Did I mention how awesome it is that someone is doing this?
Comment #45
JirkaRybka commentedThanks from me, too :)
One more thing I noticed (and honestly, am not sure whether it's already fixed or not) - all the views I converted a while back, when I tested one of the above patches, lost the "new/updated" mark on node titles (these views are rendered as tables BTW). It was an option "with new mark" (or the like) in Views1, and now I had to add a new field "Node: Has new content" manually (and put it into the title's table column in my case).
I don't insist on a fix, as I'm converted already, but stating it here for reference.