Viewfield: Drupal 8 version

Thanks for your inquiry and for creating this issue. We have no concrete plans for a Drupal 8 port at the moment. Please feel free to contribute your patches in this issue. As you go forward, I would recommend you thoroughly research the work that has been done in Drupal 8 (e.g., Views in core, pervasive use of entities) to determine the best way to move forward with the "view in a field" concept behind this module. I look forward to seeing your patches!

Here is a patch. It is not a complete port, but it is enough to get started on a d8 branch.

We (@InternetDevels team) made patch, most of the functionality is already working, but this is not all.

#6 worked for me without any errors on D8 Beta 4 with some basic testing; will test more soon.

#6 worked for me in D8beta6 ...

Wouldn't it be better to base your work on Entity Reference instead of creating a new field type?
I didn't lok too far but it seems you can restrict Formatters and Widgets according to the target type of the entity reference field. I don't know how hard it is to have additionnal data saved with the reference but I think it would be better from a "Drupal way" point of view.
My 2 cts.

That is probably a good thing to look into. Config entities are entities and we should be able to link to them with this existing field. I wonder about linking to a single display within a view.

We needed a fast solution - so this version is running against D8rc4 ...
Sorry no patch ...

I summarized the patches from this issue in https://github.com/derhasi/viewfield to ease further development.

Attached is a patch for the version in #13 with an interdiff to pferlito's version.

@DuaelFr, as Views Displays are no config entities, it isn't that straight forward of simply using entity reference. But maybe some approach like in entity_referenc_revisions might work. I have a look at that.

The last update of sachbearbeiter fixes https://www.drupal.org/node/2609062

Updated patch with:

• Move viewfield_field_instance_settings_form_validate() in class ViewfieldItem
• Added composer.json to support composer workflow
• Fixed validation of force_default

Still need to test the tests.

@pferlito, I'm hosting my changes in https://github.com/derhasi/viewfield for keeping track of them, as I think github is better for collaboration on such issues (PR for the win :)). The repo there also uses viewfield's git history as base.

How is this coming along?

Maybe some maintainer should copy the latest github work to D8 and create a first dev version ...
We use this module for a long time now and it only needed some minor fixes from time to time to work fine.
There are still some minor things in the ui, but a dev version would be appropriate and as a result some more people would test more scenarios.

I will work on this again within the next days.

I can confirm that the basic functionality works. I used this module in D7 in combination with paragraphs. This gives a very flexible tool to create content an have views embedded inside nodes. Lets create a D8 branch and file further issues against it. On thing I encountered though: I guess viewfield.install is not needed anymore, right?

I use the viewfield implementation from over at github in conjunction with Paragraphs module too. But instead of D7 I use it in D8. Like @lukas-von-blarer mentioned this enables very flexible layout / content creation possibilities and it works so far for me.

It looks like the viewfield arguments do not get propagated(updated issue below). Did somebody try this and if so does it work with your configuration?

In my case I want to define the number of shown view items from the place (field of paragraph) where I reference the view so I don't have to create multiple view displays which vary only in number of returned items.

So I decided to use the view argument as the limit which sets the items per page of the view dynamically. Setting manually $view->setItemsPerPage(2); in hook_views_pre_build($view) {} works.

But it does not work so far dynamically. When I output kint($view->argument); I have an empty array but I actually defined 2 as an argument to the corresponding selected view in the viewfield.

Any suggestions why $view->argument is empty?

function yokai_helper_views_pre_build($view) {

  // outputs empty argument array,
  // should actually hold the 'to be shown number of view items'
  kint($view->argument);

  // manually setting, should actually be done by argument
  $items_per_page = 2;
  $view->setItemsPerPage($items_per_page);
}

Actually I figured it out. The argument gets passed to the view I was just outputting the wrong property.

Use kint($view->args); instead of kint($view->argument); which was also present in my case but empty. Not so the args property.

I now use limit=2 as argument pattern in the viewfield and have written the following function which checks for the pattern and appends the limit if the pattern matches.

/**
 * Implements hook_views_pre_build
 *
 * Act on the view before the query is built, but after displays are attached.
 */

