[D7] Entity Reference Rendered Display

Multiple Applications

It appears that there have been multiple project applications opened under your username:

Project 1: https://www.drupal.org/node/2295491

Project 2: https://www.drupal.org/node/2293079

As successful completion of the project application process results in the applicant being granted the 'Create Full Projects' permission, there is no need to take multiple applications through the process. Once the first application has been successfully approved, then the applicant can promote other projects without review. Because of this, posting multiple applications is not necessary, and results in additional workload for reviewers ... which in turn results in longer wait times for everyone in the queue. With this in mind, your secondary applications have been marked as 'closed(duplicate)', with only one application left open (chosen at random).

If you prefer that we proceed through this review process with a different application than the one which was left open, then feel free to close the 'open' application as a duplicate, and re-open one of the project applications which had been closed.

I'm a robot and this is an automated message from Project Applications Scraper.

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

I'm a robot and this is an automated message from Project Applications Scraper.

Automated Review

PAreview: It appears you are working in the "master" branch in git. You should really be working in a version specific branch. The most direct documentation on this is Moving from a master branch to a version branch. For additional resources please see the documentation about release naming conventions and creating a branch in git.

Initial observations

Individual user account

Yes: Follows the guidelines for individual user accounts.

Git Clone Command

No. Your git clone command refers to the "master" branch. You first need to have 7.x-1.x as the default branch, then refer to this branch in the git clone commend. Also, your git clone command is for you, and will not work for others.

Licensing

Yes: Follows the licensing requirements

3rd party code/content

Yes: Follows the guidelines for 3rd party code.

Project page

No. Please take a moment to make your project page follow tips for a great project page. In particular, you should add the section "Similar projects and how they are different".

README.txt

No: Please take a moment to make your README.txt follow the guidelines for in-project documentation and the README.txt Template.

I am removing the PAReview: review bonus tag. To add this tag, you first need to do three manual reviews and add links to these reviews on your project page.

Removing PAReview: review bonus tag, since you have not done three manual reviews.

Just posting a link to PAReview is not a manual review.

Personally, I do not think your two other reviews is substantial enough to qualify, but I leave that call to a more senior reviewer.

Manually review

Line 22, file entityreference_custom_display.module, function entityreference_custom_display_field_widget_info()

You should set default value for widget settings for each widget in hook_field_widget_info()

$widgets['custom_display'] = array(
    'label' => t('Custom display'),
    'description' => t('An custon widget for entityreference'),
    'field types' => array('entityreference'),
	'settings'=>array(
	  'custom_display_fields'=>array(),
	),
    'behaviors' => array(
      'multiple values' => FIELD_BEHAVIOR_CUSTOM,
      'default value' => FIELD_BEHAVIOR_NONE,
    ),
  );

Line 63, file entityreference_custom_display.module, function entityreference_custom_display_field_widget_form()

When field instance has maximum number of values = 1, you should render widget as single select element or radios button, do not render each entity as checkbox.

Change issue status

@guilopes
Are you working on open issues in your sandbox?

Hi @guilopes
I've installed your module and got this:
Notice: Undefined variable: rows in entityreference_custom_display_attach_fields() (line 164 of W:\home\dru\7\sites\all\modules\test\entityreference_custom_display\entityreference_custom_display.module). which causes Fatal error: Unsupported operand types in W:\home\dru\7\sites\all\modules\test\entityreference_custom_display\entityreference_custom_display.module on line 97

Steps to reproduce:

1. go to Article content type;
2. add field of type "Entity Reference", widget "Custom display";
3. set field settings: Number of values "1", Target type "Node", Mode "simple" (the only available), Target bundles "Basic page", Sort by "A field ...", Sort field "Body (column value)", Sort direction "Asc";
4. set Article (field) settings: not required, View mode displayed "teaser" (also tried "entityreference_custom_display");
5. then go to node/add/article and you'll get the above error.

debug_backtrace() shows that $all_entities in entityreference_custom_display_attach_fields() are empty.

@guilopes, to address your comment in #18, the application process is described in https://www.drupal.org/node/1011698

The final approval is done by one of the review administrators. They typically work through the Needs Review and RBTC, in order of oldest-since-update. Some of the admins will only look at applications with a Review Bonus (you have one, which is good).

