Make WordPress.org

Tagged: meta Toggle Comment Threads | Keyboard Shortcuts

  • Samuel Sidler 9:18 pm on January 7, 2016 Permalink |
    Tags: meta   

    Meta Team in 2015 

    Just a week into 2016, it’s time to take a look at what the meta team did in 2015. As a reminder, here’s a version of this post from last year.

    Sure, I could give you a long list of trac tickets, but instead here’s a general overview of the bigger things we accomplished:

    • Theme Directory: Launched an all-new theme directory, completely open source and powered by WordPress instead of bbPress 1.x. Lists are now sorted by active installs instead of downloads and you can “favorite” your favorite themes.
    • Plugin Directory: Crossed 1 billion cumulative downloads. Redesigned the plugin directory. Lists are now sorted by active installs instead of downloads.
    • Translate: Launched the ability to translate WordPress.org themes and plugins directly on translate.wordpress.org, language packs for said themes and plugins, added a stats overview, and refreshed the GlotPress interface to improve usability.
    • Rosetta: Introduced internationalized theme and plugin directories for all locales, automated Rosetta deploys, and fixed a number of issues throughout the sites. On the forums side, we launched two new internationalized forums, powered by bbPress 2.x.
    • WordCamp.org: Version 1 of the JSON API was added to WordCamp.org, which involved customizing it so only whitelisted data was exposed. Additionally, WordCamp Payments, WordCamp Site Cloner, and WordCamp Remote CSS were launched, to say nothing of the dozens of contributions reviewed and committed. Part of WordCamp Central received a refresh as well.
    • Trac: Mentions were added throughout all of the WordPress.org trac instances so you can @-mention someone. Additionally, the entire design was refreshed, among other improvements.
    • Meta Environment: A number of sites were added to the WordPress Meta Environment including: BuddyPress.org, bbPress.org, wordpress.org/themes, global.wordpress.org/themes, and translate.wordpress.org.
    • Open Source: The changes in this list were mostly open source as the meta team is committed to open sourcing as much of WordPress.org as possible. In 2015, we also open sourced the Showcase theme and reviewed/committed numerous patches from contributors (see below).
    • Feature Plugins: Added the ability to sync feature plugins on GitHub with the plugin directory.
    • Slack: Worked on further integrations including /announce for team leads and better warning/error reporting for Translate and Meta services.
    • Devhub: Added user contributed notes to the developer reference, migrated hundreds of examples from the Codex, and added Used By and Uses section to show direct relationships.
    • Profiles: A number of teams received badges for the first time, including the core, polyglots, and training teams. Favorites was expanded to include themes and updated with plugin icons and new ratings data.
    • Centralized Logins: We started the process of centralizing logins on WordPress.org, which will lead to other improvements.

    There’s a ton more that we did throughout the year. You can keep up with changes using the meta trac timeline.


    The following 79 people‡ received 149 props over the course of 2015 to the meta repository and its related project: @adrian2k7, @akirk, @amylaneio, @ankit-k-gupta, @atimmer, @bandonrandon, @bansod_deven, @boonebgorges, @bordoni, @bowlhat, @brashrebel, @chaselivingston, @clorith, @coffee2code, @colorful-tones, @dd32, @deconf, @djpaul, @drewapicture, @dzver@empireoflight, @erikguimaraes, @folletto, @francescolaffi, @garyj, @helen, @hideokamoto, @hugobaeta, @iandunn, @isaackeyet, @jasonm4563, @jeffgolenski, @jeherve, @jeremyfelt, @joefletcher, @johnbillion, @johnjamesjacoby, @johnnypea, @kovshenin, @kraftbj, @liljimmi, @markoheijnen, @matheusfd @mcguive7, @mdawaffe, @melchoyce, @mercime, @mj12982, @morganestes, @nacin, @nao, @nataliemac, @nathanshubert, @nbachiyski, @netweb, @nickmomrik, @nvwd, @obenland, @obrienlab, @ocean90, @otto42, @pauldewouters, @pento, @pixolin, @rachelbaker, @ramiy, @rclilly, @ryelle, @sa3idho, @samuelsidler, @sergeybiryukov, @siobhan, @stephdau, @tfrommen, @tyxla, @valeriosouza, @yoavf, @zodiac1978, and @_dorsvenabili.

    A HUGE thank you to all of the contributors above. I’d especially like to call out @sergeybiryukov and @ramiy, who both made large contributions (21 and 15 props, respectively) to the meta team last year.

    As a basis for comparison, here’s a table of our stats in 2014 versus 2015.

    2014 2015
    Contributors 45 79
    Props 113 149
    Committers 14 18
    Commits 875 1163

    (The table above only includes props, committers, and commits for the meta repository, not related projects.)

    ‡ Note that this total includes contributors to the Meta Environment, Camptix, and Tagregator repositories.

    • Matheus Martins 9:44 pm on January 7, 2016 Permalink | Log in to Reply

      Congrats @valeriosouza and @bordoni

    • Rami Yushuvaev 10:05 pm on January 7, 2016 Permalink | Log in to Reply

      Looking forward to 2016, I would like to see the plugins directory open sourced.

    • Caspar Hübinger 7:59 am on January 8, 2016 Permalink | Log in to Reply

      @samuelsidler Congratulations, and thanks so much for this post! It is so great to see all the progress listed in one place. Often times these contributions can be overlooked as many of them are not directly visible to the public.

      Being part of one of the locale teams, I tried to publicly raise awareness for needed improvements on Rosetta sites more than once during WordCamp Q&As in the past. So I feel this is the time to thank everyone who contributed to making Rosetta and WordCamp.org sites easier to work with. Thank you tons!

      It may seem silly for outsiders, but when you’re a volunteer and you regularly publish on those sites, having tools at hand that work for you, not against you, can make all the difference in terms of motivation. The improvements implemented on Rosetta in 2015 help us a great deal to keep those sites populated and active.

      After all, for a locale project their Rosetta site is the official place where they represent WordPress in their language. Naturally you want this place to look neat and beautiful. With their efforts for better Rosetta sites, the Meta team enables us to better represent WordPress in parts of the world where English isn’t first language. I hope the Meta team will be equipped with everything they need to keep up their great work in 2016.

    • Peter Nemcok 7:53 pm on January 8, 2016 Permalink | Log in to Reply

      Good job! Really looking forward to 2016. Do you already have plan for 2016?

    • alen0923 6:19 am on February 8, 2016 Permalink | Log in to Reply

      Thanks for this articles. Will look forward for 2016.

  • Samuel Sidler 8:51 pm on January 22, 2015 Permalink |
    Tags: meta   

    Meta Team in 2014 

    We’re a few weeks into 2015, but I wanted to take a moment to look back at the meta team in 2014.

    Over the course of 2014, we worked on a number of projects:

    • Trac improvements: A number of improvements to both trac and make/core landed, which make following tickets much easier.
    • Devhub: Working with the docs team, we launched developer.wordpress.org.
    • WordPress Meta Environment: Making it easy to contribute to the meta team was a priority and the WordPress Meta Environment shipped with just that in mind.
    • Open Source: A number of sites were open sourced over the year, including the Rosetta theme, WordPress.tv plugins and theme, and more. (You can find all of our open sourced code here.) Additionally, developer.wordpress.org and apps.wordpress.org launched open source from the start.
    • WordCamp.org: Lots of iteration on current features, many improvements around automation, and the WordCamp Payments plugin launched.
    • SSL: WordPress.org now forces SSL across all of our sites.
    • WordPress.org Profiles: Profiles got a design refresh, including badges for contributing to Make teams, and we’re now automatically pulling in more activity from Trac, WordPress.org posts and comments,WordCamp.org speakers and organizers, and theme and plugin repositories.
    • Slack: Setup Slack and wrote many custom plugins and integrations with WordPress.org.

    Lots of other tickets were fixed over the course of the year and work on a new theme directory began (open source from the start!).

    As always, if you’re interested in getting involved with the meta team, find us on Slack in #meta or dive right into the meta trac, filing or fixing issues.

  • Ian Dunn 5:04 pm on September 8, 2013 Permalink |
    Tags: meta, open source,   

    Open Sourcing Meta Plugins 

    TL;DR: I’m proposing that some of the new plugins we write for WordPress.org live in the official plugin repo, rather than the Meta repo.

    I’m working on #meta187 and part of it is a modification to P2 to allow assigning a category to a new post. I created a plugin for it, and initially I was just planning on putting it in the Meta SVN repo, but since this is generic functionality — rather than something specific to WordPress.org — I started thinking about where the best place for it to live would be.

    One of our goals it to open-source as much of WordPress.org as possible, and putting the plugin in the Meta repo would achieve that, but probably not in the most effective way. 99% of WP users and plugin developers aren’t aware that the Meta repo exists, so the code isn’t very visible. And if they wanted to get updates, they’d have to set it up as an svn:external, rather than just using the regular plugin update system.

    So for the most part, the only people who would benefit from using it outside WordPress.org, or contribute back to it, would be other developers on the Meta team.

    So instead, I’m thinking we should put it — and other plugins like it, in the future — into the regular WordPress.org plugin repository. That would give it much more exposure and would make it easy for others to use the plugin. The extra exposure would lead to more feedback from users and more contributions from developers.

    We could add the wordpressdotorg user as a contributor to the plugin, to ensure the Meta team still has commit access to it if the original developer isn’t available.

    What does everyone think about that?

    • Ian Dunn 5:13 pm on September 8, 2013 Permalink | Log in to Reply

      One potential problem would be providing support for the plugins. We obviously don’t have the resources to do that for other users, which could lead to frustration on both sides.

      I think if we could mitigate that problem by putting a note in the plugin description on the repo, though, letting users know up front that we’ll only support bug fixes and security issues, but won’t provide any support for helping them use or customize the plugin.

    • David Laietta 5:42 pm on September 8, 2013 Permalink | Log in to Reply

      I think that it’s a great idea to put it somewhere public and usable. While leaving a note about support might also be a good idea, you’re probably still going to end up with some users expecting it. Hopefully the niche needs of the plugin will make this less likely to happen.

      • Ian Dunn 7:10 pm on September 8, 2013 Permalink | Log in to Reply

        Yeah, I think you’re right that we’d still get some people expecting it. As long we do our part to manage expectations up front, though, I don’t think I’ll feel bad about ignoring the requests. It’s also possible that other forum users will be able to help them out, too.

    • Ulrich 5:59 pm on September 8, 2013 Permalink | Log in to Reply

      Has GitHub been thought about? That would make it easier for other developers to provide improvements.

      • Ian Dunn 7:14 pm on September 8, 2013 Permalink | Log in to Reply

        There have been a lot of discussions about GitHub vs the WPORG repo in the larger community, and I think the general consensus is that we’d rather use and improve our own tools, rather than rely on a third party. The WPORG platform includes parallels for a lot of GitHub’s features, although I agree that they’re not as nice as GitHub’s right now. We can always use both, too, but then that involves extra work to keep them in sync and manage multiple forums, bug trackers, etc.

    • Erlend Sogge Heggen 6:00 pm on September 8, 2013 Permalink | Log in to Reply

      Would love to have easier access to the various Meta customizations. Love the idea!

    • Andrew Nacin 2:18 am on September 9, 2013 Permalink | Log in to Reply

      For this particular situation: Unfortunately pretty much any plugin written for P2 is a terrible hack that is always very fragile and can very easily break. (I can see how fragile and hacky this one is from the screenshots.) Despite writing a dozen plugins for P2, I will never release a plugin for P2 into the directory and I don’t think anyone should. Also, with Automattic finally writing a replacement, we will likely be able to replace it next year sometime.

      More generally: The meta directory is designed to be a place for code that powers WordPress.org, not a place for people to install code from for their own site, in the same way they would a plugin. It’s purposely designed to not target 99% of users. If someone wants to run it on their own site, they’re welcome to (and it’s all GPLv2 or later), but it isn’t something that we need to be encouraging.

      Are there some things that could be useful in the plugin directory? Perhaps. But we’re not writing code for mass use or mass support, we’re writing code specific to WordPress.org in order to make WordPress.org better. And that should be our focus.

      If we write something that makes sense as a “mass-market” plugin instead of being checked into meta.svn, I think we’ll know it when we see it. Most of the plugins I have seen running on WordPress.org (many of which I wrote) are just a few adjustments using filters. When the handbooks plugin becomes more than a set of hacks and actually has a decent, matured feature set, I think it could be a fine plugin. For reasons stated above, I wouldn’t publish this particular plugin to the directory, but that decision is totally up to you.

      • Jen Mylo 7:23 pm on September 10, 2013 Permalink | Log in to Reply

        I agree with @iandunn, that this instance is a general plugin not specific to the wordpress.org setup (I have had feature requests for it before from WC organizers and meetup groups, for example, who use P2). That said, if the wordpress.org team won’t support it and it’s just Ian writing it, then we could get around the “WordPress thinks this is worth releasing and supporting and building a community around” implication by having Ian release it in the repo with Automattic rather than .org as the author. Since p2 comes from Automattic also, and Ian is employed by Automattic, that wouldn’t be weird. Then .org would just be a user of it instead of an official party.

    • Bryan Petty 8:37 am on September 9, 2013 Permalink | Log in to Reply

      I tend to agree with @nacin here, and just have a couple other thoughts to add.

      With everything running on W.org actually managed and maintained on meta, it’s all in one spot where anyone who wants to contribute knows where to go rather than maintaining a secondary list of W.org sites, and which plugins in the whole directory are installed and being used at any given time. Of course, this mostly echoes the notion that this is for W.org, not anyone else.

      I guess nacin already covered this as well, but it’s worth reiterating that a *lot* of these plugins are frequently going to be minor filters, adjustments, and system hooks very specific to W.org, and those definitely are not going to be worth the trouble of listing individually on the plugins repo, so there’s already going to be stuff maintained in meta regardless. Might as well leave the rest there too unless it absolutely makes sense to publicly offer it as a usable plugin to the masses, and those can be handled on a case-by-case basis.

    • Sam Sidler 6:34 pm on September 9, 2013 Permalink | Log in to Reply

      I also agree with @nacin and @bpetty. I don’t think this should be something we push for, but when it makes sense, if the plugin developer (in this case, you) wants to do so, they can. But even in that case, we’d still want to pull in the plugin from the meta svn and not the plugin directory.

      • Ian Dunn 2:18 pm on September 10, 2013 Permalink | Log in to Reply

        Nah, I don’t think it’d be good to maintain two different copies. I’m fine w/ just using Meta for this since that’s what everyone else wants.

  • Samuel Wood (Otto) 10:00 pm on October 29, 2012 Permalink |
    Tags: , meta, , reviews   

    Welcome to Meta (with a feature!) 

    During the WordPress Community Summit pre-planning sessions, it became obvious that there’s not a lot of good communication about what we do, plan, and code for the WordPress.org website itself. So, after a bit of chatter, Make-Meta was born. This is where we plan on talking about changes to the WordPress.org site, as well soliciting feedback for feature ideas. Consider it a community site; we don’t always know what the best way to make the website work is, so feedback is not just welcome, but encouraged.

    In order to kick things off properly, I figured I’d announce a new feature: Reviews!

    After a lot of discussion, it became clear that a “plugin review” concept was very much desired by the community in general. So we implemented reviews, but didn’t bother to limit it to just plugins. So now, plugins and themes can have reviews.

    In order to keep things straight, reviews are tied to ratings. In order to rate a plugin, you must write a review as well. All the old ratings are still there and won’t be going away (we use those, after all), but if you want to change your rating in the future, well, explain it. Tell your side of the story. What’s broken? What works? What’s the best and the worst of the code? How can the plugin or theme author improve it?

    Communication is important, and “support” is only half of the equation. Feedback is critical, and hopefully, the new Reviews system will go a long way to improving communication between the many millions of users of code we host on WordPress.org and the many thousands of contributors who write the themes and plugins that we all use every day. And all reviews go into our forums and can be commented on by everybody, just in case somebody needs some extra help.

    (Note to Plugin/Theme authors: You can subscribe to your reviews alone via RSS feed, but the email subscription is cross-tied to the support-forum email subscriptions. If you’re subscribed to those, you will get review emails as well.)

    There won’t be a lot of reviews at first, but hey, that’s where you come in! Just to get everybody started, I went ahead and wrote a couple of reviews to kick things off. So if you want to see it in action immediately, you can see them here:


    These are accessible for any plugin or theme through the “Reviews” tab. Alternately, try to rate a plugin or theme and you’ll be sent to the review form as well.

    Note that this is “iteration 1” of the feature. I expect to make many visual and stylistic changes over the next couple of weeks, and perhaps add a few new features. If you have a great idea for a feature or enhancement, feel free to comment and let me know. (Don’t bother me with the visual-only stuff yet, I know the CSS needs some love. Also, reviews don’t really display all that well on profiles yet; I know, working on it.)

    BTW, the majority of the code to power the reviews came from our own Scott Reilly, who is, frankly, a genius. Give him mega props. 🙂

    • Rarst 10:26 pm on October 29, 2012 Permalink | Log in to Reply

      For some reason review form on those example links is filled with text of your review, which doesn’t quite make sense?..

    • Mert Yazicioglu 10:56 pm on October 29, 2012 Permalink | Log in to Reply

      Great news!

      By the way, there is a textbox right after the text “Select the version of WordPress you are using”.

    • Austin Passy 11:16 pm on October 29, 2012 Permalink | Log in to Reply

      Props Scott.

    • nofearinc 11:29 pm on October 29, 2012 Permalink | Log in to Reply

      It’s an awesome feature that would prevent plugin/theme authors from getting anonymous 1-star ratings with no elaboration. Not sure if that’s implemented, but a minimum review length might be handy as well (for the same reason).

      The email communication is always good to have, if possible, as an extra extension to the other notification system.

      And welcome to Meta as well 🙂

    • Shane Pearlman 12:15 am on October 30, 2012 Permalink | Log in to Reply

      just wrote a ton of feedback and it vanished – checking to see if i am on pending status or if I should just sigh and feel sad.

      • Shane Pearlman 12:22 am on October 30, 2012 Permalink | Log in to Reply

        oh balls. ok the short version:

        This is EPIC. So Glad to see it.

        • add “7 reviews” somewhere on description right rail http://cl.ly/KYh1 – wonder if we filter by version like the apple store?
        • would be nice to show the version of WP reviewed on the theme: http://cl.ly/KY1W (I don’t see it) and the version of the theme / plugin the review is based upon. Bad version can happen and it is nice to know.
        • love that we can reply to reviews (thank you thank you), from a simple ux perspective, might be nice to have a “reply” link next to “0 comments”
        • look forward to seeing a hint of “credibility” added to the reviewer. Something which tells you what they have contributed without having to click on their name – maybe badges or just simple text with “37 reviews | 4 plugins | 2 themes | 18 core patches | core contributor | 108 relevant articles” – although I have no idea how to do the last one, I do believe that is a form of credibility that would be nice to track.

        that all I can remember with the time I have.

        Go team!

        • Mike Schinkel 5:24 am on October 30, 2012 Permalink | Log in to Reply

          One concern about version ratings is that most plugins have very few ratings across version, splitting them across versions makes their ratings even less valid. And it’s relevant if a plugin has had bad ratings all it’s prior versions but the new version is posted that gets high ratings from a handful of friends. Not suggesting version ratings are bad but that they will have unintended consequences which need to be considered before diving in with another change.

          Frankly I’d like to see multiple dimensional ratings that not only indicate rating but indicate a confidence level based on the number of ratings. 4.5 stars from 500 people means a lot more to me than 5 stars from 3 people. Maybe this could be accomplished with color, from dull gray to bright yellow and several levels between on an exponential scale. A small number of 5 star ratings get you a dull grey 5 stars and 500 four stars get you bright yellow stars?

          As far as credibility, I wish they’d factor in StackExchange’s WordPress Answers rep. Just saying… 🙂

    • Matt Mullenweg 2:48 am on October 30, 2012 Permalink | Log in to Reply

      Should we zero out all the old ratings, they don’t have any context.

      You should be able to click a review number bar (under the stars) and see all the reviews at that level.


      • Shane Pearlman 4:09 am on October 30, 2012 Permalink | Log in to Reply

        There is a wealth of plugins & themes that have earned a strong (or mixed or poor) reputation over the years. Until this new feature matures it would leave .org users with little guidance.

        Maybe we could do something like apple did with app version?

      • Samuel Wood (Otto) 4:33 am on October 30, 2012 Permalink | Log in to Reply

        Lets give it some time before dumping the old ratings data, see how well it works.

        The bars link is a good idea, I’ll look into it.

    • Ray 3:30 am on October 30, 2012 Permalink | Log in to Reply

      Question about moderating reviews. What if someone is trolling a plugin author or plugin? It’s bound to happen. Is a report mechanism in the works?

    • Michael Torbert 3:34 am on October 30, 2012 Permalink | Log in to Reply

      This is very awesome. Imagine if for every one star rating one of my plugins has ever received, I got some useful feedback that could turn it into a 5 star.
      Great work Otto!

    • Mike Little 6:53 am on October 30, 2012 Permalink | Log in to Reply

      This is great. Looking forward to it maturing.

      BTW: There’s no Subscribe form in the sidebar. So I had to comment to be able to tick the notify box.

    • scribu 2:26 pm on October 30, 2012 Permalink | Log in to Reply

      Works pretty well. One thing I would like is if the star rating showed up somewhere while viewing the review in the support forums. For example, when I go here:


      It would be nice to have the rating given by that user in the sidebar or on the left, under the user details.

      • Samuel Wood (Otto) 3:45 pm on October 31, 2012 Permalink | Log in to Reply

        I decided to make it a little more obvious and put it under the topic title.

        Note that I wasn’t saving the data correctly before to implement this, but I am now. So ratings made starting now (including edits to existing reviews) will show the stars from now on.

        Check out my original 2 review topics to see the stars on them.

    • Joost de Valk 6:06 pm on October 30, 2012 Permalink | Log in to Reply

      Awesomness! This blog is not in the feed list on https://make.wordpress.org/ yet 🙂

      • Samuel Wood (Otto) 7:47 pm on October 30, 2012 Permalink | Log in to Reply

        There’s a reason for that. Looking at redoing that in a different way.

        • Ryan McCue 3:20 am on October 31, 2012 Permalink | Log in to Reply

          I don’t have posting privileges here, but I’m willing to work on this as mentioned at #wpcs. Should I file this on Trac?

          • Samuel Wood (Otto) 5:00 am on October 31, 2012 Permalink | Log in to Reply

            You know, I personally don’t like w.org refinements being on the core trac. I think it’s additional clutter. Some may disagree.

            Maybe we need to come up with a better way and/or a separate trac. Regardless, let’s sort out some ideas before putting anything on trac about it. Like we discussed, a simple design would be good, just a way to sort of showcase what’s going on everywhere, sort of thing.

            • Shane Pearlman 2:34 pm on November 2, 2012 Permalink

              We’re probably down to contribute some code for .org as well. My support team let me have it yesterday with issues they are facing that could be truly easily resolved with less than a day of code. I told them to write me a blog post and then I’d share it with the community. If you buy off, then we can discuss contributing.


              A simple message at the top of the support tab would be a serious tool. There is no easy way to set expectations for users. We have had 2 people this week complain that the plugin is unsupported and write a bunch of vitriol when no one replied to their post on .org in 24 hours on a weekend. We need a way to let people know how much support we can offer, and when we are out on holiday etc.

              A quick comp example: http://cl.ly/KceM

            • Jane Wells 9:35 pm on November 25, 2012 Permalink

              I also think they should not be on core trac, but a separate trac or whatever.

              I did a sketch a while back for a make landing page, then revised it at wpcs. Will look for it and post as a proposal. I think we didn’t move on it at the time bc it wasn’t perfect, but it was a good example of letting perfect be the enemy of the better. Almost anything would be better than the RSS collection we have now. I went and looked at a bunch of other FLOSS projects’ Get Involved landing pages today (list at https://make.wordpress.org/community/floss-community-programs/ ), and think what we talked about doing at wpcs is still a good idea.

              Side note: as all the new groups get going, there will be a lot of crossover with the Meta group as feature requests and or design/content work comes out of the new groups. We should figure out how/where to handle that, so improvements aren’t worked on in parallel/vacuums, but together.

            • Samuel Wood (Otto) 12:59 am on November 26, 2012 Permalink

              I’m perfectly okay with changing the base make site, we just need a design or an idea of one.

    • Samuel Wood (Otto) 7:48 pm on October 30, 2012 Permalink | Log in to Reply

      For reference, ratings were acting weird and wonky. I think I’ve finally sorted out the issues there though. If your rating didn’t appear to save properly, or isn’t showing up, just re-save your review with the fixed rating, and it should sort itself out.

    • Dougal Campbell 6:07 pm on November 2, 2012 Permalink | Log in to Reply

      Buglet? Can’t seem to login directly from a review page view. Redirects back to same page, but not logged in.

      • Samuel Wood (Otto) 4:22 am on November 6, 2012 Permalink | Log in to Reply

        Login appears to work fine for me on the review view pages. No reason I can think of for them to be special in that respect, actually, the view is just a view like any other there, with no special login handling code on them.

    • Samuel Wood (Otto) 4:23 am on November 6, 2012 Permalink | Log in to Reply

      Bug fix: it is now possible for a person to actually review more than one theme and have it saved. If you tried and found your old review removed, whoops. Sorry about that. It works okay now.

    • Marko Heijnen 4:40 pm on November 6, 2012 Permalink | Log in to Reply

      I just received my first review and the mail wasn’t clear for me. The Subject only has the title of the review and not showing about which plugin it is

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar