Make WordPress Core

Updates from April, 2011 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 4:40 am on December 19, 2012 Permalink
    Tags: ,   

    For Wednesday, let’s plan on a 3.5.1 ticket triage meeting at 19:00 UTC (2 p.m. Eastern). Please be around if you can (#wordpress-dev of course), especially if you have something in progress for 3.5.1, so we can hammer things out and start thinking about timing.

    The dev chat is normally two hours later, at 2100 UTC. I won’t be available, and will leave that to @markjaquith and co. I expect it will be a light meeting again. 3.5.1 timing should be discussed, which should be easier with the triage session happening earlier.

     

    • Andrew Nacin 8:51 pm on December 19, 2012 Permalink | Log in to Reply

      I’m currently feeling January 2 for a 3.5.1, which gives us a few weeks to fix everything in the pipeline. We could offer a hotfix now for #22985 and #22944, which both screw with data.

      Specific 3.5.1 tickets to discuss:

      • Whether to remove wp-app.php on upgrade: #22855
      • How to handle recoverable data loss for image editing: #22985 (fairly serious and needs a plan of action)
      • Windows-based servers are going to experience a bit of an issue. Need a plan of action. #22900. cc @dd32, @kurtpayne
      • No idea what is going on with #22899 (load-scripts.php issues). Is this the source of mod_pagespeed woes? Any more ideas (from @ipstenu and @dh-shredder, particular)?
      • Status on the three TinyMCE tickets, @azaozz? #22941, #22766, #22888
      • #22895, a create_posts issue, needs investigating.

      Additional notes on remaining tickets:

      • Any media UI-related tickets are getting reviewed by koopersmith (who is traveling today), so feel free to skip those. None are serious.
      • #22883, #22944, #22858, and #22882 are all API-level (post/user) issues that seem good to go. They need unit tests.
      • I need to pow-wow with @dd32 on Twenty Twelve upgrade issues. If anyone has any other thoughts: #22856
      • I will handle $wpdb->prepare() this week. That’s #22873.

      • Mike Schroder 9:02 pm on December 19, 2012 Permalink | Log in to Reply

        I don’t suspect #22899 is the source of the mod_pagespeed issues, since encoding the brackets doesn’t solve the problem. We’re reaching out to the mod_pagespeed guys on this, and adding a temporary rule to avoid mod_pagespeed optimizing wp-admin’s JavaScript (which it arguably shouldn’t be doing anyway).

      • Robert Chapin (miqrogroove) 8:50 pm on December 21, 2012 Permalink | Log in to Reply

        #23041 needs review for 3.5.1 milestone.

    • Andrew Nacin 8:55 pm on December 19, 2012 Permalink | Log in to Reply

      And as alluded to in the previous comment, is there anything we can offer a hotfix for? This should be based on both severity and impact. Is forcing out a fix for load-scripts.php (that involves either encoding [] or chunking <script> tags) enough to fix most JS issues? If not, is there anything else we can do to avoid a lot of JS conflict/error issues people are having? Is there a common pattern in the support forums that suggest there is something we can target? etc.

  • Andrew Nacin 7:17 pm on December 18, 2012 Permalink  

    Commit Promotions 

    Jon Cave, who many of you know as duck_, is now a permanent committer, joining core developers @koopersmith and @dd32. He has been a guest committer for the last three WordPress cycles, and continues to grace all of us with great code and a sharp eye for both code review and security (he’s often found on Trac cleaning up my messes). He’s also a great guy and always willing to help. Twitter: @joncave.

    Helen Hou-Sandí, who now simply goes by helen on Trac (and in WordCamp San Francisco keynotes), is now a guest committer for WordPress 3.6! She’s a committer with a focus area — front-end dev. She’s made a tremendous impact to WordPress core over the last year, working hard on the user interface, CSS, and accessibility, and running weekly meetings in #wordpress-ui. And, her code is pitch-perfect. (See what I did there, I made a music joke, since she’s also a collaborative pianist who studied at the Eastman School.) Twitter: @helenhousandi.

    Congrats, both of you.

     

  • Andrew Nacin 5:12 pm on September 20, 2012 Permalink
    Tags: , ,   

    Timeline for Twenty Twelve 1.0 — final testing window 

    During the dev chat yesterday (logs), it was determined that the timeline for Twenty Twelve’s release to the WordPress.org theme directory will be next week.

    That means if you have any bugs to report against Twenty Twelve, please do so now! It’s time for final reviews. Once 1.0 is released, it will be very tough for us to make style or code changes, as we will then need to avoid breaking child themes (both code wise, and stylistically).

    So, if you haven’t looked at Twenty Twelve yet, now’s the time. Here’s the demo site: http://twentytwelvedemo.wordpress.com. Also, if you’re using the Beta Tester plugin instead of a checkout from Subversion, you may not have Twenty Twelve installed and up to date. In that case, here’s a direct link to download a ZIP.

    (@westi, @dd32, we should adjust how beta theme installs are handled…)

     

  • Jen Mylo 10:53 pm on December 18, 2011 Permalink
    Tags: ,   

    Core Team Meetup Recap – Part II 

    Picking up where we left off….

    Friday

    We kicked off Friday with a discussion about the high-level roadmap for 2012. Using our earlier talk about process and scope, we identified areas/userflows that we could use to focus a release. Areas of interest included changing themes/customizing your site, uploading a bunch of photos, interacting with audience/feedback loop. (There were more, but let’s face it, there are too many things we’d like to improve to do them all at once.)

    We all donned WordPress gear so that people would recognize us at the happy hour later.

    Dion

    Dion (dd32) modeling the latest swag

    Dion and Andrew

    Dion and Andrew Ozz before lunch

    Lunch: Went to The Sentient Bean in Savannah.

    The Sentient Bean

    The Sentient Bean

    Back patio at the Sentient Bean

    Back patio at the Sentient Bean

    Koop and Mark, Dion and Ozz in the background

    Koop and Mark, Dion and Ozz in the background

    Next we went to ThincSavannah, my coworking space in downtown Savannah. We did the livestreamed Town Hall/Q&A (recording coming soon), answering questions from that forum thread I put up last week and a few that came in live from IRC.

    Core team town hall video screen cap

    Core team town hall

    After that was happy hour at Jazz’d. Only two people came to hang out with us (and to think we dressed up especially!), but they were two great people, so we were fine. Some drinks and appetizers later, we departed for WordPress on Ice, in which we went ice skating at the Civic Center.

    Nacin and Koop on skates

    Nacin and Koop on skates

    Nacin, Mark, Jane, Matt, Jon, Daryl

    WordPress on Ice! Nacin, Mark, Jane, Matt, Jon, Daryl

    Then a stop at Huc-a-Poo’s, then home.

    Saturday

    We spent the morning talking about mobile apps and their place in the WordPress ecosystem, as well as making the dashboard a better experience when viewed in a mobile browser.

    Lunch: Went to AJ’s and ate on the deck. Continued talking about mobile. This eventually morphed a bit into a discussion about the lines between .org/.com.

    Core team at lunch at AJ's Dockside

    Core team at lunch at AJ's Dockside

    After lunch we talked about the default theme for 2012, including what it should do/be that our current themes don’t already accomplish, and the process for its creation. Breakouts followed. One was focused on multisite, while the other was focused on hosting/diagnostics/health check. We tested doing a Google Hangout with screensharing as a way to collaborate more effectively throughout the year, and agreed we would try to do them once a month. For dinner we got takeout BBQ from Gerald’s Pig & Shrimp. We pretended @ryan was with us by playing a video of him from last year’s meetup. Afterward, Koop gave a primer on JavaScript.

    Sunday

    When we started this morning, we tried to at least quickly hit the things we hadn’t gotten to yet, since today was the last day. These included: Google stuff, core plugins, how leadership in core does/does not translate to leadership of the whole project, wordpress.org site, pairs (creating process to make collaborative/non-solo development the norm), and CMS stuff.

    Since a lot of us were pretty interested in making the theme customization process a focus of the next release, we starting identifying what the chunks of that might look like under the new process and with people working in pairs/teams. We continued talking about this over brunch at the Tybee Island Social Club, where @nacin and @dkoopersmith drank bacon bloody marys.

    Bacon Bloody Mary

    Bacon Bloody Mary

    Nacin attempting to consume a bacon bloody mary

    Should Nacin eat the bacon or drink the bloody mary? He can't decide.

    After brunch, @markjaquith and @dd32 left for the airport, and @joncave and @azaozz left two hours later. Bye bye, core team!

    Now we begin a 2nd mini meetup. Matt, Nacin, Koop, and I are staying, and have been joined by @otto42 and @chexee. The next couple of days we’ll be doing some planning and starting projects to make visiting wordpress.org a better, more useful experience. Â Tonight, though, everyone is catching up on some individual work after a week of long days.

    We’ll post summaries of the specific core meetup discussions over the coming week.

     

    • Michael Beckwith (@tw2113) 11:26 pm on December 18, 2011 Permalink | Log in to Reply

      Very curious to see how the focus on theme customization process turns out, and maybe I can jump in and help a bit with that as it’s one areas I love focusing on.

    • Andrew Nacin 12:12 am on December 19, 2011 Permalink | Log in to Reply

      Worth nothing a few things:

      First and foremost, that bacon bloody mary was good. Really good. Who cares how you consume it.

      Second, please don’t interpret the lack of a mention of any peculiar topic to mean it wasn’t discussed — only that only so much can fit in one of these posts. For the developers, we had some discussions on security practices and procedures, unit testing, and core architecture (and planning for the future). The word “multisite” escapes with a single mention, but in that meeting we came away with a number of immediate action items, as well as a potential roadmap for the next year. And if you didn’t catch the livestream, you may have also missed that we’ve committed to a JSON API in core to go alongside RSS.

      This was just the day-to-day play-by-play. There’s a lot more we need to write up. Woo.

    • David Johnson 2:46 am on December 19, 2011 Permalink | Log in to Reply

      Thanks for the recap write-up!

      Any word about backup/restore/migration issues within the WordPress core? It seems like basic security and backup should be in the core installation..but maybe I’m missing something.

      Thank you WordPress core team for allowing the community to be involved and aware of the goings on within WordPress.

      • Jane Wells 2:24 am on December 20, 2011 Permalink | Log in to Reply

        Security is definitely something that was talked about, but a backup utility is more suited to a plugin than core (though we did discuss the possibility of a core/canonical plugin for backups).

    • Adam W. Warner 2:34 pm on December 19, 2011 Permalink | Log in to Reply

      It’s great to get an “insider” view of your meetup, so thanks, the community appreciates it and all the work you all do to make the World a more open and accessible place for many to have their voices heard.

      Also, @Nacin, thanks for the additional mention of Multisite. I’m an avid user and am pleased there will be some additional focus.

    • Lance Willett 3:00 pm on December 19, 2011 Permalink | Log in to Reply

      Great job with all these newsy updates, Jane. Kudos.

    • mitcho (Michael 芳貴 Erlewine) 3:07 am on December 22, 2011 Permalink | Log in to Reply

      Wait, is the “Nacin and Koop on skates” photo the answer to my request!?

      Here was the original ticket:
      https://twitter.com/#!/themitcho/status/147901791776935937
      :D :D :D

    • havahula 3:51 am on December 23, 2011 Permalink | Log in to Reply

      ok. i’ll bite. where does one get those fancy, baby blue track jackets Dion, Ozz and Matt are wearing? and did Nacin have one too before he drank the bacon bloody mary, which turned his brown?

  • Andrew Nacin 5:06 pm on November 9, 2011 Permalink
    Tags: ,   

    Weekly project meeting changed to 21:00 UTC starting Nov. 16 

    Normally the timing of the weekly project meeting IRC chat will not change with daylight savings changes, as it is anchored to 16:00 UTC. However, it also becomes an opportune time to adjust the time to better fit schedules for the core team and our most active contributors.

    We’re going return to 21:00 UTC time. This is morning in Australia, afternoon in the U.S., late evening in the U.K. It will be nice to see @dd32 at our chats again. :-)

    Today we’ll meet at 17:00 (now) and we’ll start with 21:00 next week.

    A number of us are doing daily bug scrubs (triage sessions) and 3.3 status checks (typically spontaneous and generally occurring in the U.S. afternoon), so we’ll see you around!

     

  • Jen Mylo 4:17 pm on August 17, 2011 Permalink
    Tags: , ,   

    Commit This 

    It is with great pleasure (not to mention optimism, satisfaction, and many other adjectives) that I officially announce the addition of Jon Cave (aka duck_, or said aloud as “duck undah”) to the WordPress version 3.3 commit team. Duck’s consistently good code, communication skills, eye for security, and tireless efforts made it a natural choice to give him a more official role with this release cycle. Also, @ryan is just sick of having to commit his patches. :)

    duck_ joins permanent committers @nacin, @dd32, Nikolay, and Joseph Scott, as well as @dkoopersmith, whose 3.2 commit stint has been re-upped.

    Congrats, you deserve it!

    Jon Cave aka "duck_" at WordCamp SF 2011 — photo by Mark Jaquith

     

  • Jen Mylo 6:13 pm on May 5, 2011 Permalink
    Tags: , , meeting summary   

    Dev Chat Summary – May 4, 2011 

    We have passed feature freeze, and are now in UI week, leading up to a beta date of May 11. This week’s dev chat checked in on all the things we originally targeted for 3.2.

    • Drop PHP4 compat: This is done, but there are 1 or 2 places we went a little too far and need to revert to not break things.
    • Distraction-free Writing (dfw): Backend is ready. Need to change the buttons used for HTML actions, provide support for escape key, support theme styles, and fine-tune transition times. @azaozz owns this one.
    • List tables API improvements: Not happening for 3.2. Westi’s basic summary of findings: More actions/filters/standardization and don’t support subclassing as an override method. Will try to get to this in 3.3.
    • Twenty Eleven (new default theme): Mostly finished, needs editor style support added.
    • IE6 EOL: Most agreed with @aarondcampbell’s suggestion for the nag — IE < 8 could say "you're insecure" and anything < most recent could say "your browser is outdated" @aarondcampbell will write patch, with confer with nacin about recent api work.
    • Speed improvements: There are lots and lots of speed improvements under the hood. Ryan has done time testing to prove it. If we have release video, Mark J suggested doing side by side view to show the difference. Nacin looked into PHP lazy loading, said it would not bring much improvement, so skipping it.
    • Partial core upgrades: work begun by @dd32, being finished by @nacin. Says nothing needs to be done in core, just on .org side re generating appropriate zips.
    • Style update: @dkoopersmith got first patch into trunk yesterday, had a large chunk of the update in it. Getting the rest in now, and then we’ll do a sweep to see what needs fixing/adding. Asking people to hold off on design feedback/requests/details until we’re ready, to avoid lots of trac messages about details that are already being added, just haven’t been committed yet. Should be there in a day.
    • Trac tickets: feature requests and enhancements mostly getting punted since past feature freeze. If there’s a bug you really wanted fixed, then get in there and find more people to test the patches on the ticket. Tickets withut patches will be punted.
    • Remainder of UI week will be dedicated to finishing the style update, and hitting small UI tickets that weren’t urgent/important enough to take attention away from core functionality, but that just make things a little bit nicer (it’s embarrassing that there are still things we put in during 2.7 that we said we’d clean up in 2.8 and then never got around to).
     

    • Aaron D. Campbell 6:22 pm on May 5, 2011 Permalink | Log in to Reply

      I opened a ticket for the out of date browser nag (#17323). There’s a patch there, but you can’t test it since the API it’s supposed to work with doesn’t exist yet.

    • arena 11:34 pm on May 5, 2011 Permalink | Log in to Reply

      date_i18n bug #17278 patch is ok for me

      would like to have a feedback on #17334

      keep up the good work

    • KranzKrone 2:43 pm on May 6, 2011 Permalink | Log in to Reply

      Sounds good, so far.

      I still hope that you make WordPress more faster, and Update the P2 Theme. Maybe give them a bit more features or maybe some Child Themes? ;)

      • Jane Wells 3:16 pm on May 6, 2011 Permalink | Log in to Reply

        As noted in the summary, WordPress has been made significantly faster. P2 is not developed by the WordPress open source project, it is developed by Automattic. If you want to request features you should contact them or leave a post in the themes forum. As for child themes, anyone can make one; if there are features you’d like to see in P2, why not just make a child theme of it yourself that does what you need?

  • Jen Mylo 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.

     

  • Jen Mylo 12:21 am on April 10, 2011 Permalink
    Tags: ,   

    Agenda for April 13 Dev Chat 

    • 3.2 check-in
    • GSoC update

    Sometimes not everyone is able to get to the dev chat due to time zones, work schedules, nap time, etc, so I think it would be useful to do a pre-meeting run-through of what we’ll cover. If any of these things apply to you (you’re working on it) and you won’t be at the dev chat, please leave a comment here before the meeting so we’ll know the status.

    3.2 check-in

    Freeze is 3 weeks from today, so if anyone has been putting off work on their assignments, now’s the time to get cracking. Quoting from Mark’s scope post for reference:

    people stay on target and making sure we don’t try to slip “one more thing†in.

    Just remember, if we stay on schedule (or better, get ahead of it), then the next release cycle will be here before you know it. No slipping things in.

    List Tables API improvements (Westi and Koop) — finalize the API for third party use and more flexibility.
    List Table XHR loading — to be investigated only after List Table API has stabilized. Make sure it’s worth it before we burn time on it.

    @westi said last week that he needed to “sit down and summarise the changes I think we should make to make it more extensible and start on them.” Progress report?

    PHP 5.2 (5.2.4, specifically) to be required. Drop compat. But don’t go adding a bunch of PHP5 stuff. This release is about dropping the old, not adding the new. More red than green.
    MySQL 5 to be required. This quite literally involves no work beyond changing the requirements. Do not change queries.

    @ryan: I think you were talking about starting on this before getting pulled onto some other stuff last week. Is this still something you’re handling?

    IE6 EOL for the admin. If BrowseHappy is updated in time, we can consider adding a “use a real browser†nag for IE6 users. We probably can’t drop much CSS, as IE7 shares a lot of the issues. This is mostly symbolic, and reduces the platform combos we need to test. This also means any security issues that are shown to only affect IE6 only can be lowered in priority.

    Who owns this?

    Distraction Free Writing. This is our headline “ooh, shiny†user feature. Replace our current fullscreen implementation with something more beautiful, more useful (in terms of line-length and font size), and simpler (only limited RTE functionality). Look at WriteRoom, OmmWriter, http://www.quietwrite.com/ for inspiration. Koop is investigating this, and may crank out a quick plugin to jump-start development efforts.

    @azaozz and @dkoopersmith were working on this, but I haven’t seen a plugin yet. Status?

    Upgrade improvements. Changed-files-only upgrades can be done with zero changes to core. For the first effort, let’s just do updates to the latest point-point from within the same major version. So, 3.2 to 3.2.2 and 3.2.1 to 3.2.2. Optionally consider scanning for changed core files and offering them a full upgrade to overwrite those changed files. Skip the wp-contents directory when upgrading (no more upgrading the default theme or bundled plugins).

    @dd32: Status?

    Speed improvements. There are a bunch of little things we can do to make WordPress load or at least “feel†faster. Nacin is looking at PHP lazy loading. He also is working on a patch to make the admin menu load faster by doing the expansion in PHP.

    Second one is in, first one is not, according to @nacin.

    Speed improvements. We can make the dashboard faster by not doing async requests for panes if the cache is hot.

    Who’s on this?

    Speed improvements. Dion has some FTP improvements that should make upgrades a lot faster for people using a certain FTP server.

    @dd32: update?

    Speed improvements. Everyone can get involved here. Pick sometime small and manageable that will make WordPress a little faster. Together, they’ll add up to a bullet point in the release post.

    Anyone working on any patches that fall under this category? Let’s get them on the list.

    Not on the original post by Mark, but being actively pursued:

    • Low-hanging XML-RPC tickets by @josephscott. Needed to go through them and identify likely candidates. Joseph: any update?
    • TinyMCE update being added to trunk by @azaozz, autop also needs an update. @azaozz asked for help with writing tests for autop. @azaozz: any update?

    GSoC

    By the time of the dev chat, all mentors should have rated/commented on all the student applications and come up with their list of the projects/students they would be willing to mentor. If we have more selected projects than we are likely to have slots, we can discuss the potential projects to see how much community interest there is in each idea. Note that we would have this discussion about projects, not students.

     

    • Andrew Nacin 12:38 am on April 10, 2011 Permalink | Log in to Reply

      I’ll be looking into PHP lazy loading this week. Browse Happy will be me as well.

      Mark started on the dashboard widgets with a patch. I’ll return to that this week, and collaborate with Mark on it. We had differing takes on the implementation, I think.

    • scribu 12:42 am on April 10, 2011 Permalink | Log in to Reply

      Speed improvements:

      • Taxonomy AND SQL performance: #16706 (tested and patches good to go)
      • General WP_Query SQL performance: #10964 (latest patch needs testing)

      meta query API improvements that should have been in 3.1:

      • meta_value = 0: #15292 (patch + tests ready)
      • ‘relation’ arg: #17011 (needs patch)

    • scribu 2:16 pm on April 10, 2011 Permalink | Log in to Reply

      More speed improvements, this time to the rewrite engine:

      • %postname% permalinks #16687 (needs-patch)
      • make better use of stubs #9824 (has-patch)

    • WraithKenny 2:35 pm on April 11, 2011 Permalink | Log in to Reply

      I’m willing to help on testing TinyMCE and autop (tab switching). I’ve got a Javascript guy in the office who expressed interest in helping also.

      • Andrew Ozz 9:55 pm on April 12, 2011 Permalink | Log in to Reply

        Great. Made a general ticket #17105 for reporting HTML 5.0 issues with the editors and autop.

        TinyMCE is set to keep all new tags although many of them do not display properly in the iframe (this is browser dependent and should improve as the browsers support more and more HTML 5).

        Autop has some known problems (rarely seen) with block tags that contain other block tags but apart from these all new tags should work well. What we need most seem to be more auto-tests for autop.

  • Andrew Ozz 8:10 pm on April 4, 2011 Permalink
    Tags:   

    To the Directors of White Space 

    Dear Sirs,

    It has come to my attention that our White Space is running wild. Would it be possible to tame that beast back into submission please.

    Seriously, I would like to propose adding another rule to the coding standards: when outputting HTML directly, leave all white space in PHP. Currently we do something like this:

    if ( something ) {
    ?>
    <div id=...>some more</div>
    <div id=...>even more</div>
    <?php
}

    That’s all nicely readable on the PHP side but the outputted HTML is surrounded by quite a bit of redundant space. What I’m proposing is to stop/start PHP immediately around the HTML:

    if ( something ) {
    ?><div id=...>some more</div><?php
    ?><div id=...>even more</div><?php
}

    This doesn’t impact the readability on the PHP side and produces “tight” HTML with no white spaces as it should be for production. In fact the HTML source would be “pseudo-minified”.

    Of course the readability of the HTML source will be affected but not that much. Currently our HTML output is all over the place which makes it pretty hard to read. Considering that most people never look at the HTML source directly any more thanks to FIrebug and friends and all coding oriented text editors have a function to reformat HTML, I believe outputting “minified” HTML is an advantage. This also reduces the size of our output from 3% to 15% depending on the page.

    Of course I’m not proposing for everybody to rush and reformat the whole codebase if this is accepted. But we can apply it to new code and clean up functions that are being patched for other reasons.

     

    • Ken 8:20 pm on April 4, 2011 Permalink | Log in to Reply

      This would be fine with me, I also use firebug when examining html.

    • Joseph Scott 8:25 pm on April 4, 2011 Permalink | Log in to Reply

      Wouldn’t it be better to optimize for the code that is read more often (PHP)? For HTML there are plenty of options to minify automatically if you want to go that route.

      • Alex M. 8:44 pm on April 4, 2011 Permalink | Log in to Reply

        This is my thoughts as well. While pretty HTML is nice, pretty PHP should be the priority IMO. Stepping into PHP just to step right back out again on the next line seems like a waste and makes it a lot harder to read.

        As for size, if that’s a concern then gzip should be used.

      • Andrew Ozz 8:55 pm on April 4, 2011 Permalink | Log in to Reply

        Yes, we can minify the HTML automatically but that’s just another (although minimal) overhead. IMHO if we leave all white space in PHP we are optimizing both at the same time.

        Our code is already pretty much optimized for readability on the PHP side. If we accept this as coding standard, it would enhance the PHP side a bit (as we won’t have to think about HTML output formatting at all and can place it anywhere we need) and also enhance the HTML output a lot.

      • Andy Skelton 9:07 pm on April 4, 2011 Permalink | Log in to Reply

        I agree with Joseph. I spend so little time looking at the HTML output that I couldn’t care less what whitespace there is. When I’m looking at PHP, I don’t want to have to look at the beginning and end of every line. That’s even worse than reading a long column of echoes.

      • Andrew Nacin 11:17 pm on April 4, 2011 Permalink | Log in to Reply

        I agree with Joseph and Andy as well.

      • Brian Layman 2:28 pm on April 6, 2011 Permalink | Log in to Reply

        I’m in this camp too.

        Plus this may appear moderately readable with two lines but once you get into more it doesn’t hold up nearly as well. I’d rather be consistent in our handling and also save 7 bytes per line of code.

    • Jon Brown 8:36 pm on April 4, 2011 Permalink | Log in to Reply

      Isn’t what you’re proposing the opposite of the existing coding standards which are to open/close php around the actual PHP? More like:

      if ( something ) { ?&gt;
     &lt;div id=...&gt;some more&lt;/div&gt;
     &lt;div id=...&gt;even more&lt;/div&gt;
&lt;?php }

      Which is compact and doesn’t needlessly open and close php (although I’m pretty sure that’s been shown not to be a performance issue, right?)

      • Ramoonus 12:33 pm on April 5, 2011 Permalink | Log in to Reply

        this is what I prefer, much easier to read
        and most programs can do color coding with this format

    • Mike Schinkel 8:50 pm on April 4, 2011 Permalink | Log in to Reply

      Here’s a question I don’t know the answer to: Is there any performance penalty for excessive context switches between PHP and HTML? Also, rather than context switching, why not use HEREDOCs instead?

      • Andrew Ozz 8:59 pm on April 4, 2011 Permalink | Log in to Reply

        As far as I can tell, no. No performance penalty for switching in and out of PHP at all. IMHO HEREDOC is quite hard to read and is inflexible in many cases.

    • scribu 9:06 pm on April 4, 2011 Permalink | Log in to Reply

      We should avoid context switches, not for site performance, but for developer performance, as Joseph Scott already mentioned.

      Adding more characters to reduce whitespace doesn’t seem like a sweet deal to me. A standard in this area would be good, but not that one.

      How about:

      if ( something ) {
?&gt;
    &lt;div id=...&gt;
        &lt;p&gt;lines&lt;/p&gt;
    &lt;/div&gt;
    &lt;div id=...&gt;&lt;?php inline_call(); ?&gt;&lt;/div&gt;
&lt;?php
}

      Multi-line blocks should never be indented.

      • Alex M. 9:09 pm on April 4, 2011 Permalink | Log in to Reply

        This is how I write and prefer code.

      • Andy Skelton 9:12 pm on April 4, 2011 Permalink | Log in to Reply

        I recently banished all thoughts of pretty HTML and decided to focus on PHP indentation. So I indent the PHP tags. Here’s my example:

        if ( $lines ) {
    ?&gt;
    &lt;div id=&quot;lines&quot;&gt;
    &lt;?php
    foreach ( $lines as $line ) {
        ?&gt;
        &lt;p class=&quot;line&quot;&gt;&lt;/p&gt;
        &lt;?php
    }
    ?&gt;
    &lt;/div&gt;
    &lt;?php
}

    • Ken 9:09 pm on April 4, 2011 Permalink | Log in to Reply

      Alternatively, we can recommend NOT using indents for html blocks, but rather line-breaks and comments:

                  if ( something ) { ?&gt;

&lt;!-- #someid --&gt;
&lt;div id=&quot;someid&quot;&gt;some more&lt;/div&gt;
&lt;div id=...&gt;even more&lt;/div&gt;
&lt;!-- /#someid --&gt;

            php }

      I’d just be happy with any standard.

      • Brian Layman 2:30 pm on April 6, 2011 Permalink | Log in to Reply

        I imagine my preferred standard of making the HTML indented to the correct level when the HTML source is viewed would be generally hated by all :)

    • miqrogroove 9:24 pm on April 4, 2011 Permalink | Log in to Reply

      The only time this white space has ever mattered to me is when dealing with textarea elements, which have a required trailing linefeed. At any other time, I would prefer the former syntax for simplicity and let the HTML look slightly out of alignment. I would never try to minify my HTML.

      • Ken 9:30 pm on April 4, 2011 Permalink | Log in to Reply

        There was a trac ticket a while back about white space between Nav LIs that caused styling issues… He was setting the menu items to display: inline. That and your textareas are the only things I can think of.

    • demetris 10:12 pm on April 4, 2011 Permalink | Log in to Reply

      I think the gain in size is not worth it because, when the document is gzipped, the reduction in percentage is much smaller: 2 or 3 percent at most. (Which, in absolute numbers, is an even smaller gain.)

      My personal preference at present is to always stay in PHP mode. I use echoes with a line feed at the end of the string. So, the only white space in the generated HTML is line feeds. (One reason I started using this style is that HTML highlighting with a PHP document distracts me.)

      • Andrew Ozz 10:33 pm on April 4, 2011 Permalink | Log in to Reply

        Agreed. Assuming that most hosting companies gzip HTML by default the gain will be even smaller: about 0.1% and under as white space compresses extremely well.

      • Jan Fabry 6:47 am on April 5, 2011 Permalink | Log in to Reply

        Indeed, I also prefer to stay in PHP mode. With this proposal the difference will be even smaller, so if there would be a change, I propose it is to PHP-with-echo everywhere.

    • arena 10:59 pm on April 4, 2011 Permalink | Log in to Reply

      ok for me and please please remove the trailing and useless ?> in most wordpress php files

      • Peter Westwood 7:15 am on April 5, 2011 Permalink | Log in to Reply

        It’s not useless – it is good practice in my opinion and makes it easier to identify when people have uploaded part of a file by FTP

        • Mike Schinkel 7:21 am on April 5, 2011 Permalink | Log in to Reply

          I’ve seen whitespace after a trailing ?> cause syntax errors. I’ve never seen those same syntax errors occur when there is not a trailing ?>. FWIW.

        • Peter Westwood 7:24 am on April 5, 2011 Permalink | Log in to Reply

          Syntax errors seems unlikely, Headers already sent is probably what you saw.

        • Mike Schinkel 7:28 am on April 5, 2011 Permalink | Log in to Reply

          Possibly. Either way it was a fiddly error that can take a while for many people to track down. Again, FWIW.

        • Dion Hulse (dd32) 8:50 am on April 5, 2011 Permalink | Log in to Reply

          Mike: Thats the exact reason why user editable files in WordPress don’t have the closing php marker (wp-config-sample.php and themes functions.php)

          But for all other files, no user should edit them, so its a useless argument there

        • Mike Schinkel 8:57 am on April 5, 2011 Permalink | Log in to Reply

          @dd32 – Although it’s not worth debating as an attempt to change the opinions of the core team related to the source files in WordPress, as a point of note it is not completely useless.

          People accidentally modify files all the time. If they open a core file to learn what it does but accidentally add white space to the end they can spend quite a bit of time trying to figure out why their site code now fails although they can’t “see” any difference.

          Again, FWIW.

    • arena 11:28 am on April 5, 2011 Permalink | Log in to Reply

      @peter
      having or not having a ?> at the end of a file do not mean you have reached the end of the file ….
      then change the
      trailing ?>
      by
      /* end of file */

    • John James Jacoby 1:22 am on April 12, 2011 Permalink | Log in to Reply

      I’m against the grain with everyone here. Go figure. :)

      I think having pretty HTML output is important, because scanning through randomly indented HTML output is as irritating as scanning through randomly indented PHP. Call me old school, but I miss the days of having poetically formatted HTML when viewing HTML source on a site. :)

      I also prefer not to echo out HTML from inside PHP, and rather close out of PHP and output raw HTML. PHP is a scripting language that essentially provides logic to HTML. Using it to output complete lines or blocks of HTML seems counter-intuitive to me, so it’s reserved in my toolbox for special cases where I may want to filter that chunk of HTML through a WordPress filter.

      This was one of my original kvetches about WordPress when I stopped lurking and started posting in the support forums. (Embarrassing reading my tone back then as an outsider to the community.)

      The problem arrises from having tabs in front of the PHP open brace. It’s good for PHP code readability, but bad for HTML output readability.

      This example taken from index.php of twentyten:

      &lt;?php get_header(); ?&gt;

		&lt;div id=&quot;container&quot;&gt;
			&lt;div id=&quot;content&quot; role=&quot;main&quot;&gt;

			&lt;?php
			/* Run the loop to output the posts.
			 * If you want to overload this in a child theme then include a file
			 * called loop-index.php and that will be used instead.
			 */
			 get_template_part( 'loop', 'index' );
			?&gt;
			&lt;/div&gt;&lt;!-- #content --&gt;
		&lt;/div&gt;&lt;!-- #container --&gt;

