Article comments: the reply form and buttons are children of the <ul> of comments
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- html, javascript, php
- Domain
- accessibility, frontend
Research direction
Start with peer_reviewed_article::buildDiscussionsHtml() and trace how it builds the discussion wrapper, comment list, reply form, and action button. Move the form and buttons to the wrapper after the list, then check rendered public comments and review discussions to confirm the <ul> contains only <li> elements; linked pull request #700 is already open.
Written by the indexing model from the issue text.
Description
The comments under an article are a <ul> with one <li> per comment. The form to reply, the button to send it, and in a review the button to close the discussion, are appended to that same <ul>:
<div class="public-comment-wrapper collapsed"><ul>
<li class="first-comment">…</li>
<form …>…</form>
<a class="button" …>Reageer</a>
</ul></div>
A <ul> may only hold <li> (and script-supporting elements). Screen readers announce the list with a wrong number of items, and axe reports list (WCAG 1.3.1).
On a test copy of a site, axe found it on every page with public comments, about 950 pages.
peer_reviewed_article::buildDiscussionsHtml() (the part that renders each discussion) calls $commentList->createChild('p'), $replyForm->appendTo($commentList) and $commentList->appendChild($this->makeDiscussionActionButton(…)).
Fix: append these to the wrapper <div> of the discussion, after the list. No script depends on the form being inside the list; the stylesheet of the default theme only styles ul and li inside the wrapper.
🤖 Generated with Claude Code
- Dominant language
- JavaScript
- Stars
- 5
- Forks
- 9
- Avg merge
- 18h 49m
- Merged PRs (30d)
- 13
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PlanBCode/hypha
-
Component: User interface Impact: Low Level: Easy Pagetype: Peer reviewed article Type: Bug Value: Visitors
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Impact: Medium Level: Easy Type: Bug Value: Users
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Impact: Low Level: Easy Pagetype: Festival Type: Bug Value: Coders
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Impact: Medium Level: Easy Pagetype: Mailinglist Type: Bug Value: Users
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
Maintainers usually reply within 1 day
-
Impact: Low Level: Easy Type: Bug Value: Coders
Difficulty 1/5 1-3 hours Newbie friendliness 85/100
PlanBCode/hypha#586 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
[ordering-review] workshop order graph: 1 confirmed ordering problem, 3 cycles are false positivesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
githubnext/gh-aw-workshop#5331 ·
Maintainers usually reply within 1 day
-
Remove: 21 SexturyOpenchannels:remove check:passed
Difficulty 1/5 Under an hour Newbie friendliness 65/100
Maintainers usually reply within 4 days
-
[vika] console keeps a stale "in progress" turn after a daemon restart mid-runPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
volcengine/OpenViking#7011 ·
Maintainers usually reply within 1 day
-
__VERSION__ within dist build is not replaced, causes missing version in XDM implementation detailsOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Issue: ready for confirmation Reported on 2.4.9 Triage: Dev.Experience
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
magento/magento2#41773 · 1 comment ·
Maintainers usually reply within 5 days