WordPress.org

Make WordPress.org

Updates from February, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 7:19 pm on February 24, 2015 Permalink |
    Tags: ,   

    Theme Directory Launch Checklist 

    Tomorrow we’re going live with the new Directory! We’ll start going through the checklist February 25th 2015 1700 UTC.

    Disable uploads on bbpress themes.
    Replace the uploader page with an “uploads temporarily offline” message.

    Disable themes.trac sync process.

    • Announce launch in WPTRT meeting.
    • Commit an early return to sync-theme-review-results.php.
    • Inform Admins directly: No setting themes live between February 25th 2015 1600 UTC and the new directory is live.
    • Channel notification in #themereview.

    Migrate themes to WP.
    Run migration script in /bin/themes/

    Switch over Directory to not use API.

    Test themesnew API.

    • Switch to use themesnew.php on sandbox.
    • Test /wp-admin/theme-install.php locally.

    Test themesnew downloads.

    • Switch to use themesnew.php on sandbox.
    • Test downloads locally and on /themesnew.

    Up until here, no real damage is done, marks the last chance to postpone the launch.

    Switch over downloads and API scripts.
    mv index.php old-api.php
    mv themesnew.php index.php

    Switch over URLs and redirect.

    • Commit /themes removal.
    • Notify @seanosh about making the switch.
    • Commit mu-plugins commercial change.
    • Test the hell out of /themes.

    Switch over review sync script.
    mv sync-theme-review-results.php sync-theme-review-results-old.php
    mv sync-theme-review-results-themesnew.php sync-theme-review-results.php

    Enable theme uploads in directory plugin.
    Remove custom message and uncomment upload handler.

     
    • Andrew Nacin 9:19 pm on February 24, 2015 Permalink | Log in to Reply

      Are there actually redirects that need to occur? Are nginx rules already written for this? As far as I know, we should just need to remove bbPress-specific rules and let /themes/ fall through to WordPress.

      This is actually a bit complicated. The order of operations should be to change the DB to reflect /themes not /themesnew, and then remove the rules. But, that’s not quite enough. We also need to remove the /themes bbPress external. This external will *not* be fully removed upon deploy — because it has externals inside of it, it will leave behind directories in the form of e.g. /themes/bb-includes/backpress/includes/pomo.

      So, all of this needs to happen at basically the same time:

      • /themes needs to be deleted from dotorg.svn, and deployed.
      • The remnants of /themes/* needs to be removed manually from production servers.
      • nginx needs to be reloaded (with rules removed).

      I don’t think anyone has tested these steps. :-) @seanosh should be able to remove the /themes-specific nginx rules on your sandbox for you, then you can test the rest. The wporg-plugins-themes nginx conf file would also be a good thing to review as it might illustrate missing features from the new themes directory as well as what existing URLs should be supported, including /rss, /profile, /browse, etc. You can view these files from your sandbox.

      We should probably create a script to do this in one go, as in, you commit to dotorg.svn and do not deploy, then @seanosh runs this as a global command:

      svn up public_html # remove /themes, essentially deploying
      rm -r public_html/themes/ # actually remove /themes
      /etc/init.d/nginx reload # let it fall through to WordPress

      • Konstantin Obenland 11:17 pm on February 24, 2015 Permalink | Log in to Reply

        We also need to remove the /themes bbPress external.

        As far as I can tell, there are only two externals, bbpress and backpress/includes, yes?

    • seanosh 11:23 pm on February 24, 2015 Permalink | Log in to Reply

      I’d prefer if the deploy itself went through the deploy script instead of calling “svn up” everywhere. If need be, we can execute commands immediately after the deploy has taken place. Or is that not possible, @nacin?

  • Konstantin Obenland 12:22 am on February 24, 2015 Permalink |
    Tags:   

    Theme Directory Update 2/23 

    Last week I fixed most of the fixable tickets for the Theme Directory, switched to using WP_Query instead of the API for server-side rendering of themes, updated the WordPress-based Themes API with changes from the bbpress-based one, and finished the import script for the new directory. @otto42 committed the new reviews code today, so we should be able to get those integrated today or tomorrow.

    Which means that we’re going to launch on Wednesday or Thursday!

    There is still a lot more work to be done, but everything that’s remaining can be added, changed, or improved with the new directory active. Most importantly we want to make it available to language sites, so that we have an internationalized theme directory, and there will be more to be done around that.

     
  • Konstantin Obenland 1:57 am on February 13, 2015 Permalink |
    Tags:   

    Theme Directory Update 2/12 

    The two major parts of my week were fixing bug reports that came in after my post on make/themes, and getting started with adopting @melchoyce‘s modal design (Modal == modal + single). With the exception of reviews and support, I tried to stick as close as possible to the mockup. While I’m obviously not done yet, a first pass however is live (including some mobile styles).

    @otto42 made progress on the rating integration, working on a solution that lets us use existing ratings/review with limited migration efforts. He projected to be done with that around Wednesday next week.

    Next week I’ll be focussing on switching the server-side rendering of themes from using the API to using WP_Query directly. Towards the end of the week I’d also like to have ratings/reviews integrated and my work on the modal finished.

     
  • Konstantin Obenland 7:47 pm on February 6, 2015 Permalink |
    Tags: ,   

    Theme Directory Update 2/5 

    A very busy week with lots of improvements! These are some previously mentioned TODOs that I was able to scratch off the list:

    • Rewrote the Theme API’s update endpoint to work with WordPress.
    • Made synchronizing theme review results a cron job.
    • Made sure uploaded theme files are always deleted, no matter the outcome.
    • Added navigational links to Upload and Commercial pages (r1211).

    Additionally, I removed the Admin approval workflow form the Directory plugin, since this is handled entirely on Themes Trac.

    I also opened the floor to bug reports from the community. After doing that at last week’s update here with limited success, I added another call for volunteers on make/themes which resulted in 15 tickets so far.

    Next week I’ll be working though the tickets, as well as @melchoyce‘s Directory mockups, and @otto42 is still working on theme reviews/ratings.

     
  • Konstantin Obenland 9:41 pm on January 30, 2015 Permalink |
    Tags:   

    Theme Directory Update 1/30 

    It’s been two weeks since my last update on the theme directory. I had a chance to get my downloader and Themes API code reviewed by @dd32, but between attending an Automattic meetup, a WordCamp, and taking a couple of days off, it was hard to continue the pace of the weeks prior.

    • @otto42 started working on migrating theme reviews from bbpress to WordPress.
    • Chatted with @samuelsidler and @otto42 about how we want to make the switch from old to new.
    • I tracked down a bug with jumping modal contents on small screens.
    • Added smooth scrolling for iOS devices in the theme modal.
    • Spent a day trying to figure out a way how I can prevent background scrolling on iOS when the theme modal is open.

    If anyone has a fix for the last mentioned bug, please let me know. My CSS and JS foo is failing me on this one, I have not idea how to fix it.

    I think the directory (with the exception of the theme uploader) is to a point where it makes sense to open it up to bug reports. If you find anything wonky and out of the ordinary, please feel free to file a ticket over at meta.trac, and assign it to the Theme Directory component. Thanks so much for your help!

     
  • Konstantin Obenland 9:20 am on November 20, 2014 Permalink |
    Tags:   

    Theme Repository Theme 

    A while back, @otto42 started to work on bringing the Theme Directory over to WordPress (I know that sounds weird, but currently it runs on an old version of bbpress). The idea is to split functionality and appearance, making the Repopackage custom post type and the uploader a plugin, and let a theme handle the display of themes.

    With the help of Matias Ventura, I continued Otto’s work on the theme part of things, taking the existing theme install experience from the admin and making it work on the front-end of the theme. I’m currently in the process of adding server output, so the repository stays crawl-able for search engines. Steps to take going forward include determining what features to take over from the existing theme repository (as the theme install UI is a lot simpler), adding these things to the API, and figuring out how single theme views should look like vs. detail views on index.
    I haven’t committed any improvements to meta.trac so far as they are dependent on #30116, but the plan is to make that process a little bit more public. Once the core improvements are in, I’ll make sure to push my updates. Everything will be trac’ed in #745-meta so you can follow along there.

    Yesterday @coffee2code and I chatted about how we can work together on the project as well. He’ll look at the difference between the current theme repository and the in-dash experience, to determine what to keep and what to drop. Scott might also be able to pitch in on the plugin side at a later point in time, where we still need to make the theme uploader work.

    We’d like to have the new experience ready to go before the end of the year. For that to happen we might decide to take a more iterative approach, go with what the in-dash experience has to offer right now, and do a v2 where we port back features from the existing theme repository. This part has not been determined so far.

     
  • Jen 6:31 pm on August 21, 2014 Permalink |
    Tags: , site deletion   

    @otto42: Can you get rid of the make.wordpress.org/events blog? We pushed it into /community a long time ago, but the site is still there, and people still wind up there and leave comments that no one responds to.

     
  • Samuel Sidler 8:24 am on May 24, 2014 Permalink |
    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 |
    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!

     
  • George Stephanis 3:36 pm on November 28, 2013 Permalink |
    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.

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