Project's page

https://www.drupal.org/sandbox/asiby/2653566

Git clone command

git clone http://git.drupal.org/sandbox/asiby/2653566.git symlink

Some modules I manually reviewed:


INTRODUCTION
-------------

Symlink is a module that solves a problem that many people are experiencing when they add more then one menu items
pointing to the same internal link. This will cause the menu trail to act erratically.

Symlink will create a custom content type that will render any node it's referencing. That way, from the Drupal's point
of view, this will be a completely different node every time even if it is always pointing to the same link, and the
menu trail and breadcrumb will work in a more predictable fashion.

THE PROBLEM
-----------

Imagine that you have an amazing tool available in your Drupal site at the address http://your_site/amazing_tool.
And imagine that the site have several sections, and that each section needs to have a link to the amazing tool in its
menu structure. This could result into a structure looking similar to the following ...

Section 1
├── Item 1.1
│ └── Item 1.1.1
├── Link to the amazing tool <----- First instance


Section 2
├── Item 2.1
│ │
│ ├── Item 2.2.1
│ ├── Item 2.2.2
│ └── Item 2.2.3
├── Link to the amazing tool <----- Second instance


Section 3
├── Item 3.1
│ ├── Item 3.2.1
│ ├── Item 3.2.2
│ └── Item 3.2.3
└── Link to the amazing tool <----- Third instance

Now the big problem here is that only one of the menu items labelled "Link to the amazing tool" will actually work.
What seems to be happening is that because the target of all these 3 links will be http://your_site/amazing_tool,
if you try to navigate to one of them, Drupal will stop searching as soon as it finds a match. I think that this
will end up being the link that has the lowest mlid (menu link DB identifier). That's basically the first of the 3 items
that was created. So if someone was already visiting a page under Section 2, then a click on the second instance of the
link to the amazing tool will take them to the tool alright, but the menu trail and the breadcrumb will show that they
are now in Section 1.

THE SOLUTION
------------

The symlink module fixes this issue by providing the following features:

1. Symlinks are nodes.
2. When viewing a node, the Symlink module will display a tab for adding a new symlink.
3. When viewing the symlink, the "Add symlink" tab will be visible since symlinks are also nodes
4. Additional symlinks can be created from other symlink, but they will always reference the original target node.
5. A permission called "create symlink content" let's you control who can create a symlink.
6. The symlink module is available for both Drupal 7 (D7) and Drupal 8 (D8)
7. Contextual links still work. This let's you edit the original node.

CommentFileSizeAuthor
#21 1.jpg54.27 KBremkor
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

asiby created an issue. See original summary.

asiby’s picture

Issue summary: View changes
asiby’s picture

Issue summary: View changes
asiby’s picture

Title: [D7] Symlink » [D8] Symlink
Project: Symlink » Drupal.org security advisory coverage applications
Component: Code » module
Status: Active » Needs review
PA robot’s picture

Issue summary: View changes
Status: Needs review » Needs work

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

Fixed the git clone URL in the issue summary for non-maintainer users.

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.

asiby’s picture

Issue summary: View changes
Status: Needs work » Needs review

Fixed all the wrapping to 80 colomns in README.txt

asiby’s picture

Issue summary: View changes
asiby’s picture

Issue summary: View changes
asiby’s picture

Issue summary: View changes
asiby’s picture

Issue summary: View changes
asiby’s picture

Issue tags: +Code Review Bonus
asiby’s picture

Issue tags: -Code Review Bonus +PAreview: review bonus
asiby’s picture

Issue summary: View changes
asiby’s picture

Title: [D8] Symlink » [D7] Symlink
Issue summary: View changes
asiby’s picture

Issue summary: View changes
asiby’s picture

asiby’s picture

Issue summary: View changes
asiby’s picture

Issue summary: View changes
remkor’s picture

I have downloaded this module, it worked good when I added symlink to test node. But when i tried to view that node through symlink this warning showed up:
Warning: Creating default object from empty value in symlink_node_view() (line 95 of /home/www/test/d7-symlink/sites/default/modules/symlink/symlink.module).
It seems that redundant node title wasn't properly removed, but when i changed line 95 from
$output['body']['#object']->title = '';
to
$output['#node']->title = '';
warning didn't showed up again (node title also).

asiby’s picture

Thanks for reviewing my module.

Excellent finding. I fixed it as you suggested.

Do you mind telling me which version of Drupal you are using? Even though your finding and the related fix make perfect sense, I couldn't reproduce it. And this line that you are referring to is line #118 now. You may need need to pull a newer version from Git.

Thanks.

remkor’s picture

FileSize
54.27 KB

To test your module I have used Drupal 7.43 with Coder and Devel modules enabled.
I have pulled the newest version from git, no warnings showing up now. But still I see change at line #95 not #118, maybe I'm doing something wrong.

