Updates from December, 2010 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 8:00 pm on December 31, 2010 Permalink | Reply
    Tags:   

    The published exploit for WordPress 3.0.4 isn’t accurate 

    We were informed yesterday of a published vulnerability for WordPress 3.0.4, “Stored XSS (via Editor role)”.

    This is an invalid report. (Edit: The exploit has been delisted by the database.)

    The dead giveaway was the title: “via Editor role.” In WordPress, users with the role of Editor or Administrator have the ability to post unfiltered HTML. It has always been like this.

    From the Security FAQ on the Codex:

    Users with Administrator or Editor privileges are allowed to publish unfiltered HTML in post titles and content. WordPress is, after all, a publishing tool, and people need to be able to include whatever markup they need to communicate. Users with lesser privileges are not allowed to post unfiltered content.

    We also issue a warning for security researchers, which wasn’t followed here:

    If you are running security tests against WordPress, use a lesser privileged user so that all content is filtered.

    How to change this behavior

    In multisite, only super administrators can publish unfiltered HTML. All other users are considered untrusted in this case, as they can be administrators for their own sites. (There is a plugin to restore unfiltered HTML to editors and regular administrators in this case, if you trust those users: Unfiltered MU.)

    There’s a constant you can use to disallow unfiltered HTML for everyone, including administrators and super administrators. To disallow unfiltered HTML for all users, you can add this to wp-config.php:

    define( 'DISALLOW_UNFILTERED_HTML', true );

    Filtered HTML for Editors

    To deny unfiltered HTML for Editors, try the Filtered HTML for Editors plugin, which I put together today. The description and FAQ go into much of what was covered here.

    How to report security vulnerabilities

    Standard practice when finding a security vulnerability is to privately notify the vendor and give them an opportunity to respond and prepare a fix for public release. It’s the concept of responsible disclosure. We’ll always credit responsible disclosure in the release announcement as the person requests, such as with a link to your blog.

    For WordPress, suspected vulnerabilities can be privately emailed to our security team at security@wordpress.org.

    Unfortunately, not everyone follows responsible disclosure. In the case of 3.0.4, an exploit published regarding 3.0.3 forced our hand to release the fix we had been privately testing (thanks to responsible disclosure). This can sometimes force our hand in very bad ways — the fixes included in 3.0.4 were very complicated and involved more than a hundred hours of work from more than a dozen individuals. Had we rushed a release due to a public announcement, we might have missed something.

    Not following responsible disclosure also prevents us from responding to invalid reports. Unfiltered HTML results in false reports every so often. The fact that this was published as an exploit, without any confirmation or notification, only contributes to FUD and perception issues.

    The status of WordPress 3.0.4

    This all said, there are currently no known vulnerabilities for WordPress 3.0.4. I’ll go knock on wood now.

     
    • Andrew Nacin 9:48 pm on December 31, 2010 Permalink | Reply

      The report is being removed from the exploit DB. I’ve updated the post.

    • Travis Miller 4:15 pm on January 3, 2011 Permalink | Reply

      Hi Andrew -

      Thanks for the update. I’ve been trying to research this security patch, and a few things still aren’t clear.

      1. Do I need to upgrade my 3.x sites to 3.0.4, or not? This post seems to be saying that the vulnerability that 3.0.4 supposedly fixes did not exist in the first place. Am I understanding that correctly?

      2. If there *is* a vulnerability, does it exist in the 2.x branch as well, or only 3.x?

      3. If the vulnerability does exist in 2.x, is there an official or quasi-official patch for that branch, or am I stuck doing a major version upgrade from 2.x to 3.x?

      Sorry if this isn’t the best venue for this question – comments are closed on the post on the main WordPress blog, so I can’t ask there. I’m sure others in the WordPress community would appreciate some clarification on these questions.

      • Jane Wells 4:31 pm on January 3, 2011 Permalink | Reply

        Hi Travis. I think you misunderstood Andrew’s post. After 3.0.4 came out, a website started reporting that there was a new vulnerability. That is the one that is invalid. Yes, you should update to 3.0.4. The 2.x versions are no longer supported, so please please update to the most current version. If you are still running 2.x versions, you are likely facing multiple vulnerabilities.

    • Travis Miller 6:58 pm on January 3, 2011 Permalink | Reply

      Thanks, Jane. You’re correct; I misunderstood the post. Thanks for the info.

  • Jane Wells 5:22 pm on December 28, 2010 Permalink | Reply
    Tags:   

    Agenda for dev chat tomorrow, 12/29/10, the last one of the year:

    • What do we need to do to get from RC1 to launch for 3.1. Top Priority.
    • Code-in: we need more people willing to review tickets and act as mentors. please volunteer if you are a regular core contributor. Pick a couple of tickets in the future release milestone that you want to see happen, post them in the code-in app, if a student picks one, when they return with a patch within a few days, look it over and say pass, need more work (make suggestions), or no good. Anyone? Bueller?
    • Priorities for 2011. Core leadership meetup will be Jan 10-16 this year, posted about it on .org main blog and created a forum thread to take suggestions and questions for video town hall. Thinking maybe we’ll time the town hall during normal dev chat time that week, but will post when we hack out a schedule.
     
    • pexysedinny 6:51 am on December 29, 2010 Permalink | Reply

      Hi:

      I’ve been keeping an eye on wpdevel.wordpress.com as a lurker for your time now.
      I elected that I need to get involved and socialize with the other folks here.
      I’m expecting to join a lot of interesting people and discover some incredible stuff.

      I hope this post did not get put in an inappropriate category. I aplogize if this is incorrect.

      ——————–

      DARNELL MCKINNEY
      Audiovisual Production Specialist

      • Jane Wells 4:35 pm on January 3, 2011 Permalink | Reply

        Hi Darnell. If you want to get involved in development, this is the right place. If you want to get involved in design, try http://make.wordpress.org/ui. And one of the best and easiest ways to get involved is to help people in the support forums. Not only does it give back to the community, but it keeps you in touch with what the biggest issues are.

  • Jane Wells 2:52 pm on December 23, 2010 Permalink | Reply
    Tags:   

    As everyone knows, we’re behind on the 3.1 release schedule, and as we have not hit RC yet, it’s unlikely we’ll release before the end of the year. Sad Christmas. There are 11 tickets in the milestone right now. I know it’s the holidays, so people are busy, but it also means people are taking time off work and hanging around killing time in a lot of cases, so if everyone could pitch in and test the crap out of things, that would be great.

    This release has had fewer contributors than previous ones, and while some put that on the shorter dev cycle, I don’t know that that’s really right, since 3 months in on any release we usually have more activity. It’s easy to leave it all to @nacin since he’s fast and everything, but we really need more people trying to break things and find actual technical bugs to help ensure that we don’t wind up shipping a release that hasn’t been widely tested. Thanks!

    (And happy holidays! Today specifically, happy Festivus!)

     
    • Darnell Clayton 6:36 pm on December 23, 2010 Permalink | Reply

      Festivus for the rest of us! Ironically when I was high school, I had a teacher who would “punish” students in detention by forcing them to watch episodes of Seinfeld. We all became addicts after a few weeks. ;-)

      Perhaps I’ll consider “upgrading” one of my other blogs in order to test out 3.1 features. After Christmas that is (as I have to make sure my theme is compatible with 3.1 first).

    • Jon Brown 7:10 pm on December 23, 2010 Permalink | Reply

      I think the last sentence of Darnell’s comments says it, “waiting for theme support”

      Arguably the biggest feature/incentive to test 3.1 is post formats which requires extensive theme support it’s not nearly as easy to add as featured images or menu support.

      That said thanks to your plea I’m installing 3.1 on three sites today.

    • Denis 6:25 pm on December 24, 2010 Permalink | Reply

      Happy Christmas!

      And many thank you for not ruining my own year end vacation by releasing on schedule. ;-)

    • Malcjohn 9:56 pm on December 24, 2010 Permalink | Reply

      Hi peope behind the WP. It’s important to say that WP is great (i also use it) and i hope that you will continue to release new versions, doesn’t matter when. I am a fan of WP, but i cant help you with PHP, just some easy HTML.

      But i want to say one thing. It’s very, very important. I will not criticise the “production of next version”, but i will tell you the truth.
      As far as i know : somebody says “the next realse will be on 15.7.20xx ” and the major improvements are …….
      Afterwards, admin make a timetable and tickets starts to be doing.

      So from this moment its a bad start to close tickets. Nobody should says when the next release will be published. It’s better to say : “we will close 250 tickets, doesn’t matter which one” (look in the trac, some tickets are should be closed in 2009 <<< something is wrong !) and only then realese a new version. We don't need a huge improvments, "but be with time" ( for example : HTML5,CSS3 etc., or just to maintain the hole WP, thought bugs etc. )

      Also i must tell, that there isn't any marketing for devs. Of course, some WP sites publish arcticles (for users only), but we have to make marketing also for the developers !!! Only they can help us to make WP better. We have less people working on it and everybody (matt, jenne) has to convience devs and just normally people to work on WP in trac. It should be prestige to work for WP, as the same for HTML5 in W3C.

      So my recommendations are :

      complettly change the release plan (dev cycle plan). Start thinking hard on a change for pre-production of next WP.

      make a lot of marketing for devs, some bonus for them. NOT MONEY, but something which matt and jenne must made up. (some small gifts). Just make WP valuable to contribute

      I really like WP and a huge thanks to nacin and other people who make it. But we have to change our habbits and start a new period of WP

      Merry Christmas to everybody.
      John from Prague,

      • Jane Wells 4:38 pm on January 3, 2011 Permalink | Reply

        Hi John. I’m sorry, but we disagree. Saying we should close 250 tickets and it doesn’t matter which ones, would mean we could have 250 tiny bugs and miss bigger ones, or that we do 250 feature tickets and don’t touch any bugs. Our releases get much more serious thought given to them, and will continue to do so. The best way to get involved for developers is to start writing patches, following the irc chats, seeing how things play out on tickets.

    • hakre 12:08 pm on December 25, 2010 Permalink | Reply

      Happy Christmas and Holidays!

      I hope all developers and contributors can re-charge their batteries these days for the amazing things to come. Enjoy yourself, family and friends.

    • Keith B Broadbent 3:15 pm on December 25, 2010 Permalink | Reply

      how can I help. i have extensive experience in WP, just had a class in html and css, working with adobe cs5

      • Jane Wells 4:40 pm on January 3, 2011 Permalink | Reply

        Testing the development beta/RC versions to help us find bugs is always good. Helping people in the forums is always good. Right now, at the tail end of the dev cycle, there’s not much to do re design or lightweight html/css, as we are only fixing unexpected bugs. We’ll start a new dev cycle the third week of January.

    • Malcjohn 6:27 pm on January 3, 2011 Permalink | Reply

      OK, it was my opinion. Still we should not say, the next realese will be xx.xx.xx, but say “when it will be, than it will be” . The same does Blizzard, a game company with their games

  • Otto 10:18 pm on December 22, 2010 Permalink | Reply
    Tags: , ,   

    It was pointed out to me that I never mentioned it anywhere when I made this change last month, but the plugin search engine at http://wordpress.org/extend/plugins/ has been much improved. So now when you search for things like “buddypress”, you should get what you’re looking for on the first page of results more often.

    It was a minor adjustment, so it didn’t occur to me to tell anybody. Sorry about that. :)

     
    • Valentinas 10:45 pm on December 22, 2010 Permalink | Reply

      Well try to search for ad-minister. Other search strings to test: wp-e-commerce, wp-ad-manager, basically anything that has wp prefix will produce the same search results. And you know there’s plenty of plugins with that prefix.

      • Otto 10:58 pm on December 22, 2010 Permalink | Reply

        The search engine treats dashes as search operators. Meaning foo-bar searches for items containg foo but NOT bar.

        Leave out the dashes when searching, for now.

        • Jane Wells 5:03 am on December 23, 2010 Permalink

          Maybe drop a text instruction to that effect on the plugins search page? People search for wp e-commerce all the time.

        • Otto 12:25 pm on December 23, 2010 Permalink

          Jane: I was planning on just fixing it so it didn’t do that, actually. Nacin’s idea was the same one I was planning on implementing.

        • Otto 1:05 pm on December 23, 2010 Permalink

          Done. Hyphens now get escaped properly for the search when they don’t have spaces around them. So “e-commerce” will actually search for that as a word instead of considering it to be a control character. You can still use a hyphen in front of a word for exclusion, as long as it doesn’t have some other word character in front of the hyphen.

      • Andrew Nacin 12:03 am on December 23, 2010 Permalink | Reply

        We can probably make it convert hyphens into spaces if the hyphen isn’t preceded by a space. I’ll check it out.

    • Bill Erickson 12:49 am on December 23, 2010 Permalink | Reply

      When I search for Contact Form 7, the plugin shows up on the second page, even though I search for its exact name. This has been bugging me for about a month :)

      • Otto 1:47 am on December 23, 2010 Permalink | Reply

        Yep. But, that’s a pretty generic title too. I didn’t say it was perfect, just better. :)

        • Jane Wells 5:03 am on December 23, 2010 Permalink

          Actually, I think it used to come up as one of the first results, so for that one it looks like a loss. There are a couple I can’t find by searching now. What was changed to the search/what’s it searching now? If there are things we can do to the plugin metadata or readme files or whatever to make them more findable with the new search, we can publicize it.

        • Otto 12:29 pm on December 23, 2010 Permalink

          Basically, I added extra weighting to the title, gave the tags a bit more weight, and turned on the “extended” matching mode, which makes it actually use the weights. Before it was in a simple text-only keyword search mode, which didn’t use any relevance or closeness matching at all.

          The thing is that “Contact Form” is a fairly generic name, and while it does give the title a lot of boosting, every single one of the results on the first two pages has “Contact Form” in its title.

        • Sergey Biryukov 3:25 pm on December 23, 2010 Permalink

          Perhaps if there’s an exact match, it can go first?

      • Valentinas 10:37 pm on December 23, 2010 Permalink | Reply

        Yes, I wanted suggest the same as Sergey, exact match should definitely be the first.

        • Otto 10:52 pm on December 23, 2010 Permalink

          Well, that’s not the easiest thing to do in the world. The question is what do you define as an exact match?

          The Sphinx search engine works based on phrase matching. Now, in the particular case of “Contact Form 7″, the 7 is pretty much being ignored because it’s too short. So we’re really talking about “Contact Form” here. Note that it doesn’t much matter even if we were talking about the full “Contact Form 7″ because several of the other plugins above it also have “Contact Form 7″ in their titles as well.

          And that’s the trick. The whole thing is based on a weighting algorithim. I gave titles a lot of weight specifically in order to push title matches up to the top, but in this case, all the ones that show up in the top 20 results have “Contact Form” in their titles. Several of them have “Contact Form 7″ in their titles as well, because they’re addons to it or what have you. So how is the search really supposed to know that “Contact Form 7″ is more important than “Contact Form 7 Addon”? Sphinx doesn’t give extra weight to “whole” titles.

          I also give a bit of extra weight to tags, which is probably why some of those are coming up a bit higher than others. The relevance scores are all pretty close right there.

          Basically, doing exact whole-phrase matches in Sphinx is kind of a hacky PITA, involving adding extra data to the database using delimiters for before and after and such. I’d prefer to get the 90% solution where people are searching for keywords and titles and having it get close-enough rather than adding a ton of extra data just to cover that one particular case. Especially when the case involves a really generic title like “Contact Form”.

          So Protip for code authors: Come up with a unique name to be listed higher in searches. This is not specific to our search engine.

        • Matt 10:57 pm on December 23, 2010 Permalink

          We’re not really discussing matching, but ranking. I think it’s fair to, given the results that Sphinx returns, re-order based on a metric like popularity or bump exact match (search == title) to the top.

        • Otto 10:59 pm on December 23, 2010 Permalink

          Popularity ordering is already there if somebody wants to use it: http://wordpress.org/extend/plugins/search.php?q=Contact+Form+7&sort=popular

        • Matt 11:01 pm on December 23, 2010 Permalink

          I guess it’s odd to me that popularity and rating are not part of relevance — if you think outside of the strict-matching sense of relevance, they’re all really one and the same. Whichever provides the best results to the most people should just be the default.

        • Otto 11:11 pm on December 23, 2010 Permalink

          Ordering by rating is already there too: http://wordpress.org/extend/plugins/search.php?q=Contact+Form+7&sort=top-rated

          But I find the other side of this odd, really. It doesn’t make a whole lot of sense to me that popularity and rating have anything to do with relevance. Relevance is really more a measure of how well the plugin’s description/name/tags/whatever fits the keywords/phrase you’re searching for. In other words, relevance is about the plugin itself and your search query, not about user-generated meta data about the plugin like popularity or ratings.

          Could we include rating and popularity as a metric? Probably, but I’d have to investigate Sphinx in more depth. Those fields are not stored in the Sphinx database right now for sure, so it can’t include them in the relevance matching algorithm.

        • Otto 11:14 pm on December 23, 2010 Permalink

          Scratch that, they are in there (rating and downloads over the last week), so they can be used. I’ll do some testing, see if it makes any difference.

        • Matt 11:16 pm on December 23, 2010 Permalink

          I don’t think most people think of relevance that way. The core bug is you type in the name of one of the top ten most used plugins in the world and it doesn’t come up in the first page.

          Type “akismet” and Akismet is #5.

          Type “stats” and you see a page with 2 results, and 40 pages. (The counting/paging bug mentioned.)

          My goal is to not give people multiple ranking options for the plugin search, just to have one that always gives you the results you’re looking for.

        • Otto 11:19 pm on December 23, 2010 Permalink

          Yes, but everything is a tradeoff. At what cost do we bump more popular plugins? The cost is that less popular, but possibly better or more useful, plugins get bumped down.

          Moving exact whole-title matches to the top is one thing (technically tricky, actually, but doable), but counting popularity and rating in seems different to me.

        • Andy Skelton 11:25 pm on December 23, 2010 Permalink

          Stats and Akismet are good test cases. Almost any plugin can legitimately use the word “stats” in its description and many could reference Akismet, but a title including such words indicates extreme relevance. Titles are always more relevant than descriptions.

        • Otto 11:27 pm on December 23, 2010 Permalink

          This is the problem with generic phrases. “stats” has 591 results over 74 pages, and the first several dozen (at least) have the word “stats” in their titles.

          I’m doing more testing/tweaking to it now.

        • Otto 11:29 pm on December 23, 2010 Permalink

          Also, the title of the plugin is actually “WordPress.com Stats”, so an exact matching check wouldn’t help it out there for “stats” anyway. Slugs are not included in the search system at all.

        • Otto 12:13 am on December 24, 2010 Permalink

          Still looking at how to bump an exact title match to the top (this requires bypassing the search engine results to make it work), but after looking at the weights, I can at least tell you some specifics of why you see the results you see.

          Akismet is 5th because the other 4 above it include “Akismet” as a tag. So they get bumped for that.

          WordPress.com Stats: Same problem. The ones above it have tags with “stats” in them.

        • Andy Skelton 1:19 am on December 24, 2010 Permalink

          WordPress.com Stats has “stats” as a tag.

        • Valentinas 3:33 am on December 24, 2010 Permalink

          Some thought on why akismet should be first:

          Download count (maybe take into account how many copies were downloaded recently). So up to 10.000 downloads – 0%, 10k-100k: 0.1%, 100k-1m: 1%, 1M-10M: 10% and so on..
          Vote count (probably the same as download count, just different numbers, 100 votes – 1%, 500 votes – 10% and so on)
          Vote value (only take into account if has 50 or more votes): 1 star: -10%,2: -5%, 3: 0%, 4: +5%, 5L +10%.

          compactability (also only take into account if 10 or more votes)….

          and so on..
          I think these properties are good way to tell if the plugin is good or not. So by combining them with relevance you should be able to get good results. Of course this kind of stuff requires fine tuning..

          As Matt mentioned, you should test the search engine with top plugins. also do you have analytics running on plugins directory? would be a good idea to look at what keywords brings people to certain plugins and test with them.

        • Peter Westwood 7:53 am on December 24, 2010 Permalink

          To me the preferences for sorting would be:

          1. Exact Match in Title
          2. Order by install count / rating – download count is meaningless to me as it is too easily affected by having 100s of plugins release versions for minor buglets

        • jb510 8:57 am on December 24, 2010 Permalink

          Thinking a little outside the box, Otto is right each search category (rel, new, upd, pop, rating) is there, but what I really want is the ability to combine those types of search. I want the radio buttons to be check boxes so I can search for “relevance” AND “popularity”.

          Also, I wonder if you couldn’t add the abilty to search for exact name matches by entering the plugin name in quotes, ie. “Contact Form 7″?

        • Valentinas 9:23 am on December 24, 2010 Permalink

          jb510, that would be useful for advanced user, but what i’d like to have is something like Google (I think we can agree, that Google is an example of good search :) ). You don’t have any “popularity” or “relevance” or anything in Google, all you do is enter the name ( like before mentioned “contact form 7″) and you get the result. Google sells their search engine ( http://www.google.com/enterprise/search/mini.html ), but that may be not an option for WP, since it’s quite expensive (starts from $3000).

          Other than that idea about ability to search for exact name sounds pretty good (maybe even with a fallback to regular search informing the user about that – “we couldn’t find exact match for your query, but here’s some similar results”).

        • Otto 11:11 pm on December 29, 2010 Permalink

          Exact name/slug matches (or fairly close) now get bumped to the top of search results.

          In doing this, I discovered a case where results can be duplicated as well. it’s been there a while, but nobody noticed. That will take more time to figure out how to clean up.

        • Otto 10:30 pm on January 4, 2011 Permalink

          Duplicate search results removed. These were rare, but they’re gone now.

    • Rich Pedley 8:15 am on December 23, 2010 Permalink | Reply

      either the number of search results is still incorrect, or we are missing page links.

      • Otto 12:38 pm on December 23, 2010 Permalink | Reply

        The page links code was slightly off. It didn’t have the correct number set for its “per_page” count, so it had the wrong number of pages. I’ve corrected it.

        • Rich Pedley 3:26 pm on December 23, 2010 Permalink

          nope still broke. search for eshop:
          Showing 1-6 of 10 plugins with 6 displayed
          page shows 9-9 of 10 plugins , and only 1 displayed

          and why 6 per page, seems a weird amount.

        • Rich Pedley 3:28 pm on December 23, 2010 Permalink

          sorry that should have been page 2 shows 9-9etc

        • Otto 3:30 pm on December 23, 2010 Permalink

          I don’t know what you’re seeing, but for “eshop” it shows me 1-8 out of 10, with 2 pages. Works properly.

        • Otto 3:33 pm on December 23, 2010 Permalink

          Ahh, okay, actually you’re seeing different results because you are not an admin who can see the hidden plugins. Basically those are plugins that have been entered and approved but which no code has been uploaded for them yet. So they are getting removed from your display, but not from the total count.

          I’ll look closer at fixing that. But the normal display is 8 per page. If you see less, then the search is finding “unfinished” plugins then hiding them.

        • Rich Pedley 10:59 am on December 24, 2010 Permalink

          Yeah that would explain it – but won’t help others ;) Majority of people searching are not admins.

          and even so, 8 per page seems weird, can’t you bump it to 10? or is there some reason that octal rather than decimal is being used? Or even better a drop down selection to show 10/25/50 per page.

        • Rich Pedley 12:59 pm on January 3, 2011 Permalink

          a search for directorypress is returning this in the results:
          http://wordpress.org/extend/plugins/directorypress/
          but that plugin no longer exists, so I’m guessing it got removed. But it’s still being found when searching.

        • Otto 7:51 pm on January 3, 2011 Permalink

          Fixed. Numbers for searches are still going to be a bit off though. Working on it.

  • Joseph Scott 10:01 pm on December 17, 2010 Permalink | Reply
    Tags:   

    Akismet 2.5.1 is now out, with several fixes for 2.5.0 items:

    • Fix a bug that caused the “Auto delete” option to fail to discard comments correctly
    • Remove the comment nonce form field from the ‘Akismet Configuration’ page in favor of using a filter, akismet_comment_nonce
    • Fixed padding bug in “author” column of posts screen
    • Added margin-top to “cleared by …” badges on dashboard
    • Fix possible error when calling akismet_cron_recheck()
    • Fix more PHP warnings
    • Clean up XHTML warnings for comment nonce
    • Fix for possible condition where scheduled comment re-checks could get stuck
    • Clean up the comment meta details after deleting a comment
    • Only show the status badge if the comment status has been changed by someone/something other than Akismet
    • Show a ‘History’ link in the row-actions
    • Translation fixes
    • Reduced font-size on author name
    • Moved “flagged by…” notification to top right corner of comment container and removed heavy styling
    • Hid “flagged by…” notification while on dashboard

    We’d like to get 2.5.1 in as part of the WP3.1 release

     
  • Andrew Nacin 9:50 pm on December 17, 2010 Permalink | Reply
    Tags: i18n-change, string freeze,   

    i18n-change: It’s that time again. This keyword must be used on any tickets that may or need to lead to a string change from now until the end of the cycle. We’ll use this to track when to call the string freeze, and then to track any times we need to break the freeze. (I will update the translators as necessary over at http://wppolyglots.wordpress.com.)

     
  • Otto 9:17 pm on December 16, 2010 Permalink | Reply
    Tags: ,   

    Profiles now shows up-to-date info from the various trac installs once again. It won’t be up-to-the-minute, but it will be updating on a somewhat regular basis.
    Example: http://profiles.wordpress.org/users/nacin

     
    • Peter Westwood 9:19 pm on December 16, 2010 Permalink | Reply

      Great.

      I still find it mildly amusing to have this at the bottom of my profile :-D

      Tuesday June 28th, 2005 – Started a new topic in the WP.org support forums

      Old Skool!

      • Alex M. 9:21 pm on December 16, 2010 Permalink | Reply

        Mine doesn’t show my posts/threads from back in 2003. :(

    • filosofo 9:25 pm on December 16, 2010 Permalink | Reply

      Could you explain the logic, or is it still not working right? The two most recent core Trac events it shows for me are one from today and one from March 25. I think I’ve opened about 80 tickets in the intervening time.

      • Otto 9:26 pm on December 16, 2010 Permalink | Reply

        I didn’t back populate it. Didn’t seem to be a lot of point for all the effort that that would involve. It’ll update from today onwards.

        • Milan Dinić 11:09 pm on December 16, 2010 Permalink

          It’s not that only entires are outdated, it’s display name too.

          Note that that display name doesn’t show non English letters.

        • Otto 6:13 pm on December 18, 2010 Permalink

          Milan: No, you just have that stuff put in for your name on BuddyPress, which is where it’s getting the name from:
          http://buddypress.org/community/members/dimadin

          The Profiles system is built on top of BuddyPress. So it shares a lot of stuff with that system.

    • Rich Pedley 10:00 pm on December 16, 2010 Permalink | Reply

      When I can view the page… it still looks like I may be logged out in that section.

    • Milan Dinić 11:11 pm on December 16, 2010 Permalink | Reply

      Why initial layout with tabs was discontinued, I think it was more useful?

    • Michel 7:22 am on December 17, 2010 Permalink | Reply

      I agree with previous comments. Updating mechanisms seems freezed since April… Santa Claus has to work hard ;-)

  • Jane Wells 2:32 pm on December 15, 2010 Permalink | Reply
    Tags:   

    Dev Chat is today. Beta 2 went out last night. Agenda for meeting: what needs to happen to get to RC? Identify, assign, do asap. We’re about three weeks behind schedule.

    Also, we need more people to help with Google Code-in and sign up to check student work for bug tickets. Please help.

     
  • Barry 1:10 am on December 15, 2010 Permalink | Reply
    Tags:   

    We migrated all the .org trac installs and svn repositories (except WP.org plugins which had been moved previously) to a new server today and upgraded from Trac 0.11 to 0.12. Unfortunately, it didn’t go so well and trac is somewhat broken (sporadic internal errors, custom queries not working, reports showing wrong data). SVN is working fine. We are working on figuring out the problem and will update this post once we have more information. Sorry for the trouble.

     
    • Barry 5:14 am on December 15, 2010 Permalink | Reply

      Mostly everything has been fixed. Core trac is still lacking some of the customizations it had previously (like Gravatars in tickets). We are working on bringing those back.

      • Matt 8:13 pm on December 15, 2010 Permalink | Reply

        Can you remind me where that file is that needs to be edited for those customizations?

        • Barry 8:17 pm on December 15, 2010 Permalink

          site.html in /templates/ – Nacin and Otto are working on it.

    • demetris 7:06 am on December 15, 2010 Permalink | Reply

      Thanks, Barry and everyone helping, for the time and resources you put into this.

    • Peter Westwood 8:26 am on December 15, 2010 Permalink | Reply

      Note: You probably want to clear your cache before trying to use Custom Queries as trac doesn’t seem to use any cache busting on it’s js and css files and it is broken in wierd and wonderful ways otherwise!

    • Milan Dinić 12:44 pm on December 29, 2010 Permalink | Reply

      Will you upgrade Trac for plugins too, or at least see why email notification don’t work?

      • Barry 7:52 am on January 4, 2011 Permalink | Reply

        Plugins trac has been upgraded. Email notifications are disabled on plugins trac. I am not sure what the plan is there. I thought most of the trac functionality was going to be integrated into /extend/plugins/ Maybe someone on the core team can comment on that. If we want smtp functionality enabled, someone can ping me.

        • Milan Dinić 10:13 am on January 4, 2011 Permalink

          Thank you for upgrade. It still has improvements over previous version.

          But I found one huge bug. Latest revison is 142137 so none of newer changesets is shown. You can see that for any plugin (actualy, those that are older than that, newer are not shown at all).

        • Barry 6:01 am on January 5, 2011 Permalink

          Yes, a bug indeed. It is mostly fixed now. There are a few thousand missing revisions from trac, but they are really old (under rev 15000). We will get them added back ASAP.

        • Barry 11:34 pm on January 14, 2011 Permalink

  • Joseph Scott 10:10 pm on December 6, 2010 Permalink | Reply
    Tags:   

    As was discussed in the last dev chat I’ll be posting here periodically about dev changes in the Akismet plugin since it ships with WP. With version 2.5 of the plugin coming soon (next day or two hopefully) we really want to make sure it is included with WP3.1 when it ships.

    And with that, I give you:

    Changes in upcoming Akismet WordPress Plugin, version 2.5 compared to version 2.4:

    • New files:
    • admin.php
    • akismet.css
    • akismet.js
    • widget.php

    The new files should be reasonably self explanatory. We’ve been breaking out the different functions of the plugin to separate files.

    • Test mode

    The test mode provides an additional parameter to Akismet.com API calls to let it know that you are only testing and that the API calls should not be used for learning. The test mode is enabled when WP_DEBUG is TRUE or when AKISMET_TEST_MODE is TRUE.

    That last part is worth a repeat, when WP_DEBUG is TRUE then test mode is enabled.

    • Spam check history

    The plugin now keeps a history for each comment and the interaction with Akismet. The ‘Edit Comment’ screen will display a ‘Comment History’ section with details.

    Related to this is an indication on each comment explaining what Akismet did with the comment.

    • Auto retry

    When a comment check fails we note that and schedule a cron job to try again later. We found that hosts would make firewall or routing changes that would prevent WordPress from reaching Akismet.com. This retry feature will take care of processing the comments that were missed during that time once the server can reach Akismet.com again.

    • Clean up

    Various little house cleaning items, like deprecated function calls.

    • WordPress HTTP API

    The Akismet plugin now uses WordPress HTTP API. The big win here is being able use the built in proxy support.

    • Use complete details for spam/ham reports

    When a user specifically clicks on spam/not spam we didn’t have all of the original data for the comment. This records that data so that Akismet can use it to learn from.

    • Passive comment nonce

    The plugin adds a nonce field to the comment form. The result of the nonce check is then passed to Akismet to help look for abuse.

    • Call comment_check() on non-spam

    Even if Akismet says the comment is not spam, call check_comment() to see if any other moderation items need to adjust the status of the comment.

    • Link highlighting

    Make links that might not be obvious in comments a bit more obvious. Some comment spam would try to hide links, making them hard to find or see when reviewing comments in wp-admin.

    =================

    Currently available from https://plugins.svn.wordpress.org/akismet/dev/ (our bleeding edge dev section) if you’d like to try it out. Once released we’ll also have a tag for it in https://plugins.svn.wordpress.org/akismet/tags/ (2.5) which we’ll use for the WP3.1 Akismet SVN external.

    Tickets for the Akismet plugin can be created at http://plugins.trac.wordpress.org/ – be sure to set ‘Component: akismet’

     
    • Andrew Nacin 10:16 pm on December 6, 2010 Permalink | Reply

      That last part is worth a repeat, when WP_DEBUG is TRUE then test mode
      is enabled.

      -1. Many run WP_DEBUG in production environments. It shouldn’t be assumed that WP_DEBUG is for a development environment only. This will cause some serious issues.

      It would be nice for Akismet to get a quick UI review before release, given that it remains bundled. Things like “Cleared by Akismet” don’t really blend well with the core UI, but more importantly they sometimes overlap text and make links inaccessible, such as in the recent comments dashboard widget.

      • Joseph Scott 10:21 pm on December 6, 2010 Permalink | Reply

        There was some discussion about the debug/test situation. It would be interesting to know how many folks run WP_DEBUG for their production servers – I’d imagine WP would strongly recommend against that.

        On the UI front, I can have Dave Martin help bring any remaining items into line.

        • Andrew Nacin 10:25 pm on December 6, 2010 Permalink

          Not really — we have WP_DEBUG_DISPLAY that, combined with display_errors = false, ensures that nothing is shown. A lot of sites I’ve worked on use WP_DEBUG with logging, and I would highly recommend that setup.

        • graq 9:18 pm on December 7, 2010 Permalink

          Perhaps if people are using some WP_DEBUG features in a live production environment, this is in indication that they need to be available some other way. That way you can ‘enforce’ your stance that WP_DEBUG is for non-production dev environments. There is no reason for it not to be an option?

    • Andrew Nacin 10:20 pm on December 6, 2010 Permalink | Reply

      How will static page caching affect the nonce?

      • Joseph Scott 10:22 pm on December 6, 2010 Permalink | Reply

        It is possible for a cached page to fail the nonce, this is one of the reasons that for now the nonce is simply a data point and not something that specific action is taken on.

        Also the nonce can be disabled (see the Akismet Configuration page).

        • Matt 8:17 pm on December 7, 2010 Permalink

          Why is there an option for that?

        • Andrew Nacin 8:24 pm on December 7, 2010 Permalink

          Per discussion in IRC, I suggested a filter. Not sure if it made it into the final release.

        • SK 9:20 pm on December 7, 2010 Permalink

          Will either WT3C and WP Super Cache be affected? Offering that option sounds concerning. I feel like there are a lot of people using both Akismet and a caching tool.

    • Andrew Nacin 10:31 pm on December 6, 2010 Permalink | Reply

      I probably also should have commented that this all sounds awesome. :-)

    • Ozh 10:58 pm on December 6, 2010 Permalink | Reply

      wow, almost shocked to read it wasn’t using the HTTP API before! :)

    • Alex 8:33 pm on December 7, 2010 Permalink | Reply

      Something else worth a mention is the Akismet unit test plugin:

      http://plugins.svn.wordpress.org/akismet/tests/

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
Follow

Get every new post delivered to your Inbox.

Join 906 other followers