Updates from February, 2011 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 6:29 pm on February 17, 2011 Permalink | Reply
    Tags:   

    Second round of Trac changes went live earlier:

    • Reporters now automatically receive ticket updates via email.
    • Reporters are asked to add their email to Trac preferences if it isn’t there already. (Next step is pulling this directly from WP.org for all users, but it’ll take a bit of work.)
    • Reporters now see a notice when tickets are marked reporter-feedback. (This is embedded below.)
    • Tickets now need to be previewed before creation. This should cut down on formatting issues.
    • If you try to create a ticket in the Security component, you get a warning reminding you of the proper procedures for reporting suspected vulnerabilities.
    • The license note when uploading an attachment is more prominent and the upload button now explicitly says ‘Agree and Upload.’
     

    • Edward Caissie 8:27 pm on February 17, 2011 Permalink | Reply

      Any chance of getting all these latest and greatest Trac updates onto the Theme Trac?

      http://themes.trac.wordpress.org/

      • Andrew Nacin 12:11 am on February 18, 2011 Permalink | Reply

        Given that tickets there are created automatically and reporters are already CC’d, not sure what else needs to be done. But you guys can talk it over with Otto and I and I’m sure we can handle any improvements you need.

    • Xavier 4:19 pm on February 18, 2011 Permalink | Reply

      Great, great improvements! Thanks!

    • John Blackbourn 4:07 am on March 24, 2011 Permalink | Reply

      Any chance that changes to the CC field are muted? Eg. If someone adds themselves as a CC to a ticket this doesn’t really need to send an update to all those in the CC list.

  • Andrew Nacin 4:24 am on February 16, 2011 Permalink | Reply  

    Trac improvements! 

    A number of tweaks to Trac have just been pushed live, restoring our Trac template broken a few months ago and adding a number of new enhancements.

    The biggest change is a new workflow for keywords. (Believe it or not, the JS is mine.) It is now a nifty tag list with a drop-down:

    Keyword workflow improvements

    I tried to order them in a way that makes sense. Recognized keywords also have tooltips explaining what they mean. As a last resort, you can still manually edit keywords by clicking the little link. Also, a few keywords will be hidden for most users.

    The new warning when creating a ticket.
    Other changes:

    • There’s now a giant warning when creating a ticket. (Embedded at right.) Most of the text is from our old template, and the visual was inspired by jQuery’s warning.
    • Tickets are again left-aligned. The ticket properties and attachments should also now be easier to scan. The Modify section is now open by default again.
    • Gravatars are back for comments, and were added to reporters and owners.
    • The After the Deadline button is back, and integrated nicely into the toolbar. (You can see this in either screenshot.)
    • Long ticket titles no longer force horizontal scrolling on reports.
    • There is now a license note when uploading a patch.

    Please suggest any other Trac improvements, and find me if there are any bugs.

     

  • Andrew Nacin 10:07 pm on February 10, 2011 Permalink | Reply
    Tags:   

    If your menus or widgets screens broke… 

    WordPress 3.0.5 was released at the same time as jQuery 1.5. Unfortunately, 1.5 has some backwards incompatible changes that appear to break a number of areas in the admin. The timing is awkward and it looks like it was us. It wasn’t.

    There’s nothing we can do about this even for WordPress 3.1, which is freezing at jQuery 1.4.4.

    If your theme deregisters jQuery and re-registers jQuery 1.5, then you’ll want to make sure that this change only applies for the frontend, i.e. ! is_admin(). (Or use the wp_enqueue_scripts hook, which only fires for the theme-side.) This might not be obvious — if you’re enqueueing the latest jQuery from, say, Google’s CDN, you’ll be getting 1.5 suddenly, and things will break.

    Someone should put together a quick plugin that restores and enforces the bundled jQuery in the admin. I’ll do it later tonight if no one else does.

    Reference: #16508 and numerous support forum threads.

     

    • Milan Dinić 10:20 pm on February 10, 2011 Permalink | Reply

      This is why I’m always discouraging usage of wp_deregister_script and wp_register_script for jQuery from Google and instead encourage usage of Use Google Libraries plugin or its class which is the only right way to load jQuery and other libraries from Google.

      • Andrew Nacin 10:22 pm on February 10, 2011 Permalink | Reply

        I think that plugin would cause the same problem. It looks like it’s still replacing the script in the admin.

        • Milan Dinić 10:38 pm on February 10, 2011 Permalink

          Yes, it is replacing script in admin but it replaces with the same version as used in WordPress. See here.

          It also check if is_ssl, strips ?ver= from URL, adds jquery.noconflict, and loads development version if define('SCRIPT_DEBUG', false).

          I always promise to write a post on this subject but forget to do it. Will do that soon.

        • Otto 11:10 pm on February 10, 2011 Permalink

          Correct, the Use Google Libraries plugin correctly handles version numbering. Specifically, it causes both admin and front to use http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js (with 3.1RC4). This prevents the breakage.

        • Jason Penney 4:52 pm on February 14, 2011 Permalink

          The majority of the work on Use Google Libraries has been to make sure that it will do-the-right-thing and will not cause these kinds of issues (also, as demetris points out below, there’s a caching benefit to using the full version with Google’s servers). I do get a lot of requests to have it load the latest versions, but I’ve resisted adding it even as an option since I’m worried about it having unintended side-effects such as this.

          If there are any areas like this where you feel it needs improvement I’d be happy to know.

        • Andrew Nacin 4:57 pm on February 14, 2011 Permalink

          Yep, I stand corrected — it looks like great work. :-)

    • demetris 11:08 pm on February 10, 2011 Permalink | Reply

      Specifying only the major version is not a good idea in any case (or at least in any scenarios I can imagine). Not only things break, but you also get a very short cache period: 1 hour.

      Specifying major + minor version (e.g.: 1.5) avoids API incompatibilities, but you only get 1 hour of caching again.

      Specifying major + minor + maintenance (e.g.: 1.5.0) is the best option: In addition to avoiding incompatibilities, it also gets you one full year of caching.

      • demetris 11:09 pm on February 10, 2011 Permalink | Reply

        I failed to mention: The above are true for the Google CDN. I don’t know how other public CDNs, like Microsoft’s, handle caching.

    • hakre 11:43 pm on February 10, 2011 Permalink | Reply

      Re-freeze on 1.5 as a shortcut for WP 3.1. Should be a matter of hours.

      • Andrew Nacin 11:50 pm on February 10, 2011 Permalink | Reply

        I don’t know what you’re referring to. jQuery 1.5 is not in WordPress 3.1. And I’m not sure what should be a matter of hours.

        • Ramoonus 11:50 am on February 12, 2011 Permalink

          understanding his reply is a matter of hours

    • garyc40 12:17 pm on February 12, 2011 Permalink | Reply

      From what I’ve seen so far, it seems like there’s some incompatibility between jQuery UI and jQuery 1.5. So there’s probably nothing WordPress can do right now until jQuery UI gets updated.

    • Ashley 12:34 pm on February 15, 2011 Permalink | Reply

      I have upgraded to 3.0.5 and I am loading Jquery 1.4.4. (via google api) and only on the (! is_admin) frontend.

      I can’t order/reorder my wp nav (drag and drop) BUT have noticed the WP menu (left) open close functionality doent work on the menu order page but works elsewhere?
      There seems to be something with this pages functionality, not google as I am loading whichever WP uses for Jquery backend by default?

      I have also deactivated ALL plugins which made no difference either?

      I also don’t know how to downgrade back to 3.0.4 – if anyone has this data and can post a link – thanks in advance. Though I would be greatful if someone can shed some light on this as it doen’t make sense.

      • Andrew Nacin 12:37 pm on February 15, 2011 Permalink | Reply

        Hi Ashley,
        The proper place for support is http://wordpress.org/support/ — to answer your question, downgrading means undoing some security enhancements (which is bad). It also won’t solve your problem. You probably have an unrelated JavaScript conflict. (Or try a force-refresh of your browser, to clear the cache.)

        Anyway, check out the support forums, they’ll help you there.

        • Ashley 1:14 pm on February 15, 2011 Permalink

          Thanks Andrew,

          Good advice, I reset all Caches, rebooted server etc. logged out, did all the same again and eh voila, draggable menus back!

          Kee p up the great work, steller product

    • Gustavo Bordoni 11:40 pm on February 26, 2011 Permalink | Reply

      Hi Andrew,

      I have a problem with the jQuery UI Tabs, and it throws the following error:

      “uncaught exception: jQuery UI Tabs: Mismatching fragment identifier.”

      I can’t solve this problem.

      Thanks in Advance.

      • Ryan Boren 12:46 am on February 27, 2011 Permalink | Reply

        Read more about the fragment identifier exception here. Recent versions of ui.tabs are stricter in what they will accept, and your theme/plugin will have to be changed.

  • Andrew Nacin 3:14 pm on February 9, 2011 Permalink | Reply
    Tags:   

    The last handful of dev meetings have been pretty slow, given the elongated RC cycle. Here’s some sort of an agenda of hands-on tasks for today:

     

  • Mark Jaquith 9:01 pm on February 8, 2011 Permalink | Reply  

    Hotfix 

    We done goofed. One of the security fixes for WordPress 3.0.5 was overzealous. It fixed the issue, but it also stripped advanced HTML (on display, not save, thankfully) from comments by people with the unfiltered_html capability. It’s sort of a rare bug — doesn’t apply to multisite installs, and not many people know that Editors and Administrators on single WP installs can use images etc in comments, so we don’t think it warrants another release. People have WordPress 3.0 fatigue already. And 3.1 is so close I can taste it (takes like pork BBQ, natch). But it is still annoying.

    As Nacin mentioned, a hotfix for this issue went into Akismet 2.5.3. Akismet is very popular, and just happened to be planning an update today. We figured that would be an easy way to fix the issue for some WordPress users today. The Akismet team at Automattic was kind enough to oblige.

    But this wasn’t the first non-critical-but-sort-of-annoying bug in WordPress, and it won’t be the last. So I created a plugin: Hotfix. It fixes the 3.0.5 bug, but I intend for it to fix selected future bugs as well. If we can get this installed on a bunch of sites, it could be a very handy way to push fixes out to people faster than we can with WordPress core releases.

     

    • Alex M. 9:06 pm on February 8, 2011 Permalink | Reply

      If we can get this installed on a bunch of sites, it could be a very handy way to push fixes out to people faster than we can with WordPress core releases.

      Bundle it and pre-activate it?

      • Ozh 10:27 pm on February 8, 2011 Permalink | Reply

        I think that would confuse the hell out of average joes. Hotfix vs update?? zomg!!1

    • Travis 9:09 pm on February 8, 2011 Permalink | Reply

      Bundling it seems reasonable, as long as it won’t be continually reinstalled (i.e. follows the behavior that Hello Dolly and Akismet will exhibit in the somewhat near future).

    • Brian Layman 9:12 pm on February 8, 2011 Permalink | Reply

      The Akismet avenue is very practical and is a nifty fix, but also it feels rather inappropriate. I’d rather have just seen the plugin made public for those few who need unfiltered html comments before 3.0.6 is released (if ever).

      Well really, me personally, I’d rather see Akismet 3.5.3 bundled with WordPress 3.0.6 because people are still trying to figure out how to update Akismet after these upgrades anyway. But I understand rapid fire updates are unpopular with people.

      • jb510 12:49 am on February 9, 2011 Permalink | Reply

        I’ve got to agree that it feels inappropriate and I just really hope that bundling fix’s with Akismet or Hello Dolly or whatever… never becomes normal practice. Don’t get me wrong, I love Akismet but like Hello Dolly it, IMHO, it shouldn’t be bundled with core updates.

        I am intrigued by Mark’s hotfix plug-in. It would seem, at least at first look, to make a lot of sense to build into core.

        • Brian Layman 4:49 am on February 9, 2011 Permalink

          And there’s a good tradition of these hot fix plugins even predating the repository.

    • Edward Caissie 9:13 pm on February 8, 2011 Permalink | Reply

      Bundling it may be a solution to getting a “bunch of sites” to make use of the plugin as the average end-user may not be aware of its existence. I would think develoeprs, plugin authors and theme designers may follow the various social media outlets where this is being advertised but the average user tends to be of a “set-it-and-forget-it” mind-set … they are not going to know it’s broke so they are not going to think to fix it.

    • Matthew McGarity 9:19 pm on February 8, 2011 Permalink | Reply

      This is hot stuff for code n00bs like me — as I learn PHP and WordPress, I can now review future hotfixes as isolated in this plugin, rather than having to dig through core code/patch notes to see what was changed. Thanks for publishing1

    • Andrew Nacin 9:23 pm on February 8, 2011 Permalink | Reply

      As cool as the plugin is, I’d rather work to strengthen our own update procedures. That’s going to be a huge focus for 3.2.

      Brian, I’m not sure I know what you’re referring to. We decided early this morning that we were not going to go forth with a 3.0.6 release. But Akismet 2.5.3 was being released today anyway, and since it is installed on so many blogs, it is a convenient additional avenue through which a fix can be served. Also, this particular fix isn’t far from the realm of Akismet, seeing it had to do with comments. The Hotfix plugin means we now have a place we can point affected people.

      The Akismet update dance is annoying. We get that, but it’s not something we were going to fix for the 3.0 branch. 3.1 will ship with 2.5.3, and we’ll bump to additional 2.5.x releases as appropriate for 3.1.x. Come 3.2, this won’t be an issue, as one 3.2 goal is to stop updating over the wp-content directory.

      • Brian Layman 5:16 am on February 9, 2011 Permalink | Reply

        All’s good Nacin. I was just saying I wouldn’t have minded a 3.0.6 the next day if this was deemed an important issue. This obviously wasn’t. Lots of people get bent out of shape with quick releases. Yeah I don’t like bugs creeping in, but relatively painless upgrades are a better alternative than security holes. And this bug was minor and hard to catch. I’d bet through this bug more people will learn what they can do in comments than previously used the features.. But that’s also why I’m not sure it was important enough to fix through Akismet. That’s all I’m saying.

        One thing I would love to see is a consistent way to grab the latest release of any plugin via SVN or the repository. Then I could just request any plugin’s latest.zip or /tag/latest and I wouldn’t have to modify version numbers in scripts.

    • Michael Clark 10:45 pm on February 8, 2011 Permalink | Reply

      So now we have the equivalent of several versions of WP 3.0.5 out there: WP 3.0.5; WP 3.0.5 Akismet 2.4.0, WP 3.0.5 Akismet 2.5.3; WP 3.0.5, Akismet 2.4.0 HotFix 0.2; Wp 3.0.5 Akismet 2.5.3 HotFix 0.3, and I’m sure a few other combinations. I’m all for a rapid development cycle. But I think the safer (and saner) release strategy would be to push a 3.0.6 out with the new bug fixed. Or can you have Hotfix change the WordPress version number to 3.0.5.1?

      • Mark Jaquith 8:28 pm on February 9, 2011 Permalink | Reply

        We have an infinite number of versions of 3.0.5 out there, when you factor in all the plugins and the unbounded potential for custom functionality.

        • Michael Clark 3:40 pm on February 10, 2011 Permalink

          Granted. But how many plugins exist only to fix a bug, and then will be obsolete at the next WP revision? I feel that having three different official-ish versions of WP 3.0.5 out there is a problem. Is there a goal of having Hotfix version numbers reflect which version of WP they will work on?

          Also, aren’t you WP maintainers going to run into a situation where you have to maintain bugfixes is two places, WP and Hotfix? The Hotfix fix feels klunky.

        • Peter Westwood 3:42 pm on February 10, 2011 Permalink

          Also, aren’t you WP maintainers going to run into a situation where you have to maintain bugfixes is two places, WP and Hotfix? The Hotfix fix feels klunky.

          In general they are going to be the same fixes.

          This bug isn’t serious enough to demand a release straight away but for the people that is does affect the easiest solution is the hotfix.

          Simple to Install, No worry about it conflicting when they upgrade WordPress next etc.

    • James Collins 12:35 am on February 9, 2011 Permalink | Reply

      Just in case anyone missed it, the fix has also been applied to the 3.0 branch: http://core.trac.wordpress.org/changeset/17421/branches/3.0

      So if you’re using SVN to run your 3.0.5 site, svn switching from tags/3.0.5 to branches/3.0 fill also fix the problem.

      • Alex M. 12:40 am on February 9, 2011 Permalink | Reply

        +1. Branches totally pwn tags, even for stable installs. :)

    • Ryan Hellyer 4:39 am on February 9, 2011 Permalink | Reply

      The hotfix plugin a weird solution. I like it anyway since it could potentially reduce the number of WordPress updates required. I’m not seeing much point in bundling it into core though, as it isn’t any harder to update the whole of WordPress than it is a plugin. It seems to me that the plugin should be used as a way to point those who are having problems to a simple solution. Then WordPress double point updates could be used solely for security stuff.

      • Mark Jaquith 7:51 pm on February 10, 2011 Permalink | Reply

        This changes nothing about WordPress point-point releases. It’s purely a bonus offering.

    • Jon Brown 7:45 pm on February 10, 2011 Permalink | Reply

      The more I think about this the more it bugs me. I get just how minor this bug was but I still think it should have been made 3.0.5.1 or 3.0.6.

      #1 most user probably hadn’t updated to 3.0.5 yet. As easy as upgrades have become why make them upgrade, and install a plugin (akismet or hotfix). Why not let them just upgrade and skip a version?

      #2 This in theory is the last release of 3.0.x, and many user won’t be jumping on 3.1 immediately… meaning they’ll be using 3.0.5 for some time again meaning that the final release of 3.0.x should be as rock solid as possible.

      Maybe someone can explain why releasing 3.0.6 the day after 3.0.5 would have been so difficult, but this seems a case of serving the desires of the development community above the broader user community.

      • Mark Jaquith 7:48 pm on February 10, 2011 Permalink | Reply

        The bug isn not nearly severe enough or common enough to warrant a separate release. That was decided first. The plugin is just a bonus offering for people who are affected by the bug but aren’t comfortable pulling from SVN.

      • Matthew McGarity 8:02 pm on February 10, 2011 Permalink | Reply

        I suspect that the impact of the issue to the WordPress user base affect going this route — what Hotfix is meant to address are inconveniences to a small pool of users vs. an issue affecting *all* WordPress users (ex: security vulnerability). Based on that, a hotfix feels appropriate, especially considering that performing WordPress upgrades can be a time-consuming effort for end users, especially those with multiple sites to administer.

  • Andrew Nacin 7:38 pm on February 8, 2011 Permalink | Reply  

    Via the Akismet blog, Akismet 2.5.3 has been released. It includes a hotfix of something in 3.0.5 that should have been done better. More on that in #16489.

     

  • Andrew Nacin 4:30 am on February 6, 2011 Permalink | Reply
    Tags:   

    As 3.1 winds down and early 3.2 development is likely to start soon, I’m trying to make Trac a bit more usable, ranging from reports to the theme itself.

    I’ve been tinkering with report 40, Tickets Awaiting Review. It now uses the type of ticket, version it was reported against, and keywords, to create five groups of tickets:

    • Defects Awaiting Review, reported against trunk (or no version number specified)
    • Defects Awaiting Review, reported against latest branch
    • Defects Awaiting Review (all other bugs)
    • Enhancements Awaiting Review (includes feature requests)
    • Reporter Feedback / Close (tickets marked for reporter-feedback or close, which overrides the other groups)

    Each group is then sorted in descending order from when the ticket was last modified. Right now the first two groups are the same, but I’ll modify the report once 3.2 development starts.

    Ideally, this will allow us to better track and triage incoming tickets. It also increases the significance of the ‘Version’ field (version it was reported against, but ideally earliest version to which the ticket applies) and removing reporter-feedback when feedback is provided.

    I’ll be working on report 39 (Candidates for 3.2) soon. Suggestions welcome for improvements on both.

     

    • Tomas Kapler 10:44 am on February 8, 2011 Permalink | Reply

      I have noticed your recommendation to theme and plugins developers to test their themes/plugins. It would be great, if you would ask them to test it with wp-debug set to true. In last few weeks i have tested about 40 plugins, most of them with 4-5 stars and from recommended/most-downloaded group, all of them updated in last months, not old, but more then half of them throws a lot of warning notices as they are using obsolete functions (some of theme obsolete even from wp 2.0 version!), updating not-set variables etc. I have informed their developers, but i can’t do it for 13000 plugins.

      • Andrew Nacin 12:42 pm on February 8, 2011 Permalink | Reply

        First, thanks so much for testing all of those plugins — that helps a lot, even just to boost my confidence in 3.1. :-) I also appreciate that you’ve informed developers when you’ve seen issues with notices. That’s a great way to contribute back in the community.

        The issue I think is a bit more complicated though. While we try hard to avoid notices, core is not without them. On occasion it isn’t without deprecated behavior (usually an argument we deprecated earlier in the cycle). It’d be a double-standard to enforce notices in plugins. Obviously, you’re not suggesting we enforce it, only that we suggest it.

        But what we’re really looking for right now is just to verify that plugins and themes aren’t flat-out breaking, which could mean that something in 3.1 has regressed and require us to hold up the release. So right now it’s a much different standard we’re looking for. If I emphasized WP_DEBUG on the main blog, users who turn them on would be overwhelmed. Likewise, developers would see so many notices in their own code, that they would be focused on those instead of real bugs or potentially core regressions — or worse, they don’t bother with testing at all, thinking we’re crazy.

        Keep in mind this is coming from one of the larger proponents of WP_DEBUG and cleaning up deprecated usage. We need to be careful of the message we send and when. But heck, I’d fully support an International WP_DEUBG Day maybe at some point in the future. :-) Debug Bar is looking pretty nice, so hopefully once the panels are cleaned up, we can start to really push its use.

        Again, thanks for your thoughts. We really should do everything we can to emphasize debug mode.

        • Rich Pedley 1:30 pm on February 9, 2011 Permalink

          can we have WP_DEBUG Day instead…

          Submitted themes have to have tested with WP_DEBUG set, it’s part of the criteria. Plugins don’t go through checks like themes do, and no I’m not suggesting that, but could the plugin they use for themes be adapted for plugins? I’m thinking of testing for deprecated things etc. especially. I know the debug bar has that built in more or less, but that doesn’t cover everything.

        • Andrew Nacin 1:35 pm on February 9, 2011 Permalink

          Well, there’s also a fine plugin called Log Deprecated Notices. Eventually, when it is activated along with Debug Bar, it’ll actually take over and pretty up the Deprecated panel.

          You’d be surprised what Debug Bar covers. It handles notices, warnings, and deprecated usage.

        • Rich Pedley 10:26 pm on February 10, 2011 Permalink

          nah you’re missing the point. I’m talking about the automated check that is done. Now I know that themes are handled differently, but could an automated check be done on plugins in the SVN repository for deprecated things?

          The more aware plugin developer will be using the debug bar, the log deprecated notices etc etc, but there will be a few that don’t. Or even a few that get missed, having an automated checker at WordPress.org end would help find these, and appropriate action could then be taken – including a temp suspension of that plugin being listed (perhaps)

        • Andrew Nacin 10:29 pm on February 10, 2011 Permalink

          We can’t just do a code scan. The issue is that they might be doing a function_exists(), then gracefully degrading to only triggering deprecated functions if necessary — say, to support older versions of WordPress.

        • Rich Pedley 12:55 pm on February 11, 2011 Permalink

          True, though I wasn’t sure if plugins were going to go the way themes have done – and only support recent releases, hence the suggestion.

  • Jane Wells 6:14 pm on February 5, 2011 Permalink | Reply
    Tags:   

    GSoC 2011 has been announced. I’ll put in our application at the end of the month. Regular core contributors interested in mentoring a student on a project this summer should leave a comment and ID what kinds of projects you might be interested in taking on.

     

    • Peter Westwood 12:05 pm on February 6, 2011 Permalink | Reply

      I’m interested in mentoring a student on a “Unit” testing related project to improve our test coverage, get automated regression testing running or something in that area.

      • Nikolay Bachiyski 10:00 am on February 7, 2011 Permalink | Reply

        It’s not fair, you beat me to it :-) I also have a keen interest in this and will be happy to co-mentor or mentor a student in the same field.

        • Jane Wells 6:19 pm on February 7, 2011 Permalink

          Co-mentoring sounds good, to provide more contact/coverage for student.

    • garyc40 5:09 pm on February 6, 2011 Permalink | Reply

      I recalled that a WordPress-powered bug tracking system was on the idea list for last GSOC. Anyone still interested in mentoring that one, because I feel like tackling it :) Btw, I’m a graduate student, I read somewhere on Google FAQ that it still counts.

      • Jane Wells 6:19 pm on February 7, 2011 Permalink | Reply

        Yes, a student started on it last year but failed at midterm due to lack of progress and it made us all sad. And yes, grad students are eligible.

        • garyc40 2:49 am on February 8, 2011 Permalink

          That’s a pretty big task, but I believe I can do it. SVN tie-in can be tricky, but that can be learnt. The big question that I’m having now is whether to implement this as a plugin, or as a fork of WordPress. Anyways, I would love to have a mentor to discuss more about this during the application period.

        • Dion Hulse (dd32) 7:13 am on February 8, 2011 Permalink

          garyc40: That’s always your choice, but you should be able to do it as a plugin, It’d really be crazy to fork it and loose all the potential additions WordPress will have over the next few years, Save the time, develop using what people understand. thats my only suggestion.

        • Jane Wells 7:24 am on February 8, 2011 Permalink

          I second Dion’s suggestion to do it as a plugin. The point of GSoC for us is to improve the platform. Plugins do this, but forks just create one more thing that needs to get synced up.

        • Andrew Nacin 7:28 am on February 8, 2011 Permalink

          Indeed. It’s actually probably best as a theme with a few additional dependencies. There was one called Quality Control that was since bought up… But it needed work for it to be an actual replacement for serious or large projects.

        • garyc40 7:31 am on February 8, 2011 Permalink

          dd32, Jane, Nacin: Thanks for the input! After thinking about it more, you’re right, forking is a bad idea. Originally I thought I need to modify my-sites.php and network/sites.php to support multiple repositories, but that seems to be an overkill, and I probably shouldn’t plan ahead that far.

          Nacin: I was leaning more towards using the existing admin UI for this. Each registered user already has that UI, so why duplicating the effort?

    • Aaron D. Campbell 5:55 pm on February 7, 2011 Permalink | Reply

      I’m interested in mentoring again. I’m flexible on the project, but I’d really like to see someone identify where WP can most benefit from the new PHP 5.2+ and MySQL 5 functionality we’re about to gain, implements the changes, and maybe even update our coding standards accordingly.

    • Chinthaka 8:55 am on February 16, 2011 Permalink | Reply

      I also like to contribute to wordpress in this time GSoC. I need to know whether the “WordPress Import/Export ” project in last GSoC is completed or not. If it is not completed I like to do that project in this time GSoC.

      • Jane Wells 11:33 am on February 16, 2011 Permalink | Reply

        We are not yet putting together our recommended projects lists, as we first have to ID who our mentors will be. The best thing to do in the meantime is to start getting to know the WP codebase better, reviewing trac tickets and past commits (a bunch of stuff has changed with 3.1), and start attending the dev chats to get a better understanding of the project. We’ve had bad luck in the past with students who pop up out of nowhere and claim a project without spending some time getting to know the code and developer community a little bit first. Contributing a few patches between now and when we are ready to start talking specific projects (if we are accepted into the program) is the best thing you can do to increase your chances of being accepted when the time comes.

        • Chinthaka 12:03 pm on February 16, 2011 Permalink

          For the last gsoc I also submitted a proposal for WordPress Import/Export process project idea. At that time I already had developed the import process and my proposal didn’t accepted last time. So I’m trying it again this time. Thank you.

    • Justin Shreve 2:11 am on February 23, 2011 Permalink | Reply

      I’d be interested in mentoring this summer – I would love to see the other side of GSoC. I don’t have any specific projects in mind to mentor on, but as you know I’ve worked on a lot of different things so I can jump in for anything.

    • Paul Gibbs 6:12 pm on March 7, 2011 Permalink | Reply

      I’m down for any BuddyPress project.

  • Barry 8:14 pm on February 4, 2011 Permalink | Reply
    Tags: irc logs,   

    I changed the default sort order from DESC to ASC on https://irclogs.wordpress.org/ Let me know if it is better or worse :) It was a bit hard to follow conversations by scrolling up.

     

    • Jon Cave 8:28 pm on February 4, 2011 Permalink | Reply

      It was quite nice to be able to instantly see the most recent chat at the top. However, I agree with being annoyed when scrolling down to find the start of a conversation and then scrolling back up to follow it. So good and bad.

    • Jon 8:39 pm on February 4, 2011 Permalink | Reply

      link should be .ORG not .COM

    • DP 8:44 pm on February 4, 2011 Permalink | Reply

      I was ASC for a long time but switched because of following along during the day and refreshing often for the most recent comments. When there is an extensive dialogue, it’s a bit challenging either way — hard to say whether one is that much better. And when one is looking at it that much, it’s easy to toggle to choice.

    • Aaron D. Campbell 3:08 am on February 5, 2011 Permalink | Reply

      I like it. It’s more natural for reading what I missed, which I think is what most people use it for.

    • Sergey Biryukov 4:27 am on February 5, 2011 Permalink | Reply

      Seems more intuitive this way.

    • will 11:58 am on February 5, 2011 Permalink | Reply

      Way better, thanks!

    • Tom Lany 7:43 pm on February 5, 2011 Permalink | Reply

      When looking at the source code for the IRC logs, I noticed this at the bottom of one the https://irclogs.wordpress.org/chanlog.php pages:

      “

      It looks like the footer file is not being included.

    • Sergey Biryukov 11:47 am on February 16, 2011 Permalink | Reply

      When clicking on a timestamp of a single message, the order reverts to DESC. Is it possible to apply the selected order there too?

  • Otto 4:50 pm on February 3, 2011 Permalink | Reply
    Tags: , ,   

    Theme pages now have a little “Theme SVN” link in their FYI box. This just gives a link to the theme’s SVN, for people that want to use it.

    This is something several of the theme reviewers asked for, and it fits with the long term goal of allowing some theme authors the ability to directly update themes via SVN instead of using the ZIP file uploader. Encouraging SVN use is a good thing, I think.

     

    • Rich Pedley 6:52 pm on February 3, 2011 Permalink | Reply

      That just lists all the versions, ala the ‘Other Versions »’ link on plugin pages. Shame it can’t be WordPress.org-ified rather than a simple listing though.

      • Otto 6:54 pm on February 3, 2011 Permalink | Reply

        That’s what it’s supposed to do. The theme SVN isn’t organized like the plugin SVN, with trunk and tags and such. It just has one directory for each theme version.

        • Rich Pedley 7:28 pm on February 3, 2011 Permalink

          So it could be pulled into a WordPress themed page then…
          ;)

        • Dion Hulse (dd32) 1:13 pm on February 5, 2011 Permalink

          Rich: Given it’s a SVN repo, I’m not really sure it’s possible to style it like WordPress.org. That aside, as it’s a SVN repo, it’s not designed to look like WordPress.org :)

        • Rich Pedley 8:09 pm on February 5, 2011 Permalink

          On a site such as WordPress.org having unstyled pages like that is very un-professional. I still think the data could be pulled into a themed page, and even if it can’t I have seen better web front ends for SVN.

        • Peter Westwood 10:08 pm on February 5, 2011 Permalink

          You can style the SVN web interface but I wouldn’t want to be the person writing the XSLT to do it – it’s not fun and you won’t make it look much better – I don’t see why it needs styling at all.

        • Alex M. 6:58 am on February 6, 2011 Permalink

          If you want to look at a pretty version of the code, then use the plugins Trac instead of browsing the directory via SVN. Or even better just use a proper SVN client.

          The SVN repository isn’t really meant for browsing with your browser. ;)

        • Matt 6:14 pm on February 6, 2011 Permalink

          I think it would be worth a little XSLT to just put a note at the top, like “This is blah blah blah for the plugin’s page please see LINK or visit WordPress.org.”

    • Radhe 6:45 am on February 4, 2011 Permalink | Reply

      This is welcome addition,
      but I do think “trunk” folder should be given, that will be helpful when author modify theme code in response to theme-users support request.

    • Dion Hulse (dd32) 1:13 pm on February 5, 2011 Permalink | Reply

      Could we get the same thing for Plugins?

      • Otto 6:00 pm on February 5, 2011 Permalink | Reply

        Plugins have had the SVN links in their Admin sections forever. Not sure it’s worth exposing them on the public side of things.

        • Dion Hulse (dd32) 10:34 pm on February 5, 2011 Permalink

          Not everyone has access to the admin section of every plugin.

          I personally see SVN access for Plugins as more useful than for Themes. Every task is common between them however (Other than Theme review team stuff, but thats a not a normal front end task anyway). Allowing easier access to the SVN repo from the plugins page will help people who are not aware of SVN get into it at well, encourage them to use svn..

          One of the first thing I do, and I’d hope other Plugin developers do, is open the plugins SVN repo and take a glance at the code, it’s what tells me if I’m going to atttempt to use it or not. That’d be my main use for it for Plugins (as well as for Themes).

        • Rich Pedley 9:37 am on February 7, 2011 Permalink

          erm plugins already have a link to the Development log in the FYI box. This was what I was referring to when I thought that the themes should match it.

    • Denis 6:00 am on February 12, 2011 Permalink | Reply

      Slightly off topic, but… It just occurred to me that the default vote for compatibility was for 3.1 at a time where it was not released. As much as I like the idea that one can vote on works/broken for the latest beta/RC, it seems to me that the vote should apply to the latest and greatest *released* WP version by default. (Or maybe it already is the case, in which case it’s not clear at all…)

      • Denis 6:01 am on February 12, 2011 Permalink | Reply

        i’m meaning for plugins, btw. But since you’re also worrying about that and I can only assume the same logic applies for themes, I figured I’d raise it here.

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