__group__,ticket,summary,reporter,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Old Tickets,7426,Add minimum word count for description,benniledl,Photo Directory,,normal,,,defect (bug),new,has-patch,2024-01-29T12:48:00Z,2024-03-20T01:40:05Z,"Hey, often the photo descriptions are not detailed enough, the moderator team has much work to do with writing a detailed description for photos that they know little about because they are not their own.
In this pr I added a minimum number of words for the description.",benniledl
Old Tickets,7429,In Responsive mobile size the text is overlapping,pitamdey,General,,lowest,,,defect (bug),new,,2024-02-01T13:19:10Z,2024-02-01T13:19:10Z,"URL : https://wordpress.org/support/topic/i-have-a-problem-to-access-to-wp-admin-network-in-wordpress-multisite/#new-post
In the Responsive screen (375 px screen size ) the text is overlapping
I have attached screenshot of the issue for better understanding ",pitamdey
Old Tickets,7433,Consider removing logged in block when viewing support forums.,dufresnesteven,Support Forums,,normal,,,enhancement,new,,2024-02-02T01:41:53Z,2024-02-08T04:45:41Z,"I'm not sure why we need to include a block in the support forum that lets me know I'm logged in and helps me log out.
The top admin bar has the same functionality.
Do we need it?",dufresnesteven
Old Tickets,7434,Improve Support Forum side bar.,dufresnesteven,Support Forums,,normal,,,enhancement,new,,2024-02-02T02:11:03Z,2024-02-08T04:45:48Z,"As a user arriving from the plugin directory looking for support or to evaluate a plugin's support history, I am presented with a confusing and at first glance, redundant set of links in the support forum sidebar on the right. For example, visit any plugin support forum root. (ie: https://wordpress.org/support/plugin/contact-form-7/)
Here is a textual representation of the sidebar:
**Top Section**
Plugin Image
Plugin Name
Frequently Asked Questions
Support Threads
Active Topics
Unresolved Topics
Reviews
...
**Bottom Section**
Views
Topics with no replies
Non-support topics
Resolved topics
Unresolved topics
All topics
**Observations**
**Top Section**
- ""Support Threads"" and ""Active Topics"" display a very similar list except ""Active topics"" doesn't show pinned results. Do we need both?
**Bottom Section**
- As a user seeking help or evaluating the plugin, I don't see how the ""View"" section provides any value. All the links navigate me away from this plugin and drop me in generic forums.
**Solution**
Don't show the view section when viewing plugins. If we must, only for admins.
",dufresnesteven
Old Tickets,7435,Extend Support & Forum threads content max-width to 1160px to match developer & documentation,dufresnesteven,Support Forums,,normal,,,enhancement,new,,2024-02-02T02:42:17Z,2024-02-08T04:45:54Z,"Support thread page content is restricted to `960px` which is based on older browser specs and makes some information hard to read. The time string in the forum table for example.
The rest of our documentation and developer-related themes use `1160px` as the default content width. We should do that to the support forums for an immediate upgrade to legibility and would bring a more consistent look and feel.
Changes:
- Update it for the content.
- Update it for the sub-navigation.
- I would also like to see us apply the new styles to the sub nav similar to what we have done to the profiles page via https://meta.trac.wordpress.org/ticket/7175. I can open a new ticket for that if necessary.
- Reduce the width of the sidebar is it will be longer than necessary.",dufresnesteven
Old Tickets,7440,Category to Planet.WordPress.org not working,courane01,Planet (planet.wordpress.org),,normal,,,defect (bug),new,,2024-02-05T15:31:33Z,2024-02-06T00:20:01Z,"https://poststatus.com/planet/feed does not seem to be appearing on https://planet.wordpress.org.
Human readable articles https://poststatus.com/category/planet/",courane01
Old Tickets,7442,GitHub PR images not displayed,dd32,Trac,,normal,,,defect (bug),new,,2024-02-06T02:57:19Z,2024-02-15T03:21:07Z,"As of a few weeks ago (at least) GitHub images in PRs are no longer being displayed on trac.
For example:
https://core.trac.wordpress.org/ticket/57600#comment:17
In that example, I've edited the first image listed from proxying via Jetpack Photon to using the image URL directly.
This appears to be that the GitHub API is blocking Jetpack Photon from re-publishing the images.
For example; https://i0.wp.com/github.com/WordPress/wordpress-develop/assets/519727/33fc163b-7526-4a7c-87c3-57e9214b8033 gives a 403 response.
Looking at the Photon source, https://code.trac.wordpress.org/browser/photon/index.php#L294 we can see that the specific 403 presented means the upstream returned a 403 too.
'''Why do we proxy images via Photon?'''
Photon is in front of GitHub primarily as it doesn't expose CORS headers. Why do we need CORS headers? Well, because we have `` such that the embedded content isn't requested with credentials and doesn't attempt to display any external-url basic authentication prompts.
Realistically, we can probably remove the usage of Photon here, by removing the use of `crossorigin=anonymous` for github.com, as we trust github not to present a HTTP Authorization request, and as the content is within an `` element there shouldn't be any possibility of malicious content within a GitHub attachment being able to be access the trac page DOM.
I'm not 100% positive on that though.
Trac does offer a safe list of URIs that should not get crossorigin=false attributes, we can possibly just add GitHub to that.
upstream refs: https://trac.edgewall.org/changeset/15894 + https://trac.edgewall.org/changeset/16025",dd32
Old Tickets,7446,Improved Search Bar Filter Design in responsive,pitamdey,General,,lowest,,,enhancement,new,,2024-02-07T04:52:48Z,2024-02-22T05:29:38Z,"URL : https://wordpress.tv/?s=
This is just for an improvement.In Responsive screen size under 768px when we toggle the filter option the icon on it should also toggle like an upward arrow and downward arrow
I have attached screenshot for better understanding",pitamdey
Old Tickets,7448,Plugins: Consider combining screenshot and banner.,dufresnesteven,Plugin Directory,,normal,,,defect (bug),new,,2024-02-07T06:51:50Z,2024-02-07T10:03:14Z,"In looking through the meta ticket list... I don't see anything related to why we chose a banner for the first visual of the page and a screenshot section below. ( Maybe it's a legacy problem where the banner dimensions are not suitable for a rotatable screenshot preview?)
The banner has become important in communicating plugin quality which slants the playing field towards commercially driven plugins and teams who have access to design teams.
It's a common paradigm to show the banner with screenshots prominently on the page in the same interaction zone and we should do the same.
Smaller plugin developers could focus on creating good, useful screenshots to communicate the value of their plugin as opposed to forcing together a banner image with their limited graphic design skills (speaking for myself). I mean, the counter argument is that they could provide a screenshot as their banner but with the way the experience is configured, that would be unpredictable.",dufresnesteven
Old Tickets,7452,Plugins: Find a better way to surface plugin features.,dufresnesteven,Plugin Directory,,normal,,,enhancement,new,,2024-02-08T04:31:58Z,2024-02-08T04:39:31Z,"**High-level Problem**:
User feedback suggests that the plugin directory doesn't provide a robust enough experience for users searching for plugins.
So, we probably have to do two things to improve this:
1. Provide better search results and filtering in the directory (enabling this feature for API consumers as well).
2. Better highlight plugin features and reliability indicators.
**Purpose**:
Users have identified that they choose plugins based on the following criteria:
- Does the plugin have the features they are looking for?
- Is the plugin reliable?
While we definitely need to address all the things mentioned above, the purpose of this ticket is to explore ways to help users identify which features a plugin supports.
**What currently exists?**
Users currently have to read the plugin readme to identify the features. There aren't any guidelines on including features in the readme but seasoned plugin authors in general know how to craft user & search friendly readme's and they typically provide an easy to identify list of features.
The way the search algorithm works, it promotes the use of this feature list indirectly by matching it to user keyword searches but it's as simple as that. It doesn't know that it's a feature of the plugin. So if a user searches for the word ""map"", it would return plugins that use that word in a totally different context, like mapping authors to posts. I'll admit that example also unpacks a lot of different shortcomings, like bloated readmes, keyword stuffed plugin titles and lack of categorization but I think we can talk about this feature without talking about all those things.
**Discussion?**
What can we do to highlight features for plugins that we could use to provide better results and display them more prominently to users?
**What about plugin previews?**
Plugin previews are being worked on in https://meta.trac.wordpress.org/ticket/7251.
These previews will provide a way to ""test"" plugin features and see them in action, but that would be used to support ideas we come up with here. (At least in how we are currently thinking about previews).
Resources:
- Plugin Readme: https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/
",dufresnesteven
Old Tickets,7455,"Confusing experience when I click ""forums"" in the main site navigation",dufresnesteven,Support Forums,,normal,,,enhancement,new,,2024-02-08T05:04:57Z,2024-02-08T05:04:57Z,"I couldn't find the context and therefore don't understand the reasoning, but I'm confused by our support/forum flow.
From the homepage, I open the menu and click ""forums"". I land on a page that says ""Support"", with a missable subnavigation indicator of ""forums"". The first information I see is not related to forums, it is general support information.
The top section is confusing because I clearly indicated that I want to see forums.
**Welcome to Support**
This takes me away from forums and shows me guidelines.
**Documentation**
This takes me away from forums completely.
**Get Involved**
Doesn't relate to my task of viewing forums.
I understand how we probably got here and this page makes sense if the link in the navigation is ""Support"" but since it's ""forums"" my expectations I have for what I'm about to see is completely different.
Assuming we are going to keep ""Forums"" in the navigation.....
I think the easy fix is to move the top section down below the forums. Additionally we should change ""Support"" as the subnav title to ""Forums"". The only other content on this sub site is relating to contributing in the forums.
",dufresnesteven
Old Tickets,7457,Active Menu issue in mobile view,harsh175,General,,normal,,,defect (bug),new,,2024-02-09T08:51:02Z,2024-02-09T08:51:02Z,"In mobile view when the user visits any subpage of the About page, then it confuses the user which page is activated.
https://www.awesomescreenshot.com/video/24798690?key=8dcedfbb8249edf654a2708508b728bc
css
{{{
.wp-block-navigation:not([class*=has-text-decoration]) a:focus {
text-decoration-line: none;
}
.wp-block-navigation .current-menu-item > a{
font-weight: 700;
text-decoration-line: underline;
}
}}}
",harsh175
Old Tickets,7459,Enabling #enable-experimental-web-platform-features in Chromium breaks custom queries,westonruter,Trac,,lowest,,,defect (bug),new,,2024-02-09T18:11:29Z,2024-02-12T00:40:16Z,"With the `#enable-experimental-web-platform-features` flag enabled in Chromium (both Chrome and Edge), attempting to do create a Custom Query (such as by Summary, Description, or Reporter) results in an error in the console:
> Form submission failed, as the ')
This was also reported [https://trac.edgewall.org/ticket/13141 upstream] to Trac directly 5 years ago, but closed as a Chrome-specific bug. Nevertheless, it seems this might not be the case as the [https://issues.chromium.org/issues/41450238 Chromium ticket] was closed as wontfix.
I was able to fix the problem locally via [https://developer.chrome.com/docs/devtools/overrides Local Overrides] in Chrome DevTools. I modified https://s.w.org/style/trac/common/js/query.js?v=216 by simply supplying the missing ``:
{{{
44c44
< var e = $($.htmlFormat('