Updates from August, 2010 Toggle Comment Threads | Keyboard Shortcuts

  • Joseph Scott 10:32 pm on August 31, 2010 Permalink | Reply
    Tags: ,   

    Previously we’d talked about putting up a stats page on WordPress.org (WPORG) so that more people could see what was happening. While working on some of the new stats processing code on WPORG I realized that people would likely end up scraping this data for their own uses. That seemed like a waste, so instead as a first run the stats numbers are available in JSON format via:

    http://api.wordpress.org/stats/wordpress/1.0/

    http://api.wordpress.org/stats/php/1.0/

    http://api.wordpress.org/stats/mysql/1.0/

    A few notes about these numbers. First, they are summary percentages for the previous day (where day is based on GMT). You’ll also notice that these numbers don’t really line up with each other, this is because the system normalizes the version numbers and throws out odd/invalid versions (I was surprised by how many odd version strings there are out there). As a result each category is best compared to itself, instead of trying to compare PHP with MySQL numbers.

    The content type returned for this data is ‘application/json’, your browser may or may not display them correctly.

    This is a start, there are more things to be added to this in the future. One obvious item is support for getting numbers for previous days and date ranges. Another would be to add some pretty graphs to WPORG to display this data.

     

    • Andrew Nacin 7:48 am on September 1, 2010 Permalink | Reply

      Very cool! I’ll try to build a nice page for dotorg that uses this snapshot data.

      Along with change over time, I think minor versions would potentially be useful. I know it was helpful when we needed to choose a MySQL version to move to, and also identifying the number of installs actually affected by bugs like #14160. And it’s more data for people to play with.

    • Ben Forchhammer 11:56 am on September 1, 2010 Permalink | Reply

      Wow, this is great :-) Should be very useful when trying to decide which versions to support.

    • Denis 10:28 pm on September 2, 2010 Permalink | Reply

      Could it be possible to have php and mysql by WP version too? As well as WP and MySQL by PHP, and WP and PHP by MySQL? It seems the latter three would be more interesting.

      • Joseph Scott 4:41 pm on September 3, 2010 Permalink | Reply

        Certainly the data is there for that to be possible, we’d need to look at the queries involved to make sure it could be done in a reasonable way.

        • Denis 3:54 pm on September 4, 2010 Permalink

          I’ve no idea of your schema’s specifics, or whether you keep duplicate records related to each site in your stats, but I was thinking something like this:

          SELECT wp_version, mysql_version, php_version, COUNT(DISTINCT site_key)
          FROM stats
          WHERE stat_date > NOW() – interval ’1 day’
          AND wp_version IN ( $valid_versions )
          GROUP BY wp_version, mysql_version, php_version;

          The raw output of the above as /stats/raw/1.0/ would, I think, be the most interesting for plugin devs. It doesn’t necessarily need to be normalized as percentages, either: having the actual number of sites is useful to get an idea of how many users one is potentially targeting exactly.

    • Ryan McCue 11:39 am on September 3, 2010 Permalink | Reply

      Whipped up a quick Google Visualisation of these: http://ryanmccue.info/wp/stats/

    • filosofo 6:05 pm on September 3, 2010 Permalink | Reply

      Thanks for doing this, Joseph, Otto, and Ryan! A great combination of data and visualization.

    • Sergey Biryukov 6:33 pm on September 12, 2010 Permalink | Reply

      Is there any chance of making stats for localized versions available too?

    • Mike Schinkel 5:59 pm on July 8, 2011 Permalink | Reply

      Just found this thanks to Ryan C. Duff (thanks Ryan!) Curious, how is this data collected? From API requests to list plugins and themes?

  • Jane Wells 3:49 pm on August 31, 2010 Permalink | Reply
    Tags: code of conduct   

    Most of the time, all WordPress contributors are polite, congenial even, and hold themselves to a professional standard of behavior when interacting with other contributors, whether it’s here, in the dev chat, the forums, etc. Occasionally, though, we forget to put a priority on professional interaction, and we devolve into bickering or other less-appropriate behavior. Drupal has just adopted the Ubuntu code of conduct for their community, and I propose we do the same (or some slightly modified version thereof, if people have suggestions). Thoughts?

     

    • scribu 4:04 pm on August 31, 2010 Permalink | Reply

      I don’t see why not.

    • Andy 4:16 pm on August 31, 2010 Permalink | Reply

      I think its an excellent idea!

    • Banago 4:19 pm on August 31, 2010 Permalink | Reply

      That a great code of conduct – why not.

    • demetris 4:28 pm on August 31, 2010 Permalink | Reply

      No.

      We can regulate ourselves fine without signing codes of conduct.

      Fortunately, the most prominent contributors to the WordPress core behave impeccably for the most part, setting a live example of the kind of conduct that is expected. That is much stronger than a document (and, of course, a huge asset for the WordPress project).

      A few people here and there seem to think sometimes that they are above standards of good behaviour, but I don’t think an official Code of Conduct would do anything in those cases.

      Just because Ubuntu (which has a HUGE number of people involved) does this, or just because Drupal adopted it, it does not mean we have to do it too.

      Avoid unneccessary complexity!

      • Mark 4:41 pm on August 31, 2010 Permalink | Reply

        People in the community know this, but what about those daring to dip their toes in the water?

        You are right, signing a code of conduct (or a declaration, or a constitution, or…) doesn’t by extension mean anybody who subscribes to it will actually adhere to it when push comes to shove. The idea, *I think*, is more to show the community at large that there is some position of authority that will waggle their finger at misbehavior. It’s PR, and it’s not bad PR in any way, so I say go for it.

      • Jane Wells 4:55 pm on August 31, 2010 Permalink | Reply

        Right now, when we self-police, sometimes people get into a ‘who says i’m being inappropriate? that’s just your opinion, take a hike’ kind of thing. Having a code of conduct (not something people sign, just something posted on the website) to point to as the standard we’re judging by to help educate people is the goal.

        • demetris 5:52 pm on August 31, 2010 Permalink

          A code of conduct isn’t going to solve the “Who says I’m being inappropriate?” problem. To solve that, you need an authority that rules on particular cases and decides whether particular actions are appropriate or inappropriate. (sivel says this too, a few comments below, when he speaks of a community council.) Do we need that? Only if common sense and common decency fail us completely, in which case the project would be beyond repair.

          So, to repeat myself, avoid unneccessary complexity.

          Live example is the most forceful code of conduct. We should simply, all of us, try to keep our behaviour to the standards set by the best-behaved, and correct and acknowledge our mistakes when we happen to lapse.

    • Joe Hoyle 4:42 pm on August 31, 2010 Permalink | Reply

      I agree with demetris, the people who are not being polite (etc etc) are not likely to be reading the Code of Conduct.

      • Mark Jaquith 4:56 pm on August 31, 2010 Permalink | Reply

        But when they violate it, we can point to it and say “here, this is our standard.” That way it’s not just someone taking arbitrary offense or imposing their personal standards of decent interactions.

    • Andrew Nacin 4:56 pm on August 31, 2010 Permalink | Reply

      +1. I think it’s better to have one now, when we don’t necessarily have a specific need to reference one, versus having nothing to reference when we do need one.

    • Matt Martz 4:57 pm on August 31, 2010 Permalink | Reply

      I think if we do this, we however need to also define a community council.

      • Jane Wells 4:59 pm on August 31, 2010 Permalink | Reply

        To what end? If the point of a code of conduct is to have something on record, having a council (sounds awfully close to a tribunal) makes it sound like we’re going to have a punishment hearing process or something. We’d still self-police, we’d just have a common basis for judging if someone if stepping out of bounds.

        • Matt Martz 5:02 pm on August 31, 2010 Permalink

          Ubuntu has a community council that among other things decides how to ultimately deal with poisonous people within the community. Per that Ubuntu code of conduct:

          “On matters of community governance, the Community Council can make a final decision.”

          One thing that I wish we had is some sort of formal policy on those poisonous and how to deal with them.

        • Jacob Santos 5:08 pm on August 31, 2010 Permalink

          Having an independent council to decide is better than having those making the decisions rule with what could end up being an iron fist.

        • Mark Jaquith 5:12 pm on August 31, 2010 Permalink

          Ultimately, the lead developers (or the slightly expanded core team) perform that task. This is not so common that it needs to be formalized. There are only a few times that I can think that we’ve needed to consider asking someone to step back and take a break from WordPress.

          What is being proposed here is not a formal process, just something to point to when someone is being a jerk. No need to complicate it beyond that.

        • Ryan Boren 5:23 pm on August 31, 2010 Permalink

          An iron fist usually doesn’t develop without the complacency of the fistees. I don’t think we need to design for the possibility of us all becoming demure.

        • Jacob Santos 6:00 pm on August 31, 2010 Permalink

          I’ll put it this way, based on what happened when I joined the community; I do not think I would have contributed to WordPress, if it was based on a committee formed on standards of conduct.

        • Rich Pedley 6:21 pm on August 31, 2010 Permalink

          @Mark Jaquith – Support forum moderators should also fall within that scope.

    • Aaron D. Campbell 7:49 pm on August 31, 2010 Permalink | Reply

      I’m all for it. Having a standard to point to is a great idea.

    • Mr Mist 7:56 pm on August 31, 2010 Permalink | Reply

      It’s a neat idea… But.. It kinda sounds like something that you’d expect most professionals to behave according to without having to set it down on paper. Then if folk did sign up to it, what happens if the code is broken?
      Is the intention that by signing up to the agreement, the issues it covers go away? I’d expect that to be unlikely. It’d surely hold for the majority, but then the majority are not often the cause of trouble.
      So I guess in the end my problem with it is that, to be effective, you’d need an actual set of “punishments” to deal with what happens when the code is breached, and that just seems to be against the whole spirit of collaborative work.

      • Jacob Santos 8:52 pm on August 31, 2010 Permalink | Reply

        I don’t exactly understand this. I think I’m a little jaded because I’ve read about and seen first hand really bad arguments get out of hand and require someone jump in and cool down and also require a ban. None of which has occurred in WordPress community.

        Another thing I don’t understand is the punishment. Presumably, I would guess that future contributions will no longer be accepted. If that is one of the punishments, then I fail to see who that really harms. So you basically are punishing someone by giving their time back that they could otherwise spend helping the project you are lead on?

        I guess with a project as large as a contributor base as WordPress, it is no harm to the project to lose 1 or 2 contributors.

    • filosofo 8:22 pm on August 31, 2010 Permalink | Reply

      My first reaction is that a toothless statement like this serves no real purpose: if you believe in these things you’ll do them anyways; if you don’t, you’re not going to care about some random statement.

      But I think it was the author of Predictably Irrational who mentioned a number of studies that have shown that just being reminded to behave leads to better behavior (some were even reminded of non-existent codes of conduct and improved their behavior) . So it’s irrational–but apparently it works.

    • Melvin Ram 5:18 am on September 1, 2010 Permalink | Reply

      Sounds like a sound idea. It should give everyone a common foundation, even though it should be common sense.

  • Otto 9:29 pm on August 30, 2010 Permalink | Reply
    Tags: , ,   

    Email subscriptions are now enabled for individual topics on the support forums.

     

    • Jane Wells 9:29 pm on August 30, 2010 Permalink | Reply

      Nice!

    • Milan 9:38 pm on August 30, 2010 Permalink | Reply

      What about suggestion I sent you for automatic subscriptions to topics with plugin’s tag for plugin author?

      And maybe it would be better to have checkbox above submit button. (there are functions for that, if you don’t know how to, look at Kakumei)

    • scribu 10:10 pm on August 30, 2010 Permalink | Reply

      I’m starting to like this 3.org thing. :P

    • Banago 11:15 pm on August 30, 2010 Permalink | Reply

      That’s awesome – keep it up Otto.

    • Alphawolf 7:07 am on August 31, 2010 Permalink | Reply

      Thanks for that! :-)

    • Mr Mist 8:46 am on August 31, 2010 Permalink | Reply

      Nice one Otto! I posted this info to the forums list in case people follow that and not here. That feature should qiuet a few moans and make the forum more useful.

    • Pete 12:23 pm on September 4, 2010 Permalink | Reply

      This is a great feature for users to keep them coming back

  • Jane Wells 9:23 pm on August 30, 2010 Permalink
    Tags: ,   

    At this week’s dev chat, we’ll start talking about scope for 3.1. We won’t decide things until the following week, but if there’s a feature you think should be in 3.1, suggest it in a comment here, and we’ll discuss as many as we can get through on Thursday.

    [Edit: Comments closed as of the start of the 3.1 scope meeting, for organizational purposes.]

     

    • Aaron Jorbin 9:26 pm on August 30, 2010 Permalink

      Adding a new function for quickpost boxes (like QuickPress on the dashboard now), that has plenty of hooks and is usable by custom post types. I imagine something modeled on comment_form()

      • Matthias Warda 12:34 pm on August 31, 2010 Permalink

        great suggestion.. and possibilities for useres to edit their “quickposted” posts in the frontend.. also usable for custom post types and custom fields..

    • Jane Wells 9:26 pm on August 30, 2010 Permalink

      I would really like to see internal linking as a primary user feature in this release. (i.e., being able to select existing content to link to from within the post/page editor link tool)

      • Xavier 9:55 pm on August 30, 2010 Permalink

        +1.

      • Stéphane Bergeron 10:05 pm on August 30, 2010 Permalink

        +1 ! That would be awesome!

      • Banago 11:17 pm on August 30, 2010 Permalink

        Yes, this is a necessity that comes with Custom Post Types and the sooner it gets some attention, the better.

      • cehwitham 8:49 am on August 31, 2010 Permalink

        +1 this would really add to the CMS feature set.

      • EWW 11:55 am on August 31, 2010 Permalink

        I’d love to see this. Makes the content far more valuable to me if I can reference / link across posts/pages for targeted related content. Explicitly targeted “Next classes” in a series, “Related forms,” etc. I’ve been writing custom plugins to handle this, but a more native feature would be preferred.

      • Helen Hou 1:53 pm on August 31, 2010 Permalink

        +1

      • lars 5:49 am on September 2, 2010 Permalink

        jep would be cool to support the internal linking … it could be much easier

      • Beau Lebens 7:20 pm on September 2, 2010 Permalink

        Perhaps a good starting point, which I currently use *alot*: http://wordpress.org/extend/plugins/link-to-post/

    • Ryan Boren 9:27 pm on August 30, 2010 Permalink

    • Jane Wells 9:29 pm on August 30, 2010 Permalink

      Better theme finding features, like on wordpress.com

    • Nick 9:29 pm on August 30, 2010 Permalink

      Overhaul media management, the uploader, and inserting media.

    • phayze 9:29 pm on August 30, 2010 Permalink

      Native domain mapping for multi-site installs would be a very useful feature, and one I can imagine a lot of people want.

    • Matt 9:34 pm on August 30, 2010 Permalink

      Password picking, resets, and logins to industry best practices. (For example, username should be something like [a-z0-9] but we should allow login by email too, and emails should be unique.) Some of this may need to be going-forward.

      • scribu 9:40 pm on August 30, 2010 Permalink

      • Aaron D. Campbell 3:28 pm on August 31, 2010 Permalink

        Also #9568 for E-Mail logins

      • Ryan Duff 1:03 pm on September 1, 2010 Permalink

        Ability to change usernames would be great too. 3.0 allowed choosing a username for admin during setup, but you still have to go into PHPMyAdmin, etc to change the username across all versions. This would allow people stuck with “admin” an easier path to a more secure install.

    • Matt 9:35 pm on August 30, 2010 Permalink

      AJAX paging and search in all relevant screens.

    • Matt 9:35 pm on August 30, 2010 Permalink

      Upcoming WordCamp dashboard widget.

    • Shannon Smith 9:36 pm on August 30, 2010 Permalink

      Multilingual sites.

      • Shannon Smith 9:47 pm on August 30, 2010 Permalink

        With proper language switching, SEO per language, mirrored language specific menus, and multi-site compatible.

        • Kau-Boy 11:59 am on August 31, 2010 Permalink

          That would be nice to have, but I think it will be a WP 4.0 feature. Until that I stick with qTranslate :)

    • Matt 9:36 pm on August 30, 2010 Permalink

      Bring other pages in-line with the tab thing we did on the themes page.

      • Dennis 7:50 pm on August 31, 2010 Permalink

        I disagree. I don’t like having to click through to the Appearance tab, then wait for the page to load, then click Install Theme. I don’t have any issue with the tabs, but I miss the Install New Theme nav link, and I’d be rather annoyed if the Add New Plugin link in the navigation went away.

        • jeremyclarke 7:07 pm on September 2, 2010 Permalink

          I’m with Dennis. Based on how the tabs were added the to-do would be: Review the tabs idea and decide if they should be implemented in other parts of the admin, or removed from the themes section.

          IMHO they are weird and messy, I’d rather lose them than commit to more awkward implementations.

    • Andy 9:36 pm on August 30, 2010 Permalink

      Assign an existing post to a newly defined, or pre-existing, custom post type.

    • Amy 9:36 pm on August 30, 2010 Permalink

      A nice feature would be to allow the post types to use the tag system and categories or even have their own. Also would be nice to be able to create post types in the admin section.

      • Andrew Nacin 5:02 am on August 31, 2010 Permalink

        You can register your own taxonomies for both the core post types and for custom ones. You can also use the core taxonomies on custom post types (or pages) via register_taxonomy_for_object_type(). I don’t think we’ll see a UI for creating CPTs anytime soon.

        • Amy 1:16 pm on August 31, 2010 Permalink

          Well that is a shame. Also I got categories to work but not tags to work on custom post types. I posted on the forums to get an answer to how to do it and now one has answered after over a month.
          Custom post types sounded like a cool feature that was added to 3.0 until I found all these issues, so I just installed wordpress 3 times to get what I wanted custom post types to do.

    • Matt 9:37 pm on August 30, 2010 Permalink

      Make the upgrade system show real progress, and be a separate lightbox or similar from normal admin (which doesn’t work while upgrading anyway).

    • Matt 9:37 pm on August 30, 2010 Permalink

      SVN awareness for update system(s).

    • Jane Wells 9:37 pm on August 30, 2010 Permalink

      QuickPress categories.

    • Matt 9:38 pm on August 30, 2010 Permalink

      Derivative themes, like child themes but more sideways than hierarchical. (Re: convo at WC Savannah.)

      • jeremyclarke 5:27 pm on September 2, 2010 Permalink

        Whatever you’re talking about should be a part of the Child themes system rather than a new one, there must be some way to avoid increasing the number of types of themes by 50% to achieve the goal.

    • Andy 9:38 pm on August 30, 2010 Permalink

      The ability to upgrade all your WordPress installs with one click…

    • Ryan Boren 9:40 pm on August 30, 2010 Permalink

      Admin Bar, wordpress.com style

      • Alex M. 9:43 pm on August 30, 2010 Permalink

        And multi-site compatible unlike my ancient plugin.

        • Matt 9:45 pm on August 30, 2010 Permalink

          Your plugin is actually pretty slick.

        • Andrea_R 12:45 pm on August 31, 2010 Permalink

          ha! I’ve been sending people to your plugin. they’ve been managing. ;)

    • Michael Fields 9:40 pm on August 30, 2010 Permalink

      Would be great if WordPress stored collections of widgets enabling users to easily assign them to the new registered sidebars during theme change -> Much like how the menu system works.

      • Matt 9:41 pm on August 30, 2010 Permalink

        Yes, and default to first sidebar.

        • Michael Fields 9:44 pm on August 30, 2010 Permalink

          Agreed. Was also thinking that a naming convention could be established that themes could use as a base to name different locations…. not necessarily a “core item” though.

      • Matt 9:41 pm on August 30, 2010 Permalink

        (Sorry extrapolated to more general horrible bug where when you switch themes you lose all your hard-added widgets.)

      • Lance Willett 9:57 pm on August 30, 2010 Permalink

        +1 for active widgets moved to first registered sidebar instead of Inactive during a theme switch. Also, if number of sidebars match, transfer widgets exactly (regardless of sidebar ID value).

    • Matt 9:41 pm on August 30, 2010 Permalink

      Activity stream for dashboard of everything going on inside of WP — new posts, comments, moderation actions, posts edited, categories added, etc, users registered / modified, basically every CRUD action. Would be *killer* for multi-user blogs.

      • John James Jacoby 5:30 am on August 31, 2010 Permalink

        Sounds like the BuddyPress activity stream on steriods and focused internally instead of externally. This could fairly easily be a custom post type, and any activitystrea.ms standard data would be postmeta (if we went that route.)

        • John James Jacoby 5:34 am on August 31, 2010 Permalink

          Of course, storing it as a post type would be difficult for multi-site installations, unless we did some root-blog trickery similar to what BuddyPress does already.

        • Andrew Nacin 5:34 am on August 31, 2010 Permalink

          Indeed, was just about to say that. I’ve been thinking about that dilemma for a plugin as simple as this one, and will probably use CPT when running on a single site but spawn a single global table on multisite.

        • John James Jacoby 5:38 am on August 31, 2010 Permalink

          If we went the single global table route, then bp-activity may be the best place to start (although it creates two tables, activity and activitymeta.)

    • Andrew Nacin 9:41 pm on August 30, 2010 Permalink

    • Doug Stewart 9:41 pm on August 30, 2010 Permalink

      Widget logic, allowing for per-page, post or custom post selection. GUI sugar a bonus.

    • Scott Taylor 9:42 pm on August 30, 2010 Permalink

      unattach Media from posts without deleting, sort/reorder Image attachments

      • Aaron D. Campbell 3:22 pm on August 31, 2010 Permalink

        I’ve found myself needing to attach media to a different post several times. I always end up bringing up firebug and manually running:
        findPosts.open(‘media[]‘,’123′);
        Where 123 is the media id.

    • Matt 9:42 pm on August 30, 2010 Permalink

      Child theme support for theme directory installation, so we can have child themes in directory.

    • Andrew Nacin 9:42 pm on August 30, 2010 Permalink

      Opt-in meta capability handling for custom post types.

    • Matt 9:43 pm on August 30, 2010 Permalink

      Changelog information on update/upgrade screens, so you have an idea what’s new when you’re updating.

    • Andrew Nacin 9:43 pm on August 30, 2010 Permalink

      Ability to have someone with the ability to moderate comments without the need to edit posts. Requires #14520 and #12104.

    • Ozh 9:43 pm on August 30, 2010 Permalink

      Links (and Media?) as custom post types

      • Andrew Nacin 9:44 pm on August 30, 2010 Permalink

        Media is already a CPT. Links would be great.

      • Matt 9:44 pm on August 30, 2010 Permalink

        As a reduction: links just as a widget.

      • scribu 9:45 pm on August 30, 2010 Permalink

        Theoretically, Media already is the ‘attachment’ post type. The UI just needs updating.

      • Banago 11:33 pm on August 30, 2010 Permalink

        It’s some times I have been thinking to write about this Links thing – I suggest it gets into a plugin, or as Matt suggested a widget. I don’t see why it must take so much real estate when very few people really make use of it.

      • Justin Tadlock 1:50 am on August 31, 2010 Permalink

        I say move Links out of core and make a plugin using a CPT. If we keep them, they should still be a CPT.

      • Stephanie Leary 3:16 pm on August 31, 2010 Permalink

        Links as CPT for sure, so they can use the edit.php interface. The lack of paging in the current editing screen is a big problem with a lot of links.

        (I’d hate to see them removed, or moved to a plugin. Why get rid of a good feature?)

        • Devin Price 6:21 pm on August 31, 2010 Permalink

          +1 on link CPT. Instead of a removal, I’d suggest pairing it down and improving the interface. Make the link relationships a taxonomy.

        • Andrew Nacin 6:35 pm on August 31, 2010 Permalink

          They already are :-)

    • Andrew Nacin 9:44 pm on August 30, 2010 Permalink

      Opt-in index/root handling for post type archives and taxonomy indexes.

      • Aaron D. Campbell 9:20 pm on August 31, 2010 Permalink

        I was surprised when I found out I had to make my own index pages for custom post types. It would be nice functionality to have. Currently there’s a bit of an issue with rewrites on a paginated index page if it has the same slug as your post type.

        • Eric Curtis 9:49 pm on August 31, 2010 Permalink

          +1 index, paged views and archives for custom post types would be most welcome

        • Brooke Schreier Ganz 6:35 pm on September 1, 2010 Permalink

          This. There’s now a plugin floating around out there that can do this, but it was a surprising oversight that this functionality wasn’t included already.

    • Doug Stewart 9:45 pm on August 30, 2010 Permalink

      Headway/Squarespace-like front-end editing.

      • Andrew Nacin 5:27 am on August 31, 2010 Permalink

        A front-end editor API like wp_login_form(), comment_form(), and the proposed (above) QuickPress form would be very handy. Though, I suppose if done right the proposed QuickPress form could be a front-end editor.

    • Ian Stewart 9:45 pm on August 30, 2010 Permalink

      An “Update and Approve Comment” button next to the “Update Comment” button in the Edit Comments page.

      +1 for Widget Logic and an Admin Bar.

    • Matt 9:46 pm on August 30, 2010 Permalink

      Unify how plugin/theme installers work UI-wise, as they feel like two entirely separate products right now. (Where you click to install, etc.)

      • Ryan Boren 9:46 pm on August 30, 2010 Permalink

        They’ve needed thorough UX/UI love since the beginning.

    • Matt 9:47 pm on August 30, 2010 Permalink

      Something like TimThumb.

      • Doug Stewart 9:49 pm on August 30, 2010 Permalink

        Why not TimThumb itself? It’s GPL’d, no?

        • Alex M. 9:50 pm on August 30, 2010 Permalink

          TimThumb kinda sucks and it’s not complicated code at all. Better to start from scratch.

        • Matt 9:50 pm on August 30, 2010 Permalink

          Sure, just trying to stick to ideas rather than implementation details. Implementation, including if we base on existing code, we figure out later. Key to brainstorming!

        • Matt 9:51 pm on August 30, 2010 Permalink

          Alex, no need to say that.

        • Alex M. 9:56 pm on August 30, 2010 Permalink

          Alex, no need to say that.

          Sorry, I can across differently than I meant to and sucks was the wrong word.

          What I meant by my earlier statement that while TimThumb is fine and does what it was designed to do perfectly fine, it was designed to be a standalone script. It doesn’t integrate with WordPress very well and that resizing images using GD is not complicated enough to where we should use TimThumb instead of a custom solution IMO.

      • Alex M. 9:50 pm on August 30, 2010 Permalink

        I think there might be a ticket somewhere from Mark about the idea of on-demand thumbnailing. Combined with not hard-coding attachments into posts (see a bunch of comments up) would rock.

        • Doug Stewart 9:51 pm on August 30, 2010 Permalink

          My shared hosting account preemptively weeps.

        • Alex M. 9:57 pm on August 30, 2010 Permalink

          Just because it’s on demand doesn’t mean it’s for every user. It’s done on demand right now but the demanding user is you instead of a visitor. ;)

      • Michael Fields 9:52 pm on August 30, 2010 Permalink

        Definitely like this solution for automatic image resizing: http://austinmatzko.com/2010/03/11/plugin-creates-wordpress-thumbnails-on-demand/ I’ve coded a second version as well which works with almost all of WordPress’ internal functions.

      • Banago 11:36 pm on August 30, 2010 Permalink

        What do we need something like TimThumb for?

        • Alex M. 11:37 pm on August 30, 2010 Permalink

          Dynamic size thumbnail generation. See above discussions.

        • Banago 11:40 pm on August 30, 2010 Permalink

          I know what TimThumb does, but I think the actual solution the_post_thumbnail thing is pretty slick and does the job perfectly.

        • Alex M. 11:53 pm on August 30, 2010 Permalink

          What if you change the size of your post thumbnails though? :)

        • Brooke Schreier Ganz 6:37 pm on September 1, 2010 Permalink

          Don’t forget features like watermarking, rounded corners, drop shadows, and stuff like that.

    • Matt 9:48 pm on August 30, 2010 Permalink

      EXIF metadata extraction into taxonomy for things like camera, ISO, focal length.

      • Beau Lebens 8:28 pm on September 2, 2010 Permalink

        If not taxonomy then at least metadata, agreed.

    • Andrew Nacin 9:49 pm on August 30, 2010 Permalink

      Multiple featured images; dynamic resizing (Matt said TimThumb above).

    • Matt 9:49 pm on August 30, 2010 Permalink

      Taxonomy convention (no code even needed) for themes to do Tumblr-style posts, including switching 2010 to use it for its asides and gallery features.

    • Ian Stewart 9:52 pm on August 30, 2010 Permalink

      A conditional tag like is_multi_author() for multiple author blogs.

      • Andrew Nacin 9:55 pm on August 30, 2010 Permalink

        I hate the idea of discussing implementation during brainstorming, but I’ve been thinking about this. Would be dirt cheap to store it in an autoloaded option that stores either 0 or 1, and we can toggle it based on user creation. This probably can also assist in our other instances where we don’t show author drop-downs in the admin area based on the number of non-subscriber users.

        • Peter Westwood 4:55 pm on August 31, 2010 Permalink

          Slipping into implementation mode again (I’ve thought alot about this)

          Transient not option. Meaning is either “We have multiple authors and they have posts” or “We have multiple users with authoring rights” – I favour the first of these as it is more valuable to me and easier to compute but your extra use cases imply the other.

    • Andrew Nacin 9:52 pm on August 30, 2010 Permalink

      Advanced taxonomy queries in WP_Query, including tax__in etc. and the more advanced stuff with WP_Tax.

    • Milan 9:53 pm on August 30, 2010 Permalink

      Better support for non-Latin scripts in usernames and URLs (we have author, feed, comments, page, category etc. that can’t be changed while now we have internationalized domains, for example).

    • Matt 9:54 pm on August 30, 2010 Permalink

      Email notifications for upgrade available, pending post available, if someone edited a post you’re an author of.

      • Andrew Nacin 9:56 pm on August 30, 2010 Permalink

        I’ve written a plugin for the post aspects that I can probably have released. (Also utilizes Text_Diff for revisions… But it’s a specific use case.)

      • Banago 11:36 pm on August 30, 2010 Permalink

        +1

    • Matt 9:55 pm on August 30, 2010 Permalink

      Re-examination of comment moderation emails, namely the admin_email option and how that’s separate from the user system. (Perhaps should be a list of users that should get admin stuff, and be tied to the email in their profile.)

    • Mark Jaquith 9:56 pm on August 30, 2010 Permalink

      Ability to combine subdirectories and subdomains on one Network. e.g. example.com (main), foo.example.com, example.com/bar/

      • Matt 9:56 pm on August 30, 2010 Permalink

        And domain mapping in general?

      • Ozh 9:58 pm on August 30, 2010 Permalink

        an easy UI for enabling multisite on existing blogs?

        • Rich Pedley 7:19 am on August 31, 2010 Permalink

          I’d second this. Although I realise it was done the way it was to stop people completely bu.. erm messing things up. However I believe it may be more appropriate for plugin territory. I think there is one already written, but can’t place it atm.

        • Andrew Nacin 4:29 pm on August 31, 2010 Permalink

          It’s been written for core; I’ve also seen it as a plugin. But we can’t make MS easier to install until it is easier to manage and use first.

    • Michael Fields 9:57 pm on August 30, 2010 Permalink

      The ability to easily change a comment’s parent id without going into the database.

    • John P. Bloch 9:57 pm on August 30, 2010 Permalink

      More flexible permalinks for custom post types.

    • Matt 9:57 pm on August 30, 2010 Permalink

      Show comment metadata (like browser, IP) on edit comment page.

    • Matt 9:59 pm on August 30, 2010 Permalink

      Logged in (maybe just admin?) users should bypass “too fast cowboy” and dupe comment checks.

    • Mark Jaquith 9:59 pm on August 30, 2010 Permalink

      Pull the trigger on the proposed Role/Cap simplification. One role per user. No freestanding caps, no negative caps. Role = bucket of positive caps. Each person has a role. Bonus: we get fast blog+role to user lookups. Should make Author dropdown and Users page faster on sites with a lot of users. Opens door for us to include simple role management.

      • scribu 10:01 pm on August 30, 2010 Permalink

        Bang! already :)

      • Andrew Nacin 10:02 pm on August 30, 2010 Permalink

        But consider keeping multiple roles, stored unserialized in usermeta. Allows for continued flexibility but doesn’t prevent fast lookups as they’ll be additive.

        • scribu 10:03 pm on August 30, 2010 Permalink

          Exactly.

        • Mark Jaquith 10:04 pm on August 30, 2010 Permalink

          Possibly. But then we should explicitly support it in the core UI, which should be weighed appropriately. WP supports it, WP’s UI does not.

        • Andrew Nacin 10:04 pm on August 30, 2010 Permalink

          Indeed… was going to mention how that’d be a drag on a simple role management UI.

      • filosofo 10:03 pm on August 30, 2010 Permalink

        Caps as a taxonomy.

      • iamfriendly 8:02 am on August 31, 2010 Permalink

        If it was possible to ‘+1′ on this a million times, I would do so. You can take that as a ‘please do this’ :)

      • Stephanie Leary 3:21 pm on August 31, 2010 Permalink

        +1! Also opens the door to fixing all the things that are broken with private content.

    • Andrew Nacin 9:59 pm on August 30, 2010 Permalink

      Elimination of the /blog on the root site in a subdirectory installation. Implement a unique slug function for that node to ensure there are no conflicts between the root blog and any other blogs.

      • Andre 12:15 pm on August 31, 2010 Permalink

        +1. Or at least let the user set /blog to the term of their choice, like /news.

    • filosofo 10:02 pm on August 30, 2010 Permalink

      Admin notification system: log X number of messages; have the possibility of sending notifications to particular users or roles / caps.

    • Doug Stewart 10:04 pm on August 30, 2010 Permalink

      Native like/reblogging for networked sites. Conspicuously displayed features-supported meta for themes listed in the installer.

    • Ozh 10:07 pm on August 30, 2010 Permalink

      Fix some UI inconsistencies: Themes have a Install & Manage *tab*, Plugins have a “add new” *button*.

      Also, I’ve recently started to realize the setting pages are not sexy. Compare Settings/Writing to “Add new post”. One page is boring, the other is attractive.

      • TECannon 1:48 am on September 1, 2010 Permalink

        I’m all for getting rid of the table layout for settings pages!

    • Syed Balkhi 10:09 pm on August 30, 2010 Permalink

      Would be great if WordPress Child Theme support can be added, so the theme repository can allow child themes.

      Expanding the Add Plugin area to allow users to vote for Plugin compatability… (This would be great)

    • Andrew Nacin 10:11 pm on August 30, 2010 Permalink

      Consider a HTTP/Filesystem-like tiered library for ImageMagick and GD. Should improve our image generation especially when dealing with saturations and color profiles..

    • Matt 10:11 pm on August 30, 2010 Permalink

      Icons / short descriptions for plugins.

    • Andrew Nacin 10:12 pm on August 30, 2010 Permalink

      Introduce capability control to the Settings API, allowing for it to be used on theme options pages when a user has edit_theme_options but not manage_options.

    • Andrew Nacin 10:14 pm on August 30, 2010 Permalink

      Better API for handling the admin menu, including the ability to remove admin menus without messing with the globals. http://core.trac.wordpress.org/ticket/14666

    • Ozh 10:16 pm on August 30, 2010 Permalink

      One thing that annoys me a little is, when clicking on an “Add media” icon, the delay while the uploader iframe loads.
      => Maybe loading the iframe from the start, in the background & keeping it hidden till needed?

      • Matt 10:17 pm on August 30, 2010 Permalink

        Yes! And the add link button. Way too slow.

    • Scott Berkun 10:23 pm on August 30, 2010 Permalink

      Can we please, pretty please, make the UI for adding an image suck less? Between the slow flash load thing, the dialog boxes with scroll bars (wtf!) and other related weird UI decisions – it’s one of the wost UXes for frequently used WP features.

      I’ll give my right arm for this (Or at least someone else’s right arm that looks like mine)

      • Jane Wells 10:37 pm on August 30, 2010 Permalink

        We worked up a new media handling UI in the 2.9 dev cycle, but the underlying code for media features was so convoluted that it was decided to hold off until we could really give it the attention it deserved and fix the underlying structural issues. We thought we could just change the UI, but the media functions touch so much of the code base in so many ways that it turned out to be a bad assumption. It’s on the docket to come back to, but not for 3.1, since it will need a bigger release cycle.

    • JohnONolan 10:29 pm on August 30, 2010 Permalink

      Massive clean up of admin CSS dev files (ack! They have no comments!) with easier and more intuitive support for color variations.

      • Joachim kudish 3:09 am on August 31, 2010 Permalink

        I’d love to see that too!

      • Aaron D. Campbell 9:32 pm on August 31, 2010 Permalink

        And get rid of IDs in favor of classes…it’s a real pain to make your new UI match an existing one when you have to copy/paste a ton of CSS.

      • TECannon 1:44 am on September 1, 2010 Permalink

        +1 for UI CSS love.

    • Kailey 10:39 pm on August 30, 2010 Permalink

      Allow orderby parameter (and order) in query_posts() to accept multiple values.

      • filosofo 11:27 pm on August 30, 2010 Permalink

        orderby does accept multiple values, separated by spaces, but I suppose you mean for the case in which the key values have difference orders, which it currently doesn’t support (e.g. ORDER BY a ASC, b DESC).

        • Kailey 11:43 pm on August 30, 2010 Permalink

          With CPT being used more and more, it’d be nice to see some more options/control for ordering posts.

    • Aaron Brazell 10:46 pm on August 30, 2010 Permalink

      Further work on workflow on Multisite. Getting rid of the ridiculous no non-www domain rules, built in domain mapping, Make using Multisite as easy as using WordPress (it’s not… it’s like you enter an alternate universe), etc. We can’t do everything to make Multisite better in 3.1 but we can do alot a lot to improve the user experience.

      • Andrea_R 10:49 pm on August 30, 2010 Permalink

        You can use a www domain. Sure, there’s a warning, but it does work. ;)

        The whole network setup relies on the server, so does domain mapping, making it easier for non-techie people is a -1 cuz they;ll flip it on, do nothing on the server, then yell it’s broken.

        (example: mod_rewrite is needed for pretty permalinks. But urls still work without it. turn on the network without nod_rewrite and it appears busted.)

    • Doug Stewart 10:49 pm on August 30, 2010 Permalink

      Is pagination of comments broken? I seem to have lost the first page worth of such.

      • Alex M. 10:53 pm on August 30, 2010 Permalink

        P2 appears to not support comment paging. Or something.

        The first page of comments can be viewed via the homepage. I’m hesitant to disable comment paging for fear of a huge comment list.

        • Andrew Nacin 4:30 am on August 31, 2010 Permalink

          Looks like the paging endpoint works fine; it’s just missing links for it. Odd.

          Turned off paging for now across this blog.

    • Matt Wiebe 11:02 pm on August 30, 2010 Permalink

      Implement taxonomy metadata, as in trac ticket #10142 (link) and the Taxonomy Metadata plugin.

      • Nathan Rice 11:52 pm on August 30, 2010 Permalink

        +1

      • mikeschinkel 2:06 am on August 31, 2010 Permalink

        +1

      • bentrem 3:57 am on August 31, 2010 Permalink

        +1 … tag / category / topic / subject / issue …

      • Lee Willis 9:28 am on September 1, 2010 Permalink

        +1

      • jeremyclarke 7:13 pm on September 2, 2010 Permalink

        Definitely. This is a simple and obvious need. I’d also support a tool similar to custom fields in posts for adding arbitrary meta values to a term, that would cover a huge portion of use-cases without the need for a plugin. (bonus points for a way to register default fields to show in the term editing screen, a need that also applies to post meta)

    • JohnONolan 11:06 pm on August 30, 2010 Permalink

      More intuitive support for custom post types with get_archive_template() – see #12974

      http://core.trac.wordpress.org/ticket/12974

      • Devin Price 6:34 pm on August 31, 2010 Permalink

        +1 Would nice to see a template for multiple-customposttype.php. Looks like a good discussion is already happening in the ticket.

    • Banago 11:27 pm on August 30, 2010 Permalink

      Show hierarchical pages and categories on Custom Menu UI – so that you don’t have to rearrange items to parents and children, but rather import the original hierarchy.

    • Erlend 11:45 pm on August 30, 2010 Permalink

      Change of username (by default for admin only and by-request for others).

    • Mark McWilliams 11:45 pm on August 30, 2010 Permalink

      Can I open my old can of worms and basically sum it up as improving the Rewrite System and the way it works, almost like how Drupal do stuff (in a way) which would solve so many different debates! — The stuff I was shot down for in February really! ;)

      • mikeschinkel 2:08 am on August 31, 2010 Permalink

        Mark: Agreed. Here’s the ticker (the ticket evolves, that latter parts or more relevant) – http://core.trac.wordpress.org/ticket/12935

      • Mark McWilliams 12:54 pm on September 1, 2010 Permalink

        Thinking about it a bit more, not only would it solve debates, but it’d tick quite a few suggestions off already being made, even if it meant a plugin was built off a fully improved system! Oh, and thanks for the link Mike, I couldn’t remember what ticket it was you had running!

      • Mark McWilliams 1:29 pm on September 1, 2010 Permalink

        Related Trac Tickets — #13816 #12935 #12974 #14675 (Probably others too!)
        Possible-Related Tickets — #11576 #12779 #13068 #14449 (Could be others too!)

        With a better, and improved Rewrite System, 99.9% of all of these could be solved!

    • Jon Breitenbucher 11:46 pm on August 30, 2010 Permalink

      The ability to search themes in a MS install similar to how one can search for them on WordPress.com and the theme repository.

      • Andrea_R 12:49 pm on August 31, 2010 Permalink

        Jane mentioned something like this above. :)

    • Erlend 11:46 pm on August 30, 2010 Permalink

      Canonical plugins along the lines of the “More Types” “More Taxonomies” and “More Fields” plugins.

    • benkulbertis 11:49 pm on August 30, 2010 Permalink

      Make WordPress’s TinyMCE more HTML friendly?

      • bentrem 3:59 am on August 31, 2010 Permalink

        A perenial favorite of mine.

      • Andrew Nacin 4:02 am on August 31, 2010 Permalink

        Updating to TinyMCE latest is a high priority thing we need to accomplish.

    • Ron 11:55 pm on August 30, 2010 Permalink

      Unified registration: http://core.trac.wordpress.org/ticket/14108

      A couple others mentioned to me in the last week – bulk insert (into post) from media library, add context to widget_title filter.

      • Andrea_R 12:50 pm on August 31, 2010 Permalink

        Woudl this include the ability for a user to sign up to a site without going to the main blog first? Cuz that’s a complaint.

    • Bronson Quick 11:59 pm on August 30, 2010 Permalink

      How about something to add in easy Page and Post linking. Perhaps something like this plugin http://www.thatwebguyblog.com/post/sweet_links_for_wordpress_tinymce_advanced

      • Ryan Boren 1:45 pm on August 31, 2010 Permalink

        Looks like the internal linking that Jane requests above.

    • Justin Tadlock 1:01 am on August 31, 2010 Permalink

      • Term metadata
      • Full support of custom post statuses
      • Optional support of “home”/”archive” page for post types.
      • API for handling admin menus
      • More support and options for querying posts by taxonomies and post types.
      • Search for theme page templates in sub-folders.

      • Brian Richards 3:26 am on August 31, 2010 Permalink

        +1 for page templates in subfolders!

      • Andrew Nacin 4:02 am on August 31, 2010 Permalink

        Term metadata, API for admin menus, home/archive for CPTs have been previously mentioned.

        Not sure if modular themes is among the many comments above but that’d be interesting. #12877

        More options for querying taxonomies have been mentioned and there are two tickets in progress. #9951 and #12891. Not sure what you’re looking for in terms of post type querying.

        • Justin Tadlock 8:39 pm on August 31, 2010 Permalink

          Didn’t mean to add “post types” to that item. I was just quickly typing out things. Taxonomies definitely need some work though.

    • Doug Stewart 1:34 am on August 31, 2010 Permalink

      Crazy idea:
      Making WP’s output able to flip between X/HTML and HTML5 with the flip of a (wp-config?) switch. Perhaps we could even offer two “translations” of WP, one in each doctype?

      • Matt Wiebe 3:21 am on August 31, 2010 Permalink

        +1. It’d be nice to lose some markup (eg declaring type=”javascript” on script tags) that’s unnecessary in HTML5.

      • Andrew Nacin 3:58 am on August 31, 2010 Permalink

        I don’t see why we need to fork and serve both. Why not just move to HTML5 in the admin?

        • Doug Stewart 4:08 am on August 31, 2010 Permalink

          I didn’t explain myself well. Perhaps it’d be an abuse of the i18n po/mo stuff, but I was suggesting literal XHTML and HTML5 “translations”.

        • Matt Wiebe 4:22 pm on August 31, 2010 Permalink

          I’m all for switching the admin to HTML5, but we might want to leave it as a switch to ensure we’re spitting out validating script/style code for folks still on X/HTML. Losing type=”text/javscript”, type=”text/css” and CDATA sections in inline script elements will invalidate older doctypes.

    • Darfuria 2:05 am on August 31, 2010 Permalink

      Internal page links in the WYSIWYG. Huge amount of my clients ask for an easy way of linking to another page on their website without having to copy the URL, revisit and edit if that page’s URL changes, etc.

      • Alex M. 4:31 am on August 31, 2010 Permalink

        A shortcode would easily handle this.

        • Andrew Nacin 4:39 am on August 31, 2010 Permalink

          I like the idea of internal linking and I know Jane loves the idea… Perhaps a shortcode with a TinyMCE aspect to find recent posts (or suggest.js like tags) through AJAX, or something.

        • Alex M. 4:41 am on August 31, 2010 Permalink

          We could reuse the AJAX that helps you attach old unattached images to posts.

      • Devin Price 6:38 pm on August 31, 2010 Permalink

        How about a simple search interface after you click the link button? You could paste in a URL, or begin to type a title, category, tag etc and have it auto-complete.

    • Darfuria 2:07 am on August 31, 2010 Permalink

      custom-post-type.php template hierarchy support, instead of having to make a page template with a custom query to query posts of a certain post type.

      • Eric Curtis 9:51 pm on August 31, 2010 Permalink

        +1

    • sgaffney 2:13 am on August 31, 2010 Permalink

      per gsoc project on stream wrapper api:
      http://gsoc2010.wordpress.com/2010/08/12/api-stream-wrappers-week-12/

      Would love to at least see the ability to create folders in the media admin, and ecstatic to see full stream wrapper support within the UI, so I can finally have all my media in one place for my users.

      Overall the media manager needs some serious tlc.

    • mikeschinkel 2:25 am on August 31, 2010 Permalink

      In addition to some of the excellent suggestions about (term metadata, API for admin menus, query posts enhancements, custom post type “archives”, etc. ) here are some more:

      • register_post_field() – I’ll have working code to contribute for review within two weeks, if there is interest
      • Built-in support for parent/child relationships across custom post types (URLs, metaboxes, not clearing parents, etc.)
      • Metabox for adding child custom post records to a post.
      • API for adding first-class “supports” support to a post type.

      • John James Jacoby 6:20 am on August 31, 2010 Permalink

        +1 post relationships. I know mptt has been discussed in the past; not sure what ever came of it. Previous gsoc project if memory serves?

      • jeremyclarke 7:16 pm on September 2, 2010 Permalink

        +1 for register_post_field() if you mean a way to define post meta fields to show in a metabox without a plugin. The plugins for this are so popular that adding it to core is a no-brainer.

    • Jamie 3:27 am on August 31, 2010 Permalink

      Allow multiple post types to use same add_meta_box call
      http://core.trac.wordpress.org/ticket/13305

      +1 to JohnONolan comment about get_archive_template.

      More polish around the custom post types / meta boxes and UI methods to manage them.

    • Brian Richards 3:29 am on August 31, 2010 Permalink

      Is it possible to add an “exclude from gallery” option for attached images in posts?

    • bentrem 3:32 am on August 31, 2010 Permalink

      (I’ve been spidering things RPM all week; I think it’s addled my brain.)
      Is there some way to … a metric for a suggestion’s dependencies looking forward? Something almost like estimate of effort / resources / time.

    • Aaron Jorbin 4:04 am on August 31, 2010 Permalink

      Making the admin and default theme fully accessible for all users, following the w3 recommendations. http://www.w3.org/TR/WAI-WEBCONTENT/

    • Andrew Nacin 5:09 am on August 31, 2010 Permalink

      Something that can probably cut the number of support requests relating to updates by a good amount: More protection against fatal errors from plugins when updating core. #14096

      Related:

      Consider modifying file permissions through FTP then doing an update using direct, then switching the file permissions back, if doable. (Sometimes it might be ownership or other issues.)

      Consider partial core updates and/or md5 checksum for files to make sure every one was copied over correctly. Download everything, then md5 each file and only copy if the md5 doesn’t match, then md5 to confirm and try again until the md5 does match. Again that would significantly alleviate update problems.

      Finally, look for performance gains in the HTTP API.

      • Dion Hulse 7:33 am on August 31, 2010 Permalink

        > Consider modifying file permissions through FTP then doing an update using direct, then switching the file permissions back, if doable. (Sometimes it might be ownership or other issues.)

        Not possible when its a Username conflict affecting file IO. If its simply a Permission issue, then thats a viable method, But if PHP creates files as ‘apache’ and the user is ‘dd32′, Its a no-go for updates as it’ll be impossible to manipulate the files via FTP.

    • Alex 6:18 am on August 31, 2010 Permalink

      I don’t know if this is already possible, but being able to assign a template to a blog post.

      You can assign pages a custom template, but not blog posts (or at least, not from what I can see)…

    • Andrew Nacin 6:19 am on August 31, 2010 Permalink

      Menus v 1.5.

      – Meta box hierarchy. (Mentioned once or twice above.)
      – Auto-add entire page hierarchies, not just top-level pages.
      – Ability to say “use all children X levels deep” for hierarchical taxonomies and post types. (This would prevent manual management of any children for that single menu item.)
      – Drag-drop meta boxes to menus.
      – Show the states of non-published objects next to associated menu items. #13822

      • Mike Schinkel 6:55 am on August 31, 2010 Permalink

        Add to that: More Robust API that addresses many of the use-cases that were not addressed in v1.0 and thus that force those who need access to them to access menus and menu items as taxonomy terms, and custom post types, or worse, via SQL and global variables.

    • Adam Kochanowicz 7:36 am on August 31, 2010 Permalink

      I think a lot of people are like me in that they don’t want to go through the whole register, verify, login process for a million separate sites a day.

      I’d like to see WordPress 3.1 offer native support for Facebook’s Google’s and Twitter’s login APIs.

    • Ovidiu 8:05 am on August 31, 2010 Permalink

      How about an update check for plugins within the mu-plugins folder? I am sure that can’t be to difficult to do?

      • Andrew Nacin 4:31 pm on August 31, 2010 Permalink

        We don’t do any kind of detection for mu-plugins. We just blindly include the files without storing what they are, or requiring plugin headers even. mu-plugins is advanced server administration and should not be done if you expect those kinds of things. Instead of using mu-plugins if you need that functionality, use regular and network-wide plugins.

    • Fabian 9:19 am on August 31, 2010 Permalink

      sorry for my bad english,

      a blog network cross Mediathek for WP MU

      Eine Blog Netzwerk Übergreifende Mediathek bei MU verwendung

    • Sascha Basmer 9:20 am on August 31, 2010 Permalink

      One Mediathek for Multi-User-Sites

    • Bego Mario Garde 9:56 am on August 31, 2010 Permalink

      An easier way to include jQuery from Googleapis (probably with a fallback to the internal jQuery in wp-includes?) would be nice.

      • Alex M. 12:21 am on September 1, 2010 Permalink

        This is plugin material and already easily doable via many existing plugins.

    • julian19578 10:46 am on August 31, 2010 Permalink

      a better media management

    • Florian 11:18 am on August 31, 2010 Permalink

      Mulitlingual sites with multilingual urls would be great.

    • Lampe 11:30 am on August 31, 2010 Permalink

      Custom Menu Editor: Vertical Drop Down Menus

    • Tim Moore 11:54 am on August 31, 2010 Permalink

      A modification to the Media Library that would allow a user to replace a file. So instead of having to upload a new file and modify the entire range of posts/pages that link to it, just replace the file and reuse the file’s permalink.

      • Aaron D. Campbell 11:56 pm on August 31, 2010 Permalink

        +1 to this. It would be nice to be able to take a better photo and simply replace the bad one.

    • Frank 11:55 am on August 31, 2010 Permalink

      I wish a better mediamanagement, especially link from media to a post.
      Please create in the core an solution to adds exists medias to different posts, actual my plugin is an solution – but with JS and not in the core.
      I wish also better resources for RAM of webspace, actually is it an neglected resource – 256MB Ram on Autoupdate and minimal 35MB Ram?

    • Kau-Boy 12:01 pm on August 31, 2010 Permalink

      So useful CMS functions like next_page_link() similar to the existing next_post_link() function.

    • Lashon 12:06 pm on August 31, 2010 Permalink

      Hello,
      I’d like have a search button inside Themes installed.
      Also, a smush.it fonction to optimise uploads images automaticaly

    • Andrea_R 12:52 pm on August 31, 2010 Permalink

      make plugin management in a network a little easier, similar to themes enabling/disabling.

    • Matt Martz 1:16 pm on August 31, 2010 Permalink

      I’d like to see thickbox become deprecated, and something else used through out core

    • Heiko 2:01 pm on August 31, 2010 Permalink

      It will be necessary to support IDN domain names in all cases well. Some of the Javascripts have to be made aware of xn--… puny code based domain names, rss have to work, linking have to work etc.
      Because it’s world wide possible to register IDN’s WordPress should support it out of the box.

    • hakre 2:08 pm on August 31, 2010 Permalink

      From what I read here in mostly all replies, they are related a lot to the admin. I suggest you make the admin modular so that folks can offer new features easier. for example to have a basic admin and make it extensible with admin add-ons.

      And if I can suggest something on my own: Let’s do something we never did before: _no_ new feature, just fixing bugs, cleaning the code, fixing licensing and all those things that always tend to come a little short.

    • xwolf 2:19 pm on August 31, 2010 Permalink

      Add something for better domain mapping, like in “WordPress MU Domain Mapping”

    • blue 2:33 pm on August 31, 2010 Permalink

      I would like to see customizable Roles / Capabilities.

    • Mark Jaquith 3:27 pm on August 31, 2010 Permalink

      Eliminate one step from DB upgrades (show the “Done” step as an admin notice on the page they requested).

    • Mark Jaquith 3:28 pm on August 31, 2010 Permalink

      Do individual plugin upgrades without leaving the plugins screen.

    • Ryan Boren 3:44 pm on August 31, 2010 Permalink

    • JakiCrush 3:49 pm on August 31, 2010 Permalink

      i agree to many of the previous comments.
      i would vote for:
      1.) easy/easier internal linking functionality (with pages/posts editor)

      2.) international/multi-language posts/pages functionality

      3.) multiple/more enhanced dropdown menu design selection (left, right or top center aligned, and Vertical Drop Down Menus)

      4.) make the search results nicer/give more options (paging, sort-by-relevancy, how relevancy percentage, total number of results, show similar docs, show similar keyword, make search ajaxed: live results, live keywords)

      5.) Centralize the/all Plugins Configurations (some are currently below “Settings”, other below “Tools” again other create their own main menu)

      6.) native domain mapping would be nice as well

      Cheers,
      J.C.

    • Lisa Kirkman 4:48 pm on August 31, 2010 Permalink

      I would like to be able to actually disable comments on pages that aren’t blog pages – the little trail on the bottom of my content pages that says “Comments have been disabled” sort of defeats the purpose. I would also like a cleaner connection to set up Paypal and shopping cart – the WPCommerce plugin blows. Otherwise, WP 3.0 is great – I’m so stoked on it.

      • Mike Schinkel 6:34 pm on August 31, 2010 Permalink

        That’s really a theme issue, not a WordPress core. But yes I completely agree that it make zero sense to have “Comments have been disabled” on Pages (vs. Posts) and the fact is hasn’t been “fixed” in default themes continues to annoy me too because the default themes are what the world looks to as how themes should work… :)

        • Andrew Nacin 6:40 pm on August 31, 2010 Permalink

          I don’t believe this occurs in Twenty Ten. It’s not supposed to — it is a bug if it appears.

          At one time the theme development checklist was explicit in saying text should not appear on pages when comments are closed. I am not sure if it remains explicit on whichever new codex page it ended up.

      • Mike Schinkel 7:06 pm on August 31, 2010 Permalink

        @Nacin – You are correct. I should have check. Mea Culpa.

    • Bego Mario Garde 5:44 pm on August 31, 2010 Permalink

      Theme Twenty Ten is great, but for beginners way to confusing.

      To attract additional users, I would love to have a simple, yet well documented and fully functionable theme included. With such a theme newbies would get a better start for their own theme development and could learn easier how WordPress works. (Thinking of something as Starkers Theme but with some basic layout –not totally naked–to start with.)

      • Jane Wells 5:54 pm on August 31, 2010 Permalink

        No chance. A lot of time and energy was put into making 2010 the perfect starter theme and a basis for theme developers. There are simpler themes out there, but the point of the default theme is to show how to utilize the core features, and going back to something on the level of Kubrick would defeat that purpose.

      • Mike Schinkel 6:29 pm on August 31, 2010 Permalink

        I’m just curious, what about TwentyTen is way too confusing? Using it? Modifying it? Something else? If you elaborate maybe you’ll identify something that can be addressed or an alternate solution.

        • Bego Mario Garde 7:37 pm on August 31, 2010 Permalink

          Mike,

          to give you an example, let’s have a look at the embedding of wp_nav_menu. This tag even comes with some annotation:

          “Our navigation menu. If one isn’t filled out, wp_nav_menu falls back to wp_page_menu. The menu assiged to the primary position is the one used. If none is assigned, the menu with the lowest ID is used.”

          Wow, even with a little WP-knowledge, I had to chew on that for a while. I doubt that any beginner will instantly know, what all that stuff means. “primary position? id? what again is filled out?”

          How easy is, in comparison, Kubrick’s
          <?php wp_list_pages('title_li=’ . __(‘Pages’, ‘kubrick’) . ” ); ?>

          Don’t get me wrong: Twenty Ten is awesome and the developers did an excellent job. For the more experienced user, it is wonderful to see, which features WordPress offers. I’m just afraid, that new users get frustrated over a too complex default theme and switch to other content management systems. Anyway, I understand Jane’s reaction and hope, I didn’t bother anyone with my wish for an additional newbie-friendly default-theme.

        • Andrew Nacin 7:46 pm on August 31, 2010 Permalink

          It’d be nice to offer a better comment for the wp_nav_menu() call. Unfortunately the slight complexity in the API is the price to pay for having the customizable navigation menus system. Kubrick’s wp_list_pages() call similarly would become wp_nav_menu() if it were updated for 3.0.

        • Aaron Jorbin 8:36 pm on August 31, 2010 Permalink

          I for one would say that it is better to educate and improve entry level developers then dumb things down. I hope the comments in Twenty Ten do just that. If they aren’t, I think we should improve them and not take a step backwards.

      • Mike Schinkel 7:57 pm on August 31, 2010 Permalink

        @Bego: Personally I find the old way more confusing. My guess is that the old way is better known so it is just more comfortable to those who know it. Could the new way be improved? Yeah. But that’s the menu system, not the theme. JMTCW.

      • Alex M. 12:25 am on September 1, 2010 Permalink

        The solution to things being confusing is better documentation, not dumbing it down.

    • tux. 6:07 pm on August 31, 2010 Permalink

      I would like you to [b]stop integrating stuff into the core[/b]. Most things that were recently added – including a lot of “media library” additions – are useless for many users. More plug-ins, less bloat, please!

      • Mike Schinkel 6:30 pm on August 31, 2010 Permalink

        How does having more things in core actually hurt you?

      • Andrew Nacin 6:34 pm on August 31, 2010 Permalink

        The core developers are in agreement with your general thoughts. You may be interested in our Philosophy page.

        • Mike Schinkel 8:00 pm on August 31, 2010 Permalink

          “Design for the Majority” would tend to conflict with @tux’s comments and your response to his comments…

          Anyway, after reading this I think it’s time to bring up Core Plugins again…

        • tux. 8:49 pm on August 31, 2010 Permalink

          Vote +1 for Core Plugins, definitely! :)

      • Alex M. 12:27 am on September 1, 2010 Permalink

        We’re moving this direction, hence the Core Plugins. ;)

        Still, there will always be something in WordPress that not everyone uses. We go off the 90% rule (although that percentage can vary depending on the importance of the feature).

        Another good example is that we recently removed all importers from core.

    • tux. 6:48 pm on August 31, 2010 Permalink

      It hurts the server load, not myself. Regarding the “philosophy”: WordPress USED to be “clean, lean and mean”. That was before the core devs decided to make it an all-round CMS instead of a fast blog software.

      • Andrew Nacin 7:02 pm on August 31, 2010 Permalink

        I think users and developers pushed it in the direction of a CMS way before the core developers did. Performance and optimization is always on our mind.

      • Mike Schinkel 7:54 pm on August 31, 2010 Permalink

        It only hurts server load in a tangible way *if* code affects the execution path (I’m not considering the storage space for PHP files to be tangible.) So if it doesn’t affect the execution path, it really doesn’t count, does it? What that means is if something affects the main line execution path it should be held to a high standard. If it retard performances on the periphery it really doesn’t matter. Isn’t optimizing something affects almost nothing a fool’s errand?

        There is another issue and that’s conceptual overload for the user who doesn’t need it all. I think WordPress could really make some strides there by coming up with better ways to provide *progressive disclosure*; see: http://www.useit.com/alertbox/progressive-disclosure.html. Maybe a start would be a new menu item in the settings admin menu section that starts new installs with most features turned off and allows users to turn on the ones they need (Links, Pages, Plugins, Media, Users, Tools, etc. And there are a whole lot of other things where progressive disclosure could help, but I expect that would be an evolution and not a revolution, assuming the team embraces the idea.

        • tux. 8:50 pm on August 31, 2010 Permalink

          Evoluting the UI already would somewhat revolutionize it IMO.

    • Kim 8:25 pm on August 31, 2010 Permalink

      +1 for admin and default theme accessible for all users.

    • Franlk 9:28 pm on August 31, 2010 Permalink

      • Multilanguage support, please. There is no *reasonable designed* plugin out there for this.
      • Caching! System loads are horrible, If you don’t use Super Cache or sth. like that. Hosters therefore don’t love WordPress. If you run a PHP memory_limit below 64 MB and after having some plugins installed WP is going to die for sure :(

      • tux. 1:05 am on September 1, 2010 Permalink

        Which language is not available yet? About caching: Well, install one!

        • Alex M. 1:09 am on September 1, 2010 Permalink

          Franlk isn’t talking about displaying your blog in a different language, but instead writing posts in multiple languages, etc.

      • Alex M. 1:10 am on September 1, 2010 Permalink

        Franlk: I suggest you read this:

        http://www.viper007bond.com/2010/08/10/why-wordpress-doesnt-have-built-in-persistent-caching/

        There’s a very good reason behind the lack of persistent caching built into WordPress. If you get substantial amounts of traffic, you should use a persistent cache.

        As for memory, that’s an issue with the plugins you use. I rarely go over 20MB. ;)

    • Raj Sekharan 1:11 am on September 1, 2010 Permalink

      API could be modified so that plugin authors can define plugin dependencies and WordPress could offer to automatically install plugins as necessary.

    • Andyt 5:09 am on September 1, 2010 Permalink

      -) integrate basic statistics features simular to an older plugin: http://wordpress.org/extend/plugins/zdstats/ but not only for homepage. It should also give infos about RSS Feed User
      -) also add some info features in an extra menu or on Dashboard to see all main wordpress settings, memory settings, memory consumption, server & mysql status
      -) integrate a basic caching technologie
      -) Reduce memory consumption (if possible)

    • Sebastian Siebert 9:53 am on September 1, 2010 Permalink

      Hi,

      I think I speak for some user with this wish, they publish some short-lived but continous tutorials.

      If I write a new post, I can select easily the older post in the drop-down box as outdated. If I published the new post, so the older post was marked as outdated and the infobox will be enabled like following.

      An pretty infobox will be display in the post with an information to readers that the post is outdated and a link to the new post will display too. The text will be displayed like this: “Sorry, this post is outdated. It exists a new post here: ….”

      What do you think about this idea?

      • Jane Wells 6:40 pm on September 2, 2010 Permalink

        Why do separate posts? If you want to replace an outdated post, just edit it and republish. Having a redirect to newer posts is plugin material.

      • jeremyclarke 7:17 pm on September 2, 2010 Permalink

        Interesting idea but definitely plugin material.

    • Franlk 2:46 pm on September 1, 2010 Permalink

      @Alex – How do you do it to be that low with memory? After a fresh Install of WP 3.0.1 with NO plugins enabled but “WP-Memory-Usage” and NO posts but the preinstalled example ones I get in my admkin footer: “Memory : 32.48 of 64 MByte”. – Thanks for the link to the article about Caching.
      @tux Indeed: I meant writing post in serveral languages, and thanks to @Alex for making this more clear. Actual plugins are going to make you dependent on using them, so separating different languages by comment tags inside ONE post record means: you get completely cluttered posts after disabling or uninstalling the plugin or even if it stops working after a WP security update (this was my case some time ago). A lang column in the posts table of WP-core would probably be great for plugin developers, so they could implement queries very easily and simply adding posts in different langs as records. And if you decide to switch back to your one only language, and if you would be able to do this by simply setting a distinct wp-config variable to e. g. “en” – this would seem more attractive to me.

      • Alex M. 7:29 pm on September 1, 2010 Permalink

        I don’t know. All I know is that I accidentally had my limit set to 32MB and I never hit it or noticed except for a single page on my blog that I know uses a lot of memory due to some heavy calculations. I’m running like 40 plugins too.

        • Heiko 9:27 pm on September 1, 2010 Permalink

          Your should try to run your backend with a language file for each of your 40 plugins, let’s say “de_DE” and look at the memory usage now. As long as you run plain ‘en_US’ you won’t get the massive footprint of translations. Please also use the correct WordPress own *.mo files (3) with total more than 4000 strings.
          You may not longer be able to work smootly with all WordPress functions doing so!

    • Marko Heijnen 9:37 pm on September 1, 2010 Permalink

      I would love to see that http://core.trac.wordpress.org/ticket/9296 get fixed. I don’t understand why this isn’t fixed in the last 18 months since most of the functionality is already their.

      In my eyes also other old open tickets should be reviewed again. The oldest open ticket is 5 years old. That ticket should had been reviewed and closed. To have a clean cms it is important that tickets don’t be open that long, at least there should be a clear notice what is going on with that ticket.

      If i look at ticket #9296, I would expect that it should already been fixed since it is know for 18 months. If you look at the code within options-permalink.php you would expect that you can integrate custom settings to that page but you will find out that isn’t working.

    • arena 11:47 pm on September 1, 2010 Permalink

      Contact forms ?!

    • malloc 1:47 pm on September 2, 2010 Permalink

      Inserting a image via URL from an extern site shuld fetch the image and copy to mediathek. This prevents the post from broken image locations.

    • Monsoon 4:57 pm on September 2, 2010 Permalink

      The single issue I have with WP is the media upload folder puts all the uploads in a single folder. I have q0s of thousands of images from events…its a nightmare to manage that in WP with all uploads going into a single folder or month by month.

      Please please allow on upload to set the name of a folder to put images for the gallery and or create a folder based on the name of the post sot that if I upload pictures for an event names Dec 31st, in the images folder you can find:
      /images/2010/12/Dec 31st
      or if all images are in a single folder
      /images/Dec 31st

      Putting all images in a single folder is a nightmare especially with most themes making thumbnails as well you end up with a massive single folder.

      TLDR: Allow images uploads to go into an individual folder with name to be entered on upload or post title as the name

    • Franlk 5:03 pm on September 2, 2010 Permalink

      Aha, Heiko, so all the en_US (dev) people have no memory problems yet. Maybe they should give it a try using http://de.wordpress.org/wordpress-3.0.1-de_DE.zip :)

    • Marko Heijnen 5:40 pm on September 2, 2010 Permalink

      No idea what happened with my old post yesterday by my points are:

      • could this be fixed
      • major point of this is to fix of look at old tickets. Oldest open ticket is 5 years old.

    • Ryan Duff 6:44 pm on September 2, 2010 Permalink

      Password protected items in the media library similar to password protected posts. Since files have a hard URI, if somebody knows it they can access it despite it being linked from a password protected post. Allowing a password to be set on a media library item would allow better security for people that use WordPress in a corporate environment

  • Ryan Boren 3:29 pm on August 30, 2010 Permalink | Reply
    Tags:   

    Don’t use the conditional query tags (is_page, is_post(), is_*) prior to init. In 3.0 and earlier, this merely failed quietly. In 3.1 this will produce a fatal error. We’ll workaround the fatal error prior to the release of 3.1, but in the meantime we’ll leave it to serve as a flag for improper use of the query conditionals. If you see a fatal error of the form “Call to a member function is_*() on a non-object” then a plugin or theme is using that function prior to init. See ticket 14729.

     

    • mikeschinkel 5:26 pm on August 30, 2010 Permalink | Reply

      If they fail, wouldn’t it make sense for them to fail loudly? I guess there’s always WP_DEBUG but how many themers and even plugin devs know about it?

      • Ryan Hellyer 2:27 pm on August 31, 2010 Permalink | Reply

        Does WP_DEBUG pick up on stuff like that anyway? I assumed not – haven’ tested it though.

  • Ryan Boren 3:24 pm on August 30, 2010 Permalink | Reply
    Tags:   

    Per ticket 14672, WP_USE_MULTIPLE_DB will not be supported in 3.1 I don’t think many were using it, thankfully. Hyperdb is preferred if you want to do a multiple db setup.

     

  • Otto 9:32 pm on August 27, 2010 Permalink | Reply
    Tags: compatibility, ,   

    New for Extend/Plugins:

    If a user clicks the “Broken” link, it will record the click as usual, but now also redirect them to the start a new topic support form, and nicely ask them to leave a new topic explaining what’s broken. Hopefully, this will make the broken button more useful.

    Note: if you want to test this, feel free, but realize that you’re marking the plugin as broken by doing so, whether you leave a new topic or not. So please, go back afterwards and change your vote to “works” if it really does work.

     

    • Ipstenu 10:14 pm on August 27, 2010 Permalink | Reply

      Sweet!

    • Ofer Wald 11:40 pm on August 27, 2010 Permalink | Reply

      How about doing the same for the dreaded single star vote?

    • Denis 11:56 pm on August 27, 2010 Permalink | Reply

      Is there an RSS feed that plugin authors can use to grab all of these forum threads? If not, it would be even more useful… Especially if advertised.

      • Otto 12:33 am on August 28, 2010 Permalink | Reply

        Every forum thread made via this manner gets tagged with the plugin’s slug. So you can subscribe to a plugin’s topic list that way.

        Example: http://wordpress.org/tags/simple-facebook-connect has an RSS feed on it of http://wordpress.org/support/rss/tags/simple-facebook-connect .

        Email notification hopefully coming soon.

        • hakre 7:33 am on August 28, 2010 Permalink

          Feedburner offers Email Integration for RSS.

        • Denis 9:45 am on August 28, 2010 Permalink

          That’s not good enough. It’s fine when you’ve a plugin or two. But when you’ve dozens, it becomes a lot of feeds to track.

          Moreover, these tags point to multitudes of support requests that are related to WP bugs and incompatibilities introduced by third party plugins — stuff that I don’t even want to be reading.

          What’s needed are two unified feeds. The first should lead plugin devs to all open threads related to his plugins, regardless of tags. The second should lead plugin devs to the subset of these threads that were opened by the broken button.

          Using tags for any of these two feeds is not an option unless the community spirit and attitude have improved dramatically. When I was answering support requests in the WP forums, the tag I was using got dropped in a hostile effort to move it out of the hot tags page.

        • Otto 6:22 pm on August 28, 2010 Permalink

          Better ways of notification are coming as well. Email notification is next on my list, followed by handling tags better.

          One step at a time, man.

        • Denis 6:42 pm on August 28, 2010 Permalink

          Personally, I don’t read emails any more than Knuth:

          http://www-cs-faculty.stanford.edu/~knuth/email.html

          I do subscribe to RSS feeds, however. So if anything, that works better. :-|

        • Otto 10:12 pm on August 28, 2010 Permalink

          It’s a combo deal. Emails come first, because though I use RSS and agree with you, the majority want the emails. Emailing an existing feed is simpler than emailing a non-existent one.

        • Matt 4:21 am on August 29, 2010 Permalink

          Denis, I’m sorry it’s not good enough. it’s better than before. And it’s being worked on.

    • Chip Bennett 3:19 am on August 28, 2010 Permalink | Reply

      Next step: change the vote not to record until a new forum topic is posted. :)

      (Either way, very cool stuff, Otto!)

      • Rich Pedley 7:20 am on August 28, 2010 Permalink | Reply

        oh yes that would be nice. Then add automatic changing of vote to works once thread is marked resolved… Oh sorry I think I just saw a cuckoo in the clouds.

    • hakre 7:34 am on August 28, 2010 Permalink | Reply

      Yeah, nice! I’ll play a bit with it and let you know :)

    • Denis 9:52 am on August 28, 2010 Permalink | Reply

      Adding to my last comment… Isn’t there a risk that end users report plugins as broken when they run into a WP bug or some incompatibilities introduced by their theme or other plugins?

      • Pross 1:19 pm on August 28, 2010 Permalink | Reply

        Maybe the author should verify its broken?

      • Devin Reams 2:06 pm on August 28, 2010 Permalink | Reply

        Are you really suggesting that doesn’t already happen?

      • Otto 6:20 pm on August 28, 2010 Permalink | Reply

        They were doing that already. Now they have a chance to report the problem.

        Ignoring their vote because they refuse to explain it would be rather unfair. The number of people who think it doesn’t work is valid data, regardless of why they think that. This isn’t ebay, where one negative means nobody trusts it.

        • Denis 6:35 pm on August 28, 2010 Permalink

          I believe you’re misunderstanding the question. On occasion, users report things as broken when it really isn’t. For instance:

          http://wordpress.org/extend/plugins/sem-admin-menu/

          One reports CSS is loaded, always. Which is an enhancement at best…

          The next is an incompatibility with another plugin…

        • Otto 3:33 am on August 29, 2010 Permalink

          No, I understand just fine. However, if they’re reporting it broken, then that’s between you and them. What, we’re supposed to make somebody jump through hoops or make it harder or something?

    • scribu 5:05 pm on August 28, 2010 Permalink | Reply

      some info from the readme is missing: http://core.trac.wordpress.org/ticket/14719

      • Otto 5:42 pm on August 28, 2010 Permalink | Reply

        Not a bug, Matt told me to remove them.

        • Ipstenu 2:54 am on August 29, 2010 Permalink

          Otto, would that be why some authors don’t show up on their plugins? I don’t seem to be listed as an author on any of my plugins, and that …. Well, makes it hard for people to know how to get in touch with me for support :)

        • Otto 7:52 pm on September 2, 2010 Permalink

          Ipstenu: No, this was because your plugin didn’t have your correct wp.org username in the Contributors: line in the readme.txt. Caps count there too.

          I’ve just modified this to show those author listings correctly. Although, if it can’t find you as a valid user, you get no gravatar and no link (because there’s nothing in profiles to link to). This will at least prevent the link weirdness we once had on the authors listing.

        • Stephen Cronin 12:48 am on September 6, 2010 Permalink

          As a plugin author, the more links to my site the better! :)

          But that’s not important. What’s important is this:

          As a user, I’ve found that *most* plugins have extra information, comments, etc on the plugin home page on the authors site. The removed link to the plugin home page is something I clicked a lot.

          I take Matt’s argument that this link can be added to the content area, but a) the vast majority of plugins aren’t going to have this and b) those that does will have it in a slightly different location.

          End result, instead of having a *consistent place* on *all* plugin pages where I can easily find this link, I have to search for it and in many cases it won’t even be there. There’s a term for that sort of thing:

          Usability fail

          The link to the author’s site is less important, but the link to the plugin’s homepage (on the author’s site) should remain (in my opinion) – because that makes the site more usable for the users.

      • scribu 5:51 pm on August 28, 2010 Permalink | Reply

        An explanation would be nice. Spamming can’t be a valid reason, since you can insert links directly into the description.

        • Otto 5:57 pm on August 28, 2010 Permalink

          Dunno. You’ll have to ask him. Anyway, I don’t think the design there is final yet, so they may make a comeback. We’ve basically just been playing with it, to see what looks and works better. Eventually I hope to have some useful stats for authors as well, for example.

          Bringing any of this up on trac is probably premature. Email me directly if you have concerns, I read them all and respond to most. otto at ottodestruct.com

        • Denis 6:44 pm on August 28, 2010 Permalink

          I fail to see any incentive to write a free plugin if you don’t even get some web traffic as a result.

        • Alex M. 8:42 pm on August 28, 2010 Permalink

          If that’s the only reason you’re writing plugins, then I feel sorry for you Denis. :)

        • Otto 10:18 pm on August 28, 2010 Permalink

          I gotta say that I think those links drive very little traffic. Matt said at #wcsav that I remember (because we used my plugin to do it), that something like 20% of his ma.tt traffic now comes from his facebook links (which are auto-published by SFC). There’s better ways to drive traffic back to you. Developing is generally done to fill a need, not to drive traffic.

        • scribu 11:57 pm on August 28, 2010 Permalink

          As a counter-example, about 20% of my referrall trafic (10% overall) come from wp.org

        • Otto 3:34 am on August 29, 2010 Permalink

          If it’s that big a deal, put your links in the description of the plugin. You can put links there, you know.

        • Matt 4:25 am on August 29, 2010 Permalink

          Plugin links are a little redundant now that each plugin has a page on the directory. If someone has a page on their own site as well easy (and more effective) to link from the main content area.

          Author links only work for single-author plugins, for multiple author plugins (which we want to encourage) it’s broken so better to build it off the commit list, so each author gets credit.

        • Alphawolf 3:00 pm on August 29, 2010 Permalink

          Well, if it remains like this, we have a useless profile field “Website URL ” then:

          (which funnily enough sais “Give yourself some link love.” :-) )

          It’s useless if the website URI neither shows up on the profile pages nor on the plugin pages anymore.

          On a side note, the wp.org repository would be the only plugin repository I know that doesn’t link back to the dev’s website at least. Personally I found some really nice blogs worth subscribing through the plugin pages (such as Viper’s, Ozh’ etc.).

        • Matt 3:11 pm on August 29, 2010 Permalink

          Our goal is to drive even more back to plugin authors than we do now, but give some time for the iterations to finish up.

        • scribu 5:24 pm on August 29, 2010 Permalink

          Thanks for the explanation Matt. Makes sense now.

          Michael H. asks to move the author info back to the top:

          http://core.trac.wordpress.org/ticket/14725

        • Matt 10:14 pm on August 29, 2010 Permalink

          That’s nice, but not really useful at this stage. If you have something you really want on that page maybe just send me an email.

      • scribu 5:27 pm on August 29, 2010 Permalink | Reply

        Speaking of developer site links, I think we can all agree that it makes sense to show them on profiles.wordpress.org (they were there, but vanished at some point)

        • Matt 10:14 pm on August 29, 2010 Permalink

          Definitely — not sure what’s up with those pages. The URLs are wrong too.

      • filosofo 8:33 pm on August 29, 2010 Permalink | Reply

        With profiles.wordpress.org being pushed into greater prominence, can we either fix or remove the activity stream? For example, it shows my last core trac activity as having occurred in March.

        I will volunteer to make the fix.

        • Rich Pedley 7:44 am on August 30, 2010 Permalink

          Have to agree with this, it’s been like that for months.

    • John James Jacoby 6:07 pm on August 29, 2010 Permalink | Reply

      Nice work Otto! Like the changes so far and know it will only improve as you iterate.

      • Otto 9:12 pm on August 29, 2010 Permalink | Reply

        Thanks! I think a lot of people aren’t getting the “iteration” concept here. :)

        • Alphawolf 1:27 pm on August 30, 2010 Permalink

          I’m sure you are aware already, but just for the sake of completeness, the short description above the tabbed navigation doesn’t convert Markdown currently. But that’s just a minor minor issue that came to my eyes. :)

        • Otto 3:28 pm on August 30, 2010 Permalink

          The short description should be text only. Markdown is not allowed there.

        • Alphawolf 3:40 pm on August 30, 2010 Permalink

          Sorry, my fault then. ;-)

  • mdawaffe 1:06 am on August 27, 2010 Permalink | Reply
    Tags:   

    I upgraded the WP.org Plugins Directory to bbPress trunk/ today. I’m sure there’s still glitches to work out. In particular, search may be a little out of date until I get the new sphinx index set up correctly.

     

  • Andrew Nacin 8:56 pm on August 26, 2010 Permalink | Reply
    Tags: , ,   

    What do core contributors need to know? 

    I’ll be working on an outline for the core contributor handbook in the coming weeks, so I figured I would start a brainstorming session here. Some potential questions to ask yourself:

    • What do core contributors need to know?
    • What would have been great to know when you first started getting involved?
    • What resources (such as pages on the Codex) have you found useful?
    • What do people (including/especially non-contributors) need to know about the development process/cycle/philosophies?
     

    • Ozh 9:05 pm on August 26, 2010 Permalink | Reply

      Adam’s http://adambrown.info/p/wp_hooks/ is pretty hot

      Emphasis could be made on the Codex, too. I started coding plugins before there was a Codex, which then was pretty empty at its beginning so I never really used it. It’s just recently that I’ve discovered it again, and found it very very useful.

      • Andrew Nacin 9:37 pm on August 26, 2010 Permalink | Reply

        This comment is arguably better for http://wpdevel.wordpress.com/2010/08/26/api-status-check/. I’ve actually reached out to Adam with regards to his hooks DB, as we hope to integrate a hooks reference as part of the API reference.

      • Brian Layman 9:52 pm on August 26, 2010 Permalink | Reply

        Unfortunately Adam’s site is causing loads of extra work now as it is still big in Google but his automated code has identified many actions and filters as removed due to fine tweaking. I see people asking about it on wp-hackers and you and I chatted about it one of the reports on it Andrew.

        • Andrew Nacin 9:53 pm on August 26, 2010 Permalink

          Indeed, which is partly why it would be helpful to have a similar automated reference that is official and more complete. (And can be properly vetted by core folks.)

    • John James Jacoby 9:07 pm on August 26, 2010 Permalink | Reply

      How to use trac the WordPress way (keywords, tags, etc…)
      What is SVN? What do checkout/update/commit really mean and who can do that and why?
      How create a diff/patch, and how to attach a diff/patch to a trac ticket.
      General blog/chat/trac etiquette and community expectations.
      WordPress coding standards is a helpful codex page.

      There are probably more, but these are my few to start.

    • zippykid 9:09 pm on August 26, 2010 Permalink | Reply

      1. just a quick reminder on how to search the archives :) .
      2. history of some decisions (see #1)
      3. coding standards
      4. contributing etiquette
      5. Triage process

      • Jacob Santos 9:59 pm on August 26, 2010 Permalink | Reply

        I think #2 is a good idea. There are a few areas that are/were asked repeatedly on the wp-hackers mailing list that would be good to just link to. It wouldn’t mean it is set in stone, but it would provide some reasoning for people on where to leave off when continuing discussions.

    • Kenny Younger 9:22 pm on August 26, 2010 Permalink | Reply

      I always knew the trac mailing list was available, but it wasn’t until recently that I started subscribing to it that I started to really appreciate the workflow in trac – mainly because it’s now literally at my fingertips (email on my phone).

      I just have gmail filter it off into its own label, so it doesn’t clutter my inbox (I actually do this for all the lists). One of the huge benefits is that I can drop into that label and then very quickly see what tickets are getting heavy commenting/changes. Plus I can star items that I feel I want to pay attention to more so than others.

      Another added benefit: quick searching from my phone for a particular ticket’s history.

      • Andrew Nacin 9:39 pm on August 26, 2010 Permalink | Reply

        My current workflow is very similar to this, though long ago I spun that label off into its own inbox. Even when I’m at my computer, I often use Gmail search to find tickets.

        Talking about different ways to absorb the firehoses of information, if you are so inclined, is a good idea.

    • Jacob Santos 9:31 pm on August 26, 2010 Permalink | Reply

      Requirements for patches. Adding / Modifying inline documentation and changing existing documentation when changing requirements. Writing Unit Tests. Expectations of the time for patches to get committed. What to do when there isn’t any feedback? What to do when patches don’t meet expectations.

      What it means when someone from Automattic doesn’t like your patch and therefore doesn’t gain traction. Who’s who at Automattic and WordPress core community that might need to be looked for and debated for certain patches to get in.

      • Andrew Nacin 9:36 pm on August 26, 2010 Permalink | Reply

        s/Automattic/WordPress core team/. That said, a who’s who is important, especially given the number of committers, contributors, and those who triage.

        • Jacob Santos 9:52 pm on August 26, 2010 Permalink

          No, I mean Automattic. They have just as much power, most of the time, as core commit team with what goes into WordPress. There are people at Automattic who have certain areas of expertise and core commit team has historically relied on their opinion over that of the core contributor community members.

          It is helpful to know who these people are without having to go to automattic.com web site and checking. Partly because the name(s) on the web site do not always translate to Trac.

        • Jacob Santos 10:01 pm on August 26, 2010 Permalink

          Yes, the first Automattic should have read WordPress core team. The second should have read Automattic and WordPress core team and WordPress core community.

        • Andrew Nacin 10:02 pm on August 26, 2010 Permalink

          That works for me.

      • Andrew Nacin 9:39 pm on August 26, 2010 Permalink | Reply

        Also, I really like your thoughts on patch requirements, expectations. Thanks!

    • JohnONolan 9:35 pm on August 26, 2010 Permalink | Reply

      Probably need a mini section for designers / front end developers. We can title the section “for dummies” – as Nacin will attest to by the number of questions that I asked him in the early days :)

    • Andrew Nacin 9:35 pm on August 26, 2010 Permalink | Reply

      Random quick hits:

      – Our release philosophies. http://codex.wordpress.org/Release_Philosophy
      – Our coding standards. http://codex.wordpress.org/WordPress_Coding_Standards
      – What makes a good bug report. http://codex.wordpress.org/Reporting_Bugs
      – Our Trac workflow, and how to mainline Trac. http://codex.wordpress.org/Reporting_Bugs#Trac_Keywords
      – How code makes it into WordPress. http://codex.wordpress.org/How_does_code_make_it_into_WordPress
      – Reporting security issues. http://codex.wordpress.org/FAQ_Security
      – Getting started with Subversion and creating/applying patches. (Peter’s and Mark’s tutorials are great.)
      – Inline documentation.

      • Jacob Santos 9:53 pm on August 26, 2010 Permalink | Reply

        Inline documentation is found at http://codex.wordpress.org/Inline_Documentation

      • Matt 10:34 pm on August 26, 2010 Permalink | Reply

        • Andrew Nacin 2:09 am on August 27, 2010 Permalink

          Thanks! Liking that new page a lot.

        • scribu 9:40 pm on August 27, 2010 Permalink

          Nice, but the page title reads WordPress > About > Requirements

        • filosofo 5:07 pm on August 30, 2010 Permalink

          From the Philosophy page:

          There’s a good rule of thumb within internet culture called the 1% rule. It states that “the number of people who create content on the internet represents approximately 1% (or less) of the people actually viewing that content”.

          So while we consider it really important to listen and respond to those who post feedback and voice their opinions on forums, they only represent a tiny fraction of our end users. When making decisions on how to move forward with future versions of WordPress, we look to engage more of those users who are not so vocal online. We do this by meeting and talking to users at WordCamps across the globe, [sic] this gives us a better balance of understanding and ultimately allows us to make better decisions for everyone moving forward.

          (emphasis added)

          Mathematically speaking, it’s unlikely that “we” has spent enough time chatting at WordCamps to engage more than 1% of WordPress users. The counter says 13 million downloads of 3.0 so far. Assuming one user per download, talking to 1% of them for just one minute each would take by itself a full-time job for over a year, with no time to process or organize the results. It would also mean that all the past WordCamps would have had on average a couple thousand unique attendees each.

          More importantly from a statistical perspective, those with the means, the time, and the interest to attend a WordCamp are not likely to compose a representative sample of WP users in general. Nor are they are going to speak many of the hard truths in a WC reception line.

          I’m not just being pedantic; something as fundamental as a guiding philosophy should be accurate and honest. There’s nothing wrong with saying that, when it comes to resolving contentious disputes or setting big-picture goals, the ultimate arbiter is Matt Mullenweg’s judgment, which has served him well so far in numbers of WP users and the financial success of Automattic. Mullenweg keeps his finger on the pulse of WordPress users by meeting with hundreds of them at WordCamps across the world, reading thousands of blog posts, etc.

          Spelling this out would have the additional benefit of avoiding needless frustration for some contributors in controversies like capital_P_dangit, as you could just point them to the philosophy document.

      • bentrem 5:45 pm on August 27, 2010 Permalink | Reply

        • Matt 6:48 pm on August 27, 2010 Permalink

          Nice link — it’s a good idea to look at how other projects do this.

        • Aaron Jorbin 2:38 am on August 28, 2010 Permalink

          Along the same lines, this guide for the linux kernel is pretty good: http://ldn.linuxfoundation.org/how-participate-linux-community

        • bentrem 5:03 am on August 28, 2010 Permalink

          One more level of indentation of comments, pls! *G*G
          @aaron – nice come back
          @Matt – MozF is known to be … inward facing? (I call it Byzantine.) With lessons learned from that grande project along with others such as LDN, FOSS at large, &tc … WP benefits and Automattic adds to its GTD rep? :-)

    • JohnONolan 9:40 pm on August 26, 2010 Permalink | Reply

      Further thoughts and questions that took me a long time to learn:

      Who are the core team?
      Who answers to who? What is the hierarchy of power?

      (oh I see that Nacin just added this above)

      What is ETIQUETTE on Trac? I was petrified for months of Trac, not being able to edit stuff is frightening. As is changing the status/priority/anything of a ticket without knowing whether or not it’s the right thing to do.

      How do you apply a patch (in detail, inc info about how to dowload it FROM trac) for testing?

      A template for bug reporting which people can use to create better, more substantial tickets.

    • Mr Mist 9:51 pm on August 26, 2010 Permalink | Reply

      A really simple guide on how to create a workable patch in various O/S.
      When to re-open a ticket / when not to re-open.
      What to put in the tags fields

    • Andrew Nacin 9:52 pm on August 26, 2010 Permalink | Reply

      From Ryan: The two most important attributes of a core contributor are brevity and thick skin.

      I’d argue that the brevity can be applied widely: to patches, comments, personal agendas.

      • John James Jacoby 10:08 pm on August 26, 2010 Permalink | Reply

        Agree with this completely. No one wants to read through a 4 paragraph explanation of a bug. And no one is out to hurt anyone else’s feelings; and if your feelings are hurt, you’re doing it wrong.

    • bentrem 9:53 pm on August 26, 2010 Permalink | Reply

      25c reads like this: a) as I cited in IRC, ” Boeing’s old “Sequential Thematic Order of Presentation” (STOP)” … time tested and industry-strenght. Else you get caught up in subjective aspects. Gotta have a matrix or tree to hang things from. –ben

    • Brian Layman 9:56 pm on August 26, 2010 Permalink | Reply

      A default assumption that others know at least as much as you, if not more. This helps you ask why something was coded a particularly way rather than going in with a “this code is bullocks” attitude.

      • Jacob Santos 10:03 pm on August 26, 2010 Permalink | Reply

        This a good suggestion but hard to do. Sometimes the personality of people (like mine) is to assume everyone doesn’t know what they are doing until they prove otherwise. However, it is very quick to learn who knows what they are talking about verses those who relatively don’t.

    • Andrea_R 10:26 pm on August 26, 2010 Permalink | Reply

      Just a few broader ones for those new to the process:

      • what do I need to keep tabs on?
      • should I hang out in IRC? When? If I’m contributing on a regular basis, is there an expectation that I should show up for dev chats?
      • after reading all the above resources, who do I turn to if I have a question that needs clarifying?
      • do I need to join particular mailing lists?
      • if I file a ticket, is it expected that I need to also produce a patch? Will it help if I do?

      • Jacob Santos 10:30 pm on August 26, 2010 Permalink | Reply

        I think dev chats has always to me been a point of contention. Decisions are made there and I suppose they are tentative, but the problems has been that work places usually do not allow for IRC chats that aren’t work related. Generally also, one can not bring up dev chat related topics after the dev chat is finish barring both those who work at jobs restricting access to the IRC chat and those who sleep during the time periods of the chat.

    • Ron 10:32 pm on August 26, 2010 Permalink | Reply

      I jumped into the deep end of the pool in January. A brief guide to trac (which others have mentioned) would be indespensible, imo.

      Second, for people who are interesting in being actively involved on an ongoing basis, I would strongly recommend that they follow activity in trac and review all the IRC logs for at least a month. The huge benefit to the contributor is that they will become familiar with the “regulars” and how they work together.

    • Ryan McCue 12:47 am on August 27, 2010 Permalink | Reply

      One essential piece of knowledge is knowing how to get your patches actually committed. I’ve found that the trick is to bug committers until they get sick of you doing so and finally commit it. ;)

      (Seriously though, at least mentioning your patch in #wordpress-dev helps to get it committed)

      • Andrew Nacin 2:12 am on August 27, 2010 Permalink | Reply

        Justification is also important. I like this from our Release Philosophy page on the Codex: “If you’re too lazy to do the homework and think through the big-picture rationale, I’m too lazy to add the feature. On the other hand, patches that come with well-thought-through rationale are often applied right away.”

    • Andrew Nacin 2:32 am on August 27, 2010 Permalink | Reply

      Another good thing that takes a while to figure out, is navigating specific aspects and functionality of the codebase, and how that goes into creating patches. A few examples that come to mind:

      – CSS and JS. Don’t minimize. It keeps the patches small, it prevents patches from going stale over an otherwise unrelated change in the file, and it allows the committer to confirm that the file was indeed properly minimized.
      – Images. Attach them to the ticket, preferably the originals too so we have a record of them. (Good for UI group.)
      – Script/db_version bumps. No need to include the bumps in the patch; we can handle them that way we know we got everything.
      – DB upgrades. How it all works is definitely confusing as first. Same with update-core.php.
      – Deprecated functions. Where they go, how we do it, etc. Maintaining full functionality is vital.
      – Also knowing how to test certain aspects of the code, using WP_DEBUG, etc.

    • dougwrites 5:59 pm on June 4, 2011 Permalink | Reply

      Still taking suggestions? Thank you for doing this!

      General: having patience with the cycle, but also understanding deadlines and when to jump before those points when no longer can get something in.

      Docs: especially contextual help but also inline. Different from other patches?? Best way to package patches (individual files, omnibus sets, also attach text files of what text would look like with changes?). Knowing that writing is rewriting and re-rewriting. Balancing brevity with hitting enough key points.

  • Andrew Nacin 8:49 pm on August 26, 2010 Permalink | Reply
    Tags: ,   

    /extend is currently being upgraded. Currently @mdawaffe is working on the plugins directory. Please excuse any ceiling tiles if you’re hit with one.

     

    • Alex M. 10:29 pm on August 26, 2010 Permalink | Reply

      You weren’t kidding about those ceiling tiles. :(

      http://wordpress.org/extend/plugins/syntaxhighlighter/ = 404

    • Sergey Biryukov 10:50 pm on August 26, 2010 Permalink | Reply

      Plugin descriptions are messed up at the moment. Some are totally gone and some are duplicated and displayed for the wrong item. I hope this can be fixed soon.

    • Alex M. 11:09 pm on August 26, 2010 Permalink | Reply

      Things should be fixed now.

      • Sergey Biryukov 11:55 pm on August 26, 2010 Permalink | Reply

        I’ve updated the changelog section for one of my plugins about an hour and a half ago, however the changes are still not reflected. It used to take up to 15 minutes for them to appear before. Other than that everything seems to be OK.

        • Sergey Biryukov 2:43 pm on August 27, 2010 Permalink

          I’ve updated readme.txt once again and this time the changes were reflected right away.

        • Otto 5:43 pm on August 27, 2010 Permalink

          Things will be wacky while we’re making changes. Expect delays.

← 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