Updates from January, 2010 Toggle Comment Threads | Keyboard Shortcuts

  • Aaron D. Campbell 5:31 pm on January 29, 2010 Permalink | Reply
    Tags:   

    Core Plugin Infrastructure Update 

    Just a quick update on where we stand with the infrastructure for core plugin development. The mailing lists are currently being used and it looks like they should be able to scale fine.

    We still need a patch or plugin for Trac (http://core.trac.wordpress.org/ticket/11898) to help it handle the sheer number of plugins currently in the repository (not to mention the expected future growth). If anyone is able to help with that, please post on that ticket.

    The next steps will be to rework the current layout of the plugin pages on wordpress.org. Currently there’s a link on the admin tab to that plugin’s Revision Log as well as the RSS feed for that log. That needs to be moved some place where regular users can see it. Additionally the plan is to add a way for plugin authors to request a mailing list for their plugin directly from the wordpress.org repository.

    I’m excited to see all this fall into place so that we can turn the corner and see how core plugins will really shape up!

     

  • Peter Westwood 9:58 pm on January 28, 2010 Permalink | Reply
    Tags:   

    Suggest Agenda Items for Feb 4th 2010 dev chat

     

    • arena 8:45 am on January 31, 2010 Permalink | Reply

      Hi !

      Where can i get some info on WPMU migration (2.9 to 3.0) ?

      thanks

    • jeherve 5:12 pm on February 2, 2010 Permalink | Reply

      Could we get to know more about 2010? I know there is http://2010dev.wordpress.com/ , but I’d be happy to get a small update from Matt about how it is going, when can we expect to have a 1st version out for testing, will the background change option be implemented as suggested by Matt during dev chats, …
      Thanks!

  • Peter Westwood 9:46 pm on January 28, 2010 Permalink | Reply
    Tags:   

    Summary of Jan 28th 2010 Dev Chat 

    This week we started of with a quick merge updated and we are pleased to say that we are at the stage where people should dive in and start testing. It is obviously not yet ready for production and if you notice any UI issues then Jane would like to know about them here: http://wpdevel.wordpress.com/2010/01/28/see-any-post-merge-ui-wierdness-leave-a/

    Next we talked about menu management and whether on not the current patch was making the process too complex and we would be better to spend more time reviewing the best existing plugins for ideas. This led to quite a long discussion about the minimum feature set and how the ui should work.

    We then had a quick status update on core plugins, in particular the infrastructure improvements.

    We then talked about the possibility of a core contributor meetup around the time of WCSF which seemed like a popular idea.

    At the end of the meeting Jane gave us an update on the improvements to the ideas forum which include categories and making it easier to mark threads as closed.

     

    • arena 10:42 pm on January 28, 2010 Permalink | Reply

      Hello, i just upgraded my local wpmu from last nightly build and got this when trying to reach wp-admin :

      Fatal error: Call to a member function add_rewrite_tag() on a non-object in C:\Vn\wpmu\wp-includes\taxonomy.php on line 207

      Any help appreciated

      • Ryan 6:32 pm on January 29, 2010 Permalink | Reply

        Perhaps a file didn’t get copied over? No problems here.

      • arena 8:54 am on January 31, 2010 Permalink | Reply

        got this now !

        Fatal error: Call to undefined function wp_redirect() in C:\Vn\wpmu\wp-includes\ms-settings.php on line 91

        • arena 8:40 pm on February 2, 2010 Permalink

          Did it by deactivating my plugins !

        • nacin 11:37 pm on February 3, 2010 Permalink

          Fixed in trunk.

      • Michael 8:02 pm on March 18, 2010 Permalink | Reply

        I had the same problem and it had to do with the order items were loaded in wp-settings.php. The plugins were loaded before global $wp-rewrite is set. This causes a problem is you are registering a taxonomy. I just moved the plugin loading from LINE 177 to LINE 237

        • dd32 11:30 am on March 19, 2010 Permalink

          The issue is your plugin will be running code upon inclusion of the plugin. All code should be run on a action hook, ‘plugins_loaded’ or in this case ‘init’ when wordpress is loaded would be appropriate.

    • Andreas Nurbo 9:39 am on January 29, 2010 Permalink | Reply

      You forgot to mention the privacy stuff which were on the agenda and that I wanted an update on but didn’t get. My inquiry was met with a sarcastic comment from Matt and then silence. He could at least say he had forgotten it.
      “In January or February I’ll talk with our legal folks about a revision to the WP.org privacy policy.”Matt 9:15 pm on December 13, 2009

      • Alex M. 9:41 am on January 29, 2010 Permalink | Reply

        It’s still January and not February yet. ;)

      • Matt 9:46 am on January 29, 2010 Permalink | Reply

        I was not being sarcastic. I think everything we do is covered by the “Aggregated Statistics” part of the privacy policy, what sort of language would you like to be added to the policy to clarify our keeping of everything, forever.

        • Andreas Nurbo 4:48 pm on January 29, 2010 Permalink

          There were and are disagreements on this issue which, I assume, is why you thought about seeking legal counsel in the first place. What have changed since then? Why write that you were going to check something with no intention of following through?

          Discussions to refresh your memory: Suggest Agenda Items for Dec 17th Dev Chat, WordPress phone home, What data does wp send?, Is wordpress spyware?, WordPress privacy policy draft

          We “the community” wrote about this problem greatly last year in December, as evidenced by the previous links. There are suggestions also.
          I can not give any suggestion since I do not know what is retained and how. But if you really want suggestions I’m sure someone more articulate than me can come along and give you some. This will probably require complete openness on what is actually retained and how. Also if the information is in anyway/will be crossreferenced with data collected by Automattics services given the relationship between WP and Automattic.

      • aarondcampbell 5:42 pm on January 29, 2010 Permalink | Reply

        I’ll be honest…I think that it’s pretty normal to assume that digital information is stored forever unless it’s specifically stated otherwise. I’m not going to argue about whether or not this specific data *should* be kept forever (I have no problems with the info collected), I just don’t see why “forever” needs to be specified somewhere.

  • Jane Wells 8:34 pm on January 28, 2010 Permalink | Reply  

    See any post-merge UI wierdness? Leave a comment and describe it here. Include the screen URL. Thanks.

     

    • Paul 2:42 am on January 29, 2010 Permalink | Reply

      This has happened consecutively 3 times.
      1. Install trunk – latest build.
      2. Log on for first time.
      3. Select to set up MS Features with sub directories site/directory
      4. Copy provided info to wp-config and htaccess
      5. Am logged out
      6. Can access front end but not admin area and have to revert to original wp-config and htaccess
      First Browser error reads:
      The URL was redirected to http://****.com/wp-admin/network.php Please click on link…
      Then, upon clicking browser error reads:
      http://****.com/wp-login.php?redirect_to=http%3A%2F%******.com%2Fwp-admin%2Fnetwork.php
      I have asterisked out the real domain, but will install on one I can publicize tomorrow.
      WP is installed int he root directory with no other info in the htaccess.
      Please let me know if there is anything I can do to help.

      • Matt Rude 4:27 am on January 29, 2010 Permalink | Reply

        Paul, Clear your browser history after WordPress logs you out. When you update the wp-config.php file, you are changing your “AUTH_KEY” key, clearing your browser cache will allow for the new key.

    • Paul 7:50 am on January 29, 2010 Permalink | Reply

      Thanks Matt.
      I use Opera. Clearing the cache did not work (though it probably would have done if I had closed it and restarted. Changing Browser to Firefox worked though. So maybe there needs to be some instructions and a warning for users to prevent repeat requests for the same help.
      Will test UI this weekend.
      Thanks for helping me!
      Best wishes

  • Peter Westwood 6:27 pm on January 27, 2010 Permalink | Reply  

    Agenda for Jan 28th 2010 dev chat 

    • Merge update
    • Menu management ticket
    • Core plugins infrastructure update
    • Possibility of a core contributor meetup timed around WordCamp SF – Jane
    • Update on progress on update check privacy issues – photomatt
    • Update on fixing Ideas forum – Jane
     

  • Jane Wells 2:55 pm on January 25, 2010 Permalink | Reply  

    Someone started a thread on Ideas forum about the plugin compatibility widget on Extend. Maybe some of you could weigh in over there? http://wordpress.org/extend/ideas/topic.php?id=3554

     

    • Peter Westwood 9:59 pm on January 25, 2010 Permalink | Reply

      I think this is another thing that the team looking at workflow improvements for core plugins could maybe investigate.

  • Denis de Bernardy 6:42 pm on January 24, 2010 Permalink | Reply
    Tags:   

    Taking advantage of UUIDs 

    Now that we require MySQL 4.1.2, we can look into using UUIDs in WordPress.

    Universally unique identifiers are numbers that are unique in time and space. In the database world, they’re primarily used in order to work with data that is created in a decentralized manner. It allows to characterize a piece of data that isn’t stored in the database yet, to merge data from separate databases without needing to work around ID conflicts, etc.

    The lack of genuine UUIDs introduces all sorts of quirks in the WP editor when we’re dealing with yet to be saved posts. #9471, #10456, #11145, #11990, and many more underscore the architectural problem that we’re facing. The media-related tickets exacerbate the issue.

    Mark recently opened #11889 and suggested that we a) always create a new post when hitting the new post button, and b) have a garbage collector clean things up periodically. It is a solution, but I feel that using UUIDs — which were designed to deal with this kind of stuff — would be simpler.

    Using them would mean pre-assigning a UUID to new posts, and placing it in a hidden field. Since this UUID characterizes our yet to be saved post, we can safely pass it around to an autosave handler, a media thickbox, etc., allowing to create the post on the fly when necessary.

    Further down the stream, we introduce a slight change in our insert/update post handler: when saving a post whose ID is not assigned yet, we start by verifying if that post exists already — by querying the posts table’s post_guid field to know if that UUID exists.

     

    • scribu 7:25 pm on January 24, 2010 Permalink | Reply

      You’ve been pushing for this aproach for some time now, Denis.

      Since you’ve got the best grip on your ideea, how about a patch?

    • Oncle Tom 7:34 pm on January 24, 2010 Permalink | Reply

      Is this a good idea to rely on such a database specific feature? How will it works if, one day, a database abstraction is used, to support other DB engines?

      It should be code logic no?

    • Matt 12:52 am on January 25, 2010 Permalink | Reply

      Philosophically, I’m a fan of fixing things with the smallest possible change that works, because it decreases the chance that an architecture change will introduce new and impossible-to-anticipate bugs.

      Also worth pointing out two old but classic essays on abstraction and architecture:

      http://www.joelonsoftware.com/articles/fog0000000018.html
      http://www.codinghorror.com/blog/archives/000165.html

      • Mark Jaquith 5:59 pm on January 25, 2010 Permalink | Reply

        That fix would probably be the “Create a draft whenever you visit the ‘Add New X’ screen” method. The bulk of the code will be the cleanup (change post_status on a real save, cleanup the unused items after a long enough time).

        And I suppose there is another benefit to this: it is DB agnostic.

        • Ryan 6:25 pm on January 25, 2010 Permalink

          If we keep guid as a varchar and wrap the MySQL syntax in a short-circuitable function we can remain DB agnostic. I don’t really want a schema change to the posts table in 3.0 anyway since we want to make MU upgrades to 3.0 as easy as possible.

          Even if we introduce UUID, I kinda like auto-creating a draft. It is very simple and fairly clean. The only messy part is the GC, but that doesn’t bother me too much. Regardless, both ways seem like solid approaches that would allow us to clean up the gallery mess.

        • Brian Layman 8:49 pm on January 25, 2010 Permalink

          A big difference I see is that one causes a DB write while the other doesn’t.

          Denis made two points advantages of the UUID:
          1. It allows to characterize a piece of data that isn’t stored in the database yet,
          2. to merge data from separate databases without needing to work around ID conflicts, etc.

          And I guess that qualifies in the first one because it avoids the need to store something. I discount the second one because we are way too far down the line for ppl not to worry about ID conflicts when merging DBs, IMHO.
          (BTW can we get some cookies around here to save our name, email and site for commenting :) )

      • hakre 6:23 pm on January 28, 2010 Permalink | Reply

        An easy one would be: User clicks Add New Post, comes to a screen where it’s a need to enter the title of your new post before user can continue to the editor. Post will be created within the request where the user enters the editor.

      • hakre 1:44 pm on February 17, 2010 Permalink | Reply

        Philosophically, I’m a fan of fixing things with the smallest possible change that works, because it decreases the chance that an architecture change will introduce new and impossible-to-anticipate bugs.

        That’s really an important thing, the smallest possible change. To achieve that in the long term, this resource is valuable as well:

        http://www.joelonsoftware.com/articles/fog0000000043.html

        Especially the point that explains when it makes sense to fix bug and how to handle changes in the code.

    • Mark Jaquith 4:28 am on January 25, 2010 Permalink | Reply

      I wasn’t quite getting this at first, but now I think I see how it could work. Is this about right?:

      Instead of populating a post ID field for a new draft, you’d populate a post_uuid field. The add attachment links, thumbnail selection link, postmeta forms, etc, would all pass this UUID if a post_id isn’t yet available. Whenever something ([whatever]) is created in relationship to a UUID and a post with that UUID doesn’t exist, you create it, and give the post that UUID (and then add the [whatever] pointing to the post ID of that newly created post). Forms that are still open and reference the UUID for the the newly created post will continue to work, except the UUID lookup will succeed, and they’ll attach [whatever] to the post ID of the post row with that UUID.

      We’ll need a function that accepts a UUID and returns either the existing post object, or if-not-exists, creates one and returns the new object. get_post_by_uuid( $uuid ) or something.

      The advantage is that we’re not creating post rows that add overhead and need cleaning up. We’d have to write code to handle the “did we get a UUID or a post ID?” stuff, but it’d probably allow us to fix all those bugs and get rid of a lot of hairy JS code.

      Denis, can you affirm or deny my stated understanding?

      • hakre 12:38 pm on January 25, 2010 Permalink | Reply

        I understand it this way: The UUID names post that is created / refered to by a user doing a specific post related action to a possibly non-existing-in-database post.

        The UUID is used to describe the simple fact, that a user knows about a post first compared to our current post-related-data-structure(s) in core. I like that Idea.

      • Denis de Bernardy 3:12 am on February 5, 2010 Permalink | Reply

        “Whenever something ([whatever]) is created in relationship to a UUID and a post with that UUID doesn’t exist, you create it, and give the post that UUID (and then add the [whatever] pointing to the post ID of that newly created post). Forms that are still open and reference the UUID for the the newly created post will continue to work, except the UUID lookup will succeed, and they’ll attach [whatever] to the post ID of the post row with that UUID.”

        sorry I didn’t reply earlier (sick, then busy), but yes, that pretty much is exactly it…

    • miqrogroove 1:54 pm on January 25, 2010 Permalink | Reply

      A third and very simple strategy would be to have the front end keep track of the image IDs whenever there is no parent ID, and then include that ID list with the first auto save. That way you have no GC, no schema change, and no empty drafts..

    • Brian Layman 5:30 pm on January 25, 2010 Permalink | Reply

      Coming from a database background where 50gb dbs were not that unusual, I still cringe thinking at PHP’s loose typing and handling numbers as strings. Reading up on UUIDs it is neat to see that it is a actually stored as a 128bit integer. Which I thought was a really good thing, but because this will be passed around as a string, this is not the end of the story:

      There’s a warning in the documentation that character sets play a significant role in UUIDs. I’m not sure how that will affect us, but you can setup a case where the character set of the column doesn’t match the values stored in that column and therefore the indexes fail.

      Maybe this can be fixed by regenerating the index, I don’t know. Is it a concern? It might be if the blog is set to a different character set than the database right? I’ve run into problems like that before when the data was a different character set than the structure in which it was stored. Maybe it was only because we do a lot of tossing around of blogs…

    • Joseph Scott 6:17 pm on January 25, 2010 Permalink | Reply

      Which type of UUID was being considered for this?

    • Brian Layman 7:14 pm on January 25, 2010 Permalink | Reply

      I don’t think the MySQL UUID() function has various types.. http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_uuid

      • Joseph Scott 8:30 pm on January 25, 2010 Permalink | Reply

        From the discussion so far it seemed implied that the UUID would be generated in PHP, not MySQL. That said it looks like the UUID showed up in MySQL 4.1.2 so we could potentially use it.

    • Peter Westwood 9:49 pm on January 25, 2010 Permalink | Reply

      I am really against trying to use UUIDs as the linkage between posts and there metadata/attachments.

      We have a perfectly good method of providing this linkage and a simple solution has been proposed to resolve the issue with autosave prior to a draft existing.

      All we need is for get_default_post_to_edit() to ensure something exists in the database and most of the rest of the code won’t need touching.

      I am with Matt on the small change is better.

      UUIDs aren’t designed to solve the issue we have here – they are designed as a way of letting you generate IDs that are unique accross multiple sites/machines and are a candidate for using as the GUID in the posts table but not as the linkage/post_id

      • wpmuguru 5:58 pm on January 26, 2010 Permalink | Reply

        +1
        The problems being addressed in those tickets occur infrequently. Reinventing the post ID management system seems to be an excessive solution to the problem.

      • hakre 5:02 pm on January 28, 2010 Permalink | Reply

        Westi, from what you write in your comment is that you did get it wrong. The UUID would not be used to replace the Post ID, it would be only in use as long as there ain’t no Post ID. You understand the difference?

        • Peter Westwood 5:50 pm on January 28, 2010 Permalink

          Yes. But it would effectively replace post ID.

          Either we would have to have all the code cope with matching based on ID or UUID or we would have to switch solely to using UUID.

          Introducing UUID for posts that aren’t saved yet just introduces unnecessary complexity

        • hakre 6:11 pm on January 28, 2010 Permalink

          The unnecessary (?) complexity was introduced by users who do upload attachments for non-existing posts because the UI made them think, they are actually uploading images to a new post.

          The UUID is only a technical thingy to make the software again capable of that situation. The UUID itself is not introducing any more complexity. The opposite is the case, it makes things more simple and useable. The current data structure is not able to cope with the situation we have in the post editor.

          Or what do you suggest as analysis why this bug is staying open so long unfixed?

        • Peter Westwood 7:52 pm on January 28, 2010 Permalink

          If we introduce a UUID just for this situation we have to write a lot of extra code for WordPress to handle the action on an un-saved post to handle the action and every plugin author that wants to do something similar has to do this too.

          If we just always create a draft then the current code in core and plugins will just work.

    • Brian Layman 5:13 pm on January 28, 2010 Permalink | Reply

      I wasn’t going to reply because comments on this had slowed, but I think I got it wrong too. I don’t think that Denis implied any changes at all to the data structure. If you read the last paragraph, he is envisioning the UUID being stored in the post_guid field. So his proposal is one for the editing screens only and not an altering of the post table’s structure. If I understood it more correctly upon re-read that is.

      • Peter Westwood 5:51 pm on January 28, 2010 Permalink | Reply

        This would still affect a lot of code which wouldn’t need changing if we just created a draft before outputting the page.

    • Jeremy Stark 5:53 pm on February 19, 2010 Permalink | Reply

      I wrote a UUID plugin in order to integrate WordPress with another publishing system:

      http://wordpress.org/extend/plugins/simple-uuid/installation/

      It just adds a uuid to each posts metadata.

  • Denis de Bernardy 2:48 pm on January 23, 2010 Permalink | Reply
    Tags: ,   

    I’m inaugurating a new trac keyword, “bug-hunt”, and the bug hunt report, in order to keep track of of tickets that get posted/could get posted in this blog’s “bug hunt” posts.

    Updated: I’m inaugurating a new trac keyword, “featured”, and the featured bugs report, in order to keep track of of tickets that get posted/could get posted in this blog’s “featured bugs” posts.

    I’ll be tagging more tickets in due course. You’re most welcome to mark additional tickets as such, if you feel they qualify.

    For information, I try to stick to batches of tickets that loosely interfere or interact with one another. The batch of tickets should then meet the two or more of following criteria:

    • It is annoying when you run into the issue
    • It underscores an architectural problem
    • Fixing it can lead to performance optimizations

    Areas I plan to highlight in the future include: UUIDs, i18n post slugs, permalinks, rewrite rules, cache, private posts.

    Btw, I’d like to stress that the point in these blog posts is try to reverse the WP bug trend:

    Open WP bugs, props Hakre

    Thus, I’d like to revisit two of my last post’s tickets:

    1. #10779, on optimizing our unzip method. DD32 committed the fix, but marked it as still needing testing. Here’s how. Related ticket #10403 is still pending, but I feel it’s extremely minor compared to #10779.
    2. #10913, on optimizing the upgrade process, is still a major niggler imo. #10611 will probably seem cosmetic if #10913 gets fixed. Two possible solutions are highlighted in the ticket’s comments. It still needs a patch, and of course testing once one is around.

    We need your help on both, and on future tickets that will make it in these posts. Thanks for patching/testing.

     

    • Ryan 6:59 pm on January 23, 2010 Permalink | Reply

      It would be interesting to see the trend for enhancements/feature requests. Currently, 53% of open tickets are enhancements and feature requests.

    • DD32 10:54 pm on January 23, 2010 Permalink | Reply

      I’m wondering if ‘bug hunt’ is the correct term for these.
      Historically Bug Hunt days are testing a heap of bugs and/or patching them..
      The criteria hardly relates to what Bug Hunts used to be (not to speak of them in ast tense, but its been a little while). So i’m wondering if its going to confuse some people, Its not a bug hunt, its just tickets which you see as annoying, or a possible optimization – Many of the latter is not something most people can even attempt to look at.

      For a start, #10611 is neither a bug, nor does it have a patch, So whilst it’s a performance thing, Its not something that most people should be told to test..

      As for #10779 however, I need to know who its failing for, and what kind of server setup they have.

      I’d like to see Bug Hunts left to things that end-users can attack and test, and make sure works for them before being commited (Or testing the commited code still works for them)

      • Denis de Bernardy 3:44 pm on January 24, 2010 Permalink | Reply

        Fair enough. Would you find the keyword “featured-bug” more appropriate?

      • Denis de Bernardy 4:13 pm on January 24, 2010 Permalink | Reply

        I changed it to “featured”

        • Jane Wells 2:54 pm on January 25, 2010 Permalink

          The word Featured has a lot of connotations in terms of official endorsement and promotion (featured plugins, etc), which we currently already have in trac with the keyword “blessed.” If the point of the tag is that you are asking for the bug to be given a higher priority, a more appropriate tag would be “denis” or “please-look” or something that is more specific.

    • Andrew Ozz 12:23 pm on January 28, 2010 Permalink | Reply

      Looking at the chart above: there were a lot of fixed bugs/closed tickets for 2.8 and at the same time it had more problems than either 2.7 or 2.9. So it seems “more tickets closed” equals more problems at release.

      Going through the currently open tickets with patches marked as bugs, lots of them introduce some sort of architectural change (no matter how small) which eventually breaks something else. Even tickets marked as “tested, commit” have usually been tested only for the problem described in the current ticket and potentially introduce new bugs.

      In that terms I agree with DD32: a “bug hunt” should be a lot less of “patch a bug” and more of “test the patch for a known bug” and leave a comment on the ticket about what was tested and how. Having a list of patches to start with may work but generally most patches need this type of testing.

    • Matt 6:15 pm on January 28, 2010 Permalink | Reply

      Looking at the chart above: there were a lot of fixed bugs/closed tickets for 2.8 and at the same time it had more problems than either 2.7 or 2.9. So it seems “more tickets closed” equals more problems at release.

      I am in violent agreement with this comment.

      • hakre 6:34 pm on January 28, 2010 Permalink | Reply

        Take note, that the graph does not differ between actual bugs and features as Ryan already correctly pointed to. So Andrew Ozz sentence you violently agree with could be written this way as well:

        “So it seems “more features implemented” equals more problems at release.”

        Just to show the picture.

  • Ryan Boren 7:42 pm on January 22, 2010 Permalink | Reply  

    Some goings on in trunk:

    • jQuery updated to 1.4
    • Meta boxes for custom hierarchical taxonomies thanks to prettyboymp
    • More efficient unzipping
    • Customizable death. (Plugins can put a custom handler on wp_die().)
     

    • hakre 12:29 pm on January 25, 2010 Permalink | Reply

      For those thinking about the “customizeable death” as ryan nicely named it, the according ticket is #11892 which shows some of it’s usage. You should really take care if you use that feature, I suggest to replace it with an exception because functions calling wp_die() often suspect that the function won’t return.

      This might to take some more review, I provided an additional patch in the ticket for a use scenario in the tests.

  • Peter Westwood 9:30 pm on January 21, 2010 Permalink | Reply
    Tags:   

    Summary of Jan 21st 2010 Dev Chat 

    Ryan updated on the status of the merge which is now complete in its first form. The upgrade from single to multi works well switching back and forth is easily done by copying wp-config files. A large amount of the code cleanup is but there are still outstanding areas. It will be ready for people to start testing an early preview release in a week or two.

    Ryan then gave us a quick update on custom post types which are mostly all there except for fixing bugs. Quick Edit needs some work. The taxonomy needs some work. Some of the AJAX bits need better post type awareness – so if you want to dive in a try this feature out and feedback now sounds like a good time.

    Next we discussed private posts and how support for them could be improved and the query performance improved when they used as well as the pros and cons of moving them to being in a core plugin.

    We had a short discussion on Coding Standards and agreed to try an apply them more consistently and add some more detail to our existing documentation.

    We had a short discussion around the plugin/themes repository and better notification for plugin authors when a plugin is suspended as well as making the contact information more prominent.

    Finally we talked about moving to jQuery 1.4 and the consensus was to get it in early so we had time to find any issues

    (updated to correct 3rd paragraph to mention private posts)

     

    • Gary 10:35 pm on January 21, 2010 Permalink | Reply

      Just to clarify, (I read the IRC log, but couldn’t quite get the conclusion), are you referring to moving the entire custom post type system into a core plugin, or just moving some of the existing custom post types into a plugin?

      • Peter Westwood 7:42 am on January 22, 2010 Permalink | Reply

        It was private posts not custom post types. I have updated the summary to fix this typo

    • Stephanie Leary 10:48 pm on January 21, 2010 Permalink | Reply

      Quick correction, so fans of custom post types don’t freak out — we were actually talking about the private post/page status.

    • Ryan 10:56 pm on January 21, 2010 Permalink | Reply

      Awesome. You guys have fixed, changed or discussed most of things I was hoping would get changed in the next 12 months! Thanks :)

    • arena 2:18 am on January 22, 2010 Permalink | Reply

      More info on “single to multi works well switching back and forth is easily done by copying wp-config files”.

      Thank you!

    • hakre 12:29 pm on January 22, 2010 Permalink | Reply

      Regarding the coding standards, discussion is ongoing. Thanks for all the feedback in the meeting as well.

      And a ticket for patches has been opened: #11971.

    • ryan 11:51 pm on January 22, 2010 Permalink | Reply

      Is the chat log posted? I checked irclogs.wordpress.org, but it only seems that half of the 21st’s log is there

← Older posts

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