Updates from November, 2010 Toggle Comment Threads | Keyboard Shortcuts

  • Jane Wells 11:35 am on November 22, 2010 Permalink | Reply
    Tags: , ,   

    Unexpectedly, Google’s Melange site (the app used to maange GSoC and Code-in) has removed all the mentor information from GSoC. Can anyone willing to mentor on a code-in task or two please give me their google ID in the comments? Also, I’ve been hitting repeated server errors trying to get tasks into the system, so it’s taking forever. Hope to have a first round of tasks available for students today (contest opened a couple of hours ago), but in meantime, we can hang out in #wordpress-gsoc to just kids direction if they are ready to start sooner.

     
  • Mark Jaquith 5:04 pm on November 20, 2010 Permalink | Reply
    Tags:   

    WordPress 3.1 uses jQuery 1.4.4, and jQuery UI 1.8.6. You should check your plugins to see if anything broke. If you were enqueueing jquery-ui-core and using the “widget factory,” or something that depends on the widget factory you will have to update your plugin to enqueue jquery-ui-widget instead. In jQuery UI 1.8.x, the widget factory was separated from jQuery UI core. Please examine wp-includes/script-loader.php to see the entire dependency tree.

     
  • Joseph Scott 3:50 pm on November 19, 2010 Permalink | Reply
    Tags:   

    The new post format details are now exposed via the XML-RPC API:

    ticket – http://core.trac.wordpress.org/ticket/15405
    commit – http://core.trac.wordpress.org/changeset/16484

    In short, there is a new method – wp.getPostFormats – that provides you with an array of the post format values and a new wp_post_format field supported in the metaWeblog.getPost, metaWeblog.editPost, and metaWeblog.newPost methods.

     
    • Mark Jaquith 4:40 am on December 2, 2010 Permalink | Reply

      Just a note: the default is now called “standard,” not “default.”

  • Andrew Nacin 6:28 am on November 17, 2010 Permalink | Reply
    Tags:   

    Agenda for Wednesday’s dev meeting:

    • Final preparations for beta.

    Reminder of the new time: 1600 GMT, or 11 AM Eastern.

     
  • Andrew Nacin 6:27 am on November 17, 2010 Permalink | Reply
    Tags:   

    Changes to meta capability handling in 3.1 

    If you were doing something crazy with custom or meta capabilities and custom post types in 3.0, you’ll probably want to read #14122.

    Custom post types had inconsistent meta capability handling in 3.0. current_user_can( ‘edit_post’, $id ) and current_user_can( $post_type->cap->edit_post, $id ) mapped to different capabilities when capability_type = post. We never called the former in core, however, so this would have only affected plugins in a very particular situation.

    Now, we have the map_meta_cap flag for CPTs, which allows this to be throttled properly. map_meta_cap is also true by default if capability_type = post or page, and no custom capabilities were defined.

    Making this post out of due diligence, but I don’t think this should break any plugins, except in the “This was never supposed to work” situation (which I do want to know about).

     
  • Andrew Nacin 10:27 am on November 13, 2010 Permalink | Reply
    Tags:   

    I’ve emptied and deleted the Awaiting Triage milestone. This milestone had held 3.1 tickets before we decided to empty that bucket out and start again.

    We still have nearly 500 tickets in Awaiting Review. We should try to whittle those down before beta hits and that gets flooded.

     
    • Jacob Santos 7:51 pm on November 16, 2010 Permalink | Reply

      So did you move those tickets or are those ticket gone?

  • Andrew Nacin 10:27 am on November 12, 2010 Permalink | Reply  

    Reverted in 3.1. We’re trying again in 3.2.

    If you were using $wpdb->last_result, you will need to change it to $wpdb->get_results() without a $query argument, which does the same thing. Inside wpdb, we’re now passing resources around, so the last_result property (which was private and should not have been used) no longer exists.

    On PHP5, we’re using a magic getter to return wpdb->get_results() for you, but it’ll throw a deprecated warning. On PHP4, your code will cease to work.

    Further reading: #12257.

     
    • scribu 2:51 pm on November 12, 2010 Permalink | Reply

      I’m always amased of how much old code (that I thought was solid) can be improved.

    • Brian Layman 3:36 pm on November 12, 2010 Permalink | Reply

      Thank you for the heads-up Nacin. I’m pretty sure I used last_result in something, but I think it was a one off – blog conversion tool. In any case, advanced knowledge about this kind of thing is VERY helpful.
      Appreciated!

    • Joe Hoyle 4:45 pm on November 12, 2010 Permalink | Reply

      Does WordPress not use an underscore or something similar to mark private methods / properties? I only ask because how were users meant to know $wpdb->last_result was private?

      • Peter Westwood 4:47 pm on November 12, 2010 Permalink | Reply

        For methods they will quite often have an underscore on the front if they are private yes. We also make things as @access private in the phpdoc.

        This was an attribute and not a method but it was marked as private:

        	/**
        	 * Results of the last query made
        	 *
        	 * @since 1.0.0
        	 * @access private
        	 * @var array|null
        	 */
        	var $last_result;
        
    • Peter Westwood 10:50 pm on November 12, 2010 Permalink | Reply

      Reverted for now in r16336 doesn’t seem to agree with HyperDB :-(

    • Brian Layman 3:58 pm on November 13, 2010 Permalink | Reply

      So.. when a ticket like this comes through, how is it brought into backpress and then I suppose onto bbpress? I see that db-mysqli uses last_result at least in the old version of bbpress I have checked out.
      I was wondering if it would help if I created a ticket in these projects or if it should just be left to happen when all the changes are reconciled after the WP 3.1 release.

      • Peter Westwood 6:55 pm on November 14, 2010 Permalink | Reply

        In general it makes it to BackPress once it is stable enough and someone has the time ;-)
        Tickets and Patches are much appreciated – releases the burden on waiting for me to find the time

    • hakre 11:59 pm on November 14, 2010 Permalink | Reply

      is that get_results() or get_last_results()?

  • Andrew Nacin 6:30 pm on November 11, 2010 Permalink | Reply
    Tags:   

    List of post formats 

    The current list of post formats is on the Codex page: http://codex.wordpress.org/Post_Formats

    • aside – Typically styled without a title. Similar to a Facebook status update.
    • chat – A chat transcript.
    • gallery – A gallery of images.
    • link – A link to another site.
    • image – A single image.
    • quote – A quotation.
    • status – A short status update, usually limited to 140 characters. Similar to a Twitter status update.
    • video – A single video.
    • Edit: audio has also been added as our final post type.

    There has been suggestion of an “audio” format, which makes sense given the other multimedia posts. Another one recently suggested to me was a “code” format, which I could get behind.

    I know we changed “photo” to “image” to be more generic, but I’m thinking we should change it back, and define a gallery as a gallery of photos. Not that you couldn’t use images there as well, but our target here is photos in particular, I’d imagine.

    We need to make sure we get these right the first time, so if you have a suggestion, you should weigh in. I’ll be sending a link to this post out to a number of theme developers to hear their insights based on their experiences.

    As a reminder, the main focus of this feature is portability and standardization, thus, custom formats are not being supported by the API. (For more, see Mark’s post and the comments.)

     
    • Edward Caissie 6:34 pm on November 11, 2010 Permalink | Reply

      I would definitely support a ‘code’ format, seems a sensible and likely to be often used one.

      • mfields 6:39 pm on November 11, 2010 Permalink | Reply

        +1 for code format

      • David B 9:09 pm on November 11, 2010 Permalink | Reply

        Liking the code format concept as well.

      • Aaron D. Campbell 2:47 am on November 12, 2010 Permalink | Reply

        While I definitely post code, I’m not sure I ever post it all by itself. Usually it’s part of a post that explains what it does, and it’s just wrapped in code tags. Do you see places posting just code?

      • Banago 8:27 am on November 12, 2010 Permalink | Reply

        Code is very developer centric and won’t have wide adoption. Even us as developers might only use it for snippets but not part of a regular blog. I don’t think it would be a good idea to implement code format – KISS formats!

      • Jeffikus 1:12 pm on November 12, 2010 Permalink | Reply

        I agree with Aaron, it seems too niche to have a “code” format. Very developer-centric, microblogging is primarily aimed at developers.

    • Andrew Nacin 6:38 pm on November 11, 2010 Permalink | Reply

      Obviously, a post can also have no format. A theme would explicitly register support for some or all of these formats using add_theme_support().

      • redwall_hp 10:05 pm on November 11, 2010 Permalink | Reply

        Great idea. I’ve actually been thinking about hacking together a Tumblr-style Link thing using post types, for my own usage. (Gruber’s Daring Fireball site is actually what gave me the idea…) I like the idea of having something like that built-in to the core.

    • Remkus de Vries 6:39 pm on November 11, 2010 Permalink | Reply

      Both suggestions I can fully support. Photos, to me, makes more sense than images and a code version is almost a must imo.

    • Ian Stewart 6:39 pm on November 11, 2010 Permalink | Reply

      I like image only because I imagine artists using that post format.

    • Mo Jangda 6:39 pm on November 11, 2010 Permalink | Reply

      A generic “image” is far better than “photo” (because photos are essentially images). Also would maintain consistency since the tooltip for images says “Upload an image”.

    • Brian Gardner 6:40 pm on November 11, 2010 Permalink | Reply

      I think that adding “code” as a post format would be cool. Lots of devs (including me) would like to drop snippets from time to time. if this doesn’t get in, perhaps a way to register our own post formats?

    • Brian Gardner 6:43 pm on November 11, 2010 Permalink | Reply

      Eh, #fail on me – for missing the “no custom formats” line of the post.

      • Banago 8:29 am on November 12, 2010 Permalink | Reply

        I missed that to – it would be really nice to have custom formats though.

    • Eric 6:44 pm on November 11, 2010 Permalink | Reply

      I second both ‘code’ and ‘audio’ formats. There’s a lot of custom formatting that comes with posting code, but there’s even more that comes from a blog that also houses a podcast. You could argue that podcasts would be better suited as a custom post type, and some people use it that way, but many times a podcast is posted as part of the blog’s general timeline in association with a transcript …

      • Chip Bennett 7:01 pm on November 11, 2010 Permalink | Reply

        +1 to “audio” post-format type. As with “photo” vs “image”, a podcast is a highly likely use case of “audio”, but not sufficiently different to warrant a post-format type more unique than “audio”.

    • Travis 6:47 pm on November 11, 2010 Permalink | Reply

      I agree that “image” makes more sense than “photo”. No need to suggest/push the usage in one direction.

    • Rich Pedley 6:50 pm on November 11, 2010 Permalink | Reply

      Surely photo would be limiting, image is better – after all they are all images on the web.

    • Andrew Nacin 6:51 pm on November 11, 2010 Permalink | Reply

      Okay, ignore the whole photo/image thing.

    • Matt 6:54 pm on November 11, 2010 Permalink | Reply

      Do you have examples or ideas of these being used in the wild, meaning a post is composed of entirely code and styled significantly differently than it would be if it was just one of the other types plus a pre element? I’d like to follow the Microformats-style standardization of existing usage rather than trying to predict every possible use in the world. We could have as many formats as there are tags. But the fewer there are, the more likely themes are to support a meaningful subset of them.

      • Chip Bennett 7:00 pm on November 11, 2010 Permalink | Reply

        It would make sense to me that a “code” post-format would be sufficiently niche not to warrant a place among the “standard” post-formats. However, that said, might it also be an argument in favor of allowing extensibility of post-formats?

      • Eric 7:08 pm on November 11, 2010 Permalink | Reply

        Actually, now that I think of it ‘code’ wouldn’t really stand alone as a post micro-format. Yes, a post of just code would be styled significantly differently than a content post, but at that point it would be more of a custom post type (non-post object, as @Nacin called it elsewhere) and wouldn’t fit with this schema. I rescind my vote for a ‘code’ post format.

      • Otto 8:13 pm on November 11, 2010 Permalink | Reply

        Tumblr supports a set of formats. Mostly similar to these (and they do have “audio”):

      • Lloyd Budd 9:55 pm on November 11, 2010 Permalink | Reply

        I’m with Matt, a short pragmatic list eases adoption and transitioning between themes, and reduces the pressure of getting it *all* right the 1st time.

      • Jeffikus 1:10 pm on November 12, 2010 Permalink | Reply

        I agree with you Matt, the list should be kept simple and short, Tumblr is probably the best example.

    • Lance Willett 7:04 pm on November 11, 2010 Permalink | Reply

      + 1 for audio.

      What about “recipe” as a common format?

      I would argue that code snippets don’t warrant their own post format.

      • Chip Bennett 7:26 pm on November 11, 2010 Permalink | Reply

        I think “recipe” is another example argument for making post formats extensible.

        • Eric 7:51 pm on November 11, 2010 Permalink

          Perfect example of extensibility. “Recipe” would fit on the list as it’s the right *kind* of category for a post format, but it’s a bit too specific to be included in a common list of defaults. I doubt it would ever be used by the vast majority of bloggers, though it would definitely be used by many.

        • Knut Sparhell 1:07 pm on November 12, 2010 Permalink

          A recipe as hard to implemet as a post format. It’s more a custom post TYPE (CPT), as it will require custom taxonomies and custom fields. Displaying a recipe is not just a matter of formatting, but having a lot of structured data to present.

          Now that we have CPTs I see no reason for a lot of post formats as well.

          As I see it the only reason to implement formats is compatiblity between themes. The list wil be published ad a standard. If they were to be custom, the reason to implement the feature disappers. We do have CPT’s, and they are almost completely customizable, but will require explicit support by the new theme, or a plugin.

          I also view this new feature as a way to avoid making a new CPT for things that may be displayed as a normal post.

      • David B 9:11 pm on November 11, 2010 Permalink | Reply

        What about lists (like to-do lists or any generic ‘list’)? Or is that too fuzzy of a concept?

      • Mark Jaquith 5:29 am on November 12, 2010 Permalink | Reply

        Recipes are timeless. :-) It should be a custom post type (or just a sub-page).

    • Will Anderson 7:11 pm on November 11, 2010 Permalink | Reply

      Slight side tangent here, but is there a specific reason that get_post_format() returns false rather than null if there is no format associated with that post? 99% of the time I assume it wouldn’t make a difference, but there’s one place I can think of where returning null would be more convenient. Template ‘parts’.

      Assuming different post formats display using different HTML as well as CSS, being able to leverage the get_template_part() function would be really cool. A good base name would be needed, but let’s call it “foo” for this example. It’d be nice (if somewhat inefficient on archive pages) to be able to call…

      get_template_part( ‘foo’, get_post_format() ) inside the loop. This would work for the most part, but would be broken by the fact that get_post_format() returns false instead of null. Am I missing something?

      This brings up another point, that a third argument for get_template_part could be nice too. Why not get_template_part($slug, $name, $format)? If the last argument defaulted to false, it would make the first point moot.

      More generally speaking, intelligent selection of template files based on post format would be really nice. I dread the thought of having massive if/else blocks everywhere to cover the different post formats.

    • Mike Schinkel 7:15 pm on November 11, 2010 Permalink | Reply

      Question: Does a Post Format mean that the post will be that in it’s entirety? For example, if it is a video will it not have post content? Or will it have post content in addition to the video? Maybe some guidance on this will be helpful?

    • Patrick Daly 7:25 pm on November 11, 2010 Permalink | Reply

      Are “aside” and “status” so different that they deserve their own formats?

      • Mark Jaquith 9:24 pm on November 11, 2010 Permalink | Reply

        Facebook and Twitter have muddled these, but I do think they are distinct. Status is shorter, and is a status. Aside is a short entry, but not necessarily a status.

    • Ian Stewart 7:32 pm on November 11, 2010 Permalink | Reply

      The aside and status formats sound awfully similar to each other.

    • Mike Schinkel 7:38 pm on November 11, 2010 Permalink | Reply

      Additional potentials:

      Q&A/FAQ (Question and Answer format)
      Interviews (Question and Answer but with speakers)
      Lists (i.e. Top 10 Reasons why…)
      Review (Products, Movies, Albums, etc. Might be too complex to be included as a format, though)

      Another question: Can Post Formats imply “standard” custom fields for that format?

      • donnacha | WordSkill 7:44 pm on November 11, 2010 Permalink | Reply

        +1 for FAQ

      • Eric 7:49 pm on November 11, 2010 Permalink | Reply

        I see some value in ‘lists’ as a post format, but an FAQ would be more along the lines of a custom post type. I’m ambivalent towards interviews and reviews, though.

        • donnacha | WordSkill 7:52 pm on November 11, 2010 Permalink

          A good argument could be made that EVERY website should include a FAQ section, both to save users confusion and to reduce the support burden. Owners of active sites often find themselves answering the same questions repeatedly.

      • David B 9:13 pm on November 11, 2010 Permalink | Reply

        Was thinking ‘directions’ (like directions from Point A to Point B – think Google Maps) but I suppose lists could cover this.

    • Andreas Nurbo 7:45 pm on November 11, 2010 Permalink | Reply

      Will custom posttypes be able to configure custom post formats? Or will that have to be dealt with using either tags/categories/metavalue etc?

    • donnacha | WordSkill 7:49 pm on November 11, 2010 Permalink | Reply

      Product
      Event
      Profile
      Map / Directions

      • Kel 7:53 pm on November 11, 2010 Permalink | Reply

        Yes – Event seems to be missing here. Would Time based (sub) formats cause further issue with the post format itself?

        • donnacha | WordSkill 8:26 pm on November 11, 2010 Permalink

          Actually, I’m not sure if all four of my suggestions shouldn’t actually be handled by Custom Post Types – I’m not sure what the dividing line between CPT and CPF should be.

      • Peter 1:40 am on November 12, 2010 Permalink | Reply

        I was also thinking of exactly these 4 items. We’re doing a large project right now that has all of these post types.

      • Rich Pedley 9:59 am on November 12, 2010 Permalink | Reply

        It would be wrong of me not to support Product as a suggestion.

        I assume these can also be applied to custom post types?

    • Chip Bennett 7:50 pm on November 11, 2010 Permalink | Reply

      I agree with Ian that “Aside” and “Status” are really the same thing, and can/should be merged.

      Also, the many legitimate, if (to varying degree) niche proposed post-format types – FAQ, recipe, code, list, etc. – all argue strongly in favor of providing a means of extensibility.

      The list of standard post-formats is – and should be – quite limited. But this feature has great potential, and very well may become wildly popular – which means that many people will find good, legitimate reasons to extend the format.

      • Patrick Daly 7:53 pm on November 11, 2010 Permalink | Reply

        +1 on a short list of standards with option for custom formats.

        With each version of WP we can discuss which custom formats are clearly popular and decide to add them to core or not.

      • donnacha | WordSkill 7:56 pm on November 11, 2010 Permalink | Reply

        Hi Chip. While keeping things simple is almost always a good thing, extending the range of standard post-formats might be a powerful encouragement to people to use WP for a greater variety of purposes. The “WordPress is just for blogs” meme still has quite a foothold out there.

      • Otto 8:16 pm on November 11, 2010 Permalink | Reply

        I disagree and think aside is different enough from status to be given a separate type. Status is more like a twitter post. Text only, no (or few) links, maximum length restriction, etc. Aside is more like a short form post. Paragraph format, probably highly anchor tag linked text.

        • Chip Bennett 8:22 pm on November 11, 2010 Permalink

          I’m still not seeing how the two are functionally distinct enough to warrant each getting a (coveted) place in the core/standard list. To me, the only functional difference between a Twitter tweet and a Facebook status message is the allowable number of characters.

          They’re both a brief, untitled bit of text content.

          IMHO, just pick one of the two, limit it to some # of characters (say, 255 or something), and call it a day.

        • that girl again 1:20 am on November 12, 2010 Permalink

          I get this, but the terminology bothers me. If you’re explaining the concept of asides by comparing them to Facebook status updates, people are going to get confused when you go on to say that statuses are modelled on tweets, rather than, um, statuses. ‘Txt’ or ‘mobile’ might be more helpful, if you really can’t use ‘tweet’. Or you could invent a new, WP-specific term for the things.

        • Michael 7:08 pm on November 15, 2010 Permalink

          ‘that girl again’ is right — instead of trying to explain things by referencing Twitter or Facebook, I think it’s simple enough to say that a “status” is what you’re doing right now, whereas an “aside” is simply a short blog post that doesn’t require a title.

      • Rich Pedley 9:56 am on November 12, 2010 Permalink | Reply

        My take on this -
        Status – best served by an example: I’m ill
        Aside – is like a side comment or even a QOTD. – Have you had your 15Mb’s of fame yet?

        So I see a case for both.

        • Rich Pedley 10:45 am on November 12, 2010 Permalink

          oops ignore my example for aside, forgot quote was in the list.

        • Chip Bennett 2:05 pm on November 12, 2010 Permalink

          I was going to mention the “quote” format. ;)

          But, doesn’t that further illustrate that there’s really no need to differentiate between an “aside” and a “status”? A “status” is merely one type of “aside”.

    • Ken 7:52 pm on November 11, 2010 Permalink | Reply

      I’d think most things that fit as a Microformat or (Google) Rich Snippet would be better suited as a CPT (or non-post object) and not as a Post Format. These would include hCard, Review, Event, People, Business, Recipe, etc. The rational being that they contain specific data which doesn’t fit the post object well, and their data must be formatted and marked up a specific way.

      On the other hand, doing posts of that sort without concern for data and markup (ie, just styling) then perhaps there’s an argument, but I still think they are better served by CPTs.

    • Marc Lavallee 9:03 pm on November 11, 2010 Permalink | Reply

      Roundup. For link roundups, we style each link and add an icon next to the headline. ex: http://informant.kalwnews.org/roundup/the-blotter-thursday-november-11/ .

      +1 for Q&A (or Interview). For this type of post, a custom format could allow theme developers to style the Q’s and A’s. ex: http://docs.argoproject.org/2010/07/13/content-type-qa/

      Also, +1 for Audio.

    • Ptah Dunbar 9:18 pm on November 11, 2010 Permalink | Reply

      This “standardization” is clearly causing more trouble than it’s worth and is the complete opposite way WordPress has been shipping new features.

      Put the filter back into get_post_format_strings() and educate the community on the differences between post formats and post types (e.g. because events, product, and recipes are CPTs not CPFs). Links, Status & Quotes are.

      Let WP core ship with it’s “official” post formats but allow the community to experiment with their own custom formats if they feel like the official post formats aren’t relevant enough for their theme. You can then guage based on popularity which custom post formats should warrant inclusion into core. Rinse and repeat.

      If WP ships with this “limitation”, we’re going to find ways around it so make the commit.

      • Mark Jaquith 10:59 pm on November 11, 2010 Permalink | Reply

        It’s not much more than standardization. Themes can (and are) doing this currently using categories or a custom taxonomy. The whole point of this isn’t to make it possible, but to make it portable.

        We’re working on making the specs more detailed, so that these formats are completely portable from theme to theme.

      • Alex M. 11:08 pm on November 11, 2010 Permalink | Reply

        I think allowing custom formats would be a bad idea. Photo vs. image above is a good example of why this would be a bad idea.

    • Matías 10:59 pm on November 11, 2010 Permalink | Reply

      I echo the need to keep it short. The list sounds great, though I concur that Status seems like a skinnier Aside. It certainly would be difficult to accommodate naturally design wise while having it widely adopted, which is the purpose of the standardization. Are three types of text posts really needed?

    • Nathaniel Taintor 11:33 pm on November 11, 2010 Permalink | Reply

      I’m still trying to wrap my mind around the concept here.

      If anything, I think maybe there should be a “Column”, “Editorial” or similar post format – not sure of the terminology. I see a lot of news-driven blog where authors have a regular column that follows a different logic, perhaps more personal, than their regular reporting or asides.

    • Jon Brown 12:29 am on November 12, 2010 Permalink | Reply

      First I could really use an example/demo of each of these formats.

      Second, and more importantly, plead keep generic terminology (ie images).

      Third, what about a format for lists? I’m actually thinking about recipes in this use case.

      • jb510 5:20 pm on November 12, 2010 Permalink | Reply

        Sorry, that was written way earlier than it posted, ie before all the other comments explaining/answering all that

    • Jeffikus 12:47 pm on November 12, 2010 Permalink | Reply

      Here’s my experience of actually building a tumblog theme and a tumblog plugin.

      A standard format per ‘post format’ is necessary otherwise everyone is going to be doing their own thing. That defeats the purpose of this effort and frankly developers should follow standards. When I built the tumblog plugin I kept the formats standard so it would be easy for dev’s to follow a standard format and get more microblogging themes out there. Tumblr is, in my opinion, the best model to follow for microblogging and I think their items (text, photo, quote, etc) should be included.

      I am going through the code this weekend and will post my thoughts shortly.

    • enej 8:39 pm on November 12, 2010 Permalink | Reply

      What about “Question” as a format?

      • Chip Bennett 1:11 pm on November 13, 2010 Permalink | Reply

        Couldn’t a “question” merely be a subset of “aside”, or “quote”?

    • Tara 3:13 pm on November 13, 2010 Permalink | Reply

      +1 for Audio. Podcasters would truly benefit from this.

    • Andrés Sanhueza 10:24 pm on November 14, 2010 Permalink | Reply

      Tumblr also has another post “format” based on formspring.me functionality I believe is called “Answer”. It can’t be made by the frontpage, but by answering a message another user sends you by a contact form. It displays the question, the name of the asker and your reply. The first two are not editable, I believe.

      Also, I wondered how something from Scribd, SlideShare or Issuu conceptually fits in those. In Tumblr, raw embed codes are supported by ‘video’, but still.

    • Andrew 3:09 am on November 16, 2010 Permalink | Reply

      I know that I’m a bit late to be posting to probably have any effect, but limiting it to those that are used on Tumblr is probably the way to go.

      I see ‘status’ and ‘aside’ as being very similar, and probably similar enough to warrant the use of just one of them. From what I see, they are virtually identical, so why the need for 2 of them?

      I think it should stay as ‘image’ because not every image is necessarily a photo. They should be generic terms, and photos are just part of the types of images possible.

      Otherwise, the list looks fine, but personally, the final list I think should be:

      • image
      • gallery
      • aside
      • video
      • link
      • quote

      But allow for others as well. There is no point in fixing the number of post formats when there are many others that people could use that aren’t necessarily used by others, such as ‘podcast’/'audio’

      • Alex M. 1:53 am on November 20, 2010 Permalink | Reply

        It was purposefully decided to not allow the extending of the post formats feature. The whole point of the feature is standardization. Post formats aren’t a new feature (tons of themes have already implemented similar functionality), they’re strictly a way of creating a list of types that all themes should support.

        If one theme supports podcasts by creating the type “audio” and another theme supports podcasts by creating the type “podcast”, then if you switch themes your type won’t carry over. That’s exactly what post formats is seeking to avoid.

    • Beau Lebens 2:39 am on November 17, 2010 Permalink | Reply

      I wonder if some of the work for Activity Streams could help drive this: http://activitystrea.ms/schema/1.0/activity-schema-01.html#anchor5

    • Andy Beard 10:26 pm on November 20, 2010 Permalink | Reply

      1. A generic “embed” type for pasted code

      There are lots of embeds, documents, maps, full scrolling timelines etc

      2. A generic embed type which is Oembed – thus it is a link that actually uses oembed, whereas the standard link wouldn’t necessarily do this.

      For both of these the class could be modified based on source for some extra styling possibilities.

    • Azizur Rahman 1:58 pm on December 30, 2010 Permalink | Reply

      @nacin: link to Codex Page is broken in your original post. remove the “.” from the end of the link.

    • Alex theberge 7:08 pm on January 9, 2011 Permalink | Reply

      I’m also wondering why not “review”, “business card” and “Location” as well? Even “Recipe” would be wonderful. Why not create Post formats that adhere to or coordinate with the drafted micro-formats?

  • Andrew Nacin 3:39 pm on November 10, 2010 Permalink | Reply
    Tags:   

    Reminder that the dev chat is in about 20 minutes at the new time of 1600 UTC.

    Agenda is a status check on everything outstanding for 3.1 as we prepare for beta.

     
  • Otto 8:50 pm on November 9, 2010 Permalink | Reply
    Tags: ,   

    The theme uploader tool now performs a much more extensive scan of uploaded themes and gives the results back in a list format to the uploader. Hopefully this will allow theme developers to more easily fix problems with their themes and reduce some of the load on the theme review team.

    Example of the resulting output (truncated). Note that I intentionally used a failed theme here, to show an example of what that looks like.

    And so on. This is an improvement over the previous method, which just stopped at the first error found and didn’t give a whole lot of useful output. While that old system is still in place (for now), this one is there in addition to it and will give all the results for any theme uploaded.

     
    • Denis 9:20 pm on November 9, 2010 Permalink | Reply

      Lol. Are you guys actually receiving “I created a new theme” spam? :-D

      • Otto 9:24 pm on November 9, 2010 Permalink | Reply

        Not exactly, but the process for getting a theme approved was rather frustrating. The uploader checked for a number of basic conditions, but then only reported the first error. This made it hard to use because it became a process of upload, fix the problem, repeat until it goes through. And even then, the theme review requirements are somewhat more stringent. So I made this checker code to hit all the major points and provide a sort of feedback system, to allow theme authors to fix up their themes before uploading them. I wasn’t the first to do so, Pross had a fairly extensive checker system in place which I used parts of.

    • Rich Pedley 9:23 pm on November 9, 2010 Permalink | Reply

      Could this be turned into a plugin for theme developers?

      • Otto 9:25 pm on November 9, 2010 Permalink | Reply

        Yep, Pross is way ahead of you there. He’s got a plugin in the works which can be used for development environments. Basically it runs the checks on the current theme and displays the results on an admin screen.

      • Ben 1:53 pm on November 10, 2010 Permalink | Reply

        I was going to ask the same thing – that would be awesome.

    • David Cowgill 11:07 pm on November 9, 2010 Permalink | Reply

      Great idea Otto. Being a theme developer, it will be nice to have a dev plugin to test all this before rolling out a new theme. Will Pross announce the plugin here once it’s available?

    • Ryan McCue 12:03 am on November 10, 2010 Permalink | Reply

      While this is awesome, the screenshot you’ve attached shows wp_specialchars() and attribute_escape() being used in a backwards compatibility file.

      Does this mean that themes are unable to use functions like this for backwards compatibility? (e.g. I can see a case where the theme author checks if esc_html() exists, and if not, maps to to wp_specialchars() )

      • Alex M. 12:05 am on November 10, 2010 Permalink | Reply

        Why support ancient insecure versions of WordPress?

        • Chip Bennett 3:13 am on November 10, 2010 Permalink

          Bingo!

          Right now, we would (probably) make an exception for a Theme that provides awesome, thorough, and consistent backward-compatibility for a given WordPress version. Of course, I’ve yet to see such a Theme. Usually, it’s a one-off compatibility check.

      • Otto 2:52 am on November 10, 2010 Permalink | Reply

        This check system doesn’t currently prevent the upload from succeeding (although all the previous checks are still in place). I expect to make changes before making a “pass” on this a requirement. Discussion must ensue, and such.

      • Justin 5:07 am on November 10, 2010 Permalink | Reply

        I don’t think I’ve seen a theme that’s actually backwards compatible. Many will have a function_exists() check for things added in WP 2.3 then no compatibility check for something in 3.0.

    • Mile 2:16 pm on November 11, 2010 Permalink | Reply

      These auto-search type scripts are ridiculous. I have a theme in review for weeks because of them.
      I understand the deprecated function search, but why on earth are you blacklisting php functions like “base64_encode/decode”, fopen, and force use of comment-reply script? At least mark them as suspicious and make the theme reviewer check them manually for improper use, because some themes might actually have a good reason to use them.

    • Tom 2:38 pm on November 11, 2010 Permalink | Reply

      Is the new theme uploader/reviewer available to download at all? It would be very helpful for themes that aren’t going to be uploaded to wordpress.org.

    • Tomas Kapler 11:59 pm on November 22, 2010 Permalink | Reply

      Are you going to improve the same way the plugin uploader. E.g.
      a) screenshot page with no screenshots
      b) recommended usage of all pages
      c) using of deprecated functions (php or WP)
      d) using of direct sql and not wp_query
      e) not commenting functions
      f) not using objects
      g) using non translantable strings and not allowing translations at all
      h) using very often problematic things like <?= in place of <?php echo
      … and many other problems if they can be easily detected

      • Otto 2:53 am on November 23, 2010 Permalink | Reply

        No, there’s no plans to do plugin reviews in any way.

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