WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: 3.1 Toggle Comment Threads | Keyboard Shortcuts

  • Ryan Boren 3:47 pm on October 14, 2010 Permalink
    Tags: 3.1   

    Feature status:

     
    • Jane Wells 4:03 pm on October 14, 2010 Permalink | Log in to Reply

      Based on John’s update from this week’s UI chat, the CSS cleanup is going to span two releases, as it was a bigger job than anticipated. He’s been working with nacin to make sure nothing will be messed up by what he’s doing.

    • Banago 4:47 pm on October 14, 2010 Permalink | Log in to Reply

      Lot’s of goodies to look forward to :)

    • filosofo 6:02 pm on October 14, 2010 Permalink | Log in to Reply

      I probably won’t be able to make the chat today, but I want to confirm that I’m working on the admin bar changes and will have a patch up this weekend.

    • voidmind 12:31 pm on October 15, 2010 Permalink | Log in to Reply

      It was not clear where I should send feedback about the site so I’m posting here. The Showcase part of the site doesn’t display images in FF 3.6.10 (Win7) because of an SSL certificate error.
      http://wordpress.org/showcase/

    • Tapeleg 2:58 pm on October 16, 2010 Permalink | Log in to Reply

      I may have missed it, but is there a fix for changing a site to multisite using subdirectories if the site has been in existence for more than a month? As descried here:

      http://codex.wordpress.org/Create_A_Network

    • Arlen Beiler 11:50 am on October 19, 2010 Permalink | Log in to Reply

      Sounds exciting! Especially looking forward to the Admin Bar and Ajaxified Admin.

  • Jen Mylo 9:23 pm on August 30, 2010 Permalink
    Tags: 3.1,   

    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! ;)

    • 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

  • Matt Mullenweg 4:53 pm on August 16, 2010 Permalink
    Tags: 3.1   

    When is comment moderation going to be not-broken? :)

     
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