WordPress.org

Make WordPress Core

Updates from February, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Pascal Birchler 7:37 pm on February 25, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly 

    Hello everyone, let’s have a look at what’s going on in WordPress core! This edition covers February 19th, 2015 [31479] through February 25th, 2015 [31544].

    If you want to write the next WordPress Core Weekly summary, check out the table over at make/docs and get in touch in the #core-weekly-update Slack channel.

    Customize

    • Make sure WP_Customize_Manager::theme() never returns null. [31536] #31445
    • Add theme browsing and theme switching to the Customizer. Brings into core the Customizer Theme Switcher feature plugin. You can now browse, preview, and activate themes right from the Customizer [31533] #31303

    Accessibility

    • Provide proper label associations and descriptions throughout the network admin [31517] #38406
    • Add missing labels to Archives and Categories dropdown widgets. [31520] #18650

    Press This

    • JSON encode the URL before appending it to the bookmarklet. See #31373. [31537] #31373
    • Hard-code the minified bookmarklet js. Adding the non-minified bookmarklet to the browser bookmarks bar may have unexpected effect. #31373
    • PressThis v2, first run. [31534] #31373

    Taxonomy

    • Add orderby=description support to get_terms(). This appears as a sortable column header. [31532] #31364
    • Pass taxonomy name, not object, to edit_term_taxonomy and edited_term_taxonomy actions. [31525] #30999

    Media

    • Better image-type support checks in image unit tests. PHP can be compiled without support for certain image types. Our unit tests should be sensitive to these configurations. [31510] [31512] #31124
    • Specify globals in media JS files – it is important to denote where we are diverging from dependency injection. [31489] [31491] [31492] [31493] [31494] #28510

    Upgrade/Install,Upgrade/Install

    Script Loader

    Menus

    • Menus: Remove fixed height from .description-thin fields. [31524] #31426
    • Menus: Prevent checkboxes and radio buttons from being stretched to full width on mobile. [31523] #31425

    Themes

    • Use a darker color for “No themes found” message to increase contrast. [31519] #26600
    • Add feedback for screen readers when search results are changed. [31497] #26600
    • Update the theme count when searching for installed themes, like we do on Add Themes screen. [31495] #26600

    Comments

    • Add comment-author-is-site-member class to comment output for site members. [31518] #24054
    • Delegate focusin and focusout events for row actions to make sure the actions are always revealed on focus. [31509] #29765

    Users

    • Multisite: Pass a response code of 200 to wp_die() when a user is successfully added to an individual site after using the /newbloguser/ URL from an invite email. This is a user facing success message. [31514] #31224
    • Multisite: Avoid clearing stored capabilities for a user when removing their built in role in multisite. [31516] #18934
    • When creating a new user, pasting a password should update the password strength indicator. [31483] #31226

    Administration

    • Improve table footer tab sequence by moving <tfoot> after <tbody>. [31513] #30914
    • Dashboard: Add a filter for the query arguments used for the Recent Posts widget. [31508] #29374
    • Quick Edit: Make date fields a bit wider. [31507] #27912
    • Use correct closing tag for “Under the Hood” header on About screen. [31503] #31402

    Plugins

    • Do not activate plugins on initial installation in multisite. Check is_multisite() before activating a plugin that has been installed via AJAX. Without this check, the plugin would be automatically activated on the main site of the network. [31511] #31327

    TinyMCE

    • TinyMCE wpView: don’t insert nested paragraphs when inserting embeddable URLs. [31485] #29526

    Bundled Themes

    Thanks to @afercia, @ AramZS @atimmer, @azaozz, @boonebgorges, @celloexpressions, @cfoellmann, @danielbachhuber, @dd32, @designsimpl, @dipesh.kakadiya, @DrewAPicture, @folletto, @ianmjones, @ipm-frommen, @iseulde, @janhenckens, @jeremyfelt, @jlevandowski, @joedolson, @joostdevalk, @kraftbj, @lancewillett, @mako09, @marcelomazza, @markjaquith,@michael-arestad @MikeHansenMe, @neil_pie, @NikV, @obenland, @ocean90, @PeteMall, @ravindra-pal-singh, @rachelbaker, @rianrietveld, @SergeyBiryukov, @stephdau, @stevegrunwell, @swissspidy @tyxla, @Viper007Bond, @westonruter, and @wonderboymusic for their contributions!

     
  • Pascal Birchler 10:31 am on October 23, 2014 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi everyone!

    It’s this time of the week again: WordPress Core Weekly is here. This updates covers all commits since last week up to today, October 23rd.

    In case you missed it, there has been quite some activity here. I recommend you to check out these great summaries from this week to stay up-to-date:

    Now, let’s have a look at the recent comments!

    Admin

    • Themes: Make “Live Preview” the primary action and “Activate” secondary. [29957] #26899
    • Themes: Fix some theme install stylings [29959] #28148 #29556
    • Live-update site title in toolbar when changing the corresponding field in General Settings. [29963] #28682
    • Allow apostrophes in email addresses when adding users via the Dashboard. [29966] #18039
    • Admin menu changes [29978] #29806
      • Fix scrolling the pinned menu with a mouse wheel.
      • Fix pinning when the menu is only slightly taller than the viewport.
      • Disable pinning on IE8, updating CSS top makes it jump when scrolling with a mouse wheel.

    Customizer

    • Introduce customize_preview_$setting->type action to handle multiple settings of the same type. [29948] #29165
    • Extract content markup for panels to its own method,WP_Customize_Panel::render_content(). This allows to override the behavior of a panel and its contents. [29950] #29324

    Editor

    • Editor-expand [29929] #29954
      • Better calculation for the caret position when auto-scrolling while typing.
      • Fix auto-scrolling for non-WebKit browsers when the caret is above the top of the editor.
    • TinyMCE: update the default styles: make the font size larger and make it the same size in tables. [29986] #30038
    • TinyMCE: update to 4.1.6+. Adds support for cache-busting when auto-loading JS and CSS. [29994] #30079

    Twenty Fifteen

    • Make font-size/line-height in editor-style.css the same as in style.css. Remove margins from the editor body, interferes with autoresize in some browsers and is overriden in the default styles. [29909] #29799
    • No rem in editor-style.css for now. [29910] #29799
    • Add print styles. [29919] #29967

    Internals

    • Add a 6th (!) attribute to wp_get_attachment_link() to allow aria-describedby to be added to gallery output. [29914] #27402
    • Cache get_term_by() calls [29915] #21760
      • Add a helper function, wp_get_last_changed(), to retrieve a last-modified timestamp by cache group.
      • Original term cache entries maintain BC
    • wp_schedule_single_event() should not prevent scheduling a future duplicate event. It should only reject an event as a duplicate if there is already a similar event scheduled within 10 minutes of the given timestamp. [29939] #28213
    • Add ID attribute to style element from wp_add_inline_style(). [29956] [29958] #30032
    • Move password hint text to a function. Add password_hint filter. [29962] #21243
    • HTTP API: Support both the limit_response_size and stream parameters at the same time, allowing a partial file download. [29968] #26726

    Comments

    • Don’t print an empty HTML markup when comment_reply_link() returns no link. [29908] #29895
    • Use the comment API rather than direct SQL queries in comments_template(). [29965] #19623

    External Scripts

    Queries

    • Check that search value is scalar before parsing. Prevents PHP notices when non-scalar values are passed. [29912] #29736
    • Introduce nested query support to WP_Date_Query. [29923] #29822
    • Throw notices _doing_it_wrong() notices are now generated when passing out-of-range values (month=13) or invalid dates (2014-02-29) to WP_Date_Query. [29925] #25834
    • Support date_query by user_registered in WP_User_Query. [29934] #27283
    • Comment/post author in/not_in for WP_Comment_Query. [29935] #29885
    • Better “inclusive” support for string values in WP_Date_Query. [29936] #29908

    Thanks to @westonruter, @obenland, @tivnet, @joedolson, @DrewAPicture, @rianrietveld, @wonderboymusic, @tollmanz, @boonebgorges, @Manoz69, @iamtakashi, @kwight, @pauldewouters, @ideag, @ChriCo, @NikV, @nofearinc, @ew_holmes, @neoxx, @Viper007Bond, @nacin, @chriscct7, @tellyworth, @sc0ttkclark, @jorbin, @socki03, @ocean90, @convissor, @TobiasBg, @TomHarrigan, @jdgrimes, @jcastaneda, @celloexpressions, @avryl, @simonwheatley, @hardy101, @georgestephanis, @jesin, @hugodelgado, @nobleclem, @afercia, @bradyvercher for their core contributions!

    Revisions covered: [29906] to [29994]. For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 4.1.

     
  • Andrew Nacin 7:51 pm on January 3, 2014 Permalink
    Tags: ,   

    The email used for notifications on Trac is currently specified in Trac preferences. I’m changing this to pull automatically from your WordPress.org profile. After this change, there will not be a way to have a separate email address for Trac and any manually specified email address will be overridden.

    We need to make this change because, very simply, it’s a better user experience. By killing this extra user preference, it’s one less step users need to set up in order to receive notifications. (And a tighter feedback loop could possibly boost engagement.)

    That will affect about a thousand users we have in the system, probably incidentally for most. But, about 50-100 users might have been deliberately declaring a separate email address; for example 50 users had “trac” appear specifically in their email. Even without a dedicated email, it is trivial to filter Trac emails; you just might need to make some adjustments.

    As you may have noticed, this is part of a series of changes I’ve been making to Trac. I’ll be doing a summary post in a few days outlining everything that has changed.

    NOTE: This does not affect wp-trac@lists.automattic.com. If you subscribe to the “firehose” this is not affected.

    Edit, 20:23 UTC. This is now enabled. For the moment, the email address will sync when you next visit Trac. Please find me if you have any questions.

     
    • Ionel Roiban 7:55 pm on January 3, 2014 Permalink | Log in to Reply

      Sounds good.

    • Ryan Duff 7:57 pm on January 3, 2014 Permalink | Log in to Reply

      Is there an ETA on the time this will be changed?

      I’ll have to update my email filters on my .org acct and would like to have it ready to test so my phone doesn’t blow up some night when I’m sleeping.

      That’s why I used a specific “list” acct 😉

      • Ryan Duff 7:59 pm on January 3, 2014 Permalink | Log in to Reply

        Err wait, this is the notification email, not the list email. I may be fine as I think that goes to the same email on my .org profile already.

        Heads up may still be nice for the handful that will have to adjust though.

      • Andrew Nacin 8:00 pm on January 3, 2014 Permalink | Log in to Reply

        Sometime in the next 1-72 hours.

        Note — you have the same email address in both Trac references and your WordPress.org profile. If you were referring to the firehose mailing list, that’s not affected. I’ve added a note to the bottom of the post.

        • Ryan Duff 8:13 pm on January 3, 2014 Permalink | Log in to Reply

          Yup. I’m using a separate address for the svn/trac mailing lists. When I went to verify email filters I realized that the ones that come through as trac notification went to the email on file for .org.

          This week has been a bumble from the start. At least it’s Friday. Thanks for following up!

    • Andrew Nacin 8:08 pm on January 3, 2014 Permalink | Log in to Reply

      Here is a short list of names I recognize who this will affect: @westi @dd32 @viper007bond @sterlo @coffee2code @chmac @eddiemoya @kawauso @lloydde @mrmist @ptahdunbar.

      In most cases, though, the user updated their WordPress profile but never bothered to update Trac. That’s why we’re doing this!

    • Eddie Moya 7:38 am on January 4, 2014 Permalink | Log in to Reply

      I did use “+trac” in my email address to filter for it, so I really appreciate that you went through the effort of figuring out who might specifically affected by it. Otherwise I would have been confused about why my filters stopped working, since this is something I haven’t touched in a very long time.

      Idk if the list is just really that short of people affected – but maybe it would make sense to send out a blast email on trac to let everyone know that way in case they aren’t lucky enough to be the 11 names you listed. Just a thought.

      Thanks again for the heads up.

  • Jen 6:39 pm on March 7, 2012 Permalink
    Tags: , , ,   

    GSoC/Summer/3.5 

    Normally we don’t start talking about the next release until the current one is out the door, or at least in beta/RC, so this post jumps the gun a bit, but for a good reason: the GSoC deadline. There are two approaches we could take toward our participation in GSoC this year, and one of them is tied closely to 3.5.

    Historically

    • Good GSoC mentoring takes time. Time is hard to come by at the best of times, even harder for many during the summer.
    • Many of our previous GSoC mentors have held the position for several years and could use a break from trying to mentor while simultaneously working on features for a regular release.
    • Almost none of our GSoC projects have actually made it into core. A few because they were plugins, but most because once GSoC is over there hasn’t been a concerted effort to follow up on these projects.
    • We often run late on dev cycles.

    Since 3.4

    • We have ramped up several core contributors to more responsible/trusted roles as a result of the 3.4 process experiment (teams, cycles, updates, etc). This could mean more mentors.
    • We are running late in our dev cycle, and with SXSW about to eat a week, I’m thinking we’re about to get even more behind. My guess is we’re looking at a May launch, not April.
    • The stated intention of having all feature dev for the cycle tied to a central goal of making it easier to customize your site didn’t really happen. There were at least 3 teams working on features that had nothing to do with this, and another couple that were related, but not smack in the middle of it. Good features all, but we failed in sticking to that goal as a unifying concept.

    Proposal

    What if for 3.5, instead of it being a “regular” cycle, we made it a mentoring cycle tied to the GSoC schedule (shorter than normal)? If we assume 3.4 will launch sometime at the end of April or early May (and if it does happen earlier, awesome), that would put us in a position to start working on 3.5 right when the GSoC accepted students are announced.

    If we chose a “release concept” (like customizing your theme, but something different) and outlined every feature/enhancement/bug that’s related, we could make those things be the potential GSoC projects. We could work in teams like in 3.4, but in this case each team would have a student or two working on things with them closely. Since these would be the only features being worked on (additional bug-fixing always ongoing, obviously),

    • Students would be guaranteed mentor attention and working with core
    • We would be more likely to do the work necessary to get student work to commit-worthy status
    • We would target a launch for late August to coincide with the end of GSoC (so we could do one more small release before end of year)
    • We could do additional outreach to include new contributors who do not qualify for GSoC (too young, too old, not in college, etc), improve our mentoring skills and processes
    • At the end of this mentorship-focused summer, we would not only have the features developed by mentees, but we would have an ideal pool of people to help us create documentation to help new contributors.

    I’m thinking that what might make sense would be for there to be a team or two that doesn’t mentor or work on a feature for 3.5, but begins working on one of the more complex things we keep putting off, so that it could be the first thing into 3.6 (like gallery management or something similar).

    Deciding on a release concept that could be done in a 2.5-3 month cycle would be important. I’m thinking maybe it could be the feedback loop — improving comments and communication with readers via html emails, forms, etc on the front end and a UI facelift of the comments/related screens on the back end, putting something cool into Twenty Twelve around this (or just support for something in core related to same), etc. There are a number of projects around this that have been done in the past that could be looked to for inspiration and/or what not to do, it’s needed attention for some time, and it’s not as complicated as something like media or multisite.

    Thoughts? Specifically, thoughts on:

    • Doing a mentorship-focused release timed to GSoC
    • Potential areas of focus for 3.5 if we were to do this
    • Mentoring in teams like 3.4
    • Wanting to mentor in this case
    • How many students you think we could take on if we used teams like in 3.4

    Comment here today, and tomorrow I’l round up the core team to see what people think based on the conversation so we can make a decision and I can update our application before the application deadline if needed. If we don’t do something like this, then I’m planning on reducing our GSoC student allotment to 5-6 students (we’ve asked for up to 15 in the past) to ensure enough mentors and adequate attention/follow-up on projects.

    Thanks for your input!

     
    • Jane Wells 6:50 pm on March 7, 2012 Permalink | Log in to Reply

      We could theoretically extend the idea of a mentorship summer to other groups:

      • UX/UI… could help with gallery management ideas and comping/wireframing for the non-gsoc teams
      • Forums… could write up a handy guide to solving common support requests and mentor new volunteers
      • Theme Review Team ditto
      • etc etc
    • Justin Shreve 6:53 pm on March 7, 2012 Permalink | Log in to Reply

      I think it’s a great idea. I agree that one of the biggest problems of GSoC in the past has been pulling things back into core. One of the reasons like you mentioned is time and the summer ending. I also think a lot of the projects are not appropriate for core. Most are better suited for plugins/themes anyway. If we really want GSoC projects to benefit core then we should have all of the projects be core projects.

      Since this is a little different from previous years I am thinking we shouldn’t use up all 15 spots. Maybe 8-10 students. The fewer students we use, the more attention/mentors they can get. I think last years GSoC of having multiple mentors worked pretty well.

      I’d love to help/mentor with GSoC again. Especially so if we do something with the feedback loop.

      • Jane Wells 7:20 pm on March 7, 2012 Permalink | Log in to Reply

        We don’t automatically get 15 spots, I just gave that as an example. Here are our numbers for previous years (passed/total):
        2011: 10/12
        2010: 13/15
        2009: 6/8
        2008: 6/8
        2007: 10/10

    • Mert Yazicioglu 7:08 pm on March 7, 2012 Permalink | Log in to Reply

      Even though I developed a WordPress plugin as a GSoC proejct last year, I agree that GSoC projects should contribute more to the core.

    • Travis 7:09 pm on March 7, 2012 Permalink | Log in to Reply

      Fantastic idea, Jane. I think this would be a much better experience for students, and result in better production of things that would/could make it into core.

      I also really, really like the idea of reaching out to non-students to be mentored. That might be the motivation I (and people like me) need to get more involved with contributing.

    • Ahmad Awais 8:12 pm on March 7, 2012 Permalink | Log in to Reply

      I am willing to participate in GSoC this year through WordPress , keep me posted.
      I am a beginner , will it be hard for me to adopt the core? I am into plugin development basics

    • Andy Skelton 8:18 pm on March 7, 2012 Permalink | Log in to Reply

      Excellent idea.

    • Erlend 8:26 pm on March 7, 2012 Permalink | Log in to Reply

      Like I believe I suggested last year, I think WordPress’ sister projects, mainly the “BBs” (bbPress & BuddyPress) could benefit greatly from a cycle dedicated to them alone.

      WordPress itself doesn’t have any big publicity gains through GSoC, as it just feeds on its existing userbase. The BBs however could use the extra attention directed their way, seeing as a huge amount of WP users & even developers still don’t know exactly what these projects can do and how far along they’ve come.

      • Jane Wells 8:31 pm on March 7, 2012 Permalink | Log in to Reply

        Yes, but it is WordPress that Google gives the allotment to, not bb or Buddy. We include the plugins, but the limiting factor there is appropriate mentors. J-trip is only one guy, and even with Boone and Paul (and we’ve never had all 3 at once) that’s very few mentors compared to the number of people capable of mentoring WordPress. bbPress and BuddyPress could also apply to GSoC as separate projects, but have not wanted to in the past, so that they could take advantage of the support offered by being under the WP umbrella.

        Realistically, though, GSoC is not about teaching users and developers about projects. It’s about grooming new contributors and creating more open source code.

    • Paul Gibbs 8:36 pm on March 7, 2012 Permalink | Log in to Reply

      So, I’ve been looking forward this summer to seeing if I can get involved with GSoC. I’m interested in mentoring, and what BuddyPress can get from it — I’m definitely inspired by what Stas and Boone did in previous year(s). WordPress core doesn’t hold the same sort of social focus that attracts me to working on BuddyPress.

      I get the sense that the idea is to change the outputs away from generating a ton of new or specialised plugins, and onto WordPress core, which I agree is a better way for wporg to be participating in the GSoC. I would obviously prefer for this to not be at the detriment of possibility of a project for BuddyPress (or bbPress, or GlotPress, or any of the mobile phone apps, for example).

      • Mert Yazicioglu 8:40 pm on March 7, 2012 Permalink | Log in to Reply

        I wonder if we could have something like the following:

        5 seats for WordPress core
        3 seats for BuddyPress
        2 seats for Mobile Apps

        • Jane Wells 8:53 pm on March 7, 2012 Permalink | Log in to Reply

          We have NEVER EVER EVER turned away a mobile, bbPress, or BuddyPress application due to lack of spots. Every single year, those specific projects are chosen by the mentors who want to work on them. So if this year Boone, Paul, and J-trip said they didn’t want to mentor, there probably wouldn’t be bb/BP projects. They get to choose which ones are worthy/that they want to work on. Every year I’ve donated spots back to the common GSoC pool because the mentors have chosen to focus on fewer projects with the most impressive applicants, because mentoring is a serious obligation and they don’t have unlimited hours in a day. If people want to see more GSoC projects in the areas of mobile, bbPress and BuddyPress, the first step is to go get more regular contributors to those projects who would then be qualified to mentor GSoC students in the future.

        • Mert Yazicioglu 9:18 pm on March 7, 2012 Permalink | Log in to Reply

          I’m so sorry, my bad. After seeing Paul’s post, for a split second I thought we were talking about allocating all seats to the WordPress core. After sending the comment I realized that is not the case, but it was too late. Shouldn’t have rushed to comment, sorry for any inconvenience I caused.

      • Jane Wells 8:48 pm on March 7, 2012 Permalink | Log in to Reply

        Mobile apps, bbPress, and BuddyPress have always had mentors from their own group of committers. This post really applies to those coming from the WP core contributor group.

    • Eric Mann 9:28 pm on March 7, 2012 Permalink | Log in to Reply

      Fantastic idea overall. Working in teams definitely makes the workload a bit easier (particularly if team members are in different time zones). And scheduling the 3.5 cycle to include GSoC will make things easier on core developers.

    • Wojtek Szkutnik 10:35 pm on March 7, 2012 Permalink | Log in to Reply

      A few thoughts:

      100% in for fewer spots with more focus. There are several projects from earlier GSoC editions awaiting to be merged in some part with the core – if we were able to give them more focus earlier, they would probably be already there. I still find my GSoC 2010 patches merged to the core every few weeks.

      @outreach – great idea! From my GHOP/GCI experience, people in high school have far more free time to contribute to open source. We could prepare fliers, presentations etc and try to reach them. Also, GCI mentoring requires more time but probably less skills, so if we were to participate in GCI next year it would be easier to find mentors (I, for one, would happily devote some time to be a GCI mentor again and won’t give up my GSoC student status this year for Summer of Code mentoring 😉 )

      On a side note, I would really like to see unit tests for both JS and backend in this year’s tasks. I would definitely apply! :) Testing may require some additional knowledge but brings great profits and I believe that unit tests would be very helpful – the sooner we improve this part of WP development, the less backward regressions we’ll experience in the future.

    • Conor Hughes 11:13 pm on March 7, 2012 Permalink | Log in to Reply

      I am but a lowly user of wordpress but I really like the sound of this. Keeping it teams makes it fun for all of us outside the dev comunity.

    • Mark Barnes 1:25 pm on March 8, 2012 Permalink | Log in to Reply

      This makes great sense to me. Improving core should always be the priority of the core developers.

    • Jane Wells 11:15 pm on March 9, 2012 Permalink | Log in to Reply

      UPDATE:
      I corresponded with Carol (the administrator of the GSoC program overall) and she said the approach sounded good. She said putting students onto teams with mentors and/or other students would be fine, as long as we were grading them on their own code. Since everyone starts out writing their own patches before the back-and-forth revision process kicks in, I think this seems pretty easy to ensure. Will discuss more with the people in Austin this weekend (Jaquith, Nacin, Koop, etc) but am thinking that we’ll give it a try.

    • Gustavo Bordoni 5:33 am on March 12, 2012 Permalink | Log in to Reply

      So I would like to know how to submit a project/idea to be part of the GSoC program with WordPress Core improvement?

      • Jane Wells 3:45 pm on March 12, 2012 Permalink | Log in to Reply

        Student applications aren’t accepted until Google opens the application period, and for that matter, we haven’t been approved as a participating organization yet. That said, getting involved early definitely increases the chance of being selected. Submitting patches for core bug tickets before applying is important. You can also talk to WP devs in #wordpress-dev on freenode.

  • Andrew Nacin 1:07 am on December 7, 2011 Permalink
    Tags: ,   

    New API in 3.3: is_main_query() 

    There’s a nifty new method for WP_Query that is available in 3.3: is_main_query().

    This enables someone to hook into pre_get_posts and modify only the main query. No more checking for suppress_filters (which was wrong), or comparing against $wp_the_query (complicated), or using query_posts() in a template.

    is_main_query(), the function, will return true if the current $wp_query is also the main query. (As an example, this would be false after query_posts() is called but before wp_reset_query() is called.) This is consistent with existing conditional tags — for example, is_page() refers to the main query, while is_page() can also be called against any WP_Query object.

    Quick example (YMMV) —

    add_action( 'pre_get_posts', 'nacin_modify_query_exclude_category' );
    function nacin_modify_query_exclude_category( $query ) {
        if ( $query->is_main_query() && ! $query->get( 'cat' ) )
            $query->set( 'cat', '-5' );
    }
    

    For more: #18677

     
  • Jen 6:28 pm on April 14, 2011 Permalink
    Tags:   

    GSoC mentors who have not posted their selections to the mentor blog and need to do so today if they still want to be mentors: @nacin, @dkoopersmith, @dd32, @johnjamesjacoby, Mitcho, Thorsten, @viper007bond, @filosofo, Brian Layman, Chris Jean, ocean90, Russell Fair. If anyone on this list does not know what I’m talking about, they should leave a comment saying as much immediately so I can walk you through it if you missed the original emails. We’ll be doing mentor-student matching tomorrow, so this is it.

     
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
Skip to toolbar