Make WordPress Core

Updates from March, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • Jen 6:16 pm on March 16, 2012 Permalink

    No GSoC 2012 

    WordPress was rejected as a mentoring organization from GSoC for this summer. This is unexpected, as I spent some time during the application period talking with Carol (Smith, the GSoC administrator) about our proposed approach of building a release cycle around GSoC and making it a mentorship-focused release and she seemed to approve the idea.

    We can still do a summer mentorship-focused release for 3.5 if we want to, though. We could pimp it as independent study for credit for college students and put more focus on non-student potential contributors, such as from the plugin/theme ranks. If nothing else, it would avoid the inevitable couple of students who are only in it for the $$. We’ll need to decide if we still want to do something along these lines, or if we don’t.

    Why did we get rejected? We don’t know yet. I used last year’s successful application as a template. There will be a feedback meeting in a week or so, and Carol says to attend that when it is announced and we can find out why during that meeting.

    • Daniel Chatfield 6:20 pm on March 16, 2012 Permalink | Log in to Reply

      That is very unexpected. I’m a student and would love to get involved 🙂

    • Brian Layman 6:20 pm on March 16, 2012 Permalink | Log in to Reply

      Well that’s unexpected… If we are going to get feedback from that meeting, it probably won’t pay to spend time speculating on the reason right now…

    • Aaron D. Campbell 6:22 pm on March 16, 2012 Permalink | Log in to Reply

      Mentorship-focused doesn’t sound that far from the teams setup we used for 3.4. The other advantage is that we can mentor any age, rather than restricting it to college students.

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

        Was planning to do that anyway. The GSoC part would have been a good push on external deadlines, though.

      • Kyriakos 8:45 pm on March 16, 2012 Permalink | Log in to Reply

        Sounds like a good idea Aaron. There is a wider audience than college students that will like to participate and need the guide from a WordPress Guru.

    • drecodeam 6:26 pm on March 16, 2012 Permalink | Log in to Reply

      This is seriously unexpected, but yet for us students the idea of the mentorship focused release is a nice option now, i would still love to get involved for this summers. One of the major advantages of GSoC program was the structured approach it puts the students in. If you can still chalk out such a plan, a lot of good work can still be done from the students who are deeply interested.

    • George 6:37 pm on March 16, 2012 Permalink | Log in to Reply

      I think students who wanted to work with WordPress would contribute anyway. Will WordPress team still provide mentorship?

      • Stas Sușcov 7:22 pm on March 16, 2012 Permalink | Log in to Reply

        This is debatable. WordPress is solid enough (probably that’s the reason why Google thought it doesn’t need help) to get a SoC or some sprints like it happened during 3.5 cycle.

        I remember http://rubysoc.org and it’s a great example. I would help crowd-sourcing/mentor/contribute to some projects like bbPress/BuddyPress or why not Coursewa.re.
        And many would do the same.

        • George 7:26 pm on March 16, 2012 Permalink | Log in to Reply

          That would be great. I wanted too ask about BBs mentorship. You did a great job with Courseware, I’ve idea similar to Courseware, but not sure can it be done on top of your project. Maybe when you have time we can chat and discuss this.

        • Stas Sușcov 7:30 pm on March 16, 2012 Permalink | Log in to Reply

          Thanks, sure, anytime.

    • George Stephanis 6:40 pm on March 16, 2012 Permalink | Log in to Reply

      Still planning on keeping it to core contributions only, or possibly opening it up to plugins as well? The latter could get a bit messy paperwork-wise without a more consistent oversight if done for credits.

    • mitcho (Michael 芳貴 Erlewine) 6:44 pm on March 16, 2012 Permalink | Log in to Reply

      I feel surprised and saddened by GSoC’s decision, but I agree that having a program to get new contributors more involved through some mentorship is a powerful thing that could continue outside of the purview of the GSoC program. I hope that does indeed happen.

    • Mert Yazicioglu 6:52 pm on March 16, 2012 Permalink | Log in to Reply

      I wasn’t expecting that just like the others but I’m sure there are many people out there (like me) that would love to take part in a mentorship-focused release. Most of us students have more time than the core developers during the summer so I’m sure we can make great contributions.

      This is certainly sad news but not a show-stopper in my opinion.

    • Kyriakos 7:05 pm on March 16, 2012 Permalink | Log in to Reply

      Why unexpected? WordPress should see this coming. Is obvious that Google at some point would stop supporting competitors to its own products like WordPress is for Blogger and soon other organizations will follow. (Firefox>Chrome, ChromeOS competitors etc.)

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

      Now that the list has been released, we are in good company… Drupal, Mozilla, and other big projects are out, also. There are only 54 organizations listed (vs 150+ in past years) and most look to be smaller ones.

      • Tunilame 7:42 pm on March 16, 2012 Permalink | Log in to Reply

        But the list is getting longer with minutes (180 participating organizations marked, but only 73 shown ’till now), is that normal?

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

        My bad. Not all the orgs are listed yet, because they only show up on the list ( http://www.google-melange.com/gsoc/program/accepted_orgs/google/gsoc2012 ) after they have filled in a post-acceptance profile. For all we know, Drupal, Mozilla, etc may have been acepted and we just weren’t. Will find out for sure at next week’s meeting.

        • Rafael Poveda - RaveN 11:14 am on March 17, 2012 Permalink | Log in to Reply

          I think WordPress have enough support by companies to begin with your own WordPress Summer of Code without funding problems. As said before, it can be an excellent opportunity to allow more projects –not just students projects– and to focus in company-related issues too.

      • Egill Erlendsson 8:20 pm on March 20, 2012 Permalink | Log in to Reply

        Drupal, Joomla, Mozilla, Wikimedia, Django are on the list of accepted organizations, which makes the decision even more interesting.

    • Kyriakos 7:21 pm on March 16, 2012 Permalink | Log in to Reply

      Mozilla products are direct competitors to android (b2go) and chrome (firefox) etc This day was about to come Jane, Is quite anorthodox for a company to pay competitors to grow bigger stronger better.

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

        Leaving multiple comments with the same content is a good way to get marked as spam. We got it the first time. And completely disagree.

        • Kyriakos 7:38 pm on March 16, 2012 Permalink | Log in to Reply

          And what is the reason for this kind of move from Google Jane according to your opinion?

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

          We will have to wait until the meeting next week to find out. We have participated for 5 years though, and are not exactly in need of the helping hand that GSoC offers.

      • Mert Yazicioglu 10:09 am on March 17, 2012 Permalink | Log in to Reply

        Having a stronger competitor is a good thing, it motivates you to do greater things. GSoC is to get students more involved in Open Source and not Google or its products. Google is just trying to contribute to the growth of the Open Source ecosystem, that’s all.

        And by the way, Mozilla is accepted so your argument is invalid in every possible way.

    • rhh 12:48 am on March 17, 2012 Permalink | Log in to Reply

      GSoC rejection does not matter at all. In fact WP can have its own summer of code for all open source stuff, maybe in some other name. WP needs independent and unique branding, which it has but needs to be MORE. For example, Facebook have no mention of WP, neither Google in the form of small icons, logos, or the “like it” buttons, so WHY does WP needs that in its various properties/web estates?

      First step towards shaking the unhealthy dominance by G,FB, Apple – be UNIQUE dear WP!

    • DrewAPicture 8:32 am on March 17, 2012 Permalink | Log in to Reply

      It was probably all the jokes about Melange finally getting fixed.

    • Thorsten 10:39 am on March 17, 2012 Permalink | Log in to Reply

      Bummer, nevertheless I would be happy to mentor any student who wants to do something “WordPress” during the summer.

    • Frederick Townes 12:51 pm on March 17, 2012 Permalink | Log in to Reply

      This is a bit of a surprise for me, but what I can say is that there’s still an opportunity to drive innovation for WP. Whether it’s as transparent as it could be or not, there’s quite a bit of mentorship permeating this community and I agree with some of the prior commentors that this community has the means to “institutionalize” that mentorship in least in terms of manifesting those values in the form of it’s own program. As usual, it would set the bar in terms of culture for other open source groups as well, which is definitely not a bad thing (nor a small feat). So I’m all for an “internal” mentorship program (which can have quite few different possible legs).

    • Shibu Lijack 4:28 am on March 19, 2012 Permalink | Log in to Reply

      I am extremely disappointed! Being a college student, I was eagerly waiting for GSOC’12. I thought for sure WP would be one of the mentoring organisations. So I started preparing months ago.. Developed quite a few plugins and themes. But how unfortunate! All my hopes and dreams shattered. I still wish WP could somehow get accepted into GSOC’12.

    • Stas Sușcov 4:13 pm on March 19, 2012 Permalink | Log in to Reply

      For students looking for WordPress GSoC projects, last two years Creative Commons were looking for a WordPress developer. I checked again and it looks like their WordPress RDFa plugin is still on their ToDo list:

      if you really-really want to help CC, I could be a lamb and even help you with my last year proposal draft (just to help you dig into what they were looking for) 🙂

      Good luck!

    • mbijon 5:28 pm on May 3, 2012 Permalink | Log in to Reply

      Any news yet on why we weren’t accepted this year?

  • Helen Hou-Sandi 5:55 am on February 22, 2012 Permalink
    Tags: , ,   

    Team Update: Browsing Buddies 

    @getsource (DH-Shredder) spent some more time over the past week working with @dkoopersmith refining the infinite scroll JS for #19815, which was committed earlier today. We briefly discussed having more results/pagination for some of the other theme-install.php tabs with @nacin (requires changes on the API end), as well as the recurring thought that perhaps the featured tab should show first. Therefore, the other patch that restricted the JS enqueue to the theme-install.php search tab only was not committed for the time being.

    After reviewing some comps with @jane, we started on the display of multiple screenshots. An initial rough patch will be up on #19816 soon. We still need to hash out the details of retrieving multiple screenshots, both in get_themes() and from the .org API, and how those images will be added to the extended details div without displaying in no JS, as discussed when first scoping the feature. We also need to take into consideration what happens when the window is resized. Provided that we can get that sorted out tomorrow, it looks like we’re on target for the cycle.

    I wrote the Theme Review Team and gave them an update on the anticipated screenshot sizes, which will remain at 300×225 (4:3), constrained by CSS. Gandalf functions as the large screenshot 🙂 The screenshots in the list table view will be enlarged to match, as there is more space now that details are hidden by default.

  • Andrew Nacin 10:40 pm on February 16, 2012 Permalink

    Results of 2/15 Dev Meeting 

    The teams and status document has been updated to reflect current cycles. Yesterday’s dev meeting focused on identifying issues pertaining to blockers and resources, and whether any adjustments or corrections needed to be made, across all teams. As I didn’t keep a general summary, you may find the log is here.

    I did take notes on who needs resources from whom:

    And there may be a few others I didn’t catch. Ideally this will all happen before our meeting next Wednesday.

    Two teams were added: @georgestephanis and Zach Abernathy (thezman84) working on tablets, and @aaronjorbin working with Tom Auger (tomauger) on favicons. I have been communicating with both teams to help get things off the ground.

    If you want to get involved, there are 198 open tickets on report 5, many of which fall under no team. If they do, find the team during office hours or contribute directly to the ticket, as many have done.

    Next meeting is 2/22 at 2100 UTC.

  • Jen 3:06 pm on November 23, 2011 Permalink

    15 10 6 tickets between us and launch. Still need a beta 4 and an RC. The tickets:

    Needs Dev / Bug Wrangler Feedback

    Has Patch / Needs Testing

    Patch Needs Refresh

    Needs Patch

    • Jane Wells 3:42 pm on November 23, 2011 Permalink | Log in to Reply

      If it didn’t jump out at you, some help with the accessibility and RTL fixes would great, even if it’s just doing QA the fixes the core team has made.

    • Andrés Sanhueza 3:54 am on November 24, 2011 Permalink | Log in to Reply

      Will the 3.2.2 remaining tickets be considered?

    • Denis 12:41 am on November 25, 2011 Permalink | Log in to Reply

      Would it be possible to insist, over at onswipe, that they add a “never show this crappy theme” link on WP.com? And if not, would it be possible to disable the thing on this blog, if not on WP.com altogether by default?

      I hate to be bursting on this blog in particular, but it’s the last WP.com I’m still following on my iPad… You guys (as in WP.com) have serious problems ahead if your goal is eye balls, and nonetheless stick with onswipe.

      On a seperate note, there’s a severe bug when writing comments on iOS5 with a 1st gen iPad on this blog. I’ve no idea if it’s iPad or WP related but the comment box’ size toggles between 3 and 10 lines as I’m writing.

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

    Suggest Agenda Items for August 12th 2010 Dev Chat

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

      wordpress.org website teams status quo reports.

      • Jacob Santos 8:14 pm on August 9, 2010 Permalink | Log in to 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 | Log in to 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 | Log in to 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 | Log in to Reply

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

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

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

        • Peter Westwood 10:17 am on August 12, 2010 Permalink | Log in to Reply

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

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

      • Peter Westwood 10:19 am on August 12, 2010 Permalink | Log in to 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

  • Jen 4:33 pm on March 16, 2010 Permalink

    I’m kind of thrown by what has turned up in menus since I looked at it two days ago. It appears that you can now add everything under the sun to a custom menu. The feature we talked about adding in 3.0 was to support adding pages, categories, and links. As v1 of the feature, I think it’s important we rein ourselves in here. Advanced menu stuff belongs in a plugin, not in core. It could be a core plugin, but having the default menu creator in v1 have that many options (post, page, link, tag, category, media file) is going too far and is outside the scope we all approved. We need a *basic* menu feature that plugins can build on; we should not put the whole kit and caboodle in core. If we want to put out a core plugin to add all the other stuff, I would support that, but for core I think we need to strip it back a little and focus on making it accessible.

    • Crago 4:36 pm on March 16, 2010 Permalink | Log in to Reply

      Terrible idea! Let the menu spread its menu-wings and fly!

    • scribu 5:03 pm on March 16, 2010 Permalink | Log in to Reply

      I agree that all we need in core, at least for 3.0 is page, category and link menu items.

    • Ryan 5:14 pm on March 16, 2010 Permalink | Log in to Reply

      A plugin to turn them on would be trivial. Perhaps we can add flags to the post type and taxonomy registration to enable showing them in the menu admin.

      • Nathan Rice 5:20 pm on March 16, 2010 Permalink | Log in to Reply

        I totally agree. A plugin to support custom post types (which are now a part of core, lest we forget) would be nonsense. However, a flag in the post type creation would be perfectly legitimate, and a much more elegant solution, IMO.

        Pulling out perfectly functional features seems like a bad move. It makes no sense.

      • Ryan 5:27 pm on March 16, 2010 Permalink | Log in to Reply

        I added a couple filters that will allow plugins to turn on other types and taxonomies. Since a registration flag could become obsolete in the future, I thought some dedicated filters would be better.

    • Peter 6:03 pm on March 16, 2010 Permalink | Log in to Reply

      What is the point of removing the capacity to have a menu of tags, when doing so neither increases nor decreases accessibility, nor does it affect the present subject of concentration.
      Having tags as menus actually INCREASES accessibility, because nav menus are more controllable, when it comes to accessibility features, than , for example, tag clouds.

      Secondly, post, page, link, tag, category, media file does not equal kit and kaboodle. It adds three extra types of links.

      I am concerned that removing elements from something so important, and for which people have waited a long time, will be done without logical reason. And, respectfully, I would say that Jane’s post contains no logical reason, just an appeal to restraint – perhaps on moral grounds?

    • Peter Westwood 6:22 pm on March 16, 2010 Permalink | Log in to Reply

      We do need to focus on getting the core functionality we agreed on in the dev chats working fully before we add all these extra menu item types and ideally we should only support for 3.0 the core types we discussed.

      I have been receiving personal reports that the current functionality is still very alpha in quaility and effort would be best expounded on making the core functionality rock solid than adding loads of extra menu item types.

    • ocean90 6:24 pm on March 16, 2010 Permalink | Log in to Reply

      I like the last update really. I show it some of my friends and they really like this feature.
      I think the Custom Menu is THE eyecatcher of 3.0 and so we should make it as # nice as possible. So that every user can make his own custom menu without searching any plugins to add some things again, then I don’t need the menu and add directly a plugin which can all of this.
      It should be easy.

      But I like the idea of ryan. +1.
      Eventuelly we can add screen options and add checkboxes for the ‘widgets’ and hide for example media on default.

    • Rich Pedley 6:37 pm on March 16, 2010 Permalink | Log in to Reply

      Surely the default menus system should actually include pages/posts/categories/links/tags because they are bulk standard to a WP install? So to me the current set has one extra that should be removed – that of adding a custom link. That one should IMO be handled via a plugin.

      Also please accept my apologies, have been trying to find time for the 2 of us, esmi(from the WP forums) and myself to look at the accessibility side of things and failing miserably as other projects get in the way.

    • Carl Hancock 6:45 pm on March 16, 2010 Permalink | Log in to Reply

      If you have the ability to add categories to your nav why not include tags? They are both taxonomy. I agree Media is taking things a bit too far and I don’t even use the Link functionality so I don’t find that very useful. But I think an Add Tag menu option would be extremely useful as part of the core.

    • Carl Hancock 6:47 pm on March 16, 2010 Permalink | Log in to Reply

      Forgot to mention +1 for a flag on custom post types to add a menu option in the menu builder when you add a custom post type. It seems that would round out the custom post type capabilities of 3.0 and make the Menus actually usable with custom post types. As they are now yes you could do custom post types, but your nav would have to be all manually done using links which would be a pain.

      • Idealien 8:14 pm on March 16, 2010 Permalink | Log in to Reply

        I agree. While 3.0 might happen to numerically be “just the next release” from 2.9, the opportunity to bring a combination of significant new features to core (UI for custom post types and dynamic built menus that support them) is worth shooting for with this symbolic major version release.

    • Peter 6:49 pm on March 16, 2010 Permalink | Log in to Reply

      I think too that removing tags is, to be frank, absurd. It assumes that, in the use of wordpress, categories occupy a position of greater importance when navigating a blog, than tags. And that is not true. Adding media files is, I agree, unnecessary.

    • Ryan 7:10 pm on March 16, 2010 Permalink | Log in to Reply

      With just Pages, Categories, and Custom Links the screen is already scrolling, especially once you click View All. If we add more things we have to solve that.

      Categories are the correct taxonomy for menus. Almost all themes use Categories for menu purposes. Using tags in the menus is a bit of a misuse, technically. Of course, everyone has their favorite means of using taxonomy, with many not using Categories at all. I personally would like to have Tags present, but the underlying UI issue would have to be addressed. The scrolling makes for very bad UI. You can’t the see menu when you click Add to Menu. After clicking, all you see is the selections in the checklist clear. There is absolutely no useful feedback when you are scrolled.

      Keep in mind that Custom Links allow linking to anything. Tag menu items can be added as custom links.

      • Carl Hancock 7:15 pm on March 16, 2010 Permalink | Log in to Reply

        Make the add menu boxes collapsable like sidebars in the Widget editor. Then just open the first one. A user can expand/collapse the others as needed. This would leave plenty of room to include Tags, which are core to WordPress and users ARE going to want to add tags to their menus. Sure you can add anything you want with the Custom Links functionality, but shouldn’t it at least cover the core WordPress features of posts, pages, categories and tags and then leave the rest to Custom Links or plugins?

        • Ryan 7:29 pm on March 16, 2010 Permalink | Log in to Reply

          They are collapse-able. They can also be made hide-able. It’s still bad UI once you show those things though. If we allow displaying those things we need to have a UI that can handle them.

          Tags seem to be the main point of contention. I would like to have them in there, but we need to figure a way to eliminate the scrolling. Moving Create Menu and Menu Settings out of the sidebar might help. “Delete Menu” and “Save Menu” could move back below the menu. Menu name editing could be exposed on the menu bar on hover like we do with the dashboard boxes.

        • Carl Hancock 7:39 pm on March 16, 2010 Permalink | Log in to Reply

          Remove menu settings. Move the menu title to above the menu itself just like where you edit a Post/Page Title in the post editor. Then put the save link below the menu again instead of on the right sidebar.

          Remove the “Create Menu” box. Place an “Add New” button to the right of the Menus page title that then creates a new menu… name it and save it. Make the name required.

          That frees up space for Tags on the right side by eliminating two of the existing boxes. At that point the only thing that would appear on the right side are the “Add…” toolboxes. Leaving space for Tags and hooks to allow additional boxes to be added (Custom Post Types, etc.).

      • Nathan Rice 7:33 pm on March 16, 2010 Permalink | Log in to Reply

        What screen resolution is assumed for UI purposes? On my netbook, I’d be willing to bet there’s going to be scrolling no matter what you guys do 🙂 But I don’t necessarily think that’s a problem, since netbooks aren’t the norm.

    • Carl Hancock 7:55 pm on March 16, 2010 Permalink | Log in to Reply

      I put together a quick mock up that shows what I described in a comment above as far as re-arranging stuff to free up space on the right sidebar so that it is strictly the “Add” toolbox area. It’s obviously just thrown together quickly.

      View it here:


      • The Menu name is moved into the content area similar to how you edit the Post/Page name.
      • The Add New link/button is moved to the standard location next to the page header.
      • With those 2 boxes removed from the right side, the Save button is moved to the content area and left aligned. Why left aligned? Because when the save button appears in the content area it is always left aligned (see Add Categories, Add Tags, Theme/Plugin Editor, Settings pages, etc.).
      • Carl Hancock 7:56 pm on March 16, 2010 Permalink | Log in to Reply

        Forgot to mention, the “Add Existing…” seems redundant. It could probably just be “Add Page”, “Add Category”, etc. Add Custom Link doesn’t use that terminology despite the fact whatever you are linking to obviously already exists.

        • Idealien 8:01 pm on March 16, 2010 Permalink | Log in to Reply

          I agree “Add Existing…” is redundant, but “Add Category” gives the impression it (might) add a new category to the db. What about “Add [Item] to menu” as the title and then a consistent ‘Add’ button across all of the entry boxes?

      • Ryan 7:57 pm on March 16, 2010 Permalink | Log in to Reply

        That looks good to me, regardless of the scrolling issue. I like having the sidebar be exclusively for adding menu items. I’m just the code monkey though, and will leave further discussion to you UI/UX folks. 🙂

      • Mark McWilliams 8:10 pm on March 16, 2010 Permalink | Log in to Reply

        I was thinking, do we really need the ability to alter the Menu Name? Am I not right in thinking that a theme author could register a menu in the functions.php file to work with their particular theme? – If the user ended up changing that, wouldn’t it mess with the theme? (Maybe unrelated yes, but while I’m here!)

        • Carl Hancock 8:27 pm on March 16, 2010 Permalink | Log in to Reply

          Not having a way to edit the name and having it basically set in stone would be obnoxious from a usability standpoint IMO. Can menus be called via id instead of name on the front end? If so call the menu by the id and then it doesn’t matter what the name is.

        • Mark McWilliams 1:32 am on March 17, 2010 Permalink | Log in to Reply

          OK I’ve obviously not tested it out, but I’d take a guess and say that registering a menu in the functions.php file isn’t going to work well just by giving it an ID…? Yes they can be called on the front end via an ID, maybe it’s just a personal thing!

          On the other hand though, to alter a Custom Taxonomy or a Custom Post Type, we’d have to alter the plugin or functions.php file itself, kind of a swings and roundabout situation here! 😉

    • djeckhart 8:25 pm on March 16, 2010 Permalink | Log in to Reply

      Agree that “Media Files” could go. The rest, particularly support for post types, is/should be core functionality.

    • ceenz 11:14 pm on March 16, 2010 Permalink | Log in to Reply

      All the ‘add existing…’ boxes on the right side of the menu admin page make no sense. Why not just have one for existing items and have a drop down for the type you want to add.

      [Add Existing Content Title]
      Type: [Drop Down of Types Available]
      [Search Box] [Search Button]
      [View All Link]

    • Ptah Dunbar 7:56 am on March 17, 2010 Permalink | Log in to Reply

      @jane, I sent you an email re: menus last week or so asking for UI advice, but haven’t heard back so I just went with what felt right. Here’s some of my reasoning.

      The save/delete button being at the button isn’t the best location as users will have to scroll all the way down to save when their menus become long. So I added them to the sidebar along with the ability to edit the name.

      The ability to support any post type/taxonomy was not me drifting away from bug fixing to adding features, but it was actually an added benefit while I was cleaning up the menu codebase to make the menu item types more abstract so plugin authors can add their own stuff. Based on the way the menu system works, adding additional menu item types would require the plugin author to create their own meta box along with the some js which is not WP standard. Before the last patch, they couldn’t even do that. So I added support for all types under the hood so I don’t mind the UI being limited to just pages and cats. The code is their to support any type so plugin authors only need to modify a filter and boom, it’s there.

      Also, instead of the filters, a better approach would be to just enable the pages and cats metaboxes to be ON by default while the other types are hidden and just a checkbox away in the screen options. win win?

      Right now, I’m focusing on fixing the saving/positioning bugs and making the core functionality solid. All my patches up until now were working towards this. But bug fighting is a combination of js and cross browser issues so I just have to do more testing with different browsers and such.

      Menus needs a combination of UI and bug fixing work. I can do the bug fixing part, but I’d very much like to get some explicit direction from you regarding the UI and what needs to happen. I’m just a code wrangler with aspiring UX/UI skills 🙂

    • Frank 12:01 pm on March 17, 2010 Permalink | Log in to Reply

      Thanks Jane,
      please give WP not s much features, please more features in core-plugins (my benefit to Core plugins). To many features in a new version ,in the core, this is a ko for the users, not realy good for WordPress.

    • Stephen R 12:23 pm on March 17, 2010 Permalink | Log in to Reply

      As a matter of general principle, I’m with Jane on this one. Best to show a bit of restraint than to cram the UI on the first iteration. You can always add later if the need is there, but it’s troublesome to remove things later…..

    • dd32 12:31 pm on March 17, 2010 Permalink | Log in to Reply

      I’d just like to back up the choices made during the development of the menu’s a bit.

      While Custom Post type and Custom taxonomy was not an agree’d part of the spec, Leaving them out is actually an increased amount of work, leaving them out doesnt make the functionality any easier to implement.

      The obvious reason to this is, that Posts and Pages are just post_types, Categories are just Taxonomies. Since WordPress offers such decent API’s, it makes it possible to use the Internal API’s and mearly create a generic post_type and generic Taxonomy functionality, and loop over it.

      Since this post has been written, I’m pretty certain that the functionality was extended further, so that post_type’s and custom taxonomies have to register a flag during registration to allow them to appear in the menu editor. (A Screen option would’ve been another option there, but not all objects are menu-usable anyway)

      For everyone else just stumbling across this post now, The menu editor as of this comment, only displays “Custom Links”, Pages and Categories by default.

    • ceenz 1:48 am on March 18, 2010 Permalink | Log in to Reply


      I have just been digging into the code for menu creating and management for the last 4 hours and cannot believe how convoluted, complicated and WAY over the top it all is. I cannot understand why simple menus require to be linked in with taxonomy, taxonomy relationships etc. I then looked at the number of data options stored in the wp_options DB totally ridiculous, there’s something like 15 different entries just for nav_menus.

      THE WHOLE MENU CREATION / ADMIN coding needs to be really looked at again with some type of DIRECTION and PATH mapped out. It is really a MESS, with just code piled up on top of each other.

      There needs only to be one DB entry for nav_menus and one for nav_menu_items in WP_options thats it. None of this taxonomy linking BS, none of the over the top nav_menu options currently in place.

      Each instance of nav_menu should have an id, name, array for items and array for options.
      Each nav_menu_item should have an id, name, link, type, and array for options.

      That is seriously all that is required.

      All the BS surrounding custom post types different taxonomy (eg tag, categories) can be handled through an extend-able nav_menu class based on the nav_menu_item type and store the unique options for the type in the nav_menu_item options array.

      I am really sorry but the whole situation is making me really angry.

      • Peter Westwood 8:39 pm on March 25, 2010 Permalink | Log in to Reply

        I’m not sure how storing everything is big serialised arrays really helps.

        There are a number of issues with doing it that way including the fragility of the php serialisation format with International characters in the strings and the issues around caching and interactivity if more than one person edits a menu structure which make it a sub optimal solution.

  • Jen 12:59 am on December 8, 2009 Permalink  

    Posted on dev blog re canonical plugins,… 

    Posted on dev blog re canonical plugins, and posted poll to weigh in on what to call them. https://wordpress.org/development/2009/12/canonical-plugins/ #wordpress

    • Shane 5:31 am on December 8, 2009 Permalink | Log in to Reply

      I still have my reservations about “canocial” plugins. Why there might be more than one developer and they be 100% complaint with WordPress when we go to debug code and then an author is having plugin trouble how can we be sure the plugins are not the ones causing it if we say ‘They work with wordpress 100%’ in which they don’t.

      It would be opening more holes to finding problems and I am afraid that it’s going to staunch growth once we create official plugins that already exist.

      Maybe a certification process instead, that we can say “This meets the security requirements of x.x.x version.” I know we do that with the new “Compatibility” box, but that is no way of saying that a plugin is secured.

      Plus these types of plugins should not be full feature items. Some things are better in core, but that would be decided once the plugins that are going to be developed are known.

      • Alex M. 5:49 am on December 8, 2009 Permalink | Log in to Reply

        I found your comment highly confusing, but the purpose of canonical plugins is so that rather than having 10 plugins that all do the same thing (say announce new posts on Twitter), the authors of those plugins combined their forces and develop one common, officially supported and promoted plugin. This is much like WordPress itself — we could all develop our own blogging softwares, or we can combine forces to create a single great project. Nothing is stopping anyone from continuing to make their own version of a plugin, but by making a canonical version, it ensures it’s up to date, keeps working, receives bug fixes, etc.

        A really good example of why this is needed is podPress. It has over a quarter million downloads, but the author is no longer able to maintain it and a lot of people didn’t upgrade their WordPress because podPress didn’t work with the new version. This is bad. Forking it or having someone else take over also aren’t ideal solutions as what’s stopping it from happening again?

        Instead we could make podPress (or something like it) a canonical plugin where it’s officially maintained and contributed to by multiple authors. It’s a plugin that’s really needed by a lot of people (podcasters) but isn’t really something that should probably be in core (lotta users, but they make up a low % of overall users).

    • TobiasBg 10:05 am on December 8, 2009 Permalink | Log in to Reply

      I’m not really sure what to think of this concept of “Canonical Plugins”.

      With the concept you presented, I have the fear that we are moving towards a “two-tier plugin society”, where non-canonical plugins will be valued less than they are now. This somehow sounds like an “App Store” for plugins, though not with all of [large computer company]’s restrictions. Questions that I see: What are the minimum technical requirements to be “canonical”? What are functionality requirements (i.e. a small plugin that filter “the_title” is most probably secure, but what’s its value)? Who decides which plugin is considered “canonical” and when? Are there any candidates right now?

      I would like to view “canonical plugins” more as core functions that are not in core but in a plugin. (This, for me, would lead to the name “Core Plugins”.) That way, people could be using/activating only what they need, with the purpose of running a WP that only loads what it needs. Examples for this could be the new image editing functions. They could be in a plugin and people who absolutely want to use [fance desktop graphics program] can disable the plugin. Those plugins would/could still be maintained by core developers (or/and strongly connected developers). Another example is Akismet, which I see as a Core Plugin, as it shows the way how those plugins could be added to core. (Yet there could be an additional screen on the Plugins page with “Core Plugins”, to more emphasize that they are activily maintained.)

      • Jane Wells 2:43 pm on December 8, 2009 Permalink | Log in to Reply

        What you’re suggesting is pretty much exactly what we envision.

        • TobiasBg 7:42 pm on December 8, 2009 Permalink | Log in to Reply

          Now that I read your post again, I don’t really know anymore what triggered me to write the above entry. 🙂 So, I guess, that’s a good thing 🙂
          Let’s see how it turns out.

      • Matt 5:16 pm on December 8, 2009 Permalink | Log in to Reply

        Yes, one of my suggestions was to make a new “anti-spam” plugin that’s included with core download instead of Akismet, and have Akismet be one of the services it supports as well as Typepad, etc.

      • Daniel Nautré 6:13 pm on December 8, 2009 Permalink | Log in to Reply

        It would be a good thing that some “heavy” features of WordPress would be present as “canonical” plugins to allow WordPress to be “lighter”.
        Another thing that I would like to see, is the ability for plugins to have switches to turn on/off their features. This would allow users to have only the features they need turned on, and WordPress would only load these features while being executed.

        How about porting some features of WordPress to these plugins to make the core engine lighter ?

        • Matt 5:37 pm on December 9, 2009 Permalink | Log in to Reply

          Light is a function of user interface and speed. We can and have made WordPress lighter without removing functionality before.

    • Aaron Brazell 6:37 pm on December 8, 2009 Permalink | Log in to Reply

      @jane I prefer “Plugin Frameworks” over canonical, but I know many in the WP community shy away from the word framework because themers have turned it into a dirty word. 😉

      • Eric Marden 8:31 pm on December 10, 2009 Permalink | Log in to Reply

        Framework is not a dirty word… A framework is what you used to build something useful. A plugin framework would be used to build other plugins, not to be used as a plugin directly.

        Either way, framework only says ‘developer tool’ to most folks

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