WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: themes Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 1:55 am on April 15, 2014 Permalink | Log in to leave a Comment
    Tags: , , , , , themes   

    HTML5 Galleries & Captions in WordPress 3.9 

    WordPress 3.6 introduced HTML5 versions of popular template tags, starting out with comments, the comment form, and the search form. With the 3.9 release we add galleries and captions to that list. Now, when adding HTML5 support for those features, WordPress will use <figure> and <figcaption> elements, instead of the generic definition list markup.

    To declare that your theme supports these new HTML5 features, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

    add_theme_support( 'html5', array( 'gallery', 'caption' ) );
    

    For forward compatibility reasons, the second argument with the specific parts can’t be omitted when registering support. Otherwise a theme would automatically declare its support for HTML5 features that might be added in the future, possibly breaking its visually because of it.

    For both galleries and captions not only the markup changes when a theme declares its support for them, there are also peripheral changes that come with it.

    Galleries

    By default, galleries will not include inline styles anymore when in HTML5 mode. This caters to the trend of disabling default gallery styles through the use_default_gallery_style filter, a filter that even the last two default themes used. With that, theme developers can always start with a clean slate when creating their own set of gallery styles.

    We also took the opportunity to remove the line breaks between rows of images. Not only did they encourage an inferior way of positioning elements, more importantly they were non-semantic html elements that are meant for presentational use, and they made it harder to style galleries.

    Captions

    Up until now, captions received an additional 10 pixels of width, to keep text flowing around the caption, from bumping into the image. As @nacin put it, this has vexxed theme developers for years, and even resulted in the addition of a filter in WordPress 3.7 to manipulate the caption width.

    We were not able to completely remove the inline style in HTML5 mode, it’s still necessary to force captions to wrap, but we’re no longer the adding 10px of width. We also removed caption styles in the editor, bringing it on par with how non-captioned images are displayed:

    Twenty Thirteen and Twenty Fourteen have been updated to support both features, while retaining backwards compatibility with older WordPress versions. There is a remote possibility however, that child themes that use element selectors to overwrite gallery or caption styles can lose those customizations. Please test your child themes with the current development versions of the last two default themes.

    If there are any questions about the current implementation, feel free to leave a comment below.

     
    • andrei1709 5:08 am on April 15, 2014 Permalink | Log in to Reply

      Awesome! Thank you very much for this update :)

    • Manuel Schmalstieg 12:07 pm on April 15, 2014 Permalink | Log in to Reply

      Glad to see that the HTML5 mode removes the BR tags from the gallery markup. That’s great news for responsive theme development!

    • Morten Rand-Hendriksen 3:12 pm on April 15, 2014 Permalink | Log in to Reply

      This is great and long overdue. I always say WordPress is at the forefront of web standards and the two thing that have been lagging behind are the galleries and comments. This is a major milestone that will change the way we think about built in features.

    • glueckpress 9:15 am on April 16, 2014 Permalink | Log in to Reply

      (goes updating themes)

    • Justin Kopepasah 6:43 am on April 17, 2014 Permalink | Log in to Reply

      This is great news. I was happy when the filter was introduced and now I am elated to see the ability to implement HTML5 galleries completely. Definitely adding this to my latest theme.

    • car57 6:52 pm on May 14, 2014 Permalink | Log in to Reply

      I am not a developer, so would you be so kind as to explain what is meant by:

      To declare that your theme supports these new HTML5 features, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

      add_theme_support( ‘html5′, array( ‘gallery’, ‘caption’ ) );

      I have a functions.php file for a child theme. I don’t know what code to insert to have “a callback to the after_setup_theme action”

      TIA

      • Knut Sparhell 12:39 am on May 15, 2014 Permalink | Log in to Reply

        A callback is a function (or class method) that is added to an action by add_action(). In this case add_action( 'after_setup_theme', 'my_theme_setup' );. Inside my_theme_setup() function you can add the theme support. It could also be added in other actions, like ‘init’ or ‘wp_loaded’, but not before ‘after_setup_theme’ has fired. If you just add the support in the outer scope of functions.php it may be executed too early in the load process. The internal data structures to receive this theme addition may not have been initialised before ‘after_setup_theme’.

        The outer scope of functions.php (and plugins) should only add actions and filters, nothing else. All things you want to do should be inside a “callback” (a function or a class method, to be precise).

        See http://code.tutsplus.com/articles/the-beginners-guide-to-wordpress-actions-and-filters–wp-27373

    • car57 7:56 pm on May 14, 2014 Permalink | Log in to Reply

      no matter how i add php to functions.php, this script is never run. Still getting old-style dl with inline css. Sigh.

    • paulinelephew 12:02 pm on July 23, 2014 Permalink | Log in to Reply

      Hi there,

      I am using the Argo theme and I have no caption displaying with galleries.
      I have tried about everything (including contacting the theme support a zillion times and they won’t get back to me).

      I inserted the lines below in function.php and nothing happens:

      add_action( ‘after_setup_theme’, ‘argo_setup’ );
      add_theme_support( ‘html5′, array( ‘gallery’, ‘caption’ ) );

      the website is http://www.terredalizes.fr

      If anyone can help it is greatly appreciated!

      Cheers,

      Pauline

  • Konstantin Kovshenin 3:02 pm on March 27, 2014 Permalink
    Tags: , , themes   

    Masonry in WordPress 3.9 

    If you use Masonry in your themes or plugins, here’s what you should know about the 3.9 update.

    In WordPress 3.9 we’ve updated Masonry to v3, which no longer requires jQuery. The new script handle is masonry. Some of you have been using that very same handle with your own bundled copies of jQuery Masonry v2, this has potential to break in fairly rare cases:

    • You’re using Masonry v2 options or methods that are deprecated in v3
    • You’re dumping your Masonry init code inside the bundled library itself
    • You’re using v2 class names in CSS such as .masonry-brick and .masonry
    • You’re relying on a declared jquery dependency for masonry, even if you bundled v3

    The older jquery-masonry handle is now the official v2/v3 shim, which provides (some) backwards compatible options, methods and classes. If you were using core’s jquery-masonry in your theme or plugin, you should be fine. It’s also the handle you’ll want to use to be compatible with both 3.8 and 3.9+. A short Masonry v2 to v3 upgrade guide could be found here.

    Whatever you’re doing with Masonry in WordPress, we urge you to test your themes and plugins now. Get the latest beta and head over to #27510 to let us know if you’ve stumbled across any compatibility issues.

     
  • Samuel Wood (Otto) 5:45 pm on April 14, 2011 Permalink
    Tags: , themes,   

    I’m going to be upgrading the /extend/themes bbPress install to bring it up to the same level of bbPress where the ideas and plugins and support forums are. This is to allow the login cookies to integrate properly across the whole site.

    This means that parts of the themes directory will be non-functional or broken for short periods of time as I track down issues with it. These times should be short and as minimal as possible.

     
    • DH-Shredder 5:59 pm on April 14, 2011 Permalink | Log in to Reply

      Since this is work on bbPress specifically, it should only affect the front-end of the directory, and not the SVN repo, correct?

      • Otto 6:34 pm on April 14, 2011 Permalink | Log in to Reply

        The display and search capabilities of /extend/themes and the API calls from core will be temporarily affected until I can make the proper adjustments to them. Access to the SVN will not be affected.

    • Otto 8:24 pm on April 14, 2011 Permalink | Log in to Reply

      This update is complete. Let me know if any bugs are spotted and I’ll correct them.

  • Samuel Wood (Otto) 4:50 pm on February 3, 2011 Permalink
    Tags: , themes,   

    Theme pages now have a little “Theme SVN” link in their FYI box. This just gives a link to the theme’s SVN, for people that want to use it.

    This is something several of the theme reviewers asked for, and it fits with the long term goal of allowing some theme authors the ability to directly update themes via SVN instead of using the ZIP file uploader. Encouraging SVN use is a good thing, I think.

     
    • Rich Pedley 6:52 pm on February 3, 2011 Permalink | Log in to Reply

      That just lists all the versions, ala the ‘Other Versions »’ link on plugin pages. Shame it can’t be WordPress.org-ified rather than a simple listing though.

      • Otto 6:54 pm on February 3, 2011 Permalink | Log in to Reply

        That’s what it’s supposed to do. The theme SVN isn’t organized like the plugin SVN, with trunk and tags and such. It just has one directory for each theme version.

        • Rich Pedley 7:28 pm on February 3, 2011 Permalink | Log in to Reply

          So it could be pulled into a WordPress themed page then…

          ;)

        • Dion Hulse (dd32) 1:13 pm on February 5, 2011 Permalink | Log in to Reply

          Rich: Given it’s a SVN repo, I’m not really sure it’s possible to style it like WordPress.org. That aside, as it’s a SVN repo, it’s not designed to look like WordPress.org :)

        • Rich Pedley 8:09 pm on February 5, 2011 Permalink | Log in to Reply

          On a site such as WordPress.org having unstyled pages like that is very un-professional. I still think the data could be pulled into a themed page, and even if it can’t I have seen better web front ends for SVN.

        • Peter Westwood 10:08 pm on February 5, 2011 Permalink | Log in to Reply

          You can style the SVN web interface but I wouldn’t want to be the person writing the XSLT to do it – it’s not fun and you won’t make it look much better – I don’t see why it needs styling at all.

        • Alex M. 6:58 am on February 6, 2011 Permalink | Log in to Reply

          If you want to look at a pretty version of the code, then use the plugins Trac instead of browsing the directory via SVN. Or even better just use a proper SVN client.

          The SVN repository isn’t really meant for browsing with your browser. ;)

        • Matt 6:14 pm on February 6, 2011 Permalink | Log in to Reply

          I think it would be worth a little XSLT to just put a note at the top, like “This is blah blah blah for the plugin’s page please see LINK or visit WordPress.org.”

    • Radhe 6:45 am on February 4, 2011 Permalink | Log in to Reply

      This is welcome addition,
      but I do think “trunk” folder should be given, that will be helpful when author modify theme code in response to theme-users support request.

    • Dion Hulse (dd32) 1:13 pm on February 5, 2011 Permalink | Log in to Reply

      Could we get the same thing for Plugins?

      • Otto 6:00 pm on February 5, 2011 Permalink | Log in to Reply

        Plugins have had the SVN links in their Admin sections forever. Not sure it’s worth exposing them on the public side of things.

        • Dion Hulse (dd32) 10:34 pm on February 5, 2011 Permalink | Log in to Reply

          Not everyone has access to the admin section of every plugin.

          I personally see SVN access for Plugins as more useful than for Themes. Every task is common between them however (Other than Theme review team stuff, but thats a not a normal front end task anyway). Allowing easier access to the SVN repo from the plugins page will help people who are not aware of SVN get into it at well, encourage them to use svn..

          One of the first thing I do, and I’d hope other Plugin developers do, is open the plugins SVN repo and take a glance at the code, it’s what tells me if I’m going to atttempt to use it or not. That’d be my main use for it for Plugins (as well as for Themes).

        • Rich Pedley 9:37 am on February 7, 2011 Permalink | Log in to Reply

          erm plugins already have a link to the Development log in the FYI box. This was what I was referring to when I thought that the themes should match it.

    • Denis 6:00 am on February 12, 2011 Permalink | Log in to Reply

      Slightly off topic, but… It just occurred to me that the default vote for compatibility was for 3.1 at a time where it was not released. As much as I like the idea that one can vote on works/broken for the latest beta/RC, it seems to me that the vote should apply to the latest and greatest *released* WP version by default. (Or maybe it already is the case, in which case it’s not clear at all…)

      • Denis 6:01 am on February 12, 2011 Permalink | Log in to Reply

        i’m meaning for plugins, btw. But since you’re also worrying about that and I can only assume the same logic applies for themes, I figured I’d raise it here.

  • Samuel Wood (Otto) 8:50 pm on November 9, 2010 Permalink
    Tags: themes,   

    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 | Log in to Reply

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

      • Otto 9:24 pm on November 9, 2010 Permalink | Log in to 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 | Log in to Reply

      Could this be turned into a plugin for theme developers?

      • Otto 9:25 pm on November 9, 2010 Permalink | Log in to 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 | Log in to Reply

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

    • David Cowgill 11:07 pm on November 9, 2010 Permalink | Log in to 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 | Log in to 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 | Log in to Reply

        Why support ancient insecure versions of WordPress?

        • Chip Bennett 3:13 am on November 10, 2010 Permalink | Log in to Reply

          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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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

  • Jen Mylo 7:10 pm on November 9, 2010 Permalink
    Tags: , themes   

    FYI, Daisy Olsen is going to head up the theme developer handbook. She’s started working on an initial outline/TOC. Anyone want to volunteer in advance to help with it?

     
    • Eric 7:40 pm on November 9, 2010 Permalink | Log in to Reply

      I’ll volunteer in advance to be a sounding board for it.

    • Tim 8:43 pm on November 9, 2010 Permalink | Log in to Reply

      I’ll volunteer to help with writing/editing or anything needs to be done.

    • Jim Doran 9:38 pm on November 9, 2010 Permalink | Log in to Reply

      I’m interested in helping.

    • David Cowgill 11:24 pm on November 9, 2010 Permalink | Log in to Reply

      I’ll volunteer to help Jane. My voice will be from a theme developer’s standpoint. Just let me know when and where.

    • Daisy Olsen 2:13 am on November 10, 2010 Permalink | Log in to Reply

      I’m looking forward to seeing this project take shape. I look forward to working with you all :-)

    • Chip Bennett 3:15 am on November 10, 2010 Permalink | Log in to Reply

      I would be more than happy to help. I would be happy to contribute anything that I can, and am also interested in ensuring that the handbook and the Theme Repository review guidelines are consistent with the handbook, and vice versa. But in any case, I’ll help in any way I can.

    • jim doran 3:55 pm on November 10, 2010 Permalink | Log in to Reply

      I can help, too. Editing, writing, etc. (I tried to post this comment yesterday – hope it didn’t end up in spam).

    • Laurie M. Rauch 10:11 pm on November 23, 2010 Permalink | Log in to Reply

      I would also be interested in helping – writing and/or editing. Please don’t hesitate to contact me. :)

    • Tom 2:28 pm on November 25, 2010 Permalink | Log in to Reply

      I’ve been looking for a way to contribute. Please add me to the list of volunteers.

    • Ed 11:34 pm on January 6, 2011 Permalink | Log in to Reply

      Count me in too. I can assist with writing/editing on anything theme related!

  • Samuel Wood (Otto) 6:20 pm on August 3, 2010 Permalink
    Tags: boolean, filter, , themes   

    Theme filter searching now has an all/any selection box, for people who didn’t like it being exclusively boolean AND. See it here: http://wordpress.org/extend/themes/tag-filter/

     
  • Michael Adams (mdawaffe) 9:18 pm on May 3, 2010 Permalink
    Tags: , , themes   

    In preparation for 3.0, themes should wrap calls to next_post_link() and previous_post_link() in is_singular() conditionals if those functions are being used on index.php/archive views.

    See #10867 .

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

    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.

     
  • Ryan Boren 6:01 am on September 18, 2008 Permalink
    Tags: , themes,   

    We need to find someone to pick up the theme update and install work. The hookups to api.wp.org are already in. Much of the job can be done with a cut-and-paste of the plugin update and install code. Any takers?

     
    • Serge K. Keller 7:26 am on September 18, 2008 Permalink | Log in to Reply

      If you need “little hands for little works”, I’ll be happy to give some help (with this or any other task you need)

    • Jacob Santos 7:02 pm on September 18, 2008 Permalink | Log in to Reply

      Um, me? Ah crap, you also mean diff file changes and the like. That would be both challenging and a lot of fun. I’ll think about it after this week. If no one else jumps at it, then I’ll be riding that pony. It will be different from what I usually do with patching WordPress.

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