Update to 6.0

Right on! Thanks for the issue.

Here's the plan:

I've made a couple of exciting commits of late that make insert view an actual filter module (using hook_filter rather than hook_nodeapi):
http://drupal.org/node/224987
http://drupal.org/node/180042

I have one more patch to allow users to use a special insert view tag to insert paged views: http://drupal.org/node/148400. (Would love a review of the patch.)

Once I have that committed, I plan on doing an honest-to-goodness release of the module (5-x--1-0). Then I'll begin working on the D6 release.

Looks like Views 2 has a different API, so we'll need some changes around that. And last time I checked there wasn't any documentation for Views 2 (other than in the code).

Also, I'd like to verify that we have proper support for i18n in D6 (reference: http://drupal.org/node/132078). I18n is something I haven't even looked into at this point. If anyone can steer me in the right direction, that'd be great. Otherwise, I'll seek it out when I get to that point. :)

mlsamuelson

Very grateful you are proceeding with this, as Insert View is a key module as far as I am concerned. I also need it to work with i18n in D6, and am happy to help with testing. But unfortunately I am not a coder!

Subscribing

The doco for views2 is here: http://views.doc.logrus.com/

See http://drupal.org/node/253840 for more info.

Any further news on the timing of a D6 version of Insert View? Much hoping for it soon.... Thanks!

Subscribing :)

I've got the update in process.

Actually have a working version for 6, but still trying to figure out if we're going to get to keep all the features. With Views 2, we're interfacing with views_embed_view instead of views_build_view... at this point.

Nothing in CVS yet, but I'll post back here when there is.

mlsamuelson

I didn't end up using views_embed_view, but relied on another method to invoke Views... but it works, and I like it.

In CVS, there is now a Drupal-6--1 branch, and before long a downloadable package ought to appear on the project page.

There are some changes - the "limits" slot (which expected a number) is now the the "display" slot (and expects a string - the name of the view's display). For folks upgrading, the legacy tags should be supported, though the limits will be disregarded and the view's "default" display will be used. Similarly, the [view_pager:viewname] tag is deprecated in favor of using Views 2's excellent display functionality. Essentially, the limits and pager controls were a way to do a local override of the base view's settings. Now, by relying on Views 2's ability to create different "displays" of a base view, we simply invoke our view using the desired display. If none is provided, we use the default. Pretty simple. May require some manual tweaking for folks upgrading, but I've attempted to support the legacy tags as much as possible. More info on this, and an explanation on how to get a view's display ID in the README.txt.

Download it, take it for a spin. Report back with issues. After a few weeks, if feedback is good (I consider silence good) and there are no outstanding critical bugs I'll make an official release.

mlsamuelson

Thanks so much Michael! My first testing shows no problems. If I run into any I will report and issue. Very grateful to you for doing this, and the whole community will benefit.