Updated peer reviewed article to new standard. #258
No reviewers
Labels
No labels
Component: User interface
Component: Wymeditor
Help wanted
Level: Difficult
Level: Easy
Level: Moderate
Pagetype: Festival
Pagetype: Mailinglist
Pagetype: Peer reviewed article
Pagetype: Text
Privacy GDPR AVG
status: has conflicts
Status: Needs changes
Status: Needs discussion
Status: Needs review
Status: Ready to merge
Status: Waiting for response
Type: Bug
Type: Enhancement
Type: Question
Usecase: De Stadsbron
Usecase: Koppelting
Usecase: MeetjeStad
Value: Coders
Value: Security
Value: Users
Value: Visitors
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
harmen/hypha!258
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "newtext"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I've reviewed up to
approveAction(). Nothing blocking so far, just some thoughts for improvements. I'll try to review the rest ASAP.Possible improvement: Should status change and approve need their own path? Or would it make more sense to just use a null path for them?
@ -468,0 +235,4 @@$discussions = $this->xml->find(self::FIELD_NAME_DISCUSSION_PUBLIC_CONTAINER);/** @var NodeList $commentCollection */$commentCollection = $discussions->findXPath('.//' . self::FIELD_NAME_DISCUSSION_COMMENT . '[not(@pending="1")]');I wonder if this should use
->children()rather than->getHtml(). AFAICSgetHtml()serializes into a HTML string, which is not really needed. Same applies for similar lines below.I was a bit confused by the
appendChildrenToDiscussionsDomElementmethod, I somehow expected it to add$discussionsDomElementsomewhere into the HTML DOM (though I now see that happens in the next line). In reality, the method only adds existing comments to the container. Perhaps it should be named differently?addDiscussionsToElement, orfillDiscussionsContaineror something like that?This setHTML call seems a bit opaque. I think the
trueis intended to wikify, but that should probably be commented, or perhaps use a newsetWikifiedHtml()method? Also, it seems thatsetHTML()with two arguments was added byDocPage, which is deleted by this commit? Does this code actually work right now?Maybe a
$request->getArgument()would be better? That emphasizes the special nature of thisargumentargument.@ -1022,2 +761,3 @@/*** @param DocPage $discussion* Creates a discussion DOM element.*This uses
$list, which is reused below, but they are essentially distinct variables (since either this if, or the below loop runs but never both). Maybe using different variable names helps to clarify the distinctness of these variables.Alternatively, the variable could be removed entirely by using the (recently added)
appendTo()from DomWrapper:Or slightly shorter:
(note that
createcan also accept more complete HTML snippets, unlikecreateElement). Perhaps theulabove must be<ul>forcreateto accept it, but I think justulshould also work.One further variation would be:
But I'm not sure if that's really more readable (it does subtly fix escaping issues, though, and reduces the amount of HTML parsing needed). Might be better when the
lielement is put in a separate variable perhaps.@ -1029,0 +802,4 @@$comment = $this->xml->createElement(self::FIELD_NAME_DISCUSSION_COMMENT);$comment->generateId();$discussion->append($comment);The comment does not match the variablename (existing problem, though).
And finished the review :-)
I left quite some more remarks, but nothing really critical I believe. Most of my comments are easy fixes, so I would suggest fixing those before merging. Some comments are a bit more involved, so feel free to leave these for later (or fix them right away if you feel like that, of course). If you need input on anything specific, just tag me in a comment and I'll have another look.
Once you have made another pass over this and are happy with it, I suggest we merge it, put it on test.destadsbron.nl and do some more elaborate testing there (also with existing content).
Maybe rename this to
CMD_START_DISCUSSION?@ -468,0 +235,4 @@$discussions = $this->xml->find(self::FIELD_NAME_DISCUSSION_PUBLIC_CONTAINER);/** @var NodeList $commentCollection */$commentCollection = $discussions->findXPath('.//' . self::FIELD_NAME_DISCUSSION_COMMENT . '[not(@pending="1")]');I think this
$typevariable should be validated/checked.@ -482,0 +604,4 @@$form = $this->createCommentForm($type, $request->getPostData(), $discussion);if (!$review && !isUser()) {$form->validateRequiredField(self::FIELD_NAME_DISCUSSION_COMMENTER_NAME . $dataFieldSuffix);$form->validateRequiredField(self::FIELD_NAME_DISCUSSION_COMMENTER_EMAIL . $dataFieldSuffix);This should escape/encode the code before inserting into Xpath. There is a function available here, you should probably pull that commit into this PR and use it. Alternatively, we can leave this for now (I've created https://github.com/PlanBCode/hypha/issues/263 for the issue in general).
@ -1022,2 +761,3 @@/*** @param DocPage $discussion* Creates a discussion DOM element.*Maybe it would be clearer to rename this function to
createStartDiscussionForm(to better distinguish it from thecreateDiscussionCommentForm)?This variable and CSS class talk about "review", but this code also handles public comments.
This comment is no longer accurate.
I wonder if this query should be limited to the list of discussions. AFAICS you can now pass an id of a comment or approve element, and then the XML structure will be messed up (which is possibly a DoS vulnerability or worse). This might be out of scope for this PR though (maybe just add a TODO comment in the code).
Note that this also holds for other calls to
getElementByIdelsewhere.This should probably read "Creates a discussion DOM element inside the given container and fills it with data from the submitted form passed."
All this stuff about blocking and closed, shouldn't that be only for review discussions?
This should probably read "Creates a comment DOM element inside the given discussion and fills it with data from the submitted form passed."
This should probably read "Creates the approves DOM element and fills it with a list of previous approvals."
This is not terribly easy to read. Maybe using usort on
$discussionsbefore looping is cleaner and easier to understand?Huh? When is $comments ever an array here? It seems this is a remnant from when DocPage::getChildren() was used which returns a nested array of children sorted by tagname or something like that. Now this uses the regular
children()method, so I think this check, as well as the loop over$commentsbelow can be removed. Additionally,$firstComment = trueshould be moved up one loop then.Maybe add "(when all comments are still pending)" here?
I wonder if this should/could use the same interpolate / replace function as translations. Might be overkill, though. Maybe at some point an URL-specific interpolation / building function might make sense (that can also handle urlencoding and/or decoding when needed)
This probably needs
nl2br.@ -1029,0 +802,4 @@$comment = $this->xml->createElement(self::FIELD_NAME_DISCUSSION_COMMENT);$comment->generateId();$discussion->append($comment);fixed it
removed the paths
@ -468,0 +235,4 @@$discussions = $this->xml->find(self::FIELD_NAME_DISCUSSION_PUBLIC_CONTAINER);/** @var NodeList $commentCollection */$commentCollection = $discussions->findXPath('.//' . self::FIELD_NAME_DISCUSSION_COMMENT . '[not(@pending="1")]');done
@ -1022,2 +761,3 @@/*** @param DocPage $discussion* Creates a discussion DOM element.*Found out that
text()does not returnself.Implemented like:
@ -468,0 +235,4 @@$discussions = $this->xml->find(self::FIELD_NAME_DISCUSSION_PUBLIC_CONTAINER);/** @var NodeList $commentCollection */$commentCollection = $discussions->findXPath('.//' . self::FIELD_NAME_DISCUSSION_COMMENT . '[not(@pending="1")]');changed name to
fillDiscussionsContainer@ -468,0 +235,4 @@$discussions = $this->xml->find(self::FIELD_NAME_DISCUSSION_PUBLIC_CONTAINER);/** @var NodeList $commentCollection */$commentCollection = $discussions->findXPath('.//' . self::FIELD_NAME_DISCUSSION_COMMENT . '[not(@pending="1")]');fixed
@ -468,0 +235,4 @@$discussions = $this->xml->find(self::FIELD_NAME_DISCUSSION_PUBLIC_CONTAINER);/** @var NodeList $commentCollection */$commentCollection = $discussions->findXPath('.//' . self::FIELD_NAME_DISCUSSION_COMMENT . '[not(@pending="1")]');made improvements
@ -468,0 +235,4 @@$discussions = $this->xml->find(self::FIELD_NAME_DISCUSSION_PUBLIC_CONTAINER);/** @var NodeList $commentCollection */$commentCollection = $discussions->findXPath('.//' . self::FIELD_NAME_DISCUSSION_COMMENT . '[not(@pending="1")]');done
@ -1022,2 +761,3 @@/*** @param DocPage $discussion* Creates a discussion DOM element.*done
@matthijskooijman, we should create a separate issue for this. I regard this as "out of scope" for now.
Done, #270
@ -482,0 +604,4 @@$form = $this->createCommentForm($type, $request->getPostData(), $discussion);if (!$review && !isUser()) {$form->validateRequiredField(self::FIELD_NAME_DISCUSSION_COMMENTER_NAME . $dataFieldSuffix);$form->validateRequiredField(self::FIELD_NAME_DISCUSSION_COMMENTER_EMAIL . $dataFieldSuffix);done
current text covers all (future) cases
@ -1022,2 +761,3 @@/*** @param DocPage $discussion* Creates a discussion DOM element.*good catch!
out of scope for this pull request
Renamed to
CMD_DISCUSSION_STARTEDdone
@ -482,0 +659,4 @@$userId = $this->O_O->getUser()->getAttribute('id');$blocking = (bool)$discussion->attr(self::FIELD_NAME_DISCUSSION_BLOCKING);Maybe this should be:
Then both sides are a bit more consistent with each other? If so, we should change that in text as well (I'll do that, then).
Maybe also use the same syntax (dash-separated parts rather than camelCase) for the other variables?
@ -482,0 +659,4 @@$userId = $this->O_O->getUser()->getAttribute('id');$blocking = (bool)$discussion->attr(self::FIELD_NAME_DISCUSSION_BLOCKING);done
I've removed the textpage commits from this PR, since they are essentially unrelated and part of #272.
I've extracted the
xpath_encodefunction into a separate commit and force-pushed that.I've done another fairly shallow review of the code and some quick testing, and it seems good for merging. Shall we just merge this as-is now, or maybe first put it on test.destadsbron.nl first? @laurensmartina, did you already look at publishing this on test?