WordPress.org

Making WordPress.org

{5} Accepted, Active Tickets by Owner (Full Description) (26 matches)

List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.

DrewAPicture (3 matches)

Ticket Summary Component Milestone Type Created
Description
#620 developer.wordpress.org activity should appear on profiles Profiles enhancement 09/23/2014

Now that developer.wordpress.org is truly taking shape, it would be great if we could start thinking about how we can get contributor activity appearing on a person's profile.

So far we have the following activity:

  1. Contributions to the theme and plugin developer handbooks:

https://developer.wordpress.org/plugin/credits-2/ https://developer.wordpress.org/theme/credits/

  1. Submitting a user contributed note

For example: https://developer.wordpress.org/reference/hooks/wp_get_attachment_image_attributes/#comment-61

And possibly (when the workflow is sorted)

  1. Having a suggestion approved for changes to curated code reference content

It would be cool if contributors could get a badge under the following circumstances:

  • anyone who is listed as contributing to the handbooks
  • anyone who has 10 or more user contributed notes approved in the code reference

#1866 Add a basic "suggest an edit" workflow to the handbooks plugin Handbooks enhancement 07/29/2016

We've talked about this quite a bit in the context of DevHub where User Contributed Notes are occasionally used as a feedback mechanism. Basically, we need a way for docs consumers to report problems or suggest edits of published documentation on .org.

The initial proposal would be to build or use something akin to Post Forking on the front-end of handbooks and eventually other places like DevHub or HelpHub.

Personally I don't think an MVP has to be a complete solution, it mostly needs to cover the rift drawn between moving away from the Codex where any user could edit anything to the now largely closed systems on .org.

I think starting with the handbooks would be the way to go.


#1913 Expand documentation of WP_Term_Query() in Code Reference. Developer Hub enhancement 08/17/2016

With the release of 4.6, many devs will be researching WP_Term_Query() only to find that its Code Reference page has very little information. I was expecting documentation similar to WP_Query().

Upon further investigation, I found that much of the information I was looking for is actually in the docs of the WP_Term_Query::__construct() method. I only realized this after reading the DocBlock in the source code, which includes @see WP_Term_Query::__construct() for accepted arguments.. However that info is nowhere to be found in the Code Reference. The the only way to find it is to click __construct() in the Related section.

Can we better reflect the documentation from the __construct() page (specifically the acceptable arguments) in the docs for WP_Term_Query()? This could be accomplished either through examples, or at least a more obvious callout that refers you to the __construct() method for anyone researching how to format the query.


Otto42 (2 matches)

Ticket Summary Component Milestone Type Created
Description
#596 Create plugin icons for all plugins General enhancement 09/04/2014

Core now displays plugin icons on the installer screen, so it'd be nice to have them for many of the official plugins.


#2699 Add a new role to the forums: plugin/theme support Support Forums enhancement 04/07/2017

Plugin and theme authors currently have the power to mark threads as resolved within their own support forum, which is great.

Problem description However, some of the larger plugin/theme shops have a support team to help out on their own support forums. I think it would be useful to be able to recognize those people in the support forums, like we’re able to recognize authors.

Proposal So what I would like to propose is adding a new role: Plugin/Theme Support. Everyone with this role should have rights to mark topics within their own support forum as resolved, and should not be affected by posting speed limitations for their own support forum. This role should also show in the forums as ‘Support’, similar to author.

The reason why I propose a new role, instead of adding the capability to the contributor role is because, in my opinion, they serve a different purpose. Let me explain.

A contributor is someone who helped your open source project forward. This can be by providing feedback, writing code, creating images, doing marketing or being a friend of the project, for example.

Someone working on support does contribute his/her (paid) time to your project and is in that way a contributor. However, I think there are more than enough valid use cases where you don’t want someone who contributed code (for example) once to be able to close support request on behalf of the author.

That’s why I think having a separate support role would be viable. It would show the community that this person is vetted and answering on behalf of the plugin/theme author.

Related ticket This proposal is related to ticket #2598.

Managing support role Of course, it should be possible for plugin authors to manage the list of support people. I see two reasonable ways to do so, which should be mutually exclusive.

One way is by adding the usernames to the readme.txt file, the same way contributors are currently added. The other way would be to add users the same way committers are currently added, on the Advanced View of the plugin.

Showing support staff To be transparent about this, we’d probably also need a place to list people in the support role. This could be the Advanced View page, or even the plugin page itself.


SergeyBiryukov (2 matches)

