This is postponed on actually getting profile2 into core: #1668292: Move simplified Profile2 module into core But I have most of the patch ready, I will post soon.

Files: 
CommentFileSizeAuthor
#2 1894770.patch6.16 KBdamiankloip

Comments

damiankloip’s picture

Title: Add view integration for profile2 module » Add views integration for profile2 module
damiankloip’s picture

FileSize
6.16 KB

Here is an initial patch for this, I have had this laying around for a little while but forgot to post it. This is still dependent on the linked issue in the summary, just posting some work.

dawehner’s picture

Great, just posting some general points.

+++ b/core/modules/profile2/lib/Drupal/profile2/Plugin/views/argument/Pid.phpundefined
@@ -0,0 +1,37 @@
+/**
+ * Argument handler to accept a profile pid.
+ *
+ * @Plugin(
+ *   id = "profile2_pid",
+ *   module = "profile2"
+ * )
+ */
+class Pid extends Numeric {
+
+  /**
+   * Overrides \Drupal\views\Plugin\views\argument\Numeric::title_query().
+   */
+  public function title_query() {
+    $titles = array();
+
+    $profiles = entity_load_multiple('profile', $this->value);
+    foreach ($profiles as $profile) {
+      $titles[] = check_plain($profile->label());
+    }
+
+    return $titles;

I think we should instead write a entity generic one, which get's the entity type from outside.

+++ b/core/modules/profile2/lib/Drupal/profile2/Plugin/views/filter/Type.phpundefined
@@ -0,0 +1,49 @@
+class Type extends InOperator {

Can't we use an optional callback and the generic InOperator?

+++ b/core/modules/profile2/profile2.views.incundefined
@@ -0,0 +1,169 @@
+    // @todo wizard id/integration.

Well, we don't have to provide a wizard, unless we have an idea what a profile one should provide.

+++ b/core/modules/profile2/profile2.views.incundefined
@@ -0,0 +1,169 @@
+  // pid

Just for reference: we should remove that.

+++ b/core/modules/profile2/profile2.views.incundefined
@@ -0,0 +1,169 @@
+        'id' => 'string',

Any reason not to use the language field handler as well?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.