If you project is at Needs Review, and an admin finds no blocking issues, they will mark it RBTC, and assign it to another admin for a second look. If this is OK, they will do the promotion. If the project is already at RBTC, and they feel that the previous reviews have been comprehensive enough, they will do the promotion.

Please be patient during the process. The review admins are all volunteers, and some get busy from time to time. Fortunately, a few new admins have come on, which has started to help clear out the log-jam of applications.

Review of the 7.x-1.x branch (commit 1464523):

• No automated test cases were found, did you consider writing Simpletests or PHPUnit tests? This is not a requirement but encouraged for professional software development.

This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. You have to get a review bonus to get a review from me.

manual review:

1. the project page is not very clear. The module is called "Entityreference custom display", but it has nothing to do with displaying referenced entities, right? It provides a custom widget, which is used when adding/editing new entityreferences. A screenshot would help a lot that shows an edit form. See also the tips for a great project page: https://www.drupal.org/node/997024
2. Broken link on the project page.
3. "Custom Display" as view mode name is similarily bad, since it doesn't have any meaning. This should probably be "Reference edit display" or something.
4. "An custon widget for entityreference" should be "A custon widget for entityreference".
5. "'There are entities of type @type and bundle @bundle'": you mean there are NO entities?
6. How does your module scale? What if there are very many entities that can be referenced? I guess then this module cannot be used because the edit form will explode? Could you clarify that in the README?

So the project name and project page need some improvement, but otherwise I think this is RTBC. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

Assigning to ELC as he might ahve time to take a final look at this.

@guilopes
One more remark.

It seems that your widget is trying to show list of entities of the same bundle as where the field is attached, and not that in "target bundle" setting. For example, I have done all the same steps that I described previously. And now when I want to create new Article the widget says "There are no entities of type node and bundle article", though I've set the Basic page in target bundles of the field.

Can you confirm this behavior?

P.S.: I am not changing this issues status, because everything else seems OK. However I would like to get clarification on my question.

Regards.

I agree that this module needs a different name with a closer relation to what it actually does. It is reliant on Entity Reference so that should be in there. It's a Selection Widget, and it renders a display of the entity as a label to do so.

Entity Reference Rendered Display Selection Widget ? Entity Reference Rendered Display Radio/Checkbox Select Widget? It does need a slightly more purpose specific naming but the final name is up to you.

I'm not sure that I'd include "view" in the name since it might get confused with the Views module, which is what the module mentioned below does. The other elements involved like "Custom Display" needs to be something else too; Rendered Display? Rendered Display Radio Select? Even using "display" is confusing since this is for edit/selection and not for actual display of the final entity.

Could the functionality of this module be achieved with a view and Entity Reference View Widget? It's a different path to rendering the output, but wouldn't it look very similar? This is probably a little simpler in that it doesn't also needs views. I'm led to believe that duplicating functionality is not a show stopper.

The code looks good. There's a double ";;" in there, but everything else looks ok. It might be nicer to avoid directly calling drupal_render and instead building a larger render tree, or using a theme function to pass the same data to build the same output. Both options allow for greater customisation without hacking the module as right now the output is pretty rigid.

Your git commit entries should be formatted differently from now on. Please refer to Commit messages - providing history and credit about giving yourself some credit and properly formatting commit messages.

As part of changing the name, please also attend to the project page and flesh it out a bit. The README file is similarly terse.

Fixing the name of the module should be the first step. Once promoted, a project cannot have its name changed without going through a d.o issue queue, consuming the old namespace plus the new one so that there is no module confusion in the future.

The project is also currently sitting in the "Other" package group. Please have a look around and see there is a more specific group it could fit into.

Fixing the name should make this module ready to go.

I still think that "Entity Reference Rendered Display" is not ideal, "Entity Reference Rendered Widget" would make it more clear that this changes the widget in editing forms, not on entity reference field display.

But since there were no other objections ...

Thanks for your contribution, guilopes!

I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.

Here are some recommended readings to help with excellent maintainership:

• Dries' post on Responsible maintainers
• Best practices for creating and maintaining projects
• Maintaining a drupal.org project with Git
• Commit messages - providing history and credit
• Release naming conventions.
• Helping maintainers in the issue queues

You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

Thanks to the dedicated reviewer(s) as well.