Ticket Summary Component Milestone Type Created
Description
#20 Possible for user's to break layout when adding forum posts Support Forums defect 07/17/2013

When a user wraps text in their forum posts with "<li>" tags - The layout of the page breaks.

For an example of this see - http://wordpress.org/support/topic/please-ignore-just-testing-something?replies=1#post-4430248


#2204 Forum RSS Feed Issues Support Forums defect 11/03/2016

The RSS feeds generated by the new Plugin Directory platform have a number of drawbacks/defects compared to the feeds that were generated by the old platform.

  1. When a new reply is posted to a topic:
  • The email message generated for "subscribers" to the topic also has the correct information, but the message comes as plain-text so markup for code blocks, lists, etc. is lost.
  1. When the original post in a topic was modified, the feed generates and ongoing stream of "updates" identical to the original except for the "This topic was modified 2 weeks, 6 days ago by ..." text. This makes it hard to identify topics with genuine updates.
  1. When updates are posted to old topics (e.g. started 8 months ago), no RSS feed update is generated. It is hard to know when new activity occurs in an old topic.

Minor notes:

  1. The subject line no longer includes the plugin name, which makes it harder to organize an archive by plugin.
  1. The subject line no longer includes the post author, which would be fine if the actual author value was set correctly.
  1. The subject line now identifies "[Resolved]" topics, but not any other status value.

In short, RSS updates should contain:

  • The actual text of the update, with HTML markup
  • The actual date/time of the update
  • The actual author of the update
  • A subject line that includes the plugin name and perhaps the current status in addition to the topic title.

coffee2code (1 match)

Ticket Summary Component Milestone Type Created
Description
#1424 Automate meta contributor badge assignment when receiving props Profiles defect 12/01/2015

Profile badges don't seem to automatically appear for all areas. My core and plugins badges appeared on my profile on their own (as far as I can tell), but my Speaker badge had to be added manually with some difficulty, and my Meta badge hasn't appeared at all after getting first props a few weeks ago (see [2016]).


coreymckrill (6 matches)

Ticket Summary Component Milestone Type Created
Description
#2849 Add sessions list and other details to speaker pages WordCamp Site & Plugins enhancement 06/05/2017

For the new CampSite theme we had the idea to include a speakers bio page with an improved sessions list not only showing the session title, but also an excerpt as well as links to the slides and WordPress.tv video. We decided against a page template and rather add this additional markup to the post types plugin.


#2893 Admin Flags: Add Attendee filtering by Flag WordCamp Site & Plugins enhancement 06/22/2017

Currently the Camptix Attendee Flags doesn't allow filtering by flag, it'd be great if it did.

If you've got a flag Speaker set, you can't display all attendee's who are flagged as a Speaker unless you export it.

The attached patch adds the Flags as filter views on the Attendee post type listing.


#2894 Admin Flags: Internationalise the post-status-change label WordCamp Site & Plugins defect 06/22/2017

When toggling a status in the Flag section, the toggle afterwards is missing the capitalisation, this is because it just sets the label afterwards to the command, rather than the textual label for it.

The attached patch adds internationalised Enable/Disable text which it switches in/out instead of using the command. It's hard-coded inline with the JS, as that's the format of the current JS and changing it up further probably deserves a rethink of the entire flagging UI and storage.


#2923 Layout / Responsive issue on Opera for Android (Central Wordcamp) WordCamp Site & Plugins defect 07/04/2017

Hi guy's,

This is the first time I write a ticket here. Do not hesitate to give me advice if it is not the usual way to fill a ticket.

I would like to bring to your attention that there are problems about the layout on the website https://central.wordcamp.org/ for Opera users on Android.

Here is an example on this screenshot, but there are probably others :

http://i.imgur.com/Nz9xrbfm.png

I posted this info on slack yesterday and @coreymckrill recommended me filling a ticket here.

Regards, Jason


#3003 Tagregator - Twitter resets settings randomly WordCamp Site & Plugins defect 07/26/2017

Hello,

While I was working on these tickets: #2100 and #2907

I've noticed that my error log was getting grumpy and I saw this error:

[22-Jul-2017 11:26:20 UTC] PHP Notice: Undefined index: consumer_key in tggr-source-twitter.php on line 152

For some reason when you view the results page on the front end the twitter module bugs out randomly ( not all times ) and after that php error all the settings are getting reset so you are losing all login information etc.

I haven't been able to find out why.

@dipeshkakadiya is on it for a solution so we can implement it on gwtd3 new website as well.

