WordPress.org

Ready to get started?Download WordPress

Make WordPress.org

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Ian Dunn 2:13 am on June 23, 2014 Permalink | Log in to leave a Comment
    Tags: contributing, vagrant, varying-vagrant-vagrants, wordcamp.org, wordpress-meta-environment   

    WordPress Meta Environment 

    Setting up local development environments to contribute to the Meta sites can be an obstacle for those without access to the private subversion repositories or a sandbox, especially at a meetup or WordCamp contributor day, where time is limited.

    We’ve talked a bit before about making this easier by creating a Vagrant configuration, so I put together a prototype based on Varying Vagrant Vagrants, with WordCamp.org as the first site. The sample data needs a little love, but other than that I think it works pretty well.

    I’ll test it out with some people this weekend at WordCamp Seattle. If anyone on the team wants to add other sites or make any changes, just let me know and I’ll add you to the repo.

     
  • Jen Mylo 12:27 am on June 13, 2014 Permalink | Log in to leave a Comment
    Tags: team meetup, wcsf, wcsf2014   

    WCSF 2014 

    Heads up, meta team! We’re getting ready to publish details about the plans for WordCamp San Francisco this October (which includes a mini team meetup), so if you’re thinking of attending, please read the post at http://make.wordpress.org/updates/2014/06/12/wordcamp-san-francisco-travel-contributor-days/ and take the short survey linked at the end of it so I’ll know how many team members to plan for (don’t worry, this isn’t a commitment or anything, I just need to get some rough numbers for budgeting purposes). Thanks!

     
  • Samuel Sidler 8:24 am on May 24, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    As we’ve been doing weekly, we had another meta trac triage yesterday. @atimmer, @coffee2code, @iandunn, @nacin, @Otto42, and @samuelsidler attended.

    We’d love some feedback on #30. That is, anyone interested in creating better theme preview data, it’d be great to have it submitted to the ticket. There’s a current proposal that could use some feedback as well.

    @jenmylo: For #482, will the training team be using their P2 or using the community P2? They’ve been using the community one recently. If they’ll continue to use the community P2, we can wontfix that ticket.

    Next week (Friday at 17:00 UTC), we’ll be looking at the Plugins Directory component (I won’t be present).

     
  • Samuel Sidler 11:54 am on May 10, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    We did a meta trac triage on Friday.

    • @Clorith, @coffee2code, @georgestephanis, @iandunn, @otto42, @samuelsidler attended
    • We’ll be doing another meta trac triage exactly a week later on May 16, 2014 17:00 UTC.
    • Our focus this time (and next) was on the General component in trac and closing out some of the issues. We made it through about half of the tickets in that component (20) and a handful were fixed.
    • @otto42 wants to ask anyone and everyone for help with responsive fixes for WordPress.org (#461)
    • A number of tickets need follow up. Some have been assigned so we know who’s on point. I’m taking a number of others.

    Those interested, we’ll see you next week!

     
  • Samuel Sidler 4:52 pm on May 7, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    We’re going to do a meta trac triage this coming Friday at 17:00 UTC (10am PDT, 1pm EDT) in #WordPress-meta. We’ll be steering clear of devhub tickets (the devhub chat is a good time to look through those) and focusing on older tickets. If you’re interested in working with the meta team, join us!

     
  • Andrew Nacin 5:33 pm on January 15, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Trac updates 

    Over the last month, I’ve been making a lot of improvements to Trac, which have been announced and documented on make/core.

    At this point, I’ve brought most of these improvements to most Tracs on WordPress.org.

    Core, meta, bbPress, BuddyPress, GlotPress, themes, and plugins now all use WP.org cookie authentication, SSL, and the refreshed design. bbPress and BuddyPress received their own skins. These Tracs also all gained image attachment previews, email address syncing, IRC cross-references (for #wordpress-meta, #buddypress-dev, #bbpress-dev, #glotpress, #wordpress-gsoc), and various bug fixes and tweaks. A few other improvements (like comments columns) require Trac report SQL updates, versus template or configuration changes. I’m happy to help the developers on other Tracs to help make their reporting better, something we’re also doing for core.

    The meta repository now includes configuration files shared by various Tracs, to shine as much light as possible on everything. These files join MySQL schemas, patches to Trac, a number of template files, a lot of JS and CSS, and even a WordPress plugin.

    Notifications are coming very soon to BuddyPress, bbPress, GlotPress, and meta. Probably in the next few days. Once a Trac is running the new notifications feature, that means it has been migrated to MySQL, which means the data is more accessible to the rest of WP.org, as well.

    I’m sure I’ll continue to make tweaks to Core Trac in the coming months, but as everything is now shared and well-organized, it won’t even need to “trickle down” — they’ll be deployed everywhere on the first run.

     
    • Andrew Nacin 5:38 pm on January 15, 2014 Permalink | Log in to Reply

      Oh, and I’ve been experimenting with design/functionality of the plugins trac. Here’s what I got so far: https://plugins.trac.wordpress.org/plugin/akismet. It requires a few final touches:

      • Links from the plugin directory to these new plugin pages, which will be the new way to create tickets (no more generic /newticket, which allows us to remove the component dropdown)
      • Notifications, including per-plugin notifications (where committers are subscribed by default)
      • Bring back the syncing of components when a new plugin is approved, as there is no longer a concern about a bloated component dropdown

      Overall, this actually makes this Trac useful again. It’s the same barrier to entry as the forums now (cookie auth goes a long way here), and is no longer a complete embarrassment.

      • Bryan Petty 5:52 pm on January 15, 2014 Permalink | Log in to Reply

        This is great. Certainly goes a long way towards treating plugins more like additional open source projects like core itself instead of just these 3rd party projects developed outside of WP.

        Custom query and report pages that are already pre-configured to filter down on the plugin’s component would also probably be important.

      • Scott Kingsley Clark 5:54 pm on January 15, 2014 Permalink | Log in to Reply

        Would be great to be able to customize the bug tracker URL via the readme.txt for this URL, for plugins that have already invested large amounts of time into places like GitHub Issues.

      • Jose 5:32 pm on February 3, 2014 Permalink | Log in to Reply

        That looks really cool. Curious if something like this would be able to make it to themes as well.

    • Boone Gorges 6:52 pm on January 15, 2014 Permalink | Log in to Reply

      Excellent! Thanks a million, @nacin. These small changes go a long way to lowering the barrier to participation.

    • Xavier Borderie 11:15 am on January 22, 2014 Permalink | Log in to Reply

      This is not related to Trac, but from this page (which can be accessed from the /download/source/ page), the “Trunk” and “WordPress 3.8″ links each lead to a 403 error. Just so you know :)

    • Dave Kellam 6:41 am on February 26, 2014 Permalink | Log in to Reply

      Thanks for all your work! I’ve just recently submitted my first ticket/patch, and added comments and a patch to another ticket. Overall, you’ve made it seem a lot less scary.

      One thing I’d consider doing is collapsing the Modify Ticket dialog by default for commenting. It’s a bit daunting for first timers, and makes it sort of awkward UI with the submit button below.

    • zipsuckscom 6:15 pm on April 19, 2014 Permalink | Log in to Reply

      Folks, ya all doing a great job!
      Thank you.
      Meanwhile, I tried to set up a free Iranian Comics at

      عکسها.com
      or
      http://zipsucks.com
      It had a tremendous response from the day one. But a month later it was hacked. I assume by the not so funny ayatollahs.
      I’m no match to those guys, and I can’t figure out what exactly they did to disable the site.
      Is there anybody out there to give me a hand?
      Michelle

  • Jen Mylo 7:10 pm on January 8, 2014 Permalink | Log in to leave a Comment
    Tags: accessibilty, tables, tmce   

    The accessibility team needs a plugin for their site that will allow them to create tables for displaying tabular data/content in their accessibility reports (pages). I know TMCE has a table builder that we could add, but what I’m not sure about is if it creates accessible tables.

    1. Getting tables on there at all: better with a plugin that’s already out there, or better to write a one-off that just adds that one thing?

    2. Once the options are identified something in place, @accessiblejoe can take a look at the table output to see if it’s accessible of if we need to write an add-on to make it that way.

     
    • Kim Parsell 7:14 pm on January 8, 2014 Permalink | Log in to Reply

      Has anyone looked at TablePress? http://wordpress.org/plugins/tablepress/ Not sure about the accessibility of the output, but it’s a possibility.

    • Andrew Ozz 7:47 pm on January 8, 2014 Permalink | Log in to Reply

      Generally TinyMCE has very good accessibility. We can add the ‘table’ plugin to it quite easily. However not sure about “creating accessible tables”: are there any special requirements apart from the standard HTML?

      Looking at the tablepress plugin, it’s huge and pretty complex, and seems to offer a spreadsheet-like features when editing a table (formulas and what-not). Is that needed?

      • Jen Mylo 8:25 pm on January 8, 2014 Permalink | Log in to Reply

        Nope, we just need basic tables. Accessibility centers on the table elements being properly labeled. Joe can talk to you about it, linking him here.

      • Sam Sidler 6:24 am on January 13, 2014 Permalink | Log in to Reply

        Can we add it to core as part of 3.9? The make blogs run trunk, so that’d enable it by default; but there was also discussion of it being in core anyway, now that we can.

    • Rian Rietveld 8:31 pm on January 8, 2014 Permalink | Log in to Reply

      Maybe in this discussion there are two different issues; is the output accessible and can a table be added by someone using only a keyboard.

    • Joseph Karr O'Connor 5:31 am on January 9, 2014 Permalink | Log in to Reply

      Rian is correct, there are two different types of situations involved with admin pages. We use WCAG 2.0 AA guidelines for web pages and ATAG AA guidelines for web applications. In both, keyboard accessibility is required. Jen suggested that I post a link to info about accessible tables, here it is: http://webaim.org/techniques/tables/

  • Jen Mylo 7:24 pm on January 7, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Talked with @coffee2code about Profiles today.

    • He’s going to deploy (and test, and fix any bugs) the profile/buddypress stuff that Mert did during GSoC. At this time only the back-end stuff is going to be deployed, no UI changes.
    • Scott is going to install/turn on the plugin(s) to pull Make posts and comments, trac comments, etc into the activity stream to make it more inclusive.
    • I’ll work with @melchoyce on new UI for profiles based on my conversation with Scott.
    • After the back end stuff is running smoothly, will work on launching UI improvement.

    Later follow-up work/projects:

    • Bring activity from events (wordcamps, meetups, etc) into the stream.
    • Create one .org profile instead of 2 (bring in the support stuff).
    • Related: upgrade forums to current bbPress plugin (big standalone project, big implications, but will tie in)
     
    • Amy Hendrix (sabreuse) 7:25 pm on January 7, 2014 Permalink | Log in to Reply

      Nice! I’m looking forward to the changes!

    • daveshine (David Decker) 8:21 pm on January 7, 2014 Permalink | Log in to Reply

      Great that a few changes are coming, but sadly no UI improvements. I was so amazed in summer by reading that profiles will be updated, a bit disappointed that we have to wait more weeks or months for this???

      Also, speaking .org UI: the responsiveness is still a mess here, now for weeks already, almost unuseable on mobile devices. I rather have a non-responsive website than such a “public-work-in-progress” – on such a huge website. Not amused.

      • Jen Mylo 8:26 pm on January 7, 2014 Permalink | Log in to Reply

        The UI changes proposed in the gsoc project were very minor and did not increase usability or usefulness. We’ll update the UI to incorporate the new feeds and give more room to things that need it.

      • Sam Sidler 9:10 pm on January 8, 2014 Permalink | Log in to Reply

        Responsiveness is being worked on. There’s a few open meta trac tickets and quite a few changes have already landed. Since most of that is CSS, feel free to jump in or file tickets on specific areas that need to be made responsive. We need all the help we can get.

    • Siobhan Bamber (siobhyb) 10:39 pm on January 7, 2014 Permalink | Log in to Reply

      Awesome. Really looking forward to the new profiles! :D

    • Xavier Borderie 8:47 am on January 22, 2014 Permalink | Log in to Reply

      I haven’t really followed that GSoC projet, but would that be able to tie into http://openbadges.org/ eventually?

  • George Stephanis 3:36 pm on November 28, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    The plugins repo is currently serving up the 2.6.1b1 tag for Jetpack, but saying that it’s 2.6.

    When you download the file and open it up, the changelog contained in the readme.txt file matches the 2.6.1b1 tag, not the 2.6 tag, or trunk (which it had glitched to previously a few months back).

    Trunk’s current readme does point to 2.6 as the stable tag.

    Today, on Thanksgiving, I’m thankful that this is just a minor bugfix point release that slipped out early, and everything that changed in it should be safe and good to have deployed. However, users that upgrade to or install it via their dashboard, or download the zip are still getting told that it’s a beta release, which can certainly scare users.

    cc: @otto42 @samuelsidler

    I’m going to be trying to do whitespace commits to some of the readme.txt files, hoping to glitch it back to being correct again.

     
    • George Stephanis 3:39 pm on November 28, 2013 Permalink | Log in to Reply

      Also emailed to plugins@wordpress.org

    • Samuel Wood (Otto) 3:43 pm on November 28, 2013 Permalink | Log in to Reply

      You know how I once said that branches don’t matter?

      Yeah, I was wrong. Get rid of the /branches/2.6 directory. It’s seeing that and building the 2.6 zip from that.

      • George Stephanis 3:46 pm on November 28, 2013 Permalink | Log in to Reply

        I’m moving them all into /branches/point-release-branches/ — that should keep it from catching, yes?

      • George Stephanis 3:46 pm on November 28, 2013 Permalink | Log in to Reply

      • J.D. Grimes 4:17 pm on November 28, 2013 Permalink | Log in to Reply

        So does this mean that plugins shouldn’t have a branches directory, unless they want the zip to come from there? Or do we just need to have a 2.6.0 tag if we want a 2.6 branch?

        • George Stephanis 4:51 pm on November 28, 2013 Permalink | Log in to Reply

          I think what’s happening is that the zip generated by branches goes to the same url as those generated by tags. So while it’s parsing the plugin headers from the tags and using that to populate the plugin page, the branches get parsed afterwards, and then that zip overwrites the tag zip.

          So the plugins page is built off of the tag, but the branch zip winds up being what’s built at the url the tag one should live at, if they’re named identically.

          As such, I think I could have renamed it to branches/2.6-legacy and been fine?

    • George Stephanis 4:00 pm on November 28, 2013 Permalink | Log in to Reply

      Confirmed, it’s serving 2.6 again now.

      Major thanks for the response, especially on a holiday. Gin & Tonics are on me next time.

  • Isaac Keyet 11:30 pm on November 4, 2013 Permalink | Log in to leave a Comment
    Tags: forums, , todos   

    Migrating & Merging Mobile App Forums 

    Hey guys, this is something we’ve discussed many times in the past and.. what can I say. It’s close to our hearts.

    To recap, the plan of action was to…

    • Collect all threads and rooms within each of the apps forums (ex.: ios.forums.wordpress.org). I know @nacin had made some progress on this.
    • Create a new subforum here on WordPress.org titled “Mobile Apps” or similar.
    • Import each forum as a sub-forum of “Mobile Apps”
    • Mobile group to manually go through and add cross-platform threads (like FAQs, the plugin blacklist, general how-tos).

    If I remember correctly we figured we could start with a forum that has extremely low traffic to see how that goes, say the Nokia app’s forum (an app that’s in hibernation).

    What do you think? Does this fit in on the road map?

     
    • Sam Sidler 3:31 pm on November 7, 2013 Permalink | Log in to Reply

      This sounds generally fine. I assume you want the forums to be part of the support forums not their own thing? I’m not sure how hard this would be given the codebase that’s on the support forum. @otto42 would know more. When we can get it done will depend a lot on how long it’ll take (and if we have encoding issues…).

      I do wonder… What’s the goal of moving them over? Better visibility to mobile forums? Do we get a lot of misfiled forum posts to the support forums that belong in the mobile forums? I notice that each of the mobile apps has its own site. Would there be interest in bringing those in under wordpress.org/mobile/[platformname] for consistency?

      • Isaac Keyet 6:53 pm on November 7, 2013 Permalink | Log in to Reply

        Yes, the plan has been to consolidate the sites’ content: landing pages/download, “how to contribute” (now make/mobile and the mobile handbook), FAQ/Help (could be in the forums), dev blogs (now all are closed, we only use make/mobile), the official app blogs (could live under wordpress.org/mobile/platform), and the forums.

        There are two main reasons for moving the forums (and everything, really) over:
        1. Maintaining all these separate sites has proven to be a difficult task (usually lag behind further than they should).
        2. There’s a lot of overlap and redundant content, this goes for landing pages, feature listings, download links, ‘get involved’ type pages, as well as support.

        @aerych and I did talk about how if this proves to be hard to do in a timely and swift manner we could simply dump all the content in the current forums to an archive to live on somewhere and redirect hits to a new Mobile Apps forum under Support here on WordPress.org. We could then go through and manually add everything we think would make sense to have ‘global’ for the apps and what makes sense on the app level (by creating sub-forums). We’d hate to lose all the threads, but as long as we can preserve them somehow I doubt it’d be a problem for neither users nor us.

      • Isaac Keyet 8:34 pm on November 8, 2013 Permalink | Log in to Reply

        Just checking in, would be nice to figure out a way forward. Feel free to ping me or @aerych anytime.

      • Isaac Keyet 11:45 pm on December 4, 2013 Permalink | Log in to Reply

        @samuelsidler, any update here? I know it’s crunch time for 3.8 but we need a resolution, been a month today :)

        • Sam Sidler 11:22 pm on December 5, 2013 Permalink | Log in to Reply

          Sorry for not getting back to you @isaackeyet.

          Talking this over with @nacin, we’re going to punt until 1Q or 2Q next year. Migrating things over doesn’t make sense right now (on the old bbPress), but work is starting on the a bbPress 2.x solution for the future. We’ll probably do some locale forums first, then can bring these over before bringing over all of the support forums. I think it’s best to wait until we have new forums rather than trying to migrate the mobile forums into the old forums.

          • Isaac Keyet 11:52 pm on December 5, 2013 Permalink | Log in to Reply

            No problem.

            Maybe then the best option is to simply archive the old forums and start fresh, manually carrying over important topics and threads. We could then just disable logins and posting on the individual forums and create a message to display for anyone visiting to go to the new forum with any discussions.

            Given that it’s been over 1.5 years since we first initiated the move it just seems like there may just be no way it can happen if it didn’t happen up until now.

          • Isaac Keyet 5:59 pm on December 9, 2013 Permalink | Log in to Reply

            We decided to go with the simple approach outlined above.

            @samuelsidler could we get new subforums created so we can start migrating (manually)? Or let me know when/how we can talk about what needs to be done.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel