Updates from Mark RSS Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 4:51 am on November 16, 2009 Permalink | Reply
    Tags: , ,   

    WordPress 2.9-beta-1 is available! Get it here: zip, tar.gz. Start hammering away.

     
    • Shane 5:07 am on November 16, 2009 Permalink | Reply

      oh yeah. Time to really kill some bugs. :D

    • Ramoonus 8:35 am on November 16, 2009 Permalink | Reply

      release notes?

    • Ryan 11:38 am on November 16, 2009 Permalink | Reply

      Lol, this broke my site something wicked! I’ve been testing the trunk install for about a month now and am yet to find a single bug!

    • gillesv 2:52 pm on November 16, 2009 Permalink | Reply

      Does the_post_image() work yet? I tried it locally but am seeing nothing?

    • Ryan 2:58 pm on November 16, 2009 Permalink | Reply

      • Matt 7:10 pm on November 17, 2009 Permalink | Reply

        Aaron’s has a few things that aren’t actually new.

        • Dre Armeda 7:27 pm on November 17, 2009 Permalink

          Aaron also listed that the PHP5 requirement is coming in 3.0, I thought that wasn’t set in stone?

        • Mark Jaquith 7:39 pm on November 17, 2009 Permalink

          Some things already require PHP 5, like time zone support or oEmbed. There are no plans that I know of to remove PHP 4 support in 3.0 — last I checked we still had 12% of WP installs using PHP 4.

          I see more of a natural and gradual deprecation of PHP 4. We’re very much open to making new features require PHP 5 if it would be a pain to make them PHP 4 compatible.

        • Alex M. (Viper007Bond) 7:43 pm on November 17, 2009 Permalink

          To be clear, oEmbed doesn’t require PHP5, it’s just that XML decoding isn’t supported under PHP4 (not worth the trouble). That’s not a big deal though as most sites support JSON and we have a class that provides JSON support for PHP4.

        • Dre Armeda 8:32 pm on November 17, 2009 Permalink

          Mark, that’s what I thought. Just a bit misleading in the post. I also agree that a gradual deprecation of PHP 4 is more likely, eventually it will run its course.

        • Matt 10:18 pm on November 17, 2009 Permalink

          Correct, there are no plans to change the minimum requirements.

        • Aaron Brazell 2:02 am on November 18, 2009 Permalink

          I will update the post. Mark already corrected me and I acknowledged in comments. Just haven’t had a chance to update. :)

        • Dre Armeda 6:48 pm on November 18, 2009 Permalink

          Aaron, great post by the way! :)

    • Ajay 6:19 pm on November 17, 2009 Permalink | Reply

      I can’t download it using the plugin

      • Kirk M 9:23 pm on November 17, 2009 Permalink | Reply

        If you mean the WP-Beta-Tester plugin I believe that only deals with point release nightlies (currently states it’s a development version of 2.8.6 or that’s what it says when I just checked it on my test site anyway) and bleeding edge nightlies (2.9 rare). I don’t think you can use it to download beta builds or at least I can’t.

        • Alex M. (Viper007Bond) 9:24 pm on November 17, 2009 Permalink

          Beta 1 is just a particular nightly. Once a version of WordPress hits beta, it’s better to run trunk (nightlies) than the above ZIP anyway (it’s more up to date).

      • Kirk M 9:32 pm on November 17, 2009 Permalink | Reply

        Alex – That’s what I thought although I did want to check it out. Just FYI: I switched the plugin back to “Bleeding edge” and auto upgraded to 2.9 beta 1 ;) Go figure.

    • Kirk M 4:19 pm on November 18, 2009 Permalink | Reply

      Mark – Just to avoid confusion, the “version.php” file in the .zip file for 2.9 beta 1 shows as “2.9 (rare)” and not “2.9 beta 1″. Some testers are being thrown off by this as this. Was this intentional or just something that was missed?

  • Mark Jaquith 7:14 pm on October 13, 2009 Permalink | Reply
    Tags: , BuddyPress, commits, embeds,   

    Two big patches for 2.9 just went in. [… 

    Two big patches for 2.9 just went in.

    [12025] by Andy Peatling allows themes to use register_theme_directory() to specify a wp-content-relative path containing theme directories. WP will additionally scan that. Primary use case is BuddyPress adding its themes without requiring copying.

    [12023] by Viper007Bond enables smart embeds along with oEmbed support. For instance, to embed a YouTube or Vimeo video, just paste the URL in your browser on a blank line. It’ll grab the correct embed code for you. Much easier than wrangling with embed code vomit or remembering special shortcodes.

     
    • Alex (Viper007Bond) 7:17 pm on October 13, 2009 Permalink | Reply

      Writing up a post for my blog right now that goes more into depth on the new embeds feature, how to use it, how plugins can interact with it, etc.

    • Otto 7:51 pm on October 13, 2009 Permalink | Reply

      Sweet baby Jebus! I am just now finding out about oEmbed. Brilliant. Never would have occurred to me to look for such a thing.

      Upgrading to trunk now. :)

    • Denis de Bernardy 4:54 pm on October 14, 2009 Permalink | Reply

      Hat Alex for the built-in oEmbed. :-)

  • Mark Jaquith 7:07 pm on August 31, 2009 Permalink | Reply  

    Agenda for 2009/09/03 dev chat:
    - Discuss WP.org plugin directory policies. Should have Mark Riley present. As people are beginning to experiment with GPL-compliant business models around plugins, some issues should be clarified WRT the plugin directory:
    – Plugins that promote expanded services by the author (“have me customize this plugin for you!”)
    – Plugins that ask for monetary donations in the admin UI
    – Plugins that are a “lite” version of a premium GPL plugin/support bundle

     
    • Jane Wells 7:15 pm on August 31, 2009 Permalink | Reply

      I’ll see if Mark’s available, but I know he’s in an all-week support team conference this week, so making it to a 9pm chat might not be feasible. Might also want Matt, as people bringing this up in dev channel keep referencing his post re themes and GPL?

    • Mark Jaquith 2:07 am on September 1, 2009 Permalink | Reply

      Nevermind. Matt and I had a chat and there’s not really anything to discuss. Plugins that merely exist as placeholders for a plugin hosted elsewhere (like a “requirements check” plugin) are out, but “lite” versions, etc are in. The goal is to have the directory be free-to-download plugins. A placeholder for a premium plugin is against that spirit.

      • sc0ttkclark 7:03 pm on September 1, 2009 Permalink | Reply

        What about the other issues, like an official WP stance on:

        – Plugins that promote expanded services by the author (”have me customize this plugin for you!”)
        – Plugins that ask for monetary donations in the admin UI
        – Plugins that are a “lite” version of a premium GPL plugin/support bundle

      • Jeffro 10:48 pm on September 3, 2009 Permalink | Reply

        Well, while it might be fine and dandy to have that explanation here on this site, I’m hearing that Matt is working on a post that will address these sorts of issues and make it more clear what the guidelines are for the plugin repository. Is this true? Some clarification along with perhaps a few examples would go a long way from having tons of people guess and throw around the topic that WordPress is anti-business.

      • Mark Jaquith 12:47 am on September 4, 2009 Permalink | Reply

        WordPress is not anti-business. We’ve just decided to keep the wp.org Plugin Directory a hosting site for zero-cost plugins. There is already a rule (#3) that says it is a hosting site, not a listing site. It’s for actual plugins, not plugins whose primary purpose is to send people somewhere else to download a plugin. This is not a change in policy as much as being consistent about the existing policies. One “requirements check” plugin was allowed in, and another was not. I was concerned about the dual standard.

        If your plugin is actually a plugin, not just an advertisement or a placeholder for a plugin hosted elsewhere, you’re fine, as far as this rule is concerned.

        • Jeffro 1:45 am on September 4, 2009 Permalink

          I personally know WordPress is not anti-business it’s the other people that seem to think this. However, those in question pretty much agree with the responses they received regarding the issue so I’ll just spread the word.

  • Mark Jaquith 3:50 pm on July 22, 2009 Permalink | Reply
    Tags: , edit lock, question, user experience   

    The way the edit lock works now, if you close your browser with the post open, the lock will stay in effect until it times out. Might it not be better if we shortened the edit lock time to something like 120 seconds and kept it locked via an XHR every 90 seconds that the edit screen for that post is open?

     
    • Denis de Bernardy 5:25 pm on July 22, 2009 Permalink | Reply

      That would be nice, yeah.

    • Andrew Ozz 7:21 pm on July 22, 2009 Permalink | Reply

      It’s currently renewed with the autosave XHR every 120 sec. Don’t think we need another AJAX specifically for the post lock, perhaps will be better to add something onbeforeunload that will remove it when the user navigates away or closes the browser (of course the “remove lock” XHR will not be sent when saving the post).

      • Mark Jaquith 7:36 pm on July 22, 2009 Permalink | Reply

        Yeah, that could work. Are onunload XHRs fairly reliable?

        • Andrew Ozz 7:41 pm on July 22, 2009 Permalink

          Will have to test that more but the browser waits until “true” is returned to proceed with the unload (it’s not a typical DOM event), so don’t think there will be a problem sending the request.

      • Aaron D. Campbell 8:44 pm on July 22, 2009 Permalink | Reply

        If it’s already renewed every 120 seconds, couldn’t we just set the lock to expire in 150 or 180 seconds?

        • Mark Jaquith 9:49 pm on July 22, 2009 Permalink

          Could do that in conjunction. I was going to suggest this as well, as a sole mechanism. But where this issue is a problem is on very active blogs with a lot of contributors. On such blogs, even with a maximum lockout of 2.5 minutes, they could run into it a lot.

  • Mark Jaquith 4:54 pm on May 18, 2009 Permalink | Reply
    Tags: , , esc_url, esc_url_raw,   

    Deprecated clean_url() in favor of esc_url(), and deprecated sanitize_url() in favor of esc_url_raw().

     
  • Mark Jaquith 3:13 pm on May 18, 2009 Permalink | Reply
    Tags: , , esc_attr, esc_html,   

    Deprecated wp_specialchars() in favor of esc_html() (also: esc_html__() and esc_html_e()). Using wp_specialchars() with more than one param works for backwards compat. Also, esc_html() (or wp_specialchars() with one param) escapes quotes, just like esc_attr(). This buys security for plugin authors who were mistakenly using a one-param wp_specialchars() call in an HTML attribute. See this wp-hackers message for more detail.

     
  • Mark Jaquith 9:16 pm on May 5, 2009 Permalink | Reply
    Tags: , ,   

    Standardizing and shortening the WP security escaping functions.

    attribute_escape() is now esc_attr()

    Additionally, you can do attribute escaping and translation in one go. Just add the translation function to the end. Like so:

    • esc_attr__() — translate and return, attribute-escaped.
    • esc_attr_e() — translate and echo, attribute-escaped.

    Will be following up with esc_html (with __() and _e() variants), esc_url(), maybe some more. Will be nice, short, predictable, and allow you do translate/escape in one go without a lot of nested parenthesis.

     
    • Viper007Bond 5:04 am on May 6, 2009 Permalink | Reply

      An esc_js() or whatnot might be useful to (i.e. an improved js_escape() (see #7648).

      • Mark Jaquith 5:58 am on May 6, 2009 Permalink | Reply

        Yes, I meant to include that in the list of “coming soon” ones. Though js_escape() would continue to work, as would attribute_escape() and wp_specialchars().

        Improvements to esc_js() née js_escape() are a separate issue — I’ll take a look at that ticket.

    • Leandro Vieira Pinho 3:11 am on May 9, 2009 Permalink | Reply

      Why not escape_attr than esc_attr?. Write escape is more intuitive than esc.

  • Mark Jaquith 7:44 am on November 3, 2008 Permalink | Reply
    Tags:   

    Changed Publish Module style to offer more flexibility. Having the columns side-by-side was too cramped and would have been a nightmare for translators.

     
  • Mark Jaquith 4:58 am on October 28, 2008 Permalink | Reply
    Tags: SEO, title, wp_title   

    wp_title() now consistently handles reverse order title breadcrumbs. So in “right” mode, you get “July (sep) 2008 (sep) Blogname.” SEO plugin authors may want to take note.

     
    • Baris Unver 8:07 am on October 28, 2008 Permalink | Reply

      wp_title always adds more spaces than it has to add. check out my blog – it’s turkish but when you view the source of the pages of any types (permalink, archive, tag, category, page…), you can see the double spaces:

      Permalink: http://beyn.org/27-ekim-2008-tarihli-gunumun-ozeti/
      Category: http://beyn.org/kategori/b/
      Tag: http://beyn.org/etiket/family-guy/
      Date Archive: http://beyn.org/2008/05/
      Page: http://beyn.org/hakkimda/

      I can send you the code I use at headers if you wish. I never was able to read or write at trac.wordpress.org so I’m writing this through here, sorry about that. Actually I noticed this bug(ish?) last night, when I succeeded to do every stuff All in one SEO Pack does, in my theme files. Yeah, I wrote 2.5KB of code and I’m now able to deactivate the 90KB plugin :) . But, as I said, there’s a bug about the spaces.

    • monika 1:12 pm on October 28, 2008 Permalink | Reply

      oh my dear why this?

      this is absolut not useful

    • koconborz 1:49 pm on October 28, 2008 Permalink | Reply

      it would be better to add the smtp mail sending option…

    • Baris Unver 3:12 am on October 30, 2008 Permalink | Reply

      I agree with @monika.

    • Mark Jaquith 6:54 am on October 30, 2008 Permalink | Reply

      It is better for SEO to have more specific information earlier in the title. This won’t change anything if your theme doesn’t use reverse title breadcrumbs. If it does, it’ll make them more consistent.

    • Baris Unver 10:55 pm on October 31, 2008 Permalink | Reply

      My English is not very good, so I need to ask: Will wp_title function have another parameter to reverse the order, or will it be reversed by default?

    • monika 11:17 pm on October 31, 2008 Permalink | Reply

      Mark I am a seo and a very good one and so I say: this is not useful for seo to have the blog title in every title between head and /head.

      title must be unique –

      regards

      Monika

    • Mark Jaquith 6:23 am on November 1, 2008 Permalink | Reply

      Baris, the order is NOT reversed by default. It’s manually reversed in the bundled themes (Default and Classic), with the last parameter.

      monika, you’re free to omit it when designing themes. This only really affects the bundled themes.

  • Mark Jaquith 4:30 pm on October 14, 2008 Permalink | Reply
    Tags: canonical URLs,   

    Added canonical URL redirection for feeds. Now requests for /index.php?feed=atom or /wp-atom.php will redirect to the correct location.

     
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
esc
cancel