Pointers for devs: Grab the /trunk of Tagregator through svn, apply the extra patches to have the latest as they have not been implemented yet and then work on this ticket.


#3122 Documentation for prefilling coupon field in CampTix via query string WordCamp Site & Plugins enhancement 09/11/2017

To save time and avoid typos, it would be great to support a means of that prefilling the coupon field.

For example: city.wordcamp.org/tickets?coupon=2017volunteer

Volunteers, sponsors, speakers, organizers, scholarship recipients, and others rely on coupon codes, and this would enable organizers to ensure they get the coupon code right on the first try.


dd32 (2 matches)

Ticket Summary Component Milestone Type Created
Description
#2575 Codex: #dotorgredirect does not redirect to forums Codex defect 03/10/2017

I'm trying to redirect an old "Forum rules" page on Codex to a new page on the forums.

The #dotorgredirect directive is used for redirecting pages to developer.w.org, so I thought this would work:

{{#dotorgredirect:https://ru.wordpress.org/support/forum-rules/}}

However, it just displays "Invalid Redirect" on the page.

Is there a whitelist in the redirect script? Could we add forums to that list?


#2931 Plugin Directory: Incorrect parsing of code blocks Plugin Directory defect 07/05/2017

The description for Theme Check plugin appears to be parsed incorrectly (see the screenshot).

The first code sample lacks the code formatting. In the readme.txt both samples are formatted the same way:

Examples:
`define( 'TC_PRE', 'Theme Review:[[br]]
- Themes should be reviewed using "define(\'WP_DEBUG\', true);" in wp-config.php[[br]]
- Themes should be reviewed using the test data from the Theme Checklists (TC)
-----
' );`

`define( 'TC_POST', 'Feel free to make use of the contact details below if you have any questions,
comments, or feedback:[[br]]
[[br]]
* Leave a comment on this ticket[[br]]
* Send an email to the Theme Review email list[[br]]
* Use the #wordpress-themes IRC channel on Freenode.' );`

iandunn (2 matches)

Ticket Summary Component Milestone Type Created
Description
#2823 Improve IP Geolocation Results API defect 05/11/2017

There are a couple problems with our current data set. They're not strictly related to each other, but I'm creating a single ticket for this because I'm guessing that the solution to both will be the same: switch from our current data source to a better one.

It looks like our database was updated recently (March 2017), but I can't find any info on where the original data comes from. @dd32, @tellyworth, do either of you know? Do you have any thoughts on other potential sources?


#3244 Data Protection and Bank Detail issues WordCamp Site & Plugins defect 11/02/2017

Within the Reimbursement back end of the WordCamp Sites personal details are being stored forever, and any organiser who has access can still see everyones personal details.

  1. Scrub the financial bank details after the set auditing time or at time of reimbursement.

Solution: I am aware that WordCamp will have to store financial data for a while but it is important to know that volunteers bank details will not be stored after they are no longer needed. WordCamp can retain the amounts but scrub the bank details as soon as they are allowed to. I do generally believe that personal bank details should be scrubbed as soon as the claim is paid, mostly because WordCamp should of stored this information somewhere more secure when making payments and also because you have receipts which are proof of payment.

  1. Currently any organiser continues to have access to the back end of any WordCamp site they were an organiser for and all of these sites hold peoples personal addresses and bank details too.

Solution: Deny access to all financial information apart from budgets once the camp has been signed off.

I am concerned about data protection and a little about financial conduct, I have a good understanding about data protection too, and kind of feel some of these changes need to be considered carefully. If WordCamp was hacked it is potentially a identity theft goldmine as it stores peoples home addresses and bank details.


netweb (3 matches)

Ticket Summary Component Milestone Type Created
Description
#1923 Forums should have a way to search for posts made from a particular IP address Support Forums defect 08/19/2016

After the upgrade to bbPress 2.x, there's no longer a way to quickly view the poster's IP address, or search for all posts made from that IP.

Previously, IP address was displayed in the author info block for each post, with a link to all posts made from that IP.

Currently, IP address is only displayed in a meta box in the admin when editing a post, and there's no way to search for all posts made from that IP.


#2532 Forums: "Most popular topics" view is broken Support Forums defect 02/23/2017

https://wordpress.org/support/view/popular/ appears to be broken: it's supposed to display the list of the most commented topics, but at the moment it just displays the first page of the "All Topics" view.

Works as expected on https://ru.wordpress.org/support/view/popular/ though, so I guess it might be a result of performance optimizations specific to the English forums.


#2537 Support Forums: Audit Log for Mod Actions Support Forums enhancement 02/27/2017

It would be helpful if the forums logged who marked a post resolved (or unresovled) as well as closed etc.

From a moderator perspective, this would help track down plugin developers (for example) who automate resolving tickets. It would also mean we'd know who to ping if someone closed a post without a comment.

Example:

  • Marked Resolved by Mika 11 Jan 2017, 22:00
  • Marked unresolved by Otto 11 Jan 2017, 22:30

or

  • Closed by Jan 13 Feb 2017, 11:30
  • Opened by Marius 14 Feb 2017, 00:13

obenland (2 matches)

Ticket Summary Component Milestone Type Created
Description
#2547 Review form; structure of star ratings Support Forums defect 03/01/2017

The Review form provides the user a star rating option. I don't think the structure makes sense from the perspective of an assistive technology. The current structure:

<div class="rate">
    <div class="wporg-ratings rating-stars">
        <a href="..." data-rating="1" title="Poor">
            <span class="dashicons dashicons-star-filled" style="color:#ffb900 !important;"></span>
        </a>
        <a href="..." data-rating="2" title="Works">
            <span class="dashicons dashicons-star-filled" style="color:#ffb900 !important;"></span>
        </a>
        <a href="..." data-rating="3" title="Good">
            <span class="dashicons dashicons-star-filled" style="color:#ffb900 !important;"></span>
        </a>
        <a href="..." data-rating="3" title="Good">
            <span class="dashicons dashicons-star-filled" style="color:#ffb900 !important;"></span>
        </a>
        <a href="..." data-rating="4" title="Great">
            <span class="dashicons dashicons-star-filled" style="color:#ffb900 !important;"></span>
        </a>
        <a href="..." data-rating="5" title="Fantastic!">
            <span class="dashicons dashicons-star-filled" style="color:#ffb900 !important;"></span>
        </a>
        <!-- hidden inputs -->
        <!-- script tags -->
    </div>
</div>

The current behaviour: When hovering over the star icons, the icons are filled with a darker shade of yellow to indicate the to-be-selected rating. This is combined with a short explanation of the icon through the use of the 'title' attribute. For example, hovering over the 4th star will reveal the word "Great". Issues with the current structure:

  • Anchor tags are used for the interactions. Anchor tags are meant to lead to content either on the same page or another page, they are not meant for custom interactions. These anchors will not be identified to assistive technologies as anything other than anchors and so this will be difficult to use.
  • The 'title' attribute isn't well supported by assistive technologies and is meant to supplement information already provided in text.
  • The ratings could be accidentally skipped because they are not form elements. Assistive technologies like screen readers have the option to use forms in a way that only navigates the form fields. This is to exclude unnecessary information on the page and focus on what's important for the task.
  • It relies on JavaScript. Although there are few people using the Web with JavaScript disabled, JavaScript can just fail to load for other reasons. In this case I don't think the form would operate correctly if JavaScript was disabled.

The solutions. I prefer Solution A.

Solution A:

  • Restructure the rating options to use form radio buttons.

Radio buttons are meant to be used in this scenario where there are multiple options that relate to one another and only 1 can be selected.

Suggested markup for Solution A: HTML:

<fieldset class="rate">
    <legend>Your rating</legend>
    <label for="poor">
      <input id="poor" name="rating" type="radio"><span class="rate-item"><span class="rate-item-text">Poor</span></span>
    </label>
    <label for="works">
      <input id="works" name="rating" type="radio"><span class="rate-item"><span class="rate-item-text">Works</span></span>
    </label>
    <label for="good">
      <input id="good" name="rating" type="radio"><span class="rate-item"><span class="rate-item-text">Good</span></span>
    </label>
    <label for="great">
      <input id="great" name="rating" type="radio"><span class="rate-item"><span class="rate-item-text">Great</span></span>
    </label>
    <label for="fantastic">
      <input id="fantastic" name="rating" type="radio"><span class="rate-item"><span class="rate-item-text">Fantastic</span></span>
    </label>
</fieldset>

CSS:

/* Prevent focus styles appearing on hover */
body:hover input:focus + .rate-item {
    border-bottom: 0;
}

/* Remove margin on fieldset */
.rate {
    margin: 0;
}

/* To remove gaps between stars produced by inline-block */
.rate label {
    display: block;
    float: left;
}

/* Hide the rating input field */
.rate label input {
    left: -999em;
    position: absolute;
}

/* Hide the rating text */
.rate .rate-item-text {
    direction: ltr;
    display: block;
    overflow: hidden;
    text-indent: -999em;
}

/* Style the rating item ready to use before and after pseudo */
.rate .rate-item {
    display: block;
    position: relative;
    height: 20px;
    width: 20px;
}

/* Replicate the star font icon for star ratings */
.rate .rate-item:before {
    color: #ffb900;
    content: '\f154';
    display: block;
    font-family: dashicons;
    font-size: 20px;
    height: 100%;
    left: 0;
    line-height: 1;
    position: absolute;
    top: 0;
    width: 100%;
}

/* On focus & On hover: Change the star icon */
.rate input:focus + .rate-item:before,
.rate input:hover + .rate-item:before {
    content: '\f155';
}

/* On focus: Add an underline to the star for an additional visual cue */
.rate input:focus + .rate-item {
    border-bottom: 2px solid #ffb900;
}

That will achieve the same look and feel of the ratings, but it will still require some JS to accumulate the stars depending on what is selected. For example if "Great" is selected then 4 stars should be highlighted. The important thing is that JS will only enhance the experience. The form will still work with JS disabled.

I will write the JS later if we're going for this.

Solution B:

  • Make the link behave like a button by replicating the role and states of the button.

Suggested markup for Solution B:

<a href="#" aria-pressed="false" role="button">
  • The 'aria-pressed' attribute would have to be updated via scripting to reflect the state of the button.
  • You may have to compromise on showing the 'title' attribute, as the descriptions should be in the link text. The 'title' attribute can still be used, but it should add supplementary information.

#3539 Implement programmatic or settings changes that can be made to /plugins/ and /themes/ General task 03/30/2018

Implement programmatic or settings changes that can be made to /plugins/ and /themes/ to allow for individual theme or plugin pages to conform to the SEO Standards. Examples of this format will be:

(1) /themes/

  • Title - ? (For example, $Theme_Name, Free $Main_Theme_Category Theme - WordPress)
  • H1 - ?
  • Meta Description
  • ? (of note, we can not do all of the standards, we must start with the most important)

(2) /plugins/

  • Title - ? - $Plugin_Name, $Main_Plugin_Category Plugin - WordPress
  • H1 - ?
  • Meta Description
  • ?

More information on this can be found here: https://docs.google.com/document/d/13YxtyPNIz8798EpZT-AXh1SW2QNLGm9PBhtDJo7O16o/edit?usp=sharing


ocean90 (1 match)

Ticket Summary Component Milestone Type Created
Description
#668 Open-source News Theme General enhancement 10/23/2014

While we were building the new bbPress theme we discovered that the WordPress theme live on https://wordpress.org/news/ would've been the best starting point. We now had to hack together stuff from various places.

Wouldn't it make sense to open-source that theme used at /news/ as well?


tellyworth (2 matches)

Ticket Summary Component Milestone Type Created
Description
#1278 Plugins Install API: Add ability to order results API enhancement 10/01/2015

Copied over from #wp12696:

Replying to apeatling:

It would be awesome if you could pass an ordering parameter to plugins_api() that would allow you to return a list of filtered plugins in a specific order.

I'd love to be able to use the API to return a list of the most popular / newest / recently updated plugins on the repo that contain the tag "buddypress".

Something like this would be awesome:

$plugins = plugins_api( 'query_plugins', array( 'tag' => 'buddypress', 'page' => 1, 'order' => 'popular' );

Even better, also allow search filtering:

$plugins = plugins_api( 'query_plugins', array( 'tag' => 'buddypress', 'search' => 'album', 'page' => 1, 'order' => 'popular' );

I'd be happy to implement this if I can get access to the API source on WordPress.org.

Reply from Otto:

This wouldn't be terribly difficult to add to the API, but it's pointless until core supports doing it there and is able to request the ordering. So, moving to the plugins component.

Now that the arguments for plugins_api() have been documented, paired with the fact that there are existing filters in plugins_api() for modifying arguments, I think there's now a more compelling case for implementing an 'orderby' (or similar) argument in the dotorg API.


#2467 Plugins not showing on plugin-install screen Plugin Directory Plugin Directory v3.0 defect 02/02/2017

Not sure if this is a Meta issue, nevertheless, it could be related to the plugins directory. I was doing a plugin search on plugin-install screen of a 4.7.2 site and got a strange behaviour: the search didn't return all the items available. The number is right – 5 items –, but I can only see 4 items on te screen: http://g.recordit.co/yMeHcCzUSY.gif


Note: See TracReports for help on using and creating reports.