Updates from Peter Westwood RSS Toggle Comment Threads | Keyboard Shortcuts

  • Peter Westwood 9:44 am on February 11, 2012 Permalink | Reply
    Tags:   

    Team Update: XML-RPC (Friday)

    We finished our first cycle last week and the implementation of the CRUD functions for Posts (and all Custom Post Types) has been committed to trunk see #18429 for more info.

    For our second cycle we decided to focus on CRUD for Taxonomies and Terms taking the patches from GSOC and iterating on them we are using #18438 as the tracker ticker for a single patch to cover all the different methods.

    We also decides to put more focus and effort into unit testing this cycle and have started creating some XML-RPC test case for existing/new functionality.

    Relevant Tickets: #18438, #18439, #18440, #18441, #18442, #18443, and #18444

    Office hours: 5pm-6pm UTC Mon-Fri

     

    • Ahmad Awais 1:31 pm on February 12, 2012 Permalink | Reply

      WordPress is taking part in GSoc 2012 ? If so , i am good in PHP , how can i join WordPress as a student for GSOC 2012.Guide me what can i do.I have 2 or 3 simple plugins written for WordPress by myself.
      Any help will be appreciated.

      • Aaron D. Campbell 4:26 pm on February 14, 2012 Permalink | Reply

        He’s talking about GSoC code from last year, but yes I think the plan is to participate again. There will be plenty more info on how to apply as the time gets closer (probably after WordPress is officially accepted to participate).
        If you’re looking for ways to increase your chances of getting chosen, I’d recommend trying to tackle some tickets on Trac (http://core.trac.wordpress.org/) so that you can point us to tickets that you’ve worked on. It’s a great way to show your coding chops and also get a feel for how the project/community works.

        • Ahmad Awais 4:45 pm on February 14, 2012 Permalink

          Thankx for your kind and informative reply , can tell me in tackling the tickets how cna i find help ? any tutorials available except codex and let me know how to adhere to the basic features of trac … how to use it , how to provide a patch how to test etc

  • Peter Westwood 7:49 pm on February 4, 2012 Permalink | Reply
    Tags:   

    Team Update: XML-RPC (Friday)

    We made great progress this week continuing our focus on the major ticket for implementing wp.newPost (#18429) and working to keep the other bits of this API supporting the same formats. Our 2 week cycle ended on Friday and we are really close to having a patch ready for commit but didn’t quite make it in time. The team are continuing work on the patch and will re-group on Monday to review progress and plan the next cycle.

    Relevant Tickets: #18429, #18430, #18431, #18432, #18433
    Office hours: 5pm-6pm UTC Mon-Fri

     

  • Peter Westwood 10:49 am on January 28, 2012 Permalink | Reply
    Tags: ,   

    Team Update: XML-RPC (Friday)

    The XML-RPC team is working on the implementation of an wp namespaced api for XML-RPC to allow the Creation, Read, Update and Delete of Posts/Pages or any CPT. We are focusing on a tight integration in naming and behaviour with the core WordPress apis and avoiding strict one to one backwards compatibility with the older MetaWeblog/Blogger post creation apis so as to create a simpler more consistent api.

    Relevant Tickets: #18419, #18430, #18431, #18432, #18433

    Some of the tickets have existing patches we are happy with and some we are reworking, our primary focus for the first week has been implementing wp.newPost (#18429) and reviewing the other tickets. Once the implementation for wp.newPost is complete the other APIs should come together quickly.

    Office Hours: TBD – I will post these once we have them

     

    • Peter Westwood 2:53 pm on January 28, 2012 Permalink | Reply

      We are going to try “Office Hours” of 5PM-6PM UTC every weekday so as to keep in touch and be available for questions – at least one of us will be there with more than one of us most days.

    • Prasath Nadarajah 4:53 pm on January 29, 2012 Permalink | Reply

      I think #18443, #18444 should also be added to use these functions.

      Why we are not concentrating on custom taxonomy management in this release. Without that we will be limited to the terms already in the site.?

      • Peter Westwood 8:56 am on January 30, 2012 Permalink | Reply

        Those tickets are definitely ones we will consider for our next 2 week iteration but for the first iteration we are concentrating on the Create, Read, Updated, Delete for “Posts”. We are looking at simple term management as part of the Create/Update APIs to see if we can include a simple create on set mechanism there as well as looking at more fully featured APIs later.

  • Peter Westwood 3:43 pm on November 3, 2010 Permalink | Reply
    Tags: intertrac,   

    I have had InterTrac linking enabled from the Core trac to a few others and back the other way (previously the core trac had a minimal configuration).

    You can now refer to changesets and tickets in related tracs as follows:

     

  • Peter Westwood 9:18 am on November 2, 2010 Permalink | Reply
    Tags:   

    I added a little to the file naming section of the WordPress Coding Standards to clarify the way in which we name our class files.

    In summary class files will be named using hypen separation and based on the class name they contain.

    I won’t be changing the name of old files but have updated the files we added in 3.1 before it’s too late.

     

    • Mike Schinkel 10:00 am on November 2, 2010 Permalink | Reply

      Glad you posted this. I’ve been meaning to ask and this seems like a great time. In core, some functions use a leading ‘wp_’ like wp_insert_post() whereas other functions don’t, i.e. update_post_meta(). Try as I might I’ve not been able to decipher a pattern but I’m sure one is in there I just haven’t been able to grok it.

      So when and why does a core function get a wp_ prefix and when not? Also, if there is legacy involved and some functions don’t follow the rationale, will they be cleaned up over time?

      This one has bugged me for a while… Thanks in advance.

      • Ozh 10:26 am on November 2, 2010 Permalink | Reply

        I think at the origin the wp_* functions were more private stuff used within APIs, but this has evolved without real guidelines

        • Mike Schinkel 10:45 am on November 2, 2010 Permalink

          Thanks for the reply. Would it make any sense to start some guidelines if none exist? If there are none it would seem like wp_ prefix might be consider reserved so a best practice would be to never name a function or variable starting with wp_ and then WordPress would be free to use that namespace for future enhancements?

        • Peter Westwood 10:47 am on November 2, 2010 Permalink

          @Mike: Actually best practise is for plugins/themes to prefix everything with something. That way they never clash with core or each other.

          I tend to prefix with my initials or the plugin slug.

    • Ozh 10:25 am on November 2, 2010 Permalink | Reply

      Any reason for the file naming scheme other than having something consistent and pretty to the eye?

      • Peter Westwood 10:28 am on November 2, 2010 Permalink | Reply

        I went with consistency to the existing rules which stated separate with hypens and just documented the current practises.
        Personally, I prefer the class. and functions. that BackPress uses but I also don’t see a need to change WordPress in that direction – what we have works fine.

        • Andy Skelton 7:36 pm on November 2, 2010 Permalink

          I value filenames that can be autocompleted with few keystrokes. My only material objection to a new filename is one that increases the number of keystrokes to access an old file.

    • scribu 4:05 pm on November 2, 2010 Permalink | Reply

      For context: #15280

    • Jacob Santos 6:12 pm on November 2, 2010 Permalink | Reply

      else if or elseif section:
      “Both notations are used in conjunction with curly brackets, there is no rule which to prefer. elseif can save you some hassles sometimes.”

      Problem 1: WTF?

      Problem 2: The point of a standard is to specify which is used for consistency. This is not a standard and therefore does not belong.

      Problem 3: elseif vs else if is only a problem when using if() : elseif() : else: endif;. Since this is rarely if ever used in WordPress, it makes more sense to use “else if” instead.

      “If you forget an equal sign it’ll throw a parse error instead of just evaluating true and executing the statement. It really takes no extra time to do, so if this saves one bug it’s worth it.”

      These bugs are certainly hard to find, however, if this is the case, then it also makes sense to never have any assignment in the if statements. This may go against the previous rule where variables aren’t created unless they are used more than once. It is worth it for consistency. It should be noted that assignment already exists in the if statements now confusing the standard.

      The “Self-Explanatory Flag Values for Function Arguments” Section.

      Most people solve this by simply using constants, it might be something to look into.

      • Andrew Nacin 7:21 pm on November 2, 2010 Permalink | Reply

        I’m working on a new coding standards document. In it, I’ve proposed s/else if/elseif/ and I plan to make that change across core.

        I don’t mind assignment in the if statement. We just need to be worried about left-hand comparisons.

        Re: function arguments: I’d rather a string any day.

        • Jacob Santos 8:19 pm on November 2, 2010 Permalink

          The mistaken assignment is most often a novice mistake and often corrected with simple peer review. When you have assignment in an evaluation statement, it confuses the reviewer as to whether you made a mistake or if it is intentional. It is considered best practice in that instance to always do assignment outside of evaluations for clarity and to let those reviewing the code know that you’re not making a mistake.

          Coding standards aren’t always preference, when working with others they should be considered for ease of review, clarity, beauty, and preference last.

          It also appears that certain aspects are being drawn from compiled languages and applied to interpreted ones without discerning why certain standards are applied to compiled and why those similar instances do not apply to languages like PHP.

        • hakre 11:13 pm on November 3, 2010 Permalink

          @nacin – I asked multiple times when the coding standard gets actually applied it to the wordpress codebase. I even offered help for that multiple times but I can not see any traction for months. Shouldn’t this something be done prior to a new point release? Is this actually something to expect or is the coding standard just to fill up a codex page?

        • Andrew Nacin 6:20 am on November 4, 2010 Permalink

          I’ve spent some time reading the contribution handbooks of other open source projects. I’ve noted a relevant section on coding standards from the Linux manual, specifically, the second hazard listed in the “coding style” section.

        • Peter Westwood 8:09 am on November 4, 2010 Permalink

          @hakre: Coding Standards are always a guide. It is a waste of everyones time and effort going back and applying them to legacy code.

          They are all about promoting consistency going forward.

          We do not need to create unnecessary churn in the codebase as this just increases the test burden.

        • hakre 1:59 pm on November 4, 2010 Permalink

          The argument of legacy code can be left aside. The coding standard is not applied to new code as well. This might be about promoting something but not about actually doing it.

          But I didn’t pose my question that some might think they need to defend themselves, I mean this package is the work of many and as peter stated, this is all about promoting consistency going forward.

          Instead I wanted to find out if we can see some traction for this in the near future or not?

          We last talked about the coding standards before the hiatus and it was said that it will become applied to the codebase (IIRC the statement was by you Nacin). At least it sounded like quite a plan. This was somehow related to the sourcecode documentation on the wordpress website, this probably helps you to remember what I mean.

  • Peter Westwood 12:09 pm on November 1, 2010 Permalink | Reply
    Tags:   

    Suggest Agenda items for Nov 3rd 2010 dev chat 

    Suggest agenda items for this weeks developer chat.

    Please note the new day and time – Wednesdays at 16:00 UTC

     

  • Peter Westwood 7:54 am on September 30, 2010 Permalink | Reply
    Tags:   

    Suggest Agenda Items for today’s meet-up
    Please keep them on-topic

     

    • demetris 2:48 pm on September 30, 2010 Permalink | Reply

      Before trying to get feedback from plugin/theme authors and translators about my idea for an approach that would make it easier to translate plugins/themes, I would like to know what core contributors think about it.

      Proposal: Pool of common strings for core, themes, and plugins

      http://core.trac.wordpress.org/ticket/14972

      As I explain in the ticket, what would this mean for core, as far as I have thought it out, is designating a few dozen commonly used strings as strings for common use and not liable to change, and copying them over to a new file.

      I don’t know if this needs to be discussed in a dev meetup or if we can just use the ticket. Whatever people think.

      • Jane Wells 6:40 pm on September 30, 2010 Permalink | Reply

        Let’s use the ticket, so that time zone/availability won’t be a barrier to participating in discussion.

    • scribu 6:09 pm on September 30, 2010 Permalink | Reply

      Admin menu API. #14666 which led to #12718

  • Peter Westwood 10:20 am on August 12, 2010 Permalink | Reply  

    Agenda for August 12th 2010 dev chat 

    • 3.org team upates
     

  • Peter Westwood 8:59 am on August 9, 2010 Permalink | Reply
    Tags:   

    Suggest Agenda Items for August 12th 2010 Dev Chat

     

    • hakre 3:04 pm on August 9, 2010 Permalink | Reply

      wordpress.org website teams status quo reports.

      • Jacob Santos 8:14 pm on August 9, 2010 Permalink | Reply

        Indeed, development of WordPress 3.1 is supposed to start up again in September and it doesn’t appear that anything significant has been made in some of the projects. It would be nice to know what exactly has been done in the two months since it has started.

      • Mark McWilliams 11:35 pm on August 9, 2010 Permalink | Reply

        Yup, it sure would be nice to find out (for people not involved or in the know) what’s going on, and considering what @jane said below…! Things have been done yes, but what else we don’t know about yet? ;)

      • Andrew Nacin 3:46 am on August 10, 2010 Permalink | Reply

        Sure would be great to see your actual involvement, instead of just asking for updates.

        • Mark McWilliams 12:23 pm on August 10, 2010 Permalink

          Counter argument, it’d be nice to know what had been done, so someone like myself (or in fact anyone) would know where they stand if they wanted to assist? I think it’s only a fair question to ask, but hey ho, I guess my involvement is staying out of things! — For the best probably!

        • Denis 10:57 pm on August 10, 2010 Permalink

          I’d be curious too, myself. Not that I plan to participate, since i’m tied up in mountains of other things. But you know. Sort of like when I need to wake up on following track and getting a to the point summary of what changed on wp.org.

          It helps if you’re only casually around…

        • Denis 10:58 pm on August 10, 2010 Permalink

          Adding to that, what happened to meet-up summaries?

        • Peter Westwood 10:17 am on August 12, 2010 Permalink

          @denis: dev chat summaries get posted when there is something significant worth summarising rather than as a regular thing. The IRC logs can be visited via the link in the sidebar if you want to see what was discussed in detail

    • arena 11:56 am on August 11, 2010 Permalink | Reply

      How to reopen tickets blocked in ‘Future release’ for 3.1 ?

      • Peter Westwood 10:19 am on August 12, 2010 Permalink | Reply

        We’re not really scheduling anything for 3.1 at the moment.
        This wil be discussed when we start the 3.1 cycle in september

  • Peter Westwood 4:46 pm on August 3, 2010 Permalink | Reply
    Tags:   

    Suggest Agenda Items for August 5th 2010 Dev Chat

     

    • Milan 5:23 pm on August 3, 2010 Permalink | Reply

      Discussion about making rules in release process since current process is very unfriendly to translators (who maintain locale wp.org sites) and to users of locale versions, as I described in my mail on wp-polyglots mailing list.

      I can make a proposal with my views about how process should work that could be discussed on wppolyglots and on IRC.

      • Jane Wells 6:37 pm on August 5, 2010 Permalink | Reply

        This comment got stuck in moderation until now, 2 hours before dev chat. I think this should be talked about after you’ve done a proposal as you suggest and have some feedback from the polyglots group.

        • Milan 6:45 pm on August 5, 2010 Permalink

          OK, I’ll make proposal and post it to wppolyglots and I’ll prepare more detailed request next week.

      • Matt 6:38 pm on August 5, 2010 Permalink | Reply

        You should really just subscribe to the wp-svn list.

    • Jane Wells 6:17 pm on August 5, 2010 Permalink | Reply

      Does no suggested items mean we can skip the meeting this week and just keep working?

← Older posts

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
Follow

Get every new post delivered to your Inbox.

Join 1,061 other followers