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

merlinofchaos’s picture

The 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.

darren oh’s picture

Version: 6.x-2.x-dev » 6.x-2.2
Status: Active » Reviewed & tested by the community
StatusFileSize
new1.63 KB

I've found three problems:

  1. Views's own implementations of hook_views_convert() are not run, because views_views_api() is in handlers.inc, which is not included during conversion.
  2. Style conversions pass the invalid variable $handler->id instead of the correct variable $handler->display->id to the hook_views_convert() implementations.
  3. The node body field in Views 1 incorrectly claims to be a member of the node table, whereas Views 2 needs to know the correct table.

With these problems fixed, the conversions I have tested work. Patch attached.

darren oh’s picture

Version: 6.x-2.2 » 6.x-2.3
StatusFileSize
new10.88 KB

New patch converts all 'notafield' fields.

merlinofchaos’s picture

I 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!

darren oh’s picture

I see an entry in CHANGELOG.txt, but the patch isn't applied.

darren oh’s picture

Status: Reviewed & tested by the community » Fixed

Fixed in CVS commits 174856 and 174864.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

darren oh’s picture

Status: Closed (fixed) » Reviewed & tested by the community
StatusFileSize
new1.29 KB

Fix was incomplete. Values from node filters were lost if there was more than one filter.

darren oh’s picture

Assigned: Unassigned » darren oh
StatusFileSize
new30.46 KB

More fixes:

  • Distinct filter
  • Taxonomy: Term without vocabulary (depends on 413740)
  • Some filter operators
  • Allowed block to set default values when there is no page view.
  • Argument converters
  • Made code more consistent.

Need to check on labels and sortable fields.

EvanDonovan’s picture

Looks 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.

darren oh’s picture

Taxonomy filter is addressed in the last patch, which has not been committed yet.

EvanDonovan’s picture

Status: Reviewed & tested by the community » Needs review

Oh, 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!

EvanDonovan’s picture

Here'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):

  • Taxonomy: Term came across with the correct vocabulary and term. Excellent!
  • NOR on the Taxonomy: Term came across as =.
  • DESC on Sort order > Node: Created came across as ASC.
  • Taxonomy: Terms for {Vocabulary} field comes across as Taxonomy: All Terms (needs to have Limit terms by Vocabulary option set)

More later, when I get the chance.

merlinofchaos’s picture

Status: Needs review » Active

Ok, latest patch committed, because it's better than not committing it. Please continue to improve this! (and thank you very much for doing so!)

EvanDonovan’s picture

Thanks, 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.

darren oh’s picture

Status: Active » Needs review
StatusFileSize
new1.72 KB

Quick 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.

EvanDonovan’s picture

Great, thanks. I'll be able to test this out tomorrow, most likely.

darren oh’s picture

StatusFileSize
new14.66 KB

Lots of updates in this patch. Works for all my views, but still not quite comprehensive.

darren oh’s picture

StatusFileSize
new16.72 KB

Added better block conversion. Block settings are now preserved (if you convert your views before visiting the block administration page).

EvanDonovan’s picture

Does 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.

darren oh’s picture

Yes. Only apply the latest patch.

EvanDonovan’s picture

The new patches work well, from a cursory review. The only thing I noticed so far is that a User:Uid argument didn't convert.

darren oh’s picture

StatusFileSize
new17.19 KB

Converting a block view caused a pager to appear if the block specified the number of results to return. Fixed patch attached.

EvanDonovan’s picture

Ok, thanks. I will only apply the latest patch then, when I do the actual upgrade of my site to Drupal 6.

darren oh’s picture

StatusFileSize
new17.68 KB

Made page style apply to default view even if there is no URL. Block view replaces default style if no page view exists.

EvanDonovan’s picture

Which 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.

darren oh’s picture

The current patch works on the latest release of Views. You only need the last patch.

EvanDonovan’s picture

Great. Thanks a lot! I may have time to test this coming week; been very busy with the site upgrade.

darren oh’s picture

StatusFileSize
new24.16 KB

New patch to make writing argument converters easier and to convert argument handling code.

darren oh’s picture

StatusFileSize
new25.38 KB

Added support for empty labels.

darren oh’s picture

StatusFileSize
new31.53 KB

Added support for date format conversion.

darren oh’s picture

StatusFileSize
new30.56 KB

Accidentally included code for query.inc in last patch.

darren oh’s picture

StatusFileSize
new31.46 KB

Fixed the "use more link" setting.

darren oh’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new49.42 KB

Finished now.

darren oh’s picture

StatusFileSize
new49.46 KB

Added case transformation to title argument.

JirkaRybka’s picture

Status: Reviewed & tested by the community » Needs work

I'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.

JirkaRybka’s picture

Version: 6.x-2.3 » 6.x-2.x-dev
Status: Needs work » Needs review
StatusFileSize
new48.94 KB

OK, 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:

  if (!$title && ($context == 'menu' || $context == 'menu-parent' || $context == 'page' || $context == 'admin')) {
    $title = $view->page_title;
  }

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:

      if (!empty($field['sortable'])) {
        $options['info'][$id]['sortable'] = TRUE;
        if (!empty($field['defaultsort'])) {
          $options['default'] = $id;
        }
      }

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.

JirkaRybka’s picture

...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.

darren oh’s picture

Status: Needs review » Reviewed & tested by the community

Looks good. Whatever my tests missed was probably caught by yours.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

Committed!

darren oh’s picture

Status: Fixed » Reviewed & tested by the community
StatusFileSize
new3.81 KB

Great! Just two files missing somehow.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

Whoops. FOrgot to cvs add them. Done.

darren oh’s picture

Status: Fixed » Needs review
StatusFileSize
new12.98 KB

Made the default filter conversion work better by adding filter value.

merlinofchaos’s picture

Status: Needs review » Fixed

Committed! THanks Darren. Did I mention how awesome it is that someone is doing this?

JirkaRybka’s picture

Thanks 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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.