asiby’s picture

You are right. Strange though. It's probably my IDE playing tricks. I had recently enabled the auto wrapping of the code at 80 columns. That's probably a bad idea.

OK then. The important is that the bug is now fixed.

Thanks for your review. Do but you think that this is RTBC?

bapi_22’s picture

Status: Needs review » Needs work

Hi asiby,

Your module looks good. See below comments which needs a little work:

1. As you are creating the Symlink for any node, So in the link field, the value should be auto populated and should not be editable by user.
2. If any User edit any Symlink content and fill the link field value with its self nid, Its breaking the site when you visit the page.

So there should be a validation for that.

asiby’s picture

Doh!!!

Good point. I missed that. I will lock the link to make it non editable.

Thanks pal.

remkor’s picture

User input in symlink field is not validated properly. I can enter any number (nid of non-existing node), any alphanumeric string and it will be saved. Validate the user input by checking if nid is number and is pointing to existing node.
Making field not editable by user is not enough, it's easy to circumvent.

asiby’s picture

Status: Needs work » Needs review

Thanks again guys. This is amazing. It show how important this review process is. People can always discover things about anything.

I have added a validation process for the symlink. Please do give it another try.

asiby’s picture

Issue summary: View changes
asiby’s picture

Issue summary: View changes
remkor’s picture

When I add symlink directly by accessing /node/add/symlink, not by "Add symlink" tab node/add/symlink?symlink=, link field shouldn't be disabled.
In function symlink_node_validate you just set error An invalid value was given for the Link field. without any validation, consequently I can't add any symlink anymore ...

/**
 * Implements hook_node_validate().
 */
function symlink_node_validate($node, $form, &$form_state) {
  if ($node->type != 'symlink') {
    return;
  }

  form_set_error('field_symlink', t('An invalid value was given for the Link field.'));
}
asiby’s picture

I see. In the initial plans, it wasn't planned to add symlinks that way. That's why it says in the road map that we will later allow using entity references. That way, people can decide to go really crazy with what they want to add a symlink for. I can enable the symlink now, but it will introduce too many things that are planned for the next major iterations. And it is let flexible to have to just type a node ID vs navigating to the node and clicking on the "Add a symlink" tab.

This means that I might have to later hide the symlink item in the node/add page so that people do not just use it as regular node/add/xyz pages.

Does that make sense?

asiby’s picture

I have fixed the validation. I had missed that part when I was staging the code to be committed.

remkor’s picture

Ok, so it would be good to add in function symlink_form_symlink_node_form_alter some message when this statement if ($symlink !== NULL) is false:

  // Attempt to pre-populate the fields only if value is passed in the symlink
  // query string.
  if ($symlink !== NULL) {
  }
  else {
    // Display some message ...
  }
asiby’s picture

That makes perfect sense. I have just added it. Thanks for the suggestion.

So now, when someone tries to use node/add/symlink, the message will tell them NAY!!! lol

...
    }
    else {
      drupal_set_message(t("The 'symlink' content type does not yet support the possibility to manually enter the
      link. Please navigate to the page you want to create the symlink for, and click on 'Add a symlink' when that
      tab is available."), 'status');
    }

Cheers

remkor’s picture

In file symlink.install, line 37:

file_put_contents('/tmp/TYPE.TXT', print_r($type, TRUE));

I think this is for debug and not needed now.
Besides that, it looks good.

asiby’s picture

True. I should be more careful with these things. It is removed from the code now.

remkor’s picture

Ok, let's mark this RTB and see what will happen ...

remkor’s picture

Status: Needs review » Reviewed & tested by the community
DamienMcKenna’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for your contribution, Abdoulaye!

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:

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.

asiby’s picture

Thanks a lot. I am proud to part of the Drupal community. I will do all the readings that you have suggested. I will also revisit the standards about version numbers before setup a first release for this module.

bapi_22’s picture

Hi Asiby,

Thank you for your contribution to Drupal.

For creating a content type in a module, the best practice is to implements hook_node_info().
after that your field instances should be attached to the content type in the .install file.

Any suggestions ??

asiby’s picture

Issue summary: View changes
asiby’s picture

Noted, thanks Bapi. Can you please report it at https://www.drupal.org/project/issues/2653566. The module status is now "Fixed" so we can move all the subsequent conversations to the module's issue queue, shall we?

I will definitely make a modification to implement Drupal's API properly. I had found the code in hook_install a little verbose. This will help making it shorter and cleaner. Thanks for the suggestion.

bapi_22’s picture

Thank you Asiby for following the coding standard of Drupal.
Good Suggestion, I am going to add it in the issue queue.

Thanks,

Status: Fixed » Closed (fixed)

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