I realise that it is a mock endpoint, but I don’t think that is relevant to the end user, since it’s the only source available.
pameeela → created an issue.
pameeela → created an issue.
larowlan → credited pameeela → .
Based on the latest comments, this is blocked on not having the data about when a module was last updated.
On the UX side, I am not sure. As a few have pointed out, the updated date is not necessarily useful. But there is already a sort for 'Newest', and I think recently updated is more useful than that. Perhaps once this becomes unblocked we could replace the Newest filter with this?
(I tried to find where the 'Newest' sort was added to see if there was any discussion but I couldn't find it.)
I'm not in favour of this change, mostly I agree with #6. A few people have pointed out that the meaning might be lost on the target audience, and I must admit even I was not fully aware of the 'full release' terminology. I knew what it meant, but I stopped and thought 'wait is that really what we call it?'
I also don't think the difference is all that meaningful in contrib, as every module maintainer has a seemingly different definition for what is alpha/beta/RC etc. I think it would be an easier sell if there were consistency. It is a long list of options, with honestly not that much distinction and therefore not that much value to the user.
Wrote up a whole response to this but realised that it only matters in the context of the existing modal. I have added a screenshot of that to the IS.
Short version: I think a one-liner is preferable, and there is somewhat of a precedent of using one liners in other docs → . It would save most people time, and can be pretty easily unpacked if someone needed to run one step without the other.
However, the current 'View commands' modal shows a description of each step as well as some basic troubleshooting for each. It might be tricky to merge these cleanly. Not impossible, but it would be more confusing.
So I think it's a question of saving some time vs possibly making it harder to follow if something goes wrong.
I think this is a really, really hard thing to covey with an icon! It is interesting that there are people strongly in favour of both. I don't see either one as being very indicative, and agree with #25 that the icon itself probably won't achieve much either way.
Coming into this issue I did not know what the blue check icon meant either, but looking at PB I was able to determine from the filters that it means 'Covered by a security policy'. However, given that this is also a default filter, I am not sure the icon is a good idea? It will add clutter to the UI, considering that every module will have it by default. So I guess the use case is someone who selects 'Show all'?
I think it would probably be better to add an icon if it's *not* actively maintained, as this is something to alert users to. Otherwise, nothing to see here. And I see now this was already suggested in #2!
Screenshot of the filter for reference:
As already noted, Drupal 9 is no longer supported. If this issue can be reproduced in Drupal 10 or 11. If more information is not provided within the next three months, this issue will be closed.
@Gauravvvv can you reproduce this in Drupal 10 or 11? If not, this issue will be closed as 9 is no longer supported.
If no info is provided within three months, this issue may be closed.
As already noted, Drupal 9 is no longer supported. If this issue can be reproduced in Drupal 10 or 11, please note this.
If more information is not provided within the next three months, this issue will be closed. Or if it cannot be reproduced outside of version 9, it will also be closed.
As already noted, Drupal 9 is no longer supported. If this issue can be reproduced in Drupal 10 or 11, please update the issue with steps to reproduce.
If more information is not provided within the next three months, this issue will be closed. Or if it cannot be reproduced outside of version 9, it will also be closed.
As already noted, Drupal 9 is no longer supported. If this issue can be reproduced in Drupal 10 or 11, please update the issue with steps to reproduce. The change will not be committed unless it is clear why the value would be null.
If more information is not provided within the next three months, this issue will be closed. Or if it cannot be reproduced outside of version 9, it will also be closed.
@DrupalDope are the issues related or duplicates? If they are duplicates, it is more likely to be resolved if all but one are closed, so that all work is being done toward the same resolution.
pameeela → created an issue.
pameeela → created an issue.
pameeela → created an issue.
Infinite scroll is certainly a good use case :)
I guess I just haven't come across designs for numbered search. I sure wish I could say I was implementing designs from teams with knowledge of Drupal, do those exist? LOL. Just lucky I guess!
Confirming it no longer occurs as of at least 10.1.x, wish it were possible to give credit to all those who participated in fixing this!
Marking this works as designed based on the previous comments.
I'd honestly be very interested to see a use case where it makes sense to start ordered, paged output back at 1 on
each subsequent page load.
I think I just consider each page distinct, but it sounds like you are considering them states of a single page.
I will concede I haven’t used the ordered list formatter very much in my 12+ years of Drupaling but just because it was not needed. I use the results summary far more often. Just anecdotal but could be it’s not widely used generally and that’s why there isn't much demand for this.
@quietone confirmed to add comments to new tests.
I have added a comment explaining the regex. Uncertain about adding a comment for the test as it's one among many and none of the others have comments (other than @todos that are.... a bit confusing anyway). Should we be adding a comment to new tests as a rule?
I think this is resolved, there are a number of changes to the page since this issue and I can see the following text:
After commits have been pushed to a branch in an issue fork, and you think the code is ready for review and testing, you can create a merge request. On the issue page, find the branch you have been working on in the issue fork area, and click “compare.” Login, if you aren't already, in gitlab / git.drupalcode.org. From there, you can review your changes and open the merge request.
Spam
@joshuasosa thanks for replying. I suppose that the real question is how do you propose to fix it? Would you say the fix is to shorten the URL for all users to accommodate this? That feels like a hard sell.
Marking this as postponed because Berdir asked for more info in #9 and the scenario was not explained.
The test only patch provided later passed, and the patch with fix failed. So I'm not sure it's established that this is a bug.
More info was provided here on the use case, I think this just needs a patch, if folks think this is worth doing. Perhaps it's a feature request though not a bug :)
No reply after >1 year so I will close this. If anyone believes this is a problem, please create a new issue with specific steps to reproduce.
Setting back to needs work, needs an MR and a test still.
I'm not sure whether something has changed, but I can't reproduce the HTML stripping here. If I have a field with HTML, it displays the same way whether it its own column or grouped.
Fields displayed in the same column:
<td headers="view-title-table-column--n_pwIg-AmyE" class="views-field views-field-title views-field-body">
<a href="/node/470" hreflang="en" data-once="views-ajax">Test with comments</a>
<p>Body text here with <strong>some HTML</strong>.</p>
<a href="/node/470/edit?destination=/admin/structure/views/view/duplicate_of_manage_corporate_active_requests/preview/page_1%3F_wrapper_format%3Ddrupal_ajax" hreflang="en" data-once="views-ajax">edit</a>
</td>Fields displayed in separate columns:
<td headers="view-title-table-column--N3fpHc6FMWU" class="views-field views-field-title">
<a href="/node/470" hreflang="en" data-once="views-ajax">Test with comments</a>
</td>
<td headers="view-body-table-column--Dxql8bimhMU" class="views-field views-field-body">
<p>Body text here with <strong>some HTML</strong>.</p>
</td>
<td headers="view-edit-node-table-column--8z0MW96QIvM" class="views-field views-field-edit-node">
<a href="/node/469/edit?destination=/admin/structure/views/view/duplicate_of_manage_corporate_active_requests/preview/page_1%3F_wrapper_format%3Ddrupal_ajax" hreflang="en" data-once="views-ajax">edit</a>
</td>If the OP or anyone else has info on how to reproduce, please update the issue summary with specific steps. If that is not provided, this issue may be closed after 3 months.
Added this as a new test rather than modifying the existing test, and reverted the initial fix. So this is currently a test-only change.
Made a MR with the updated test and initial fix just to confirm what @quietone said. So this still needs work, but it feels fixable by someone better at regex than me!
Based on the previously referenced discussion, and the lack of any follow up showing interest in this change, I'm going to close this one. My 2c: I have never questioned this behaviour and if anything have found it helpful, as others have pointed out, to show that someone did something wrong.
pameeela → made their first commit to this issue’s fork.
This feels like a feature request to me, and something that should be optional. It seems strange to have a page with an ordered list that starts from an arbitrary number? I don't think it's safe to assume that everyone using ordered lists would want it to work that way, which is also supported by the lack of activity on this issue in 15 years.
This is already fixed in 10+, so this issue only applied to 9.x which is no longer supported. So I'm closing this.
I was a bit unsure about the solution myself, in testing it seemed a bit odd to reply to an unpublished comment. I am not super clear on the use case for replying before approving.
If an admin replies to an unpublished comment, the reply is unpublished as well and it has to be approved separately (even if they have permission to comment without approval). This makes sense, but you can then approve it meaning you could have a published reply to an unpublished comment. And if the original comment is deleted rather than approved, the reply is also deleted. (Why would you reply to a comment you were going to delete ? Well, exactly. But also why wouldn't you just approve the comment before replying?)
Having said all that, the stakes here seem extremely low. But it makes more sense to me to hide the reply link until the comment is approved.
The reported issue of the entity ref view not displaying the title based on the relationship has been resolved, but it's worth noting this still wouldn't work as OP expects.
The view is querying a list of teams, and using relationships to get the player names, but the query is still for teams. So the entity ref being created would be to the team, not the player. What you would need to do is create a view of players, and filter that by team, in order to get the desired functionality.
Thanks for the MR! There are test fails that need to be looked at.
Seems this is still valid, needs an MR with the proposed fix.
Should this be split into two issues? One for the valid HTML and one for excluding markup from character count? I think the character count part of it can't really be called a bug since it is explicitly tested to work that way, meaning it is intentional behaviour. I do agree that it makes sense to exclude it but that seems like a feature request.
I also think this would need to be opt-in for existing sites because it will change what is displayed for some sites.
Updated IS to be a bit more clear.
Tested manually and this does solve the problem, admins can reply to unpublished comments with the patch.
Before:
After:
Nothing has been provided to indicate this is a core bug, sounds like a misconfiguration issue, so I am updating this to a support request. No activity lately so can probably close if no further updates in the next few months.
This is fixed now:
Moving this to Bartik project since OP says it is only in that theme. However I don't understand the issue, it needs steps to reproduce.
Updating title and IS for clarity but still need steps to reproduce I think.
Updating title to reflect that there is no error from what I can see. Not sure if I have missed something.
Closed 🐛 Views Exposed form option of Remember the last selection is not working for multiple options Closed: cannot reproduce
I've tried to reproduce this, but I'm not getting the error that was originally reported. In the screencast provided, there is no error visible but I'm not seeing an error in the logs either. It does just fail silently but I don't see why this is a use case to support? Can we close this if there is no error?
I am not able to reproduce this on a fresh install:
Later comments suggest the issue is intermittent, in which case I think that should be a new issue with more information and clear steps, as that is not the same as the initial report. So I will close this issue, please create a new issue even if you are seeing something similar as it will avoid confusion.
Ah very cool! I missed that detail in the issue summary that it was building on an existing contrib module. It looks awesome!
Updated IS to make the use case a bit more clear, but it probably still needs further updates.
Discussing in Slack we are not sure this is a bug, as even the OP concedes.
Looked at this for Bug Smash triage, but I can't work out how to reproduce the issue. If anyone is facing this on their current D10 site could you please update the issue summary with specific steps to reproduce → ?
Closing this issue as no steps to reproduce were ever provided, and it seems something is going wrong rather than being broken.
If anyone is able to reproduce the issue on a fresh install, please create a new issue with clear steps to reproduce, starting with 'Install Drupal'.
Sounds like a follow up task :P
pameeela → created an issue.
pameeela → created an issue.
Needs more specific steps to reproduce. Could this be a duplicate of 🐛 Installing a module causes translations to be overwritten Fixed ?
I have been thinking about this and I really don't think it's a bug. It was built this way intentionally and I don't think it's broken, but it could be improved. So I've updated it to a feature request.
No one besides the OP has ever raised this, and although several people have noted the report's utility, none have noted any concerns with the current permission setup. This isn't that surprising because the report is really only useful to site admins who are reviewing the sites content model.
I have used it a handful of times to try to get a handle on a site’s content model, probably in mapping out a migration or rebuild. If you aren’t familiar with the site and it has a lot of paragraph types for example, it can give you an idea what is being used where. That’s especially true if there are nested paragraphs.
There are probably better ways to do it though, and I can’t say I would be particularly bothered if it were removed.
Back to needs review, I think the choices are either:
- Commit as a simple permissions change, noting that it would affect existing sites. I think the impact is mitigated by the fact that someone who didn't have view reports access would be unlikely to know about the report since they would not have the reports page in the toolbar.
- Create a new permission for this report and add it for users who previously had 'Administer content types'
- Won't fix?
Moving this to needs work so I can figure out how this permission change would affect existing sites. I assumed that anyone who used this report already had 'view site reports' but the test indicates otherwise.
Adds another option so the instructions match the download page. Removed the output of the help command as it takes up a lot of space. Updated some of the commands that were incorrect.
It might be an option to consider an initial dashboard that shows various things based on permissions only, and otherwise isn't customisable. Tailored ones per persona are obviously better, but the current state of seeing /user is really bad. So this could be a two-phased approach with the first one being the same for all and later versions being customisable.
Wordpress and Joomla provide standard dashboards and they're not perfect, but still better.
Or maybe this is a separate task to create a nicer destination for login? Since it seems based on #18 this has expanded a bit beyond just the login use case.
So there was a test of the page itself, which failed because the test user was only granted specific permissions. Anyway good news that there sort of already is a test that failed. Updated, should be green now.
Made a follow up to remove it. 📌 Consider removing the 'Field list' reports Active