Make WordPress Core

Updates from September, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Morgan Estes 9:08 pm on September 21, 2015 Permalink
    Tags: ,   

    Week in Core: Sept. 13-21, 2015 

    Welcome to the Week in Core — Week Four, with super-exciting news from around WordPress-land, and Core changes and updates for Sept. 13–21, 2015 (commits [34093][34361]). This week’s core contributors number 106! I’m especially jazzed about the number of new names on the list, and want to thank everyone for your effort this week.

    News you can use

    The WP REST API team submitted a proposal to merge the plugin into core, with a two-phase integration plan. The merge proposal blog post also does a nice job of presenting the history of the plugin and some use cases.

    Do you use my-hacks.php in your site? Don’t. (A quick search through the plugin and theme repos shows only 10 plugins and 3 themes that mention the file.)

    Multisite is making some pretty big changes, including the addition of the  WP_Network class. Check out this blog post, which outlines some of the changes and a roadmap for future updates for 4.4.

    Interested in the user-focused part of WordPress? Of course you are! Join in the conversation about “Potential UI/UX projects in core.”

    Code changes

    Here are some highlights from the 268 change sets published to Trac; the complete report is available online in plain-text format for a bit more in-depth coverage.

    (More …)

  • Morgan Estes 9:04 pm on September 16, 2015 Permalink
    Tags: ,   

    Week in Core: Aug. 31 – Sept. 12, 2015 

    Welcome to the Week in Core, with updates from weeks 2 & 3: Aug. 31 – Sept. 12, 2015, changesets [33821][34092].

    It’s been a busy couple of weeks in Core, with almost too many changes to count (for the record, this one covers 271 commits!). I’m going to keep this update shorter than usual and highlight some of the bigger changes.

    If you’re interested in helping write this weekly post, ping @morganestes in #core-weekly-update on Slack.

    Special Note: WordPress 4.3.1 was released this week, with three security-related fixes. Be sure to update your sites!

    Here’s some highlights of recent changes in core, along with some future plans and ongoing initiatives. Remember, Core moves pretty fast. If you don’t stop and look around once in a while, you could miss it.

    • WordPress will support PHP7 when it’s released. Huzzah!
    • HTTP/2 is coming! Here’s a list of tickets that need attention to get WordPress ready.
    • Get involved in Twenty Sixteen, which is in active development on GitHub.
    • Write better commit messages. The world will thank you for it. 🙂
    • As described in this post by @johnbillion, the show_ui flag for post types now gets fully honored. See #33763 for the ticket discussion.
    • A new helper function, wp_validate_action( $action = '' ), was introduced in [34059] and is used throughout admin instead of directly accessing $_REQUEST['action'].
    • A new file, wp-admin/includes/noop.php, was created to load all of the noop functions for load-script|styles.php and is only loaded by those files. DRYs in the process. [34037] #33813
    • Schema change introduced in [34030] to increase the length of wp_options.option_name to 191 chars. #13310
    • Implement a priority system for Help Tabs to add them at specific positions. [33985] #19828
    • Multisite: Don’t allow sites to be created with the following reserved slugs: wp-admin, wp-content, wp-includes [33952] #33615
    • Updated recommendations for minimum versions of PHP (5.6) and MySQL (5.5), with a special note that Oracle only actively supports MySQL for 5 years after a General Availability release. [33937] [33946]

    For the full report, visit https://core.trac.wordpress.org/log/?verbose=on&format=changelog&rev=34092&stop_rev=33821&limit=400&mode=stop_on_copy.

    Thanks to @adamsilverstein, @afercia, @amereservant, @ankit-k-gupta, @antpb, @austinginder, @azaozz, @BdN3504, @benjmay, @boonebgorges, @bradt, @brettz95, @celloexpressions, @cgrymala, @Cheffheid, @chriscct7, @codeelite, @CoenJacobs, @danielbachhuber, @daniellandau, @dannydehaan, @dd32, @dimadin, @dipeshkakadiya, @dlh, @DrewAPicture, @dustinbolton, @egower, @enshrined, @ericdaams, @ericlewis, @extendwings, @figureone, @filosofo, @gaelan, @GaryJ, @gitlost, @gnaka08, @gradyetc, @gregrickaby, @hauvong, @helen, @imath, @ippetkov, @iseulde, @ixkaito, @jazbek, @jeffstieler, @jeremyfelt, @jesin, @jobst, @johnbillion, @joostdevalk, @jorbin, @juliobox, @JustinSainton, @kevinlangleyjr, @khromov, @kitchin, @kraftbj, @lancewillett, @liljimmi, @lukecarbis, @macmanx, @MatheusFD, @mehulkaklotar, @mercime, @metodiew, @michielhab, @MikeHansenMe, @miqrogroove, @mitchoyoshitaka, @mordauk, @morganestes, @mrahmadawais, @mrmist, @Mte9, @nacin, @netweb, @nikeo, @nikolovtmw, @nofearinc, @obenland, @ocean90, @OriginalEXE, @Otto42, @paulwilde, @pavelevap, @pento, @peterwilsoncc, @racaseh, @rachelbaker, @rajnikmit, @rmccue, @rommelxcastro, @sc0ttkclark, @scribu, @SergeyBiryukov, @sillybean, @solarissmoke, @stevehenty, @swissspidy, @tmatsuur, @trepmal, @tyxla, @umeshnevase, @utkarshpatel, @wen-solutions, @wenthemes, @westonruter, @wojtekszkutnik, @wonderboymusic, @yoavf, and @zeo for their contributions!

  • Mike Schroder 8:49 am on November 14, 2014 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi Everyone!

    It’s that time again: WordPress Core Weekly is here. This is a catchup post and covers all commits since the last post up until 11/9/2014.

    First, a couple quick notes!


    • Do not create shared taxonomy terms. [30240] #21950; See #5809.
    • Split shared taxonomy terms during term update. [30238] [30239] [30241] #5809
    • Don’t force child_of=0 for non-hierarchical taxonomies in get_terms(). [30265] #30275
    • In get_adjacent_post(), $excluded_terms should check term_id rather than term_taxonom_id. [30263] #29663, #22112.
    • Allow resource_type to be specified in get_ancestors(). Being explicit about resource type (taxonomy vs post_type) allows for the proper resolution of conflicts when a taxonomy and post_type share a slug. [30141] #15029
    • In wp_insert_term(), clean up accidental duplicate terms after insert. [30238] See #22023, #5809.
    • Add some unit tests for is_object_in_term(). These tests check a number of the ways that different kinds of values for $terms (integers that match term_id, strings that match term_id or name or slug) are handled. [30204] #29467
    • In in_object_in_term(), only check numeric string values against term_id. [30205] #29467
    • Introduce term_template param to get_the_taxonomies() to allow theme and plugin authors to specify the formatting on term links as they are parsed into the taxonomy list. [30209] See #27238.
    • Allow duplicate slugs across different post types. [30158] #18962
    • In get_terms(), do not override hierarchical and pad_count when parent is present. The previous behavior resulted in descendant terms being improperly excluded from the results when passing a parent, even when hierarchical had been set to true. [30107] #29815
    • Clean up get_term_by() caching, fix cache key/group modification that was missed in [30073], and update unit tests. [30108] #21760

    Twenty Fifteen


    • Bump db_version and add upgrade routine for schema change in [30056]. [30121] [30134] #22023
    • WPDB’s __get() function should perform strict comparisons against member names. [30292]


    • Allow revision Backbone classes to be used on pages other than revision.php. [30128] #30221
    • Add a single responsibility function for outputting Revisions JS templates: wp_print_revision_templates(). Use it in wp-admin/revision.php. [30129] #30220
    • Revisions modules should not rely on global settings; only pass in global settings on init, this allows the classes to be used agnostically elsewhere. [30131] #30219


    • Pass all updated meta IDs to filters in update_metadata(). [30140] #11683
    • Unserialize get_metadata() results when key is omitted. [30115] #15030



    • Display error message when Media Library upload fails. [30156] [30177] #29891
    • Delete admin_created_user_subject() rather than deprecate. As it was never used as anything more than a callback to a filter before the MU merge, and is only available in user-new.php in multisite, it is safe to remove this function entirely. [30176] #29915


    • Improve/introduce Customizer JavaScript models for Controls, Sections, and Panels, along with a reference. [30102] see #28032, #28579, #28580, #28650, #28709, #29758. Fixes #29529.
    • Improve ColorControl‘s wpColorPicker to update UI based on setting changes. Update Twenty Fifteen’s colorScheme control to properly interact with the API, using wp.customize.control(). [30126] #30031
    • Add stable sorting for panels, sections and controls in JS. Improve sorting in PHP. [30214] #30225
    • Bind input and propertychange events for range input types. [30219] #30223
    • Twenty Fourteen: Make featured content in Customizer contextual to the front page. [30143] #29578


    • Introduce new template functions for archive titles and descriptions: [30223] #21995
      • get_the_archive_title() and the_archive_title() for returning/displaying the title of the current term, date, post type, post format, or author archive.
      • get_the_archive_description() and the_archive_description() for returning/displaying the description associated with the current term archive.
    • In get_page_children(), only check $page->ancestors once to avoid duplicates when the function recurses. Adds an argument, $ancestors. [30246] #18962
    • Allow get_pages(), with child_of passed to it, to work with interrupted hierarchies. [30159] #18962

    Thanks to @afercia, @avryl, @azaozz, @bobbingwide, @boonebgorges, @bradyvercher, @Caspie, @celloexpressions, @dancameron, @davidakennedy, @davidjlaietta, @dikiy_forester, @dlh, @donutz, @DrewAPicture, @ericlewis, @filosofo, @florianziegler, @garyc40, @gcorne, @greuben, @hereswhatidid, @iamtakashi, @iandstewart, @imath, @Jayjdk, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @kitchin, @kovshenin, @kraftbj, @kurtpayne, @lancewillett, @landakram, @loushou, @markjaquith, @mattkeys, @mattwiebe, @mboynes, @MikeHansenMe, @mlteal, @mordauk, @morganestes, @nacin, @NikV, @nobinobi, @obenland, @ocean90, @pento, @philiparthurmoore, @realloc, @rmccue, @ryankienstra, @sakinshrestha, @SergeyBiryukov, @slobodanmanic, @TobiasBg, @tollmanz, @tywayne, @voldemortensen, @wedi, @westonruter, and @wonderboymusic for their core contributions!

    Revisions covered: [30094] to [30292]. 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.

  • Mike Schroder 6:03 am on June 19, 2014 Permalink
    Tags: ,   

    Last Week(s) in WordPress Core 

    Hi Everyone! It’s time for another update. This edition covers through Sunday, June 15th, and has taken a while due to travel, but @swissspidy & @designsimply have joined the team, helping to gather the information to bring us up to date. Hopefully this will help these updates be a bit more sustainable over time. If you’re interested in pitching in with these updates as well, please let me know in the comments below!

    Especially of note are the first pass of the grid view for the media library, several SSL and oEmbed updates, and a new ‘Beta Testing’ tab on the Plugins screen.


    • Plugins Screen: Add a new ‘Beta Testing’ tab on the plugin installation screen, for features as plugins such as Press This. [28749] #28513
    • Media Library: Grid view for the media library, first pass. This is alpha; expect imperfection to start. [28682] #24716


    • Forcing SSL logins now forces SSL for the entire admin. [28609] #10267
    • Force SSL on the frontend when the home URL uses HTTPS. [28610] #27954
    • Force SSL admin when siteurl is explicitly configured with HTTPS. [28674] #27954
    • Use a secure logged_in_cookie when the home URL is forced HTTPS. [28627] #15330
    • Deprecate url_is_accessable_via_ssl(). [28709] #19555


    Themes and Templates

    • Add a filter to human_time_diff() to allow more detailed depictions of time differences. [28670] #27271
    • Allow simple modification of sections of the title by adding a wp_title_parts filter to wp_title(). [28669] #17877
    • Add CSS rules to ensure that videos will be responsive, regardless of theme. [28650] #28414
    • Replace TEMPLATEPATH and STYLESHEETPATH with get_template_directory() and get_stylesheet_directory(). These constants are now deprecated [28563] #18298
    • Update Twenty Thirteen and Twenty Fourteen to Genericons 3.0.3. [28692] [28693]


    • Improve keyboard accessibility for the media modal. [28607] #23560
    • Add screen reader labels to the date inputs on the post editing screen. [28730] #25461


    • When parsing the main query, if s is set to empty: ?s= and $this->is_main_query() && array_key_exists( 's', $this->query ) – kill the query instead of loading the homepage. This will load the search page with no results. [28612] #11330
    • Kill queries that explicitly pass empty arrays to category__in, tag__in, tag_slug__in, and author__in to WP_Query. [28664] #28099
    • Fix SQL generation when meta_query has an 'relation' => 'OR' for its queries and wants to 'orderby' => 'meta_value'. [28659] #25538
    • Allow users to sort posts by type in WP_Query. [28605] #28214
    • Add access modifiers to WP_User_Query Add magic methods for BC: get(), set(), isset(), unset(), and call(). [28528] #27881, #22234


    • Wide-reaching changes to do away with many instances of variable-variables. See #27881 for full list of changes.
    • Eliminate use of extract() within WordPress. #22400
    • Fix curly quotes around numbers when applicable. [28721] #8775
    • Only include relevant post authors in WXR exports. [28731] #20206
    • Append the date to $wp_version in the build output, for nightly packages. [28611] #26751.
    • Update wp_insert_comment() and wp_new_comment() with a check for successful database insert. [28672] #28254
    • Use get_pages() instead of a raw SQL query in get_body_class(). [28696] #28159
    • Pre-populate the selected URL or mailto:<email-address> when “Insert/edit link” is clicked. [28705] #19992
    • Live update the menu item title when the user is editing the “Navigation Label” field. [28707] #23076
    • Deprecate get_all_category_ids(). Suggest get_terms() as a replacement. [28679] #21200
    • Deprecate like_escape() and replace with $wpdb->esc_like(). [28711] #10041
    • Redirect edit.php?post_type=attachment to upload.php to avoid an empty list table. [28729] #27951



    • Update TinyMCE to 4.0.28. [28606] #28391, #27941
    • In iOS, fix placing the caret at the bottom of longer posts when the keyboard is open and disable resizing on switching editors and on show/hide of the kitchen sink row. [28626] #28242
    • Fix problems with undo/redo after resizing an image several times. [28614] #28389
    • Fix saving the editor content on switching from Visual to Text. [28576] #28353

    Thanks to @aaroncampbell, @adamsilverstein, @alexander.rohmann, @aliso, @atimmer, @avryl, @azaozz, @boonebgorges, @bramd, @celloexpressions, @clifgriffin, @coffee2code, @danielhuesken, @DavidTheMachine, @DeBAAT, @donncha, @DrewAPicture, @eddiemoya, @edwin-at-studiojoyo.com, @ericlewis, @filosofo, @frank-klein, @Funkatronic, @garhdez, @gauravmittal1995, @gcorne, @georgestephanis, @ghost1227, @grahamarmfield, @harrym, @helen, @iamtakashi, @iljoja, @issuu, @ixkaito, @jackreichert, @JanHenkG, @Jayjdk, @jdgrimes, @jeffstieler, @jeremyfelt, @jesin, @jgadbois, @jjeaton, @jkudish, @joedolson, @johnbillion, @johnjamesjacoby, @johnzanussi, @jtsternberg, @kitchin, @knutsp, @kovshenin, @kpdesign, @kraftbj, @kurtpayne, @kwight, @lancewillett, @lessbloat, @markoheijnen, @mdbitz, @MikeHansenMe, @mikemanger, @miqrogroove, @mrmist, @MuViMoTV, @nabil_kadimi, @nacin, @nd987, @Nessworthy, @netweb, @niallkennedy, @ocean90, @obenland, @pdclark, @pento, @purzlbaum, @rclations, @redsweater, @ruudjoyo, @schoenwaldnils, @scribu, @senlin, @SergeyBiryukov, @sharonaustin, @shaunandrews, @simonwheatley, @sixhours, @slimndap, @solarissmoke, @tar.gz, @tillkruess, @topher1kenobe, @torresga, @UmeshSingla, @winterDev, @wonderboymusic, @wpsmith, @zamfeer, and @duck_ for their core contributions!

    Thanks to @swissspidy & @designsimply for their help with compiling this post.
    Revisions covered: [28528] to [28757]. 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.0.

  • Andrew Nacin 4:19 pm on July 20, 2011 Permalink

    GSoC project review chats 

    Project review IRC chats with the community start tomorrow. These will be in #wordpress-gsoc on irc.freenode.net.

    Thursday July 21, 15:00 UTC:
    Refresh Android app UI, Anirudh S. (primary mentor @danroundhill)
    Extending WP Webservices, Prasath Nadarajah (primary mentor @wanagi)

    Thursday July 21, 16:00 UTC:
    Enhanced emails, Wojtek Szutnik (primary mentor @aarondcampbell)
    learn.wordpress.org, Stas Suscov (primary mentor @johnjamesjacoby)

    Thursday July 21, 17:00 UTC:
    Document Revisions, Ben Balter (primary mentor @mitchoyoshitaka)
    Local Storage Drafts backup, Mihai Chereji (primary mentor @filosofo)

    Friday, July 22, 16:00 UTC:
    Template Versioning, David Julia (primary mentor @ocean90)
    File uploader Upgrade, Jacob Gillespie (primary mentor @dkoopersmith)

    Friday, July 22, 17:00 UTC:
    Language Packs, Marko Novakovic (primary mentor @nacin)
    WordPress Move, Mert Yazicioglu (primary mentor @developersmind)

    Monday, July 25, 16:00 UTC:
    Threaded comments, Lukasz Koprowski (primary mentor @westi)

    • Aaron D. Campbell 5:38 pm on July 21, 2011 Permalink | Log in to Reply

      Unfortunately the chat was a flop. The students were there along with mentors, but no one was there that was interested and NOT already in the loop.

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

    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.

  • Aaron Jorbin 8:22 pm on July 22, 2010 Permalink
    Tags: , ,   

    Plugin Developer Handbook Planning 

    I’ve started brainstorming ideas for the plugin developer handbook and have come up with a pretty long list of topics that I think should be covered. Some of these will be chapters on their own, some will be combined together and others still need to be thought of. For right now, the best feedback you could give me is to tell me what I missed and what you think might be out of scope.

    A couple of notes:

    • I tried to include chapters so that both novice and experienced developers will be able use it. Hence ideas such as knowing the difference between the different languages used in WordPress.
    • Some things, while listed, I think will include warnings and language that discourages it. The two that stand out to me are: Custom database tables and Custom Option Pages.

    Alright, now for the list:

    • Introduction
    • Languages of WP – Differences between PHP, HTML, CSS, JS
    • WP Coding Standards
    • Organizing plugin files
    • Planning your plugin
    • Name Spacing
    • Adding Styles and Scripts
    • Actions / Filters
      • How to use them
      • How to add them to your theme so other plugins can use them
    • Shortcodes
    • Widgets
    • Front End Forms
    • Ajax
      • Front end ajax
      • Back End ajax
    • Roles and Capabilities and users
      • Custom caps
      • User Meta
    • Comments
      • Comment Meta
      • interacting with comment filters
    • Options
      • Adding options to existing admin pages
      • Adding your own pages
    • transients
    • Translating / Internationalization
    • Custom Taxonomies
    • Custom Post Types
    • Scheduled events (pseudo-cron)
    • Activation / Removal hooks
    • Interacting with the database
      • Adding Tables / interacting with them
    • Security
      • Kses
      • Escaping
      • Capabilities check
      • Nonces – Props Eric
    • Interacting with remote URLs
      • atom / rss
    • Interacting with WP_Query
    • Media
      • Media and Post relations (Send to editor)
    • Modifying / Creating URLs
    • MultiSite specific Compatibility
    • General Tips / Tricks / Notes (Ideally a tip or two from many different devs)
    • Adding Admin Notices
    • Giving your plugin the WordPress look (Hopefully the style guide will be finished before then).
    • Pluggable Functions
    • Admin Meta Boxes
    • Dashboard Widgets
    • Extending Tiny MCE
    • A Good Development Environment
    • Development Process
    • Mike Schinkel 8:25 pm on July 22, 2010 Permalink | Log in to Reply

      Wow, that’s an incredibly good list. Kudos.

      I think that to improve that list will probably take just working on it to realize what’s missing but otherwise it’s incredible.

    • Rahul Bansal 8:30 pm on July 22, 2010 Permalink | Log in to Reply

      Such a handbook will be a real treat for plugin developers.
      Being in business, I keep hearing from developers that wordpress codex is too primitive and wordpress lacks documentation a CMS need to win enterprise userbase.
      I guess such handbook can fill that void.

    • Eric Marden 8:59 pm on July 22, 2010 Permalink | Log in to Reply

      I’d also cover functions.php. While a theme file, the techniques are largely the same.

      • Aaron Jorbin 9:22 pm on July 22, 2010 Permalink | Log in to Reply

        I think the eventual Theme dev handbook will cover that more (and will share alot of chapters/sections with this handbook)

        • Eric Marden 9:24 pm on July 22, 2010 Permalink | Log in to Reply

          I think its a topic worth touching on in Plugin Dev Handbook, but covering fully in Theme Handbook.

        • Aaron Jorbin 9:27 pm on July 22, 2010 Permalink | Log in to Reply

          How do you think it should be covered? What in do you think plugin devs need to know about theme functions.php files?

        • Mike Schinkel 9:31 pm on July 22, 2010 Permalink | Log in to Reply

          For one, functions.php is a great place to start testing out proof-of-concept functionality that may be later moved into a proper plugin. Discussing that and the process of moving from proof of concept testing to actual plugin might be helpful.

        • Aaron Jorbin 9:50 pm on July 22, 2010 Permalink | Log in to Reply

          I’ve added a section on development enviorment that could probobly cover that unless there is something else I am missing?

          I think I’m also going to add a Development Process section.

        • Mike Schinkel 9:58 pm on July 22, 2010 Permalink | Log in to Reply

          Good idea. Elaborating, it would be nice to talk about setting up a local development environment on at least Windows, Mac OS X and generic Linux.

        • Eric Marden 10:00 pm on July 22, 2010 Permalink | Log in to Reply

          I’d say that it should probably cover:

          • The differences between functions.php and plugin files.
          • What’s available and not available to you in functions.php
          • When you should use it instead of a plugin

          Then point folks to the theme dev hand book.

        • Aaron Jorbin 4:55 am on July 23, 2010 Permalink | Log in to Reply

          Eric – I think the first and the third parts would be good, I think the second is straying a bit too much into theme development and might be out of scope. This is designed to be one in a series of handbooks with the focus specifically on Plugin development. While a lot of the information within this handbook will also be in the theme developer handbook, I’d prefer it not confuse the two too much.

          Mike – That’s exactly what I meant by setting up a development environment. I imagine that section is going to be heavy on links and lighter on content though.

        • Eric Marden 2:26 pm on July 23, 2010 Permalink | Log in to Reply

          Aaron – Sounds good to me. As long as their some mention of it, and pointers to more, I think it will help people avoid confusion and concur that you get into theme land pretty quickly when using the functions.php bridge.

          Mike – I agree with Aaron here, Dev Environment, while useful, is a bit out of scope. Pointing people to some good links is best, but this topic, I feel, should only be touched on in the scope of why its a good idea, not how to make it happen.

        • Mike Schinkel 2:35 pm on July 23, 2010 Permalink | Log in to Reply

          @Eric: While not completely disagreeing I will say that the biggest “hump” I had to get over before I could finally be productive was getting a dev environment set up (I had been on Windows+ASP+IIS+SQL Server for 10+ years so LAMP/WAMP/MAMP was all foreign to me.) After I finally was able to get help getting it all set up (3+ years ago, for Drupal at the time) I was rapidly able to gain relevant skills because each step was such a small step from the one before compare with the initial setup. I’ve also taught a lot of people WordPress over the past 2 years (~100 people) in workshop environments and the most important step for almost all of them is getting the development environment set up. So given how little one can do without it compared to with it and given how big a hurdle it can be to set up I would suggest we at least consider giving it more weight than we might otherwise give it if it were not such a critical path to productivity. JMTCW.

        • Eric Marden 7:22 pm on July 23, 2010 Permalink | Log in to Reply


          While I don’t disagree that a local development environment is a huge boon to productivity and is an important topic, it starts to delve into the area of systems administration – one of the reasons I feel that a lot of new developers struggle with it, avoid it, or don’t even know they should or could have a local server. What I’m suggesting is limiting the topic to just the essentials and letting other sources deal with all of the other variables.

          In other words, it could look something like this:

          • Here’s WAMP (windows)
          • Here’s MAMP (mac)
          • Here’s apt-get (linux)
          • Here’s how to configure a VHOST to serve one WP site.

          As soon as we try to help them worry about multiple virtual hosts, the specifics of configuring Apache, managing the /etc/hosts file for overriding DNS this topic soon becomes unwieldy and given that it is not essential for you to have one to develop a plugin we shouldn’t try to create even a shadow of a full blown HOWTO on the topic.

          Trust me, I’m the guy who has stepped in on a project and wouldn’t write a single line of code until the entire team got a local dev environment installed. But if there’s one thing I know about this topic is that getting the perfect set-up is almost impossible and the way they other guy did it is always “wrong”. Do I hand compile or use a package manager? Install binary components myself and tie them together in the configuration? A virtual machine with ubuntu? Or use a prepackaged all-in-one solution? Even the level of choice in this area, as you can see, can be overwhelming on its own and we haven’t even begun to tell you which steps to follow.

          Another reason to err on the side of simplicity (and letting other sources guide the users more deeply) is that anything put in this handbook will end up generating questions on the forums, #wordpress and wp-hackers and shouldn’t we really be in the business of supporting WordPress and not their (particular) local server?

          My 2 cents,


        • Mike Schinkel 10:34 pm on July 23, 2010 Permalink | Log in to Reply

          @Eric Fair points.  

          One thing that I would personally like to see is it be _comprehensive; that would have helped me so much 2 years ago and I’d like to see others not have to go thru the same. If topics are collectively deemed as being too much of whatever then I’d argue at least that we cover the topic by curating a list of articles and solutions even if they point off WordPress.org. Then, for example, we could find a multiple VHOST article that covers concerns related to WordPress or if one can’t be found then one of us could write one on our blog and link to it. FWIW multiplier VHOSTs were one of the more difficult things to figure out yet one of the ones I cannot image being without today. Ironically it was really not difficult, I just had to learn a few arcane details. those details would make a great article.

          As for the other comment you made let me relate a story and I apologize that it is off topic for the develop handbook. Shortly after graduating college, probably 1992 I attended a presentation to entrepreneurs where the message hit home and has stuck with me for my adult like. In a nutshell the person made the point that if you have something you are “selling” (in our case we are all advocating for WordPress) then it is in your win best interest to make sure the prospective customer has as easy a time being able to acquire and use your solution as possible. If there is anything that would cause prospects to stall and go elsewhere, or simply not “purchase” at all then it is incumbent upon you to handle that problem for them or at least make the problem appear to go away.  

          So yes one can argue that we want to support WordPress only and not help people with their server setups and from a standpoint of purity you would be right. OTOH if we in fact do care about seeing a lot more people adopt WordPress then such perspective may be self-defeating. Note that the solution may not always be to “brute force” it but instead may be to divide and conquer (i.e. maybe we solve the problem by working with web hosts to minimize the problems, educate prospective users on which hosts have the least problems and then provide support for the remaining.) JMTCW.

        • Tim 10:54 pm on July 23, 2010 Permalink | Log in to Reply

          Discussion of Dev Environments, to some degree, would be good. Rather than focusing on specific environments, maybe a better way to approach this section in the handbook would be to encourage standardized ways of reporting what versions of WordPress (version number and single vs. Multi-Site testing), PHP and MySQL a plugin has been tested on. Right now, there’s a “tested up to” tag in the plugin header, but there isn’t a consistent way to report PHP/MySQL version requirements.

          Or perhaps this belongs in a new section covering “Writing a good readme file”?

        • Matt 11:07 pm on July 23, 2010 Permalink | Log in to Reply

          Small handbooks, loosely joined.

        • Aaron Jorbin 1:57 am on July 24, 2010 Permalink | Log in to Reply

          Anything more then a passing reference is going to be too much. I don’t want this devolving into a 800 page coffee table book that no one actually reads.. It’s for WordPress Plugin Development, not system administration. Perhaps there will be another book focused on that.

    • Eric Marden 9:00 pm on July 22, 2010 Permalink | Log in to Reply

      Also don’t forget to talk about nonces. Probably under security and/or options pages.

    • Denis 9:05 pm on July 22, 2010 Permalink | Log in to Reply

      I think you’re missing an important bit: the WP flow, with an outline of the hooks and when they occur, in what order, what they’re used for, etc. And most importantly, how to not interfere with other plugins on the same hook… (eg never call remove_action(myhook, myfunc) on myhook.)

      • Aaron Jorbin 9:26 pm on July 22, 2010 Permalink | Log in to Reply

        I think the API reference is going to more so cover flow. The actions section will definitely cover proper use of actions and priority.

    • Eric Marden 9:25 pm on July 22, 2010 Permalink | Log in to Reply

      Media probably covers this a bit, but overriding the javascript send_to_editor was a recent find of mine and is worth covering. I’m guessing there are other Javascript ‘hooks’ (timymce stuff?).

    • Aaron Jorbin 9:48 pm on July 22, 2010 Permalink | Log in to Reply

      Pluggable Functions
      Admin Meta Boxes
      Dashboard Widgets
      A Good Development Environment

      • Eric Marden 10:09 pm on July 22, 2010 Permalink | Log in to Reply

        • PHP Docblocks
        • Licensing and Distribution
        • Promoting your Plugin
        • Best Practices with JS/CSS (like not using !important in your CSS, etc)
        • PHP Best Practices ( i.e. Coding with E_ALL on, avoiding common Notices/Warnings)
        • SVN
        • Releasing your Plugin on WP.org
        • ReadMe.txt and plugin comment header
        • Data Import/Export
        • Migrations (WP_RELOCATE)

        Obviously we’re getting into the minutiae now, and some of this stuff can be and probably is implied by some of what’s above, but thought I’d offer them up anyway. Also some of this may be running into other hand book territory.

        Is this going to be collaboratively written, and if so where and on what platform?

        • Aaron Jorbin 4:59 am on July 23, 2010 Permalink | Log in to Reply

          I’m not sure if migrations would really fall under the purview of a plugin developer. I think that might fit better for a WordPress administrator book.

          For Import/Export, I assume you mean import/export of plugin data. Correct?

        • Ryan McCue 1:12 pm on July 23, 2010 Permalink | Log in to Reply

          Apologies for the off-topic reply, but what precisely is WP_RELOCATE? I can’t find a reference to it anywhere in code, and there’s only one reference to it on wp-hackers.

      • Eric Marden 2:33 pm on July 23, 2010 Permalink | Log in to Reply

        Ryan – sorry its RELOCATE, documented here: https://codex.wordpress.org/Changing_The_Site_URL#Relocate_method

        Aaron – You may be right. I continue to suggest things from a more holistic WP Developer mind set. Maybe we need a handbook that integrates admin, theme, and plugin from a top down approach, where these topics so far have been a bit more ground up. (small component effecting larger whole).

    • Mike Schinkel 10:01 pm on July 22, 2010 Permalink | Log in to Reply

      Floating an idea. This could turn out to be a killer book if packaged as such, and might catch interest if available at major bookstores from people who might not otherwise dig into the topic. What about coordinating with a major publisher where the proceeds go to the WordPress Foundation? Again, just an idea to consider.

      • Matt 10:44 pm on July 22, 2010 Permalink | Log in to Reply

        We can cross that bridge when we get there. I wish all of the WP books thus far had been under an OS license but most authors aren’t going to have that sort of leverage with their publisher. I had one tell me “books are hard, why would we allow anyone to take the content!” Yes, ma’am, software is hard too. 🙂

        Now we’re completely off-topic, but here’s a link everyone should read:


        • Mike Schinkel 11:12 pm on July 22, 2010 Permalink | Log in to Reply

          Yep, the idea is definitely premature but I figured it would be better to have in the back of our minds if doing so was an option. FWIW.

        • Stephen R 3:05 am on July 25, 2010 Permalink | Log in to Reply

          There’s an SVN book that is… not sure if it’s open source but they givve it away for free on the web site, or you can buy the physical book from O’Reilly. S not totally without precedent in books.

    • mercime 5:31 am on July 23, 2010 Permalink | Log in to Reply

      Plugin which create table/s in DB to add Uninstall function

      • Aaron Jorbin 11:53 am on July 23, 2010 Permalink | Log in to Reply

        That is part of the reason that people will be encouraged to use the existing data structures whenever feasible, but yes, that will be a part of custom tables.

    • João Pedro Pereira 10:21 am on July 23, 2010 Permalink | Log in to Reply

      Excelent list, Nothing to add besides TEST, TEST, TEST!

    • arena 11:39 am on July 23, 2010 Permalink | Log in to Reply

      Hi ! your list lacks structure.

      Most of the topics are related to the numerous wp api’s

      i would add the following topic
      . admin (menus, admin pages, clean coding (not loading js or css if current admin page is not related to plugin))

      • Aaron Jorbin 12:00 pm on July 23, 2010 Permalink | Log in to Reply

        Actually it does have structure, it’s an unordered list with list items that sometimes contain unordered lists 🙂

        For menus, I assume you are referring to interacting with the new nav menu items?

        Clean coding will certainly be a part of the WP coding standards and proper use of wp_enqueue_script / style (i.e. adding it to the right hook) will definitely be a part of the adding styles and scripts section.

    • filosofo 3:31 pm on July 23, 2010 Permalink | Log in to Reply

      Who is the proposed audience, and what do you see as the niche for this document in a world of grep, googling, and the Codex? It would be good to determine that before investing too much time in the wrong topics or too many details.

      Languages of WP – Differences between PHP, HTML, CSS, JS

      I don’t know the exact intended audience, but if it’s “developers” by any reasonable definition it should exclude someone who doesn’t know the difference between PHP and JS. That person needs to be doing remedial programming–maybe read Master PHP in 24 Hours or whatever—first.

      • Admin Meta Boxes
      • Dashboard Widgets
      • Extending Tiny MCE

      I suspect that’s the kind of detail that won’t do any potential audience much good. If you’re at the place that you’re ready to extend TinyMCE, you’re just going to google how to do it. If you’re new to WordPress plugin development, being blasted by a firehose of details will probably impress upon you the potential of WP, but it’s unlikely most of those details will stick. Or worse, the wrong details will stick to the detriment of more important ones.

      My suggestions: make the audience to comprise those with a reasonable knowledge of PHP, MySQL, and JS; neither beginners nor those who have an advanced knowledge of WP in particular. The former need more than you could possibly provide, and the latter don’t need your help.

      And don’t think of it as an academic course, in which someone can dedicate a semester to studying every topic. That’s not how most developers with jobs learn. Instead, pick a few truly core concepts, the ones that are necessary and sufficient to getting a typical plugin running. Then you can let code examples hint at some of the other details: they will be enough to spark interest without making the reader feel unduly burdened.

      • Eric Marden 7:31 pm on July 23, 2010 Permalink | Log in to Reply


        I think that this plugin should serve more than just beginners. Even a mention of what’s possible (by covering all of the various extension points in WP) and cross linking to the function reference in the Codex will be a huge help to all developers, beginners and advanced alike. I, for one, am a bit sick of having to grep the code base just to look up a function signature or having to trace the code to discover that there is an undocumented filter buried in the middle of one of the functions that get called – the exact filter I need to write my plugin cleanly. I kind of see this handbook as a part comprehensive overview and part getting started guide.

        However, I do agree that a discussion on the difference between various languages and technologies used in the construction of a WP plugin is unwarranted and does provide a small barrier to entry for this part of the docs. Right now all the Codex has is this: “WARNING: Programming Code Ahead!” or something like that.

        • filosofo 7:43 pm on July 23, 2010 Permalink | Log in to Reply

          I think that this plugin should serve more than just beginners. Even a mention of what’s possible (by covering all of the various extension points in WP) and cross linking to the function reference in the Codex will be a huge help to all developers, beginners and advanced alike.

          Well, I guess it really depends on what the purpose of the handbook is supposed to be (its niche). To me what you’re describing sounds more like an annotated index of the Codex, or maybe even just the Codex already. That would seemingly be only a quantitative, not qualitative change from what’s already available.

        • Aaron Jorbin 2:25 am on July 24, 2010 Permalink | Log in to Reply

          I view this as being a compliment to the API reference, but more focussed on Narrative explanations and explaining full API sections. While the API reference will tell you that register_taxonomy is used to create or modify a taxonomy object, and what arguments it takes, the handbook will explain what you can do with that taxonomy after it’s created.

          Will someone like you, who has a deep knowledge of the code turn to the handbook first? Doubtful. I imagine you’ll find what you need in the code. Might you turn to it if you have never used the HTTP api and want to get an idea of some best practices and a understanding of how you can use that in concert with Simple pie? Perhaps. Will someone building there first through fourth plugin find it useful? Absolutely.

          The reason I have the differences between languages is in part to help weed out the people that aren’t willing to learn more. I don’t view that as being as very long section. I imagine it being similar to http://aaron.jorb.in/blog/2010/01/you-better-know-the-basics/ , but better written. Then a simple: “Not scared to continue? Well onward to Victory!”

          For some of the sections (like TinyMCE editor), I actually think it might be best to keep it simple and point them to a small handfull of plugins that are doing it so that they can read some actual code. That’s open for thought though

    • jeremyclarke 4:56 pm on July 23, 2010 Permalink | Log in to Reply

      This looks great!

      It’s a small detail, but It seems to me that the “Actions/Filters” section should come before “Adding Styles and Scripts”. As far as I know, adding styles/scripts is done through the API so knowing how the API works first is probably a good investment 😉

      I’m pretty sure you would have changed it during the writing but figured I’d mention it as an excuse to tell you the list looks great and I’m excited for the result 🙂

      • Aaron Jorbin 3:55 am on July 26, 2010 Permalink | Log in to Reply

        The order above was in no way meant to imply the order the chapter would actually come in. It’s more so the order I brainstormed them in.

    • Jacob Santos 8:35 pm on July 23, 2010 Permalink | Log in to Reply

      It would be better to organize it in two or three sections.

      • Plugin System
      • How to Develop
      • WordPress Library Guides

      The Plugin System should include the introduction, what filters and actions are, how they work, how to add action and filters. Why and how they might be added to your themes and plugins.

      How to develop section should include WordPress coding standards, Subversion, WordPress Extend, adding plugins, checking out, how to work with the support and Trac Ticketing. Could also include notes on PHP docblocks, unit testing, and general ui testing.

      The WordPress Library Guides will include the large portion of the guide which would include every individual API section in WordPress and WordPress Admin.

      • Aaron Jorbin 3:59 am on July 26, 2010 Permalink | Log in to Reply

        My next step is actually to synthesize all this feedback and try to come up with a more coherent outline. What you’re proposing is pretty similiar to what I have in mind. Thanks Jacob!

    • bentrem 2:08 am on July 24, 2010 Permalink | Log in to Reply

      Are you setting up to co-author? Cuz I’ve been following DAV since *blush* a long time (see MozDawg on DAV and Docs, notes for which I started shortly after Netscape “released the code”.) Reason I ask: however slow the progress, progress there’s been. Now my first instinct was to shout out “This is a good start on a wiki page!” but I choked it back with something like, “Yaaa … yet.another dusty bit-rotted wiki page”.
      Social dynamics.
      Too bad GWave and GBuzz suck so completely when operationalized.
      p.s. I got started Analogous Techniques next month but my “army of 1” batteries are flat / dead.

    • Stephen R 3:10 am on July 25, 2010 Permalink | Log in to Reply

      I think this is a really excellent idea. Part of the problem is making sure it will be updated over time and not grow stale == a problem oftentimes in Codex.

      Something you might add: a section on “final polish” — little things like adding the “Setup” link from the Manage Plugins page straight to your settings page. There are lots of little useful touches that aren’t purely core function of the plugin, but just make it a lot nicer in the details.

      • Aaron Jorbin 4:01 am on July 26, 2010 Permalink | Log in to Reply

        That tip is one that I think would be perfect for the General Tips / Tricks / Notes section. At a later date and time I’ll solicit those.

    • Ramon Fincken 1:30 am on July 26, 2010 Permalink | Log in to Reply


      Perhaps handy:
      Scheduled events (pseudo-cron) + Ajax frontend > http://www.ramonfincken.com/permalink/topic187.html

    • Mike Schinkel 3:42 am on July 27, 2010 Permalink | Log in to Reply

      I see you have transients (Transients API?[1]) but I don’t see any reference to the Settings API[2]?

      [1] https://codex.wordpress.org/Transients_API
      [2] https://codex.wordpress.org/Settings_API

      • jeremyclarke 3:01 pm on July 28, 2010 Permalink | Log in to Reply

        I think he just didn’t refer to it as the Settings API but he has:

        * Adding options to existing admin pages
        * Adding your own pages

        I think the first one would be the Settings API. Though its a good point that the section about adding settings pages should refer to the Settings API by name so that its brand is strengthened.

    • Byron 3:34 am on July 28, 2010 Permalink | Log in to Reply

      This Handbook is badly needed. It could seriously raise the average quality of WordPress plugins (my own could have benefitted tremendously when I start out a year-and-a-half ago). If it wasn’t for Vladimir Prelovac’s plugin book, I’d still be trying to start fire with sticks. Will this be open to contributors?

    • Jeff Sayre 3:04 pm on July 28, 2010 Permalink | Log in to Reply

      Aaron –

      Have you seen my article on WordPress action and filter events (hooks)? It could be useful for part of the information in the section on this subject. I have also created a plugin developers’ tool called the WordPress Hook Sniffer plugin. I just released an updated version this morning.

    • Marjorie Roswell 1:03 pm on September 17, 2010 Permalink | Log in to Reply

      Some questions that come to mind: Where should we look for the handbook? Online? In print? When? Will the handbook be available in draft form as its being developed?

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar