Description
This module allows authors to create curated content that can be referenced later when creating content that includes the prepopulatedfields_field. An example would be to create a couple different nodes using different voices/tones, and then allowing content authors to pull in that data dynamically, with the ability to modify before saving the new content.

Current sandbox project
https://www.drupal.org/sandbox/dsvoboda/2616794

Git clone command
git clone --branch 7.x-1.x http://git.drupal.org/sandbox/dsvoboda/2616794.git prepopulatedfields
cd prepopulatedfields

This is our first project submission, but we are excited to finally submit a project of our own!

Comments

dsvoboda created an issue. See original summary.

PA robot’s picture

Status: Active » Needs work

There are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxdsvoboda2616794git

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.

dsvoboda’s picture

Assigned: Unassigned » dsvoboda
Status: Needs work » Needs review

These issues should be resolved in the latest commit.

mmowers’s picture

Hi @dsvoboda! Here's an initial manual review, based on the Project Application Review Template.

Manual Review

Recommendations are in bold italics below.

Individual user account
Follows the guidelines for individual user accounts.
No duplication
Regarding module duplication and/or fragmentation, please describe the difference between this module and prepopulate, and why the functionality should be kept separate.
Master Branch
Follows the guidelines for master branch. The git clone command retrieves the 7.x-1.x branch.
Licensing
Follows the licensing requirements. No other licenses are used.
3rd party assets/code
N/A, there is no third-party code required/recommended.
README.txt/README.md
Mostly follows the guidelines for in-project documentation, with helpful instructions on the project page, a README.txt file that follows the README Template, help text in the UI, instructions in hook_help, and all functions documented. Please remove "Alt studios" as the package in .info - as written in the guidelines, "in general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like.".
Code long/complex enough for review
Follows the guidelines for project length and complexity, with 14 function definitions and ~400 lines of code.
Secure code
Meets the security requirements: Uses db abstraction layer and t() function where there is text.
Coding style & Drupal API usage
List of identified issues in no particular order
  1. Please remove configure from .info file, as there is no configure page registered in hook_menu.
  2. Consider using Drupal Behaviors for prepopulatedfields.js.
mmowers’s picture

Status: Needs review » Needs work
klausi’s picture

Assigned: dsvoboda » Unassigned
Status: Needs work » Needs review

@mmowers: those issues sound like good improvements, but are surely not application blockers. Anything else that you found or should this be RTBC instead?

mmowers’s picture

Thanks @klausi, I'm still getting a hang of what bugs/issues warrant * and + designations. I'll edit the comment and remove the stars. Those are the only issues I saw, and I just took the module for a spin on my local env, and all looks good to me on that front too. I'm probably too new to this to make the call to move to RTBC, so I'll let you or someone else decide if my review looks sufficient. Thanks again.

dsvoboda’s picture

Hello,

Thank you for reviewing our module. Just wanted to let you know that I've reworked the javascript to implement Drupal.behaviors, as well as made edits to the .info file per your recommendations.

This module is different from prepopulate in that prepopulatedfields allows you to define preset defaults for an individual field you can choose from in a dropdown below the input (textarea) - Prepopulate works with $_REQUEST variables where this one pulls data direct from a predefined content type. I've went ahead and added this to the project page as well.

legolasbo’s picture

Status: Needs review » Needs work

An additional review based on the one in #4

Automated Review

Automated review resulted in 3 issues. see http://pareview.sh/pareview/httpgitdrupalorgsandboxdsvoboda2616794git

Manual Review