&lt;?php get_sidebar(); ?&gt;
&lt;?php get_footer(); ?&gt;

      …should really be…

      &lt;?php get_header(); ?&gt;

		&lt;div id=&quot;container&quot;&gt;
			&lt;div id=&quot;content&quot; role=&quot;main&quot;&gt;

&lt;?php
			/* Run the loop to output the posts.
			 * If you want to overload this in a child theme then include a file
			 * called loop-index.php and that will be used instead.
			 */
			get_template_part( 'loop', 'index' );
?&gt;

			&lt;/div&gt;&lt;!-- #content --&gt;
		&lt;/div&gt;&lt;!-- #container --&gt;

&lt;?php get_sidebar(); ?&gt;
&lt;?php get_footer(); ?&gt;

      The differences being the whitespace before the opening and closing PHP braces is gone, and there is an additional empty line before and after the context switch to ensure the output of get_template_part() has breathing room. In the above example, the next problem is that loop.php starts out only indented 1 tab in, rather than 4, which starts the cycle of messy HTML whitespace over again.

    • John James Jacoby 1:35 am on April 12, 2011 Permalink | Log in to Reply

      Maybe we should write a plugin to format the HTML output for us?

      http://gdatatips.blogspot.com/2008/11/xml-php-pretty-printer.html

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