function yokai_helper_views_pre_build($view) {

  // check if has arguments supplied
  if ( !empty($view->args) ) {

    // argument pattern which gets used in viewfield, e.g. limit=2
    $args = explode('=', $view->args[0]);

    // check if limit is available
    if ( !empty($args[0]) && ($args[0] == 'limit') ) {

      // check if limit is an integer
      if ( !empty($args[1]) && is_numeric($args[1]) ) {

        // if so, set view items from viewfield argument
        $items_per_page = intval($args[1]);
        $view->setItemsPerPage($items_per_page);
      }
    }
  }
}

So viewfield seems to work not like I expected in the above comment.

Important: Pager settings in the view need to have the Display a specified number of items option selected. Otherwise $view->setItemsPerPage has no effect.

Maybe some maintainer should copy the latest github work to D8 and create a first dev version

This.

Lets get that rolling... its very hard to understand where to find modules anymore as it seems more and more people are doing work on Github and not updating projects here. You could always create a second remote to d.o and push to dev branch as dev is pushed on GitHub. Just a thought.

Anyway, yeah. Came here looking to see if this was in progress / working for D8. It would be a very powerful content building feature if you could use Paragraphs and inject Views displays into your content. Is there an ability to limit the Views that could be referenced and/or displays within a view?

Updated the issue summary with a link to the github repo and remaining steps.

Whoever wants to take this on (long-term) should probably apply as a co-maintainer in order to create and manage the 8.x branch.

> Wouldn't it be better to base your work on Entity Reference instead of creating a new field type?

The problem with that is that the Entity Reference field only lets you reference the view. In many cases, you want to select a specific display of the view, and possibly also pass in some arguments.

There is a sandbox module at that provides a field formatter for a rendered view for an entity ref field at https://www.drupal.org/sandbox/paulmckibben/2481503. It works great for a more limited case where you just want the default display of the view.

I did not do much research on this one, but I think the cache tags are not being set properly. When (dynamic) page cache is enabled and I create a node which is being output by a viewfield, it is not being rendered until the cache is being cleared manually. Sorry, I am not that familiar with debugging caching issues, but this should be fairly easy to reproduce.

I created a pull request. This needs tests.

https://github.com/derhasi/viewfield/pull/2

@Lukas - thanks for investigating ... sounds like this could solve my caching problems ...

I can confirm what Luk mentioned in #29. I do also have caching issues with viewfield. In my case they are date related and upcoming events do still show up (even they are in the past) until I manually flush the cache.

Did you test my pull request? It fixes the issue.

Mini summary:

- does someone want's to be an additional maintainer?
- still no D8 version on drupal.org
- github repo did not change since 8 months
- Berdir made some general remarks here: https://github.com/derhasi/viewfield/pull/2

~~~~~~~~~~~~