Individual user account
[Yes: Follows] the guidelines for individual user accounts.
No duplication
[Yes: Does not cause] module duplication and/or fragmentation.
In my opinion the differences raised in #8 are valid.
Master Branch
[Yes: Follows] the guidelines for master branch.
Licensing
[Yes: Follows] the licensing requirements.
3rd party assets/code
[Yes: Follows] the guidelines for 3rd party assets/code.
README.txt/README.md
[Yes: Follows] the guidelines for in-project documentation and/or the README Template.
Code long/complex enough for review
[Yes: Follows] the guidelines for project length and complexity.
Secure code
[Yes: Meets the security requirements. ]
Coding style & Drupal API usage
[List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:
  1. In hook_help() you are breaking up sentences like the code below:
    $help .= '<li>' . t('Create content of type <b>') . $content_type . t('</b> - <a href="/node/add/') . $clean_type . t('" target="_blank">click here</a>.') . '</li>';
    Instead of breaking up the sentences you should use placeholders like @content_type or %content_type.
  2. prepopulatedfields_field_widget_form() as a unused variable ($main_widget)
  3. Also in prepopulatedfields_field_widget_form() (line 86) you are using db_query where you could be using an EntityFieldQuery to make your code abstracted from the database.
  4. Between lines 97 and 118 you are creating markup by concatenating strings. You should consider implementing a theme function and/or template to generate said markup.
  5. Between lines 103 and 109 you are looping over an array of node ids and loading individual nodes. You should use node_load_multiple() instead and loop over the loaded nodes. This potentially saves many database calls
  6. There is no whitespace between individual functions. Your code could be more readable if the functions were separated by at least one empty line.
  7. You are using variables to pass content types, taxonomy etc along during your program execution, but these are not configurable (they are only installed). Perhaps you are better off using constants instead, to prevent people from accidentally breaking your module by altering one of the variables.
  8. 
    /**
     * Implements hook_access().
     */
    function prepopulatedfields_access($account = NULL) {
      if (!$account) {
        global $user;
        $account = $user;
      }
      return user_access('administer Prepopulatedfields settings', $account);
    }
    
  9. Does not seem to be used...

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

While the issues on their own don't warrant going back to needs work I feel the project is not release candidate material just yet. Therefor I am marking the issue needs review.

If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.

This review uses the Project Application Review Template.

dsvoboda’s picture

legolasbo, thank you for your input. Below is a list of my changes and responses!

  1. I've updated the content in hook_help() per your recommendations.
  2. The variable you marked as unused is being used, I believe that was a mistake.
  3. I've updated the db_query to use a db_select as I did in the code a few lines above.
  4. I don't think there's enough markup created here to warrant using a template or theme function for this. If you have an example of implementation that represents a solution I will consider it!
  5. I've implemented node_load_multiple() after reworking my database calls now that they are more consistent.
  6. I've added a blank line between functions.
  7. I've put in place a defined constant that we now use throughout the .module file.
  8. I've removed the hook_access and hook_permission calls as we no longer have configurable settings for this module.

One last note I didn't seem to notice anything marked with (+) or (*) - Wasn't sure if that got missed as well.

Thanks!

legolasbo’s picture

Status: Needs work » Needs review

dsvoboda,

I don't think there's enough markup created here to warrant using a template or theme function for this. If you have an example of implementation that represents a solution I will consider it!

Any markup, no matter how small should be output using Drupal's theme layer to allow for changes by other modules and themes. By using a template you even increase the readability of the HTML you are outputting and thereby improve it's maintainability.

One last note I didn't seem to notice anything marked with (+) or (*) - Wasn't sure if that got missed as well.

That's correct. In itself none of the changes mentioned warranted a + or *, but all together they made the module need work.

dsvoboda’s picture

legolasbo,

I've worked theming functions into the module to handle the markup output in our latest commit.

Thanks!

dsvoboda’s picture

Thought I'd check on the status of the module approval - Thanks.

th_tushar’s picture

Status: Needs review » Needs work

Hi @dsvoboda,

I manually reviewed your code. Below are the findings.

There is a security vulnerability in your module code.

function prepopulatedfields_field_formatter_view($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
  $element = array();
  switch ($display['type']) {
    case 'prepopulatedfields_formatter':
      foreach ($items as $delta => $item) {
        if (isset($item['value'])) {
          $element[$delta] = array('#markup' => $item['value']);
        }
      }
      break;
  }
  return $element;
}

In above function, make sure the $item['value'] variable get passed through appropriate sanitization function.

function theme_prepopuluatedfields($variables) {
  $markup = "<div data-prepopulatefields-markup data-field='" . $variables['field']['field_name'] . "[" . $variables['langcode'] . "][" . $variables['delta'] . "]'>";
  if ($variables['avail_nodes']) {
    $markup .= '<label for="prepopulatedfields-select-' . $variables['delta'] . '">Templates</label>';
    $markup .= '<select id="prepopulatedfields-select-' . $variables['delta'] . '" data-name="' . $variables['field']['field_name'] . '[' . $variables['langcode'] . '][' . $variables['delta'] . ']" data-prepopulatedfields-options>';
    $markup .= '<option value="">- Copy From -</option>';

    $avail_nodes = node_load_multiple($variables['nids']);
    foreach ($avail_nodes as $key => $value) {
      $body = field_get_items('node', $value, 'body');
      $output = field_view_value('node', $value, 'body', $body[0]);
      $code = htmlentities(preg_replace("/\r|\n/", "", trim(render($output))));
      $markup .= '<option value="' . $code . '">' . $value->title . '</option>';
    }
    $markup .= "</select>";
  }
  else {
    $permission = variable_get('prepopulatedfields_access');
    $node_add = drupal_clean_css_identifier(PREPOPULATEDFIELDS_CONTENT_TYPE);
    user_access($permission) ? $additional = '<a href="/node/add/' . $node_add . '" target="_blank">Create some</a>.' : '';
    $markup .= '<p>No templates have been created yet. ' . $additional . '</p>';
  }
  $markup .= "</div>";
  return $markup;
}

Findings in theme_prepopuluatedfields().

  1. There seems to be a spelling mistake in the function name. Make sure that the function gets called.
  2. Drupal's l() function should be used to generate link for $additional variable.
  3. If user do not have access, the undefined $additional variable warning will occur.

Changing the status to "Needs work". Change the status back to "Needs review" after fixing the above issues.

dsvoboda’s picture

Status: Needs work » Needs review

@th_tushar,

First I'd like to thank you for taking time to review our module.

In response to your concerns I've made a commit that should take care of the issues you brought up. You mention a warning if the $available variable isn't defined, however in the else it's set to an empty string if the user doesn't have adequate permission. The variable is defined as an empty string. If there's a different way you think we should go about handling that let us know, but we haven't run into an undefined variable warning in our tests.

Let us know if there is anything else you'd like us to address. Additionally We'll begin working on a D8 version once the D7 version gets off the ground.

Thanks again!

klausi’s picture

Assigned: Unassigned » th_tushar
Status: Needs review » Needs work
Issue tags: +PAreview: security

manual review:

  1. prepopulatedfields_init(): why is the constant needed if it is not a constant at all? It is defined dynamically with a variable? I think you can just remove the constant and use the variable when you need it.
  2. theme_prepopulatedfields(): a theme function should never load nodes. It should get all prepared variables passed to it.
  3. <p>No templates have been created yet. ' .: all user facing text must run through t() for translation. Please check all your strings.
  4. There is still a security vulnerability in the module and as part of our git admin training I'm assigning this to th_tushar so that the can take a look. If he does not find anything I'm going to post the vulnerability details in one week. And please don't remove the security tag, we keep that for statistics and to show examples of security problems.
dsvoboda’s picture

@klausi

I've made some changes to the code per your suggestions.

prepopulatedfields_init(): why is the constant needed if it is not a constant at all? It is defined dynamically with a variable? I think you can just remove the constant and use the variable when you need it.

I've replaced the use of the constant with recalling the variable per your suggestion.

theme_prepopulatedfields(): a theme function should never load nodes. It should get all prepared variables passed to it.

I've updated the code to use a passed object rather than creating it from within the theme.

No templates have been created yet. ' .: all user facing text must run through t() for translation. Please check all your strings.

I've replaced this with a translated string as well as in a few other spots that I had missed previously.

There is still a security vulnerability in the module and as part of our git admin training I'm assigning this to th_tushar so that the can take a look. If he does not find anything I'm going to post the vulnerability details in one week. And please don't remove the security tag, we keep that for statistics and to show examples of security problems.

I've added an additional call to filter_xss_admin() in the option markup, but await what you find as a security vulnerability.

Thank you for your time!

th_tushar’s picture

Hi @dsvoboda,

I have manually reviewed your code, found the below issues.

There is a security vulnerability in the below lines of code in .module file,

$markup .= '<option value="' . $code . '">' . $value->title . '</option>';

The $value->title should be passed through check_plain() function. Also the $code variable may not contain HTML and can not be too long as the value is being sourced from textarea. It should be a string/machine name of any entity to identify the selected value.

In prepopulatedfields_field_formatter_view() function, $item['value'] should be passed through filter_xss() as the field is also displayed for anonymous users.

The link text of the l() function should be passed through translation t() function.
l('Create some','/node/add/' . $node_add, array('attributes' => array('target' => '_blank')));

it should be

l(t('Create some'),'/node/add/' . $node_add, array('attributes' => array('target' => '_blank')));

The value of '#default_value' should be string.

'#default_value' => isset($settings['prepopulatedfields_category']) ? $settings['prepopulatedfields_category'] : array(),

it should be

'#default_value' => isset($settings['prepopulatedfields_category']) ? $settings['prepopulatedfields_category'] : '',

Since the $additional variable is initialized on if user has permission, if user don't have permission, initialize it to empty string as below.
user_access($permission) ? $additional = l('Create some','/node/add/' . $node_add, array('attributes' => array('target' => '_blank'))) . '.' : $additional = '';

On un-installation of the module, all the module related variables should be deleted from Drupal.

Changing the status to "Needs work". Please change the status back to "Needs review" once the above issues are fixed.

dsvoboda’s picture

@th_tushar

Thanks again for your review, I've implemented your suggestions. To respond to a few of them:

In prepopulatedfields_field_formatter_view() function, $item['value'] should be passed through filter_xss() as the field is also displayed for anonymous users.

The use of filter_xss_admin() instead of filter_xss() should be more than adequate as it just increases the elements allowed, but still passes them through the filter_xss(): (from https://api.drupal.org/api/drupal/includes%21common.inc/function/filter_xss/7)

  • Removes characters and constructs that can trick browsers.
  • Makes sure all HTML entities are well-formed.
  • Makes sure all HTML tags and attributes are well-formed.
  • Makes sure no HTML tags contain URLs with a disallowed protocol (e.g. javascript:).

And you mention a concern with the length of the $code variable possibly being too long as it's from a textarea, I'm unable to find a limit to the value attribute in the HTML spec - There are even people that have added 10 million character strings to values and the page renders fine (that's a lot of data!) Information can be read at this link (and links to spec docs on the page): http://stackoverflow.com/questions/1496096/is-there-a-limit-to-the-length-of-html-attributes.

Let us know if there are any additional concerns we can address as we move forward with getting this module completed.

Thanks!

th_tushar’s picture

Status: Needs review » Needs work
dsvoboda’s picture

Status: Needs work » Needs review

@th_tushar

I've made a commit addressing your concerns, I also posted comments detailing the changes I made, but they aren't showing up here. Not sure where they went. (Note the #19 and #20 are missing from the list of comments) - I think I double posted as I didn't see the first one show up. I assume they are still in the queue somewhere.

Specifically my concerns:

In prepopulatedfields_field_formatter_view() function, $item['value'] should be passed through filter_xss() as the field is also displayed for anonymous users.

It's being passed through filter_xss_admin() which does the same thing that filter_xss() does, but allows more generic HTML elements through, yet none of the elements it allows through offer any additional threat to the server, they are merely different elements that get cleaned through the same process. See https://api.drupal.org/api/drupal/includes%21common.inc/function/filter_xss_admin/7

This code does four things:

  • Removes characters and constructs that can trick browsers.
  • Makes sure all HTML entities are well-formed.
  • Makes sure all HTML tags and attributes are well-formed.
  • Makes sure no HTML tags contain URLs with a disallowed protocol (e.g. javascript:).

The other concern you brought up that I can't find any issue with is the worry that the content of $code that's stored in the select element's option value attribute may be too long, yet there's no indication of a limit in the HTML spec. So long as I'm sanitizing the code that's in the value there should be no concern. Now if I missed the limit, please let me know: http://w3c.github.io/html/, http://stackoverflow.com/questions/1496096/is-there-a-limit-to-the-length-of-html-attributes#answer-1496165

Thanks!

dddave’s picture

Sorry dsvoboda, but Mollom unpublished your comments. @All: It would be really helpful if you guys could click on the confirm button under usernames of clearly legitimate users that try to jump through this hoop. Otherwise overzelaous Mollom is very likely to swallow comments containing code or links.

khurrami’s picture

Hi,

Please correct followings in your prepopulatedfields.module file

Expected one space after the comma,
else {
$query = db_select('node','n');

Thanks

klausi’s picture

@khurrami: looks like you forgot to change the status after your review. The minor whitespace issue is surely not an application blocker. Anything else that you found in your review or should this be set to RTBC?

dsvoboda’s picture

@khurrami & @klausi,

I've updated the .module file to correct the space that was missing. Let me know if there's anything else I can do to move this forward.

Thanks!

dsvoboda’s picture

Thought I'd check to see how the approval process is going? Has been waiting a while. Anything I can do to help?

Nandu.Kumar’s picture

Assigned: th_tushar » Unassigned
Status: Needs review » Needs work

Hello,
I reviewed the module and found errors.

kindly see the automated review for your project
https://pareview.sh/node/2979

FILE: /root/repos/pareviewsh/pareview_temp/prepopulatedfields.install
FILE: /root/repos/pareviewsh/pareview_temp/prepopulatedfields.module

PA robot’s picture

Status: Needs work » Closed (won't fix)

Closing due to lack of activity. If you are still working on this application, you should fix all known problems and then set the status to "Needs review". (See also the project application workflow).

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

dsvoboda’s picture

Status: Closed (won't fix) » Needs review

I've made changes found in comment #28. Changing status to "Needs Review"

nitesh624’s picture

Automated Review

[Best practice issues identified by pareview.sh FILE: /root/repos/pareviewsh/pareview_temp/prepopulatedfields.module

Note that perfect adherence to Drupal Coding Standard is NOT a reason to block an application, except for total disregard of them. However, modules should follow them as closely as possible.

Manual Review

Individual user account
Yes: Follows the guidelines for individual user accounts.
No duplication
No module duplication and/or fragmentation.
Master Branch
Yes: Follows the guidelines for master branch.
Licensing
[Yes: Follows / No: Does not follow] the licensing requirements.
3rd party assets/code
Yes: Follows the guidelines for 3rd party assets/code.
README.txt/README.md
Yes: Follows the guidelines for in-project documentation and/or the README Template.
Code long/complex enough for review
Yes: Follows the guidelines for project length and complexity.
Secure code
In line no 130 of prepopulatedfields.install file directly used sql query which is not recommended
Coding style & Drupal API usage
List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.

This review uses the Project Application Review Template.

nitesh624’s picture

Automated Review

[Best practice issues identified by pareview.sh FILE: /root/repos/pareviewsh/pareview_temp/prepopulatedfields.module

Note that perfect adherence to Drupal Coding Standard is NOT a reason to block an application, except for total disregard of them. However, modules should follow them as closely as possible.

Manual Review

Individual user account
Yes: Follows the guidelines for individual user accounts.
No duplication
No module duplication and/or fragmentation.
Master Branch
Yes: Follows the guidelines for master branch.
Licensing
[Yes: Follows / No: Does not follow] the licensing requirements.
3rd party assets/code
Yes: Follows the guidelines for 3rd party assets/code.
README.txt/README.md
Yes: Follows the guidelines for in-project documentation and/or the README Template.
Code long/complex enough for review
Yes: Follows the guidelines for project length and complexity.
Secure code
In line no 130 of prepopulatedfields.install file directly used sql query which is not recommended
Coding style & Drupal API usage
List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.

This review uses the Project Application Review Template.

nitesh624’s picture

Sql queries can be more optimised...

nitesh624’s picture

Automated Review

[Best practice issues identified by pareview.sh FILE: /root/repos/pareviewsh/pareview_temp/prepopulatedfields.module

Note that perfect adherence to Drupal Coding Standard is NOT a reason to block an application, except for total disregard of them. However, modules should follow them as closely as possible.

Manual Review

Individual user account
Yes: Follows the guidelines for individual user accounts.
No duplication
No module duplication and/or fragmentation.
Master Branch
Yes: Follows the guidelines for master branch.
Licensing
[Yes: Follows / No: Does not follow] the licensing requirements.
3rd party assets/code
Yes: Follows the guidelines for 3rd party assets/code.
README.txt/README.md
Yes: Follows the guidelines for in-project documentation and/or the README Template.
Code long/complex enough for review
Yes: Follows the guidelines for project length and complexity.
Secure code
In line no 130 of prepopulatedfields.install file directly used sql query which is not recommended
Coding style & Drupal API usage
List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.

This review uses the Project Application Review Template.

dsvoboda’s picture

@nitesh624 I've removed the unnecessary default sort order on my select queries. Any other ideas on how you would optimize the queries? They seem pretty straightforward.

Thanks!

Satyam Upadhyay’s picture

Hi @dsvoboda,

Firstly you should fix https://pareview.sh/node/2979 and i gone through your module there i found some issue like this:

  • In hook_help you are exceeding Character Limit that should not exceed from 80 characters per line
  • Here you can see you are using $$ in $element[$delta] = array('#markup' => $$filtered_value); and i think this should $element[$delta] = array('#markup' => $filtered_value); fix this
    /**
     * Implements hook_field_formatter_view().
     */
    function prepopulatedfields_field_formatter_view($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
      $element = array();
      switch ($display['type']) {
        case 'prepopulatedfields_formatter':
          foreach ($items as $delta => $item) {
            if (isset($item['value'])) {
              $filtered_value = filter_xss_admin($item['value']);
              $element[$delta] = array('#markup' => $$filtered_value);
            }
          }
          break;
      }
      return $element;
    }

Regards
Satyam

Satyam Upadhyay’s picture

Status: Needs review » Needs work

Hi @dsvoboda,

Sorry in my previous comment https://www.drupal.org/project/projectapplications/issues/2617672#commen... i could not update the status

Firstly you should fix https://pareview.sh/node/2979 and i gone through your module there i found some issue like this:

  • In hook_help you are exceeding Character Limit that should not exceed from 80 characters per line
  • Here you can see you are using $$ in $element[$delta] = array('#markup' => $$filtered_value); and i think this should $element[$delta] = array('#markup' => $filtered_value); fix this
    /**
     * Implements hook_field_formatter_view().
     */
    function prepopulatedfields_field_formatter_view($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
      $element = array();
      switch ($display['type']) {
        case 'prepopulatedfields_formatter':
          foreach ($items as $delta => $item) {
            if (isset($item['value'])) {
              $filtered_value = filter_xss_admin($item['value']);
              $element[$delta] = array('#markup' => $$filtered_value);
            }
          }
          break;
      }
      return $element;
    }

Regards
Satyam

dsvoboda’s picture

Status: Needs work » Needs review

@Satyam

I've removed the extra $ on line 165:

$element[$delta] = array('#markup' => $filtered_value);

The character length in the hook_help implementation shouldn't be an issue as there are many published modules that exceed 80 characters per line in their help section. This should not hold up approval of this module.

Thanks!

bkelly’s picture

Status: Needs review » Reviewed & tested by the community

Hi dsvoboda -

Looks good to me. I'm marking it RTBC.

Thanks for the contribution.

- Bill Kelly

apaderno’s picture

Assigned: Unassigned » apaderno
Status: Reviewed & tested by the community » Fixed

Thank you for your contribution!
I am going to update your account so you can opt into security advisory coverage now.
These are some recommended readings to help with excellent maintainership:

You can find more contributors chatting on the IRC #drupal-contribute channel. So, come hang out and stay involved.
Thank you, 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.

I thank all the dedicated reviewers as well.

apaderno’s picture

Status: Fixed » Closed (fixed)

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

apaderno’s picture

Status: Closed (fixed) » Fixed

I am giving credits to the users who participated in this issue.

Status: Fixed » Closed (fixed)

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