Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h06/mnt/47169/domains/themehybrid.com/html/community/bb-settings.php on line 186

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h06/mnt/47169/domains/themehybrid.com/html/community/bb-includes/backpress/functions.wp-object-cache.php on line 108

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h06/mnt/47169/domains/themehybrid.com/html/community/bb-includes/backpress/pomo/mo.php on line 171

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h06/mnt/47169/domains/themehybrid.com/html/community/bb-includes/functions.bb-l10n.php on line 484

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h06/mnt/47169/domains/themehybrid.com/html/community/bb-includes/backpress/class.wp-taxonomy.php on line 581
Hybrid version 0.7 discussion « Community

Welcome, guest!

Feel free to read the blog, browse for themes, or join the club.

The community forums are currently being phased out. At the end of February or early March 2012, you will no longer be able to post here. This is because the entire site is being restructured. Please use the main forums for discussions.

Hybrid version 0.7 discussion

  1. Filter hook to disable Hybrid Settings meta box

    Might I suggest a way to disable each option in the box separately? I love the series option, but simply don't use the rest. I could see some wanting the thumbnail too, but I definitely don't want my authors having access to the title, if possible. The savvy ones are fine, but many of my authors (wpmu environment) are not web savvy. If they see the title option, they think they are required to fill it in, so they do, and break the already good title.

    Does the footer setting (under Hybrid Settings) need to be turned off for WPMU or does this work as it should?

    From my understanding, the administrator is the only person with direct access to this, but I just want to be sure.

    Not only the site admin (site admin meaning the admin over the entire wpmu installation) can see that, but also any blog admin can see it, so I could see some wpmu site owners wanting that turned off.

    The way I work my wpmu site, I am THE ONLY admin. This is not typical though. I think, typically, blogs can be created by most anyone and they can be their own admin too. In my case, they can't see hybrid settings at all, so I'm fine with it like it is.

    I know it's easy enough for you to setup a wpmu test site and play with things if you really wanted to, but just to offer a little help, I would be happy to setup a fresh install of wpmu on my host (I'm a reseller) and give you full access (cpanel and ftp included) to see how it works with hybrid.

  2. Might I suggest a way to disable each option in the [Hybrid Settings meta box] separately?

    I wish I'd thought of that. This is already possible because the array of settings is filterable. Instead of adding a completely extra hook, the theme should check if any settings are available for use before outputting the box.

    Not only the site admin (site admin meaning the admin over the entire wpmu installation) can see that, but also any blog admin can see it, so I could see some wpmu site owners wanting that turned off.

    Thanks for the clarification on that. There should definitely be a hook that allows disabling this setting.

  3. May it be possible to customize the title of the [Hybrid Settings meta box] ? Its useful when making sites for clients who doesnt know what Hybrid is, and may be interpreted as the term hybrid. May it be possible to use <?php bloginfo('show'); ?> Settings as an alternative to Hybrid Settings ?

    May it be possible to customize plugins to show meta boxes within the [Hybrid Settings meta box] to avoid cluttering with many meta boxes ?

  4. Hybrid is first and foremost, without any doubt, a framework for developers. I first created it with the intention of using it for my personal projects, then later released it for other developers to build from. It was created to be extended.

    Since Hybrid is a framework for developers may it be possible to extend it to support a easy and fast workflow to make custom write panels ? Most of this should be handled in child starter themes, but may it be some smart way of supporting custom write panels in the framework ?

    So, Hybrid's <body> class will no longer include the front-page class. We'll stick with home and blog. If it is both the blog page and the front page, then you'll get both classes.

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

    Add front-page.php ? or is that a template that should go in child themes if wanted ?

  5. May it be possible to customize the title of the [Hybrid Settings meta box]?

    I actually never much liked "Hybrid Settings" for the meta box because it could be easily confused with the Hybrid Settings (theme settings) page. "Post/Page Settings" never seemed appropriate either since all the meta boxes hold those settings.

    May it be possible to customize plugins to show meta boxes within the [Hybrid Settings meta box] to avoid cluttering with many meta boxes ?

    This is already possible. Hybrid's got a filter hook for this.

    Since Hybrid is a framework for developers may it be possible to extend it to support a easy and fast workflow to make custom write panels ?

    Are you referring to meta boxes? Or, support of adding new content/post types? If you're talking about meta boxes, WordPress already has a few functions and hooks that speed this process up tremendously.

    Add front-page.php? or is that a template that should go in child themes if wanted ?

    If this ticket gets put through, it would be something you'd only want in a child theme. I can't see it having any use in Hybrid.

  6. On the subject of meta boxes

    I've been meaning to do a rewrite of a lot of that code to automate it a little more and just make it more efficient. In fact, I'm hoping I can get in a rewrite of the entire /admin folder for 0.7.

    There's a lot of cobwebs that need cleaning there. Much of the setting page relies too heavily on custom functions I created to handle settings pages, but WordPress has since introduced new methods of adding options to the DB. There's nothing wrong with the old methods, but it's best to keep the code current.

  7. There are some different names used for custom content types. Sometimes they are called custom content type, sometimes they are called custom write panel or custom post type .

    Anyways, I`m talking about Hybrid supporting some smart and fast way of making custom content types to be able to streamline the backend for repeated tasks involving publishing posts/pages which includes custom fields data.

    Most of my thoughts are currently focused on WordPress itself and two major features:

    * Custom taxonomies.
    * Custom content types (post types).

    The direction these two things continue in (especially custom content types) will shape much of the future of the theme.

    If Hybrid supports custom content types, and starter themes and user customized themes use custom content types it should be possible to maintain a growing repository of custom content type code, and post/page templates, for users to use and customize. That would be awesome and should make Hybrid cooler, and more interesting for designers/devs ( user base 1 )

    Maybe custom content types code should be light Hybrid plugins as an alternative to functions.php editing with documentation support in the support section.

    Justin, may you elaborate on your thoughts about:

    * Custom content types (post types).

  8. Custom content/post types

    When I mentioned supporting custom content types, it's mostly about seeing where this ticket goes:
    http://core.trac.wordpress.org/ticket/9674

    While WordPress currently supports custom content types, I expect this to get an overhaul at some point. How this is handled will be reflected within the theme, but it's something I don't think will happen soon.

    I can't really say more on the subject until the work is done in WP core. I am definitely excited about the possibilities though and plan to be one of the first people on the custom-content-type bandwagon.

  9. Do you separate custom content types and custom Page templates with meta boxes to add custom fields ?

    I`d like to see Hybrid take a step towards providing custom page templates with meta box custom field support, maybe on a resources/template/documentation level.

    Check screenshots: http://gorillathemes.com/latest-themes/smooth-real-estate/

    How about more Page templates ? Is that something to consider ? Page templates that handles custom field images, titles and author info different. You may say its child theme territory, but I`d like to see it in Hybrid, and variants of these templates in child themes.

    Theres a lot of human resources used in support to repeatedly do the same or similar changes, and maybe some of that energy could go into making more Page templates. May Page templates be atomized to call template modules ?

    May Page templates be developed and added to Hybrid between major releases with community collaboration and shared within the theme club ?

    May the same be possible with category templates ? Theres a lot of potential for category templates.

    Is it possible to add some kind of dev mode css to visualize block level structure ? Is it theoretically possible to visualize actions/filter areas/potential ?

    Is more and better commenting of css something to consider ? May some theme files have more comments ?

    May Hybrid have a list of canonical plugins ? Recommended working plugins for the most important plugin features. I know I have mentioned this before, and you said there already was a list, but I believe it would be smart to do cause it will have some potential when it comes to Hybrid community sharing knowledge.

    May some features be distributed with Hybrid as plugins ? The extensions folder is basically a plugins folder isnt it ? Would it be possible to include a different extensions folder with a backend settings feature to activate to choose inclusion of chosen extensions ?

  10. Integration/support/template for the new search plugin with taxonomy support:
    http://wordpress.org/extend/plugins/search/

    The plugin creates an API to support advanced search capabilities such as boolean search, multiple content searches (posts, tags, pages, authors and any available metadata) and flags (finding posts with A string in category C) through additional plugins.

    Theres a lot of references to taxonomy in the code ( which makes more sense to you than to me ):
    http://svn.wp-plugins.org/search/trunk/search.php
    PHP Source Documentation: http://wpsearchapi.googlecode.com/files/phpdoc.zip

    Out of the box improvement of search will be a major feature upgrade of Hybrid.

  11. Page Templates

    My idea with page templates is that the theme should provide a solid set of templates to use. Templates need to be 100% compatible with all child themes, out of the box. These templates must not require any code in the child theme, even CSS, to make them appear correctly. Plus, at some point, we have enough page templates. There's already 18 in the theme.

    The goal of page templates is to be able to have something that's custom. So, yes, I do see this as child theme territory. If it meets my above requirements, then it can be considered as something that might be worth adding to the theme.

    May Page templates be developed and added to Hybrid between major releases with community collaboration and shared within the theme club ?

    Yes, you all may share and distribute templates. If something gets developed that should definitely be in the theme, it can be added.

    Do you separate custom content types and custom Page templates with meta boxes to add custom fields ?

    I don't understand the question.

    Category templates

    May the same be possible with category templates ? Theres a lot of potential for category templates.

    I'm in agreement about the potential of category templates, or any taxonomy template for that matter. I still see this as a function of the child theme though.

    Actions/Filters Visualization

    Is it possible to add some kind of dev mode css to visualize block level structure ? Is it theoretically possible to visualize actions/filter areas/potential ?

    I could see the use of a visual overview of the theme hooks, if this is what you're referring to. I've been thinking about creating something that will show what hooks are available like what we have with the CSS classes and IDs.

    Code Commenting

    Is more and better commenting of css something to consider ? May some theme files have more comments ?

    It can be dangerous to heavily comment CSS because this does reflect on page load times. I am open to suggestions and feeback on all inline documentation though.

    Canonical Plugins

    May Hybrid have a list of canonical plugins ?

    Definitely. I remembered the discussion from before but haven't gotten this started yet. This should probably be opened up in another topic.

    I'll see about getting this started this week. If I forget, just let me know.

    Extensions Folder

    May some features be distributed with Hybrid as plugins ?

    None of Hybrid's features will be distributed as separate plugins for the theme, except maybe the SEO stuff (still waiting on all the voting on that one).

    The extensions folder is basically a plugins folder isnt it ? Would it be possible to include a different extensions folder with a backend settings feature to activate to choose inclusion of chosen extensions ?

    It's an external projects folder, which means it is maintained and developed outside of the Hybrid theme. So, it's sort of like a "plugins" folder, but it's for things that are essential for the theme to work, but they're outside of the core framework.

    Some of these extensions eventually become plugins. Get the Image and Breadcrumb Trail are now both plugins, but they were developed as parts of my themes first. It's just easier for me to maintain the code in one place rather than several places.

    I've thought about making it so that you could pick and choose which extensions you wanted to use, but some things are integral parts of how the theme works. For example, get_the_image() is used in many of the template files.

    This is the same thing as you'd see in WordPress. Several of the files in /wp-includes aren't developed by WordPress. They're just integrated into the system. I'm just more of a fan of organization. ;)

  12. Dealing with custom post types

    I'm working on a huge blog post that talks about the direction I think WordPress should move in, so custom post types are on my mind. A large part of this has to do with terminology.

    WP has two major post types that we tend to deal with the most: post and page.

    A major gripe I have is that the post type post uses the single.php template and is referred to as "single" all the time. In theory, this works great because it recognizes the post view as showing a single post. Well, at least until you want to start doing contextual stuff with code and referencing $post_type. For example, I might loop through all of the post types to load something in particular. Well, because WordPress uses single instead of post for the post post type, I have to add in extra code to handle this.

    Sorry if some of this is vague or too technical. I'm trying to keep it as short and simple as possible.

    Proposal

    What I'm proposing is moving toward a post-type-specific system for classes and hooks (where this applies).

    For example, single posts and pages currently get these <body> classes:

    <body class="singular single single-100">
    
    <body class="singular page page-200">

    For efficiency in my own code and to streamline the process, the post class should be more like this:

    <body class="singular post post-100">

    Or, something like this:

    <body class="singular singular-post singular-post-100">

    Why is this important?

    Imagine you ran a real estate site. Once WP makes it easier to create custom post types, you'll likely create something like a property post type (not sure of terminology with real estate). You can use posts for a blog, pages for your regular pages, and "property" to create custom real estate content.

    And, when viewing a singular view of a piece of property, you'd get a <body> class that looks something like one of these two:

    <body class="singular property property-100">
    
    <body class="singular singular-property singular-property-100">

    Then, you could create custom CSS rules specifically for those things.

    This isn't just about CSS either. It'd be something that would benefit the atomic hooks I mentioned earlier. That would create conditionals for you to hook content anywhere, literally.

    The current implementation doesn't allow this. And, holding on to the old methods of single doesn't lend itself well to this technique.

    What do you think?

    The one thing I do know is that the WordPress method is good when dealing with what's built into WordPress, but it doesn't handle custom stuff as well as it should. If you follow my personal blog, you'll likely see a huge post (or possibly series of posts) that deals with this.

    If you do want to see this implemented, let me know how you think the contextual class should be handled. I'm leaning a little more towards this because it seems more structured:

    <body class="singular singular-post singular-post-100">
  13. Standardizing classes, hooks, and templates with hybrid_get_context()

    One of the big things I'm working on in 0.7 is creating the hybrid_get_context() function. This function is for having a standard way of understanding the context (what page we're viewing). It doesn't just give you one context though, it returns an array of contexts that can be used to determine various things about the page. For example, a single post might have a context that looks like this:

    /* The type (singular, archive) page we're viewing. */
    singular
    
    /* What post type we're viewing. */
    singular-post
    
    /* The ID of the object we're viewing. */
    singular-post-100

    Shaping the system

    Well, we've had a contextual <body> class for some time now, even before this was added as a standard in WordPress. But, if you ask me, what's in WordPress is not as clear and organized as it should be. It still holds on to old methods that should be changed to accommodate a more organized template hierarchy. One of my goals I talked about in my original post called Why I created a WordPress theme framework talked about how "WordPress is flawed":

    When I say WordPress is flawed, I don’t mean that the system is bad. I mean this opens opportunities for theme and plugin developers to shape the sytem into something better than what it already is.

    I believe I have an opportunity here to shape the system into something better.

    What does all this mean?

    hybrid_get_context() returns an array of contexts based on the current page. These contexts can be used in any number of ways. Specifically, there are three major areas that could benefit from a single contextual function:

    1. <body> class.
    2. Contextual hooks.
    3. Template hierarchy (though I'm likely not going to implement this soon).

    So, let's say you wanted to change the look of page with a custom background image. You'd have three classes to choose from:

    <body class="singular singular-page singular-page-100">

    singular would refer to all single views (post, page, attachment, custom post types, etc.). singular-page would refer to all Pages. And, singular-page-100 would specifically refer to a page with the ID of 100. We can already do this, but it's about standardizing the names and streamlining the process.

    What happens when you want to insert an ad in the header given a page's context? Currently, you have to write the "context" stuff yourself; you have to figure out the logic behind it all. With the new system, we'd have these hooks:

    hybrid_header
    hybrid_singular_header
    hybrid_singular-page_header
    hybrid_singular-page-100_header

    This does a few things:

    • Works out all the logic behind the scenes for you.
    • Allows you to hook anything, anywhere according to a page's context.
    • Gives you a cascading flow of hooks (from general to specific), so you can add actions or remove actions based on context.

    Faster PHP processing

    The great thing about hybrid_get_context() is that it only needs to run one time on a page. It sets a global variable of $hybrid_context that will be used if the function is called again and returns it instead of running through all the code. While it'll probably not cut back in a noticeable way, anytime you run less code, it's better.

    Standards and streamlining the code

    As a developer, you're always looking for ways to make your code more efficient. Reusing code is a cornerstone of good development practice. Having one function that figures out all the logic just makes sense from a development standpoint.

    In order to do this, the standards must change because the way WordPress handles this does not lend itself well to things like custom post types and custom taxonomies. Nor does it account for more than a handful of common contexts. This is because of the great Sandbox theme. Whoever added the <body> class into WP just took the code from the theme but didn't try to make it better.

    What are the available contexts?

    I'm still working out the kinks with the final naming conventions. Feel free to offer suggestions and alternatives to what's below.

    The context shown in hierarchical view:

    • home (front page of the site)
    • blog (posts page, which can sometimes be the front page)
    • singular
      • singular-$post_type
        • singular-$post_type-$ID
    • archive
      • taxonomy
        • taxonomy-$tax_name
          • taxonomy-$tax_name-$term_slug
      • author
        • author-$author_name
      • date and/or time
        • year
        • month
        • week
        • day
        • hour
        • minute
    • search
    • error-404
  14. Is documentation a part of Hybrid or is it a part of the Theme Club ?

    As Hybrids potential are growing theres more need for documentation. Hybrid is attractive cause we may build on your knowhow, but to utilize the potential we need documentation and examples. When releasing 0.7 I believe its important to release some starter themes and indepth documentation and examples at the same time ( I know you usually make some posts sharing knowhow from work-in-progress )

    Looking forward to your lengthy post to understand the implifications ( is that a english word? ) of the last two comments here ;)

    Custom post types are important, but are there any innovation potential for Hybrid when it comes to how custom fields and meta boxes may be used ?

    I find Pods and Flutter plugins too complex, and More Fields plugin has problems with the dev cycle of WP, which leaves me to rely on Custom Field Template plugin to make a userfriendly backend for custom fields. May Hybrid innovate in some direction to support something like templating for custom fields ?

  15. Dealing with custom post types

    Custom post types are exactly what I need for one of my sites. The folks over at WP seem to be focusing on extending Wordpress' media handling capability. While I'm sure that side needs help, I think they are spending an inordinate amount of time on that instead of improving the core functionality and resolving the existing backlog of issues. I really hope this is just my imagination and they're not losing mission focus. That said, I'd wholeheartedly support your proposing expanding Wordpress' post types.

  16. I think Custom Post Types is very interesting. And I'm sure that you've got the hold of something here Justin. But I also think that this might need lobbying in the trac, because it seems like it's close to the core of WordPress development.

    I found this: http://core.trac.wordpress.org/ticket/9674 that might be of interest to the ones that don't find Justin's ramblings to be greek ;-)

  17. I dont know if its appropriate to lobby in trac. Maybe #wordpress-dev on irc ? Somebody has to have the time, skills and motivation to do the work ( for free ) though.

  18. Contextual filter hooks

    After coding contextual action hooks (which are working great, by the way), I thought it'd be fun to go ahead and make the filter hooks contextual as well. The great thing about this is that all of the legwork has been done by the already-coded hybrid_get_context() function. I haven't played around with it enough to know whether it'll be in the 0.7 release, but I feel like it will.

    So, instead of seeing a lot of apply_filters() in the theme, you'll likely come across apply_atomic() instead.

    With this function, you can filter very specific elements. An often-filtered bit of code is hybrid_entry_meta. But, you usually have to write the code for the context if, say, you only wanted to filter it only on single posts. With the new way, you'd have several filters to decide on:

    hybrid_entry_meta
    hybrid_singular_entry_meta
    hybrid_singular-post_entry_meta
    hybrid_singular-post-100_entry_meta

    So, you can make changes on a broad scale right down to the specific post. This also benefits from only running the contextual code once on a page.

    Sorry if I'm going on and on and on and on about contextual hooks and classes, but this is pretty exciting stuff for me. I feel like this is a real breakthrough in how to manipulate content, especially for developers working on non-standard projects where things need to be controlled on a more atomic level. It also creates less code that less tech-saavy users have to deal with.

  19. Is documentation a part of Hybrid or is it a part of the Theme Club ?

    It's a part of the theme club. I doubt we'd have the 40+ pages of docs we currently have without the club. One day, I hope to have even more docs, but it's definitely a slow process writing it all out.

    Custom post types are important, but are there any innovation potential for Hybrid when it comes to how custom fields and meta boxes may be used ?

    I don't see any potential functions needed in Hybrid dealing with custom fields and meta boxes outside of what the theme currently uses. WP has plenty of functions for adding and extracting data from custom fields and even functions for adding meta boxes. Anything else just seems redundant unless I'm missing something obvious here.

    ... I think they are spending an inordinate amount of time on that instead of improving the core functionality and resolving the existing backlog of issues. I really hope this is just my imagination and they're not losing mission focus. That said, I'd wholeheartedly support your proposing expanding Wordpress' post types.

    I agree that they're spending too much time on the wrong things. To me, they should put more focus on making it easier for developers to extend WordPress. WP is popular because of two major forces — plugins and themes. Give the developers the tools to work with, which involves handling many long-awaited developer-friendly features such as a fast and efficient way to create custom post types. Instead of worrying over features like new smilies and photo albums, they should give developers better ways to create plugins/themes that do these things.

    Just to be clear on custom post types: I'm not "proposing expanding WordPress' post types." I'm simply making the theme more flexible, so that it handles custom post types gracefully.

    For example, let's say WP 2.9 added an easy way to create custom post types. Well, it could possibly be a month or two before the theme was updated to accommodate the new feature. Some folks might want things such as a <body> class that reflects the type of custom content a visitor is viewing. Well, the theme would have to be updated for that.

    I'm proposing preparedness and standardization right now rather than waiting around for WP to get around to implementing new features.

    But I also think that [custom post types] might need lobbying in the trac, because it seems like it's close to the core of WordPress development.

    I think it needs to be pushed. We need people publishing this stuff on their blogs and getting the word out any way they can. I never realized how popular custom taxonomies would be until I published a post dealing with them. I'm fairly certain if more people were aware of custom post types, they'd be just as excited. And, this would make WP the ultimate CMS.

  20. Performance issues with contextual hooks

    The thought that running many hooks would bog down a site came up earlier in this topic. The hybrid_get_context() function handles the theme's side of this. But, WordPress 2.9 should have some improved performance for action hooks too:
    http://core.trac.wordpress.org/ticket/10561

    Filter hooks run fine, so there's no issue there.

    Even with the contextual hooks, there's not anywhere near an extreme amount of processing.

  21. http://themehybrid.com/community/topic/custom-fields

  22. No separation of comments/pings by default

    I originally brought this up here:
    http://themehybrid.com/community/topic/hybrid-version-07-discussion#post-1525

    In the recent Hybrid 0.7 survey (still gathering all the data for this one to show you all), it looks like users have overwhelmingly voted "Yes" for this question:

    Should the current separation of comments and pings be reworked so that users and child theme developers can place the ping list in different places?

    This is great news that so many people are on the same page with this one. The current select option will be removed and put back the original way. This creates a new filter hook, hybrid_list_comments_args, which will allow users and developers to make a decision on what's shown in the main comments list. Then, you can separate comments on whatever level you'd like and not be limited by one of two choices.

    For example, you could hook tweetbacks (if you use the plugin) wherever you want in your comments template. You could do the same with any other comment type (e.g., pingbacks, trackbacks, etc.).

    $comment_type templates

    The change mentioned above also helps out with another change I've wanted to add. Individual comment templates. What I'm currently doing is running a check for templates based on the $comment_type. The default template is comment.php, but you can overwrite this with pingback.php, trackback.php, tweetback.php, and any other comment type with $comment_type.php.

    Checking for $comment_type.php makes this infinitely forward compatible with any new comment type introduced into the system in the future.

    Putting these two together

    Let's suppose a new service called Tooteroo launched and became popular. Then, a plugin was created to add a comment on your posts whenever someone tooted a post. Well, it'd create a new comment type called tootback.

    Maybe you'd only want to change something about tootbacks. You could easily create a file called tootback.php and have it overwrite comment.php when a tootback was being displayed.

    Or, you could even separate all of your tootbacks into a separate list.

  23. New feature proposal: Child theme installer. A function to install child themes hosted with you.

    Joseph Scott, comment on @ justintadlock.com : Child themes pose an interesting challenge. In part because they can, at their own option, replace portions of the parent theme which makes automated testing harder. But perhaps the most difficult part to that puzzle is providing an easy experience for end users when they want to use a child theme. A number of people find it challenging to install a regular theme, adding another layer of issues for them to be aware of isn’t likely to help.

    That said I think the theme browser support that will be in 2.8 could go a long way in helping. Because the install process is hands free we could add the necessary information to ensure that both child theme and the parent theme get installed.

    Child themes install didnt happen, so maybe theme frameworks authors can make a solution within the frameworks ?

  24. On a child theme installer

    It's definitely an idea that has crossed my mind on many occasions. Ptah Dunbar is currently working on an upgrader/installer (at least from what I understand), so I'm waiting to see what he comes up with. It's a heck of a lot easier to just build on top of or use other people's code than spending the time writing from scratch.

    Parent/child themes are becoming more mainstream now too, so I'm hoping we can get this going on the themes repository too. I don't get nearly as many questions about how to install a child theme now as I did a year ago either.

    If Ptah's solution looks good and doesn't require a ton of code, it's definitely something worth looking into. Basically, I'm just waiting on this one.

  25. While waiting you might wanna participate in this ticket:
    http://core.trac.wordpress.org/ticket/10596#comment:3

  26. Custom Post Types:

    From dev-chat:

    <JohnMyr> Re: Custom post types. Just for the log till next week: Im just wondering about priority for better support for custom post types. I have tried to ask around and theres a lot of interest for it, but Im not aware of any work going on. Imo its an important feature, as WP is being used for more than simple blogs. May it have higher priority ? Or is it plugin territory, with plugs like Pods and Flutter ?
    <scribu> JohnMyr: it has just been marked as blessed
    <Jane_> JohnMyr: when i asked the core devs earlier, they're up for it
    <JohnMyr> cool
    <Jane_> but for handling it like the taxonomy stuff
    <Jane_> i.e. support for plugins with better under the hood stuff
    <Jane_> and possibly core integration with a UI and everything in a later version

  27. I'm working on a huge blog post that talks about the direction I think WordPress should move in, so custom post types are on my mind. A large part of this has to do with terminology.

    Maybe the best timing for the custom content type ( CCT ) part would be now, or before next weeks dev-chat if custom post types gets on the agenda ?

    Make some buzz, since two CCT tickets are blessed for 2.9 ?

  28. Slug based category templates is coming. Does that open some new potential ?

  29. Slug based category templates is coming. Does that open some new potential ?

    Nope. We're going to have them regardless of what WordPress does. I'm thinking we might even have:

    taxonomy-category.php
    taxonomy-category-slug.php

    Just to match other taxonomies.

  30. How will that work ?

    Fallback like:

    taxonomy-category-slug.php>taxonomy-category.php>category-slug.php>category-id.php>category.php

Reply »

You must log in to post.

Topic Info