- i need this module, because Views displays and arguments are selectable for editors
- possible ui feature: admin driven preselection of Views displays that are offered to editors
-> would the same be possible with the entity reference widget (like DuaelFr asked in #10)?

joachim answered in #28

There is a sandbox module at that provides a field formatter for a rendered view for an entity ref field at https://www.drupal.org/sandbox/paulmckibben/2481503. It works great for a more limited case where you just want the default display of the view.

If i remember right, there is already a rendered view field formatter in the entity reference field of later D8 versions ...
But maybe this one would stay minimal in the future and we should develop viewsfield further as a field formatter with additional options?

But as DuaelFr mentioned in #10

I don't know how hard it is to have additionnal data saved with the reference but I think it would be better from a "Drupal way" point of view.

I don't have the expertise to give an answer ...

I updated the pull request as berdir suggested. Please review it: https://github.com/derhasi/viewfield/pull/2

Lets get a 8.x branch on d.o please...

I just ran across https://www.drupal.org/sandbox/andywhale/2775537 which tackles the functionality I was looking for.

I just create an issue requesting a merge with Viewfield.

I'm just curious as to the status of Viewfield getting a Drupal 8x version?

There is a working port at: https://github.com/derhasi/viewfield
I have a fork of that repository which fixes the caching issues: https://github.com/luksak/viewfield/

And here is my pull request that needs some love: https://github.com/derhasi/viewfield/pull/2

Sorry, I had no time the last months to deep dive into the code. Maybe I can find some time during Drupalcon Dublin. If there is anybody else wanting to review the PR, I am fine to merge it after that.

I would be fine reviewing a patch on d.o but I am not setup to review PRs from github for drupal modules.

Because i just have seen: https://github.com/derhasi/viewfield/pull/4

@derhasi
I hope, you find the time to improve the code ...
Have you got maintainer rights to release also a first version on Drupal.org?

Thanks and best regards
SB

is there any chance to move the code back to D.o and create a package in packagist?
would be really good..

No one has applied to be co-maintainer for the 8.x branch, so I haven't created one yet.

Releases on drupal.org automatically create packages in the legacy repository https://packagist.drupal-composer.org/ and the new official repositories on https://packages.drupal.org/7, https://packages.drupal.org/8.

I've tested https://github.com/derhasi/viewfield/pull/4, and it appears to be working. It'd be great if that could be merged, and then we can make a release on d.o.

+1 to #46

+1 to #46

So, I tried to get in the issues of viewfield again on Drupalcon Dublin. But I noticed that I'm not too deep in D8 and am not using viewfield right now anyways, so I'm not the right one to push this further, sorry. For that reason I'm stepping down from this issue.

I'd be happy to move "my" repo to someone else, so she/he can continue with that. A better approach would be, to simply continue here - especially with support for DrupalCI.

@keithm, maybe you can open an "experimental" 8.x-Branch, so the community can start to build and run tests on Drupal CI. I then would recommend, that an "alpha"-release is only made, when you found a maintainer ;)

Hi keithm, it looks like Lukas von Blarer is ready to be a maintainer. Lukas, is that correct? Keith, is the process for applying to be a co-maintainer to ask here? :-)

I could maximum do co-maintenance since i wrote around ten lines of code for this module...

I added a comment on the pull request: https://github.com/derhasi/viewfield/pull/4

Lets get this ready and merged so we can finally get a dev version on d.o...

Actually, my work in https://github.com/derhasi/viewfield/pull/4 was not being processed through the render pipeline. So, I scrapped it all and started over by simplifying field's render in https://github.com/derhasi/viewfield/pull/8.

I'm not sure if this is exactly what is wanted, but I think it's a better (more Drupal 8) way to approach the rendering going forward. What this PR is missing is:

• Recursion protection that was provided by the preRender and postRender functions.
  • I question if this is still necessary in 8.x.
• Theming per delta element.
  • Though, I am in the camp that Drupal has too many divs already and so I think that each view build providing its own wrapping div is sufficient.

@derhasi you should apply for the maintainership of this module and release the 8.x-1.x code here.

@keithm - could you add Lukas as a co-maintainer?
would be wonderful, to have a first dev release on drupal.org ...

Thank you for great work already.

The arguments issue is vital imo, because it will be a very common usecase to take the node ID and filter on that.

Until we get there, can we maybe get a quick fix by adapting #25 and a checkbox to look for a node ID?

For anyone who is interested/in need of a module that has a similar functionality to Viewfield, you may want to give Views Reference Field a try.

I'm starting to take a look at the D8 work done so far. There are several github repositories to sort through including https://github.com/derhasi/viewfield, https://github.com/luksak/viewfield and https://github.com/marcus-n3rd/viewfield. Initially I am looking for a direct port of the D7 code without any unnecessary enhancements.

I also want to check out https://www.drupal.org/project/viewsreference.

@keithm, is it okay if I transfer derhasi/viewfield to your github account? I'm cannot maintain that fork anymore but it seems to be by some developers to post PRs. That way you could sort out the PRs and maybe merge backe to drupal.org.

I also could give luksak editor rights to the github project if you want.

@derhasi I'm OK to accept the transfer (to wellebee on github) in the interest of maintaining continuity.

In the end I prefer an approach based in entity reference fields but I believe it would be good to maintain your project.

