Problem/Motivation
I recently needed to alter the path provided in _addanother_node_add_path(), but couldn't without hacking the module. The commit message that added this function seems to hint at this ("which might get turned into a hook at a later time for better intergration"), but I didn't find anything in the issue queue that suggests progress on this front.
Proposed resolution
Implement drupal_alter() in _addanother_node_add_path(), passing &$path and &$node. This would allow folks to easily alter the path. Should also probably document this in an addanother.api.php file.
Remaining tasks
Review the attached patch and possibly commit it.
Thanks for the module!
Let me know if you'd appreciate any help maintaining it.
Comments
Comment #1
guschilds commentedComment #2
robin monks commentedRe-roll, needs tests.
Comment #3
robin monks commentedIncluding the whole patch is helpful.
Comment #4
robin monks commentedReviewed and appears included tests should cover this case well. I'm hesitant to include this in 7.x-2.x, since it feel like an edge-case -- I'm also unsure how best to implement it in 8.x-1.x, or of it would be a 7.x-only feature. Would love weigh-in from the community to help make this decision.
Comment #5
apotek commentedI just reviewed addanother-node-add-path-alter-2227547-3.patch
I don't see any issues at all with the code either in terms of style or function.
There is an interesting comment in the patch "be sure to check node access when doing so" which I perhaps would suggest means that a basic node access sanity check could be implemented by this module just in order to not be introducing security issues for people. <-- this is beyond the scope of this issue, but I thought it might be worth saying.
In any case, this looks good. Have been using this in production for a while now. Works.
Comment #6
robin monks commentedThanks! This patch will get rolled into a new release for this weekend.
Comment #8
Joel MMCC commentedIt’s not just an “edge case.” It’s mandatory for proper functionality to work with modules such as Group. Group presents its own “Add content or group type” menu at the top of its group landing pages, with altered URLs so that using those provides a parameter so that Group kicks in and assigns the newly created entity as belonging to that group.
So, for instance, if you’ve created several groups, and someone logs in as a Group Administrator or other sufficiently privileged member of one of them that’s, say, Group GID #2, and you’ve enabled content types of Article to be assigned to Groups and that logged-in user has the privileges to create Articles for that Group, that user will see an “Add Article” link on the landing page. Its URL would, instead of being the standard“…/node/add/article”, be “…/group/2/node/add/article”.
But at present, with the unpatched Add Another, if you’ve configured Articles to use that button, when the user goes to save the Article, s/he’s presented with the “Add Another Article” button as usual, but its link is “/node/add/article” so the subsequent article would not be assigned to the group, leading to potentially massive group integrity failure.
Does this patch allow parameters (such as the GID of the current group in this case) to be passed, as would be needed for proper Group integration? How would we go about specifying them, and passing them from the previous URL or other context? Tokens?
@Robin Manks, since you said over three months ago (2017-Apr-11) in Comment #6 that you were rolling this into a new release “this weekend,” yet even the latest -dev for the 7.x-2.x branch is dated 2016-Nov-21 as I type this, that that didn’t happen for whatever reason? Is this patch intended to be applied to that -dev? According to robot-generated Comment #7, the “latest patch” has failed testing (but the filename shown is that of the first patch, not the latest one). Is that the reason it wasn’t rolled into a new -dev or release?
Maybe another tactic would be useful for Group and similar module integration: have “Add Another” get its URL from the URL that was actually used to add the current node, instead of just assuming that it’s always “/node/type/add”.
Comment #9
Joel MMCC commentedOkay, I just applied the patch (in #3) in a local copy of the site, and it applied successfully. While I’m a bare novice at Drupal and little better at PHP in general (my prior web application development experience has largely been with ASP.NET / VB.NET which is very different), I did notice this code in the original which seems to almost do what I requested in my final paragraph in #8:
The patch inserted a short
drupal_alter('addanother_node_add_path', $path, $node);function call just before thereturn $path;commented as allowing other modules to alter the path.Apparently, this code almost does what is needed, except from what I can see it requires that the first argument (
arg(0)) of the path be “node” and the second be (arg(1)) be “add” for it to be recognized as a proper node creation path that some other module might use to pass additional variables. It assumes that other modules such as Group would do it as “/node/add/type/group/gid” or some such instead of “/group/gid/node/add/type” as it actually does.So it seems that all that’s needed here is to, instead of requiring “node” and “add” be args 0 and 1, respectively, that you simply test whether both are present in the list of args, regardless of which args.
In my research just now, I see that the use of
arg()is deprecated in D8 (probably removed entirely by now) and discouraged in D7. For now, I decided to change the only occurrences ofarg()to instead do$args = explode('/', current_path());and then do (for instance)if (in_array('node', $args) && in_array('add', $args)) {to test for the presence of URL arguments without being position-dependent.I tested this and it works just fine in the case of the “Save and add another” button on node creation, but does nothing for the “Add Another” tab in node viewing or editing (not that I expected it to since the “/group/gid” isn’t in the URL for viewing or editing — only for adding).
I’m not yet savvy enough with NetBeans 8.2 to roll a patch with these changes, but if you want I can just upload the “addanother.module” file with both my changes and the patch #3 of this thread applied.
Comment #10
Joel MMCC commentedHere are the exact changes I made in
addanother.module. First, to remove a usage of the deprecatedarg()function that didn’t directly affect my use case, I replaced Line #84 from this:if (arg(2) == "edit" &&to this:
But the key change is in the check for Adding a Node, which started in Line #316 (before the above change which adds a line, moving it down to Line #317), from this:
to this:
This not only removes the use of the deprecated
arg()function, but it also removes position dependency. It works if both “node” and “add” are elements in the path (delimited by slashes, of course), regardless of which elements or in what order! I tested this change and it works fine with Group.Comment #11
apotek commentedInquiring on current status of this issue. It looks like this was never merged in, and in any case, last official release of this module is from 2014. So this issue is still open?