@keithm, I started the transfer. I guess you have to accept it on your site. I did not add luksak as maintainer there, so you would need to do that, if you like.

I also think, an entity reference approach will be better in the long run. If I had the time to develop it, I even would go further and run for a specific views display type, that you could configure to use specific field types (like entitiy reference, number, list) to pass arguments to the view, so the editor might have a better experience. But that's something that would need a little more of conceptual design.

In case you impement a different storage please do so in a separate major release. Let's first get the current approach working and improve from there. We need an upgrade path for this. I know a lot of people using this module in production.

In case you impement a different storage please do so in a separate major release. Let's first get the current approach working and improve from there. We need an upgrade path for this. I know a lot of people using this module in production.

+1

+ thanks

I have read this issue and the code on the various github repositories. Thanks to all of you for your interest and work on this.

The previous work that had been done had considerable merit but I didn't see that we had completely addressed two important features: bundle-wide values (via the force_default setting) and token replacement for arguments.

In the end I felt it better to opt for an approach based on entity reference fields for maintainability reasons. I have pushed a prototype 8.x-2.x implementation to https://github.com/wellebee/viewfield/tree/8.x-2.x-keithm. It is incomplete, but it addresses the two features listed above.

Please give it a try and let's discuss.

I have pushed a viewfield-8.x-3.x-dev development release. Please let's move further D8 development and bug discussions to separate child issues of this one, ones specific to those features or bugs. For now I will leave this issue open to serve as a road map, but please no new issues here.

@Lukas von Blarer and @sachbearbeiter. I'm sorry but I don't have the resources to host and maintain the original port done by derhasi, which uses a different approach and is feature incomplete. I will leave the original github repository at https://github.com/wellebee/viewfield/tree/8.x-2.x for your use.

Thank you for this much awaited release.

Thanks a lot for bringing this back to drupal.org ...
... and i totally understand that you use an entity reference field as the base, but is there an upgrade path from the old version?

Thank you for bringing all the work from the various forks on github back to d.o

Where will future development be taking place. In practice github is not a great place for communal work.

Thanks for your comment.

All of my work has been done on drupal.org and will continue that way. I only posted to github for anyone's comment but that github repository is no longer maintained anyway.

@keithm Thank you for your work! Looking forward to use the new version!

What do you think, would it be hard to create an upgrade path from the old version?

It looks like the Drupal 8 version is "done?" Should we mark this as fixed?

Hi! Thanks for the work in the viewfield version for Drupal 8.

I use in a project the previous version by wellebee, concretely the fork by Lukas in https://github.com/luksak/viewfield/tree/adding-cache-tags.

I was trying to upgrade to the official version but I am facing some problems because as I've checked, there are some differences in the module internals. I've solved the problem regarding differences in configs entities, preparing a custom upgrade path for that, but I've seen that also changes the internal structure of the field schema.

In the old version, the table regarding the viewfield has two fields, called:

- field_[bundle]_vname, storing the view machine name and the display_id separated with a vertical bar (ex: view_id|display_id)
- field_[bundle]_vargs, storing the arguments for the view

The fields in the official version are different:

- field_[bundle]_target_id
- field_[bundle]_display_id
- field_[bundle]_arguments

I've not checked it in a new installation, but I suppose the new target_id and display_id are equivalent to the previous vname, exploding the value by the vertical bar, and the arguments should maintain the same format. Is this correct?

Would you think it could be reasonable prepare an official upgrade path for those people using the old version?

I'd be very intersted in an upgrade path. I currently don't have the time to write it, but I'd be able to test it on a few existing sites.

As there is a Drupal 8 version here and we've picked up development for cleanup of that version, I think this issue can be closed. If we want to add an upgrade path for the interim versions that were forked on GitHub let's address that in a distinct ticket and please provide a patch.

In reply to #114 : If theres anybody still looking for a migration from https://github.com/wellebee/viewfield 8.x-2.x to the drupal.org 3.x branch, please look into my comment here: https://www.drupal.org/project/viewfield/issues/3262116#comment-14399839