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. First, I'd like to say I really enjoyed all the feedback and discussion on Hybrid 0.6 in these past few months. It really helped shape the final release.

    With Hybrid 0.6 officially out, it's time to open up the discussion on what should be added to the next major release. It'll likely be a few months before this release, so there's no rush. If you have an idea, just post it anytime.

    Some things may get pushed into 0.6.1 or 0.6.2 or back to 0.8. We'll just have to see.

    Much of what went into 0.6 was what I had originally planned for 0.7, but the long wait between WordPress updates gave me some time to add extra stuff in. So, I'm going to start from a blank slate.

    Refinement of how to handle custom taxonomies

    Version 0.6 handles taxonomies well, especially with the taxonomy.php template and the breadcrumbs. But, it's mostly been focused on taxonomies for posts. I'd like to branch out and allow the theme to handle taxonomies with attachments and pages a little better.

    More on this later.

    Entry meta and byline revisement

    Version 0.5 introduced filter hooks for these, but they still need some touching up. Localization of the byline has been tough and is always changing. I'm thinking of just rewriting this stuff from the ground up, which should make it easier for you translators.

    There's also situations where pages are given the same treatment as posts (like in the search results), showing the "Uncategorized" category when it shouldn't.

    Comments area hooks

    The comments area is seriously lacking in action and filter hooks. If you want to change how something works here, it can be pretty tough. This is partially because of how WordPress 2.7+ threaded comments changed things.

    Where would you like to see action hooks in the comments area? What things would you like to filter?

    Faster, lighter CSS

    @importing many CSS files can slow things down a bit. I'd like to hear some ideas on how to deal with this in a way that doesn't break anyone's child theme.

    We could even discuss alternate plugins. At the very least, it's something that should probably addressed on this site by way of tutorials or something.

  2. 1. Custom taxonomies.

    Since you seem to be very much on top of this, being a relative new feature of WordPress, I believe taxonomy support may be a important competitive feature of Hybrid. Custom taxonomy for pages is very important, and also for attachments, even though I don't yet see how. I still miss some understanding of how WP/Hybrid handles attachments and the true potential.

    2. Entry meta and byline revisement

    Entry meta and byline should be handled as a major important design pattern just like navigation, header, sidebar and footer, with flexible solutions, supported either by plugins, the framework core, or custom documented function.php hacks. I believe major newspapers are showing how this should be done. Actually Im planning to release my first WordPress article ever about this topic ( The art of hacking the byline ), once I have learned enough about the subject, so I`m very pleased to see this being one of your priorities.

    Faster, lighter CSS

    I do want fast CSS, but most of all I want easy customizable css that support important css techniques to make the visual design as flexible and easy as possible. The @import problem, should be handled optionally by minifying and combining the css, leaving the original css files on the server for manual editing in WP editor.

    I believe the WP 2.8 use minify for js in the backend, but Buffet frameWork is planning to use it also in the frontend for both css and js. http://www.zy.sg/the-buffet-framework-adding-minify/
    I also believe that its easier to make a bulletproof Minify plugin for Hybrid than a general one like Wp-Minify, which i still have some problems with. http://omninoggin.com/wordpress-plugins/wp-minify-wordpress-plugin/

    I don`t see a need for lighter css in terms of bytes, Id rather see a better css "framework" to easy use various css techniques with, but most important is css documentation.

    A helper css as I suggested in another thread to visualize the different "components" of the theme would be nice. Just use background important! properties to visualize.

  3. In my opinion the most important question to ask about a Theme Framework is:

    Which design patterns does the theme support, and how well does it support and document the possible design patterns ?

  4. 1) Custom Taxonomies-- Echoing John's comment above, I'd definitely like to be able to apply custom taxonomies to pages. Of course, it would also be nice to use the hierarchical capabilities of the custom taxonomy function but I understand that imposes additional challenges.

    Example: Include pages in "Series" with the option to make a page the parent of all other pages and posts in the Series. In my case I have 00s'/will have 000's of pages that will be dedicated to certain topics.

    2) Changing theme syntax without adding script. Examples include: Comments area-- It would be nice to easily change text above and below the comments box. "Allowed markup" and a notification as you've done with themehybrid.com. Comment license text below "Submit" button. Notify commenters their email will not be published.

    Perhaps much of this could be handled in the .po file. ... ?

    3) I'm delighted entry and byline meta will be addressed in v.0.7. Examples: Comments-link needs to be prominent to encourage user interaction. It's somewhat obfuscated when strung together at the end of tags and categories. Another example: I'd like to be able to add the category (and optionally a Series title before post excerpts.

    4) The ability to add meta for google analytics, MS Live / Bing, Yahoo etc in header ala Headspace so to make it easier to add this necessary stuff in without running an seo plugin or a bunch of small plugins (I could be off base here because I haven't really worked on this yet in my development process).

  5. Thanks for all the feedback so far. I'll try to address some of the stuff right now.

    Taxonomies

    My big thing here is making sure the theme will display them when appropriate. Sometimes, this is hard to decide though. For example, it's easy to add a custom "person" taxonomy for image attachments. But, the person taxonomy terms are not displayed anywhere. Doesn't make a lot of sense, right? What I'd like to do is actually show those taxonomy terms on the attachment pages, use them as keywords on the attachment pages, and so on. The idea is to better integrate them with the theme or allow easier integration through filter hooks.

    Entry meta and byline

    My concern with the byline is how easy it is to translate. If I even change one character, the byline has to be retranslated in the next version. It's kind of pain having to update .po files every time a new version comes out.

    I also believe that its easier to make a bulletproof Minify plugin for Hybrid than a general one like Wp-Minify, which i still have some problems with. http://omninoggin.com/wordpress-plugins/wp-minify-wordpress-plugin/

    This is something definitely worth thinking about.

    2) Changing theme syntax without adding script. Examples include: Comments area-- It would be nice to easily change text above and below the comments box. "Allowed markup" and a notification as you've done with themehybrid.com. Comment license text below "Submit" button. Notify commenters their email will not be published.

    Some of this can already be done, but I agree, there's always room for improvement in this area.

  6. In re .po file: push the non-admin syntax to child theme .po.

    In fact, since Hybrid is now a blank parent theme perhaps create a child theme file set users can cut and paste out of the package and into their themes directory to start off the development of their own theme. If documented (and read) it might cut down on the number of support questions you have to handle.

  7. In re .po file: push the non-admin syntax to child theme .po.

    Hybrid handles a most of the text. It's best to have a single translation file rather than many translation files (though child themes sometimes need extra .po and .mo files). This cuts back on the amount of work translaters have to do.

    In fact, since Hybrid is now a blank parent theme perhaps create a child theme file set users can cut and paste out of the package and into their themes directory to start off the development of their own theme.

    We have this with the Skeleton child theme. But, I want to do a few child themes that are a mixture of the Skeleton theme with some extra functionality and style.

    I like the idea of giving people a jumping off point.

  8. Cut, cut, cut

    Version 0.6 was all about cutting out all of the junk. But, there's probably areas that could be cut back on some more. If you know of any code that's just adding extra stuff that wouldn't be needed by most people, feel free to let me know.

    The more lightweight the theme is, the better.

    Text filter hooks

    You can filter nearly any text in the theme to say just about anything you want, but there's still some text that's not able to be filtered. I'd like to start working on knocking some of this out of the way.

    Footer setting for WPMU users

    This applies to WPMU users. I realize that there has to be some restrictions on what your users can do. I want to make sure Hybrid doesn't get in the way of that.

    My question: 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.

  9. At the risk of seeming abrupt, that what is lacking - and what would constitute the "killer app" for the Hybrid framework, per se - would be to SOLVE the problem of laying out a design - from within the framework itself - and to have it generate the appropriate CSS - to support the "generated" child themes.

    Hybrid is already headed in the inevitable direction - in that increasingly (and astutely, I might add) Justin has recognized the value in expanding on the Widget mechanism to allow "insertions" at various points of "functional content". Why not be the first framework to take the next logical step and include some sort of clever, ajax-driven "template layout editor" within the Hybrid Settings area - that would allow the end-user to either "move around and resize" boxes or other designated "container units" within Hybrid that would automatically generate the correct Hybrid-based CSS for each template file - and prumulgate them to the appropriate "child theme" directory.

    The first generation could be as simple as re-arranging "named boxes" within a scaled-down page display - which would somewhat mimic the current widget administration environment (or similar). An early enhancement would be to be able to stretch or expand the boxes that were being manipulated in both dimensions...

    It's clear to me that the existing style sheet hierarchy would lend itself to such an approach - and, frankly, after seeing the original enhancement to the ajax-driven widget administration scheme - I thought - Well, why not provide a similar mechanism for the overall layout as well?

    Certainly, if anyone can pull-off such a thing, I think that Justin could... and it might as well happen in Hybrid - FIRST.

    Sure, it would mean "standardizing" at least SOME of the CSS - But that is happening already with the various widget areas... I think that for the average user - it is difficult to differentiate at times between all of the possible paths to create a similar result. In all the years I have been pouring over support forums - I am stuck by the number of interactions in which the end-user simply wants to know "what to alter where" - but really has no clue - of the relationship bewteen things.

    A framework - if anything - should simply that somehow - yet ideally leave the option for more advanced users (and designers) to skirt those standardizations. We're six years into WordPress now, and it still doesn't have an end-user friendly way to build a basic 2 or 3 (or n) column design from within the environment itself - largely because of the inherent flexibility of the underlying technologies from which it is created... You can name a selector ANYTHING! - and hence, every single WordPress has different CSS to describe what are functionally, largely the same things. The ability to associate "real estate" with "formatting" and "functional content" within a single paradigm is the essential missing element.

    Why not be the first to "bind" the layout and CSS to the Hybrid framework at the template-level, so that, eventually, users will be able "drag" functionality "into" the layout itself - and not just within the well-defined "widget areas"? Perhaps these Hybrid "objects" themselves could then be exported and imported as well.

    it seems as it is where Hybrid seems to be going "conceptually"- (if I have sufficiently immersed myself in Justin's/Hybrid's concepts) - See "Hybrid Hook Widgets"

    The "clever" part would be to bifurcate the "customizable" and "generated" resultant objects - and possibly develop some manner that they could be imported and exported such that the associated CSS went with them. Obviously, as a general approach to CSS, this would be nearly impossible - But within the limited real estate of the vast majority of WordPress sites - reconciling the applicable styling from within the "box-in-a-box" model should be possible. If nothing else - it should be possible to load it into the DOM - and build the editor as some sort of browser extension - whose resultant could be re-imported back into WordPress/Hybrid.

    Anyway - that is my suggestion - For whatever upcoming Hybrid version - But before someone else does it - because whomever eventually delivers this basic capability will solve a substantial portion of the end-user inquiries - who basically want to make minor changes to layouts - but don't know (and don't want to know, particularly) the difference between a style sheet and a hole-in-the-wall.

    I'm clear as a bell, from everything that I have read here, and in fact, the entire value-proposition of this site, itself - that Justin has fundamentally grasped the basic underlying issue with WordPress - and the need for a user-centered (rather than a feature-centered) set of criteria - for enhancement. The environment couldn't be "richer" in functionality - However, exposing those capabilities, and indeed, refactoring them for meaningful "consumption" requires real genius and perspective.

    As far as I can tell - no other framework has addressed this basic insufficiency in user-centered design.

  10. @mp

    For the most part, I like your ideas. But, I don't like them as a part of the framework itself and think this should be something discussed in the Ideas forum outside of the Hybrid 0.7 discussion.

    Hybrid is meant to be...

    • A lightweight framework (imagine the frame of a house).
    • A development tool to create child themes and plugins.
    • An extension of WordPress on the frontend.

    What we're discussing in this thread is strictly about the framework itself. Like I said, your ideas are great, but mostly outside the realm of what we're focusing on here.

    I'd love for you to open a new topic and open a discussion on how you'd like to see the theme extended. Heck, copy and paste if you want.

  11. Some thoughts on Hybrid

    Sometimes, I think I need to better explain what Hybrid is to me and where I'd like it to go, so I thought I'd offer a bit more about that.

    User base

    As a theme developer, I have to cater to three main groups of users:

    1. People with little or no PHP, HTML, and CSS skills.
    2. People with some skills in between 1 and 3.
    3. Developers that need something to build from.

    I'd like Hybrid to cater to all three in some way.

    Hybrid by itself should be first and foremost something for group 3. It's a framework. I created it as a framework for my own development projects (and eventually released it to the public, of course).

    The extensions (plugins, child themes) built on top of Hybrid should cater to groups 1 and 2.

    Of course, some users from group 2 are using Hybrid as a tool to build their own custom child themes, which is something I had not really expected. It's easy to see how well frameworks have been accepted into the WP community when this group of users start using them in this way.

    Hybrid in the future

    I honestly don't know where things are going 100% for sure. Version 0.6 put Hybrid at a place where I thought we'd be a version or two down the road.

    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.

    For the most part, I don't think Hybrid will be gaining major features like we've seen in the past. The code is pretty stable.

    Here's my roadmap for each version:

    • Make the code more efficient.
    • Make the theme lighter in whatever ways possible.
    • More flexibility (action hooks, filter hooks, stylesheets, etc.)

    This is what it's all about.

  12. "Atomic" (contextual/dynamic) hooks

    One great thing about Hybrid's action hook system is that you can plug in content anywhere. Great, right?

    An example of this would be Hybrid's main header hook:

    do_action( 'hybrid_header' );

    What happens when you want to only hook something to say the category archives? Well, you'd have to write an if statement and use a WordPress conditional tag in your code. This is pretty simple stuff when you get right down to it, but it could be even easier. What I'd like to do is add atomic hooks.

    So, the example above would actually become:

    do_action( 'hybrid_header' );
    
    do_action( 'hybrid_archive_header' );
    
    do_action( 'hybrid_category_header' );
    
    do_action( 'hybrid_category-100_header' ); /* 100 is the category ID. */

    So, instead of having to write out all of the conditional statements and such, you'd only have to pick out the hook you want. It would drastically cut back on errors and code you must write.

    While this seems like more code would have to go into the theme, it's actually less code. Some of the functions I'm putting together cuts back in several places to make everything more efficient and lightweight. Plus, this is completely backwards compatible with everything currently in Hybrid; it's all done behind the scenes.

  13. @JustinTadlock

    Like your thinking. Seems like there'd be an enormous number of possible atomic hooks many of which wouldn't be used. Would it be possible to have them in a child theme .php file where unused hooks could be deleted? That could also help lighten the load.

    Re the .po file, the way you've set Hybrid up (as a framework) most all users have a child theme. This is especially nice because it protects from having theme modifications overwritten when you upgrade the Hybrid parent. Is there anyway to have a child theme .po file with all of the syntax in the parent so it's not overwritten during the framework upgrade process? I'll have to look, but my recollection is that Thematic takes this approach.

  14. Would it be possible to have [atomic hooks] in a child theme .php file where unused hooks could be deleted? That could also help lighten the load.

    Nope, this wouldn't be possible.

    There's little PHP overhead with this though. What I'm actually working on is a contextual class that could be used over and over to lighten several things within the theme.

    Is there anyway to have a child theme .po file with all of the syntax in the parent so it's not overwritten during the framework upgrade process? I'll have to look, but my recollection is that Thematic takes this approach.

    As far as I can tell Thematic does this the same as Hybrid. The difference I can see is that Thematic packages the language files within the theme itself. I'd like to do this with Hybrid, but there's way too many translations. It would make the download enormous.

    Could you explain more though? It'd be nice to have some better options for non-English bloggers.

  15. Tag and category templates

    Taxonomies have templates like this:

    taxonomy.php
    taxonomy-tax_name.php
    taxonomy-tax_name-slug.php

    This is wonderful, yet two of the the default taxonomies with WordPress don't use this method: post_tag and category (link_category uses the method above).

    They use the tag.php/tag-slug.php and category.php/category-ID.php method of loading templates. Obviously, this was thought of before the taxonomy API came into full swing, but I'd like to change this.

    I'm thinking tags and categories should load like this:

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

    It puts them in line with all other taxonomies. It's more organized.

    If I decide to go with this, it'll definitely be backwards compatible with the old method. I also have a huge WP blog post I'm working on that touches on this issue.

  16. Contextual PHP function

    What I'm working on is setting up a new contextual function to handle the contextual hooks:

    hybrid_get_context();

    This function would return the context (i.e., archive, category, category-100, etc.) whenever called. Obviously, this might be a slight problem if needing to check the context many times within one page load.

    What happens is a global variable called $hybrid_context is set. If that variable is already set, the conditional checks will not run again. So, the check is only actually run once on a page.

    This cuts back on PHP processing and the function can be reused in things like Hybrid's <body> class.

  17. Getting rid of hardcoded stuff

    One thing that Hybrid does well is that it allows you to change just about anything, but there is some stuff that can't be changed from a child theme or plugin.

    What I'd like to do is make this theme even more flexible. If there's something hardcoded (text, URL, etc.), you should be able to change it if you want.

    So, I'm opening the floor for everyone to find these things. If you come across something that needs to have a filter, please post it here.

  18. Reworking of the home/blog/front-page system

    There's a lot of confusion between what is the home page and the blog page.

    is_home() technically means the "blog" page. This is where the latest posts are shown.

    is_front_page() means the front page of the site.

    The reason for this is because WordPress originally didn't allow users to set a page as a front page. Everything was handled by home.php or index.php. It's kind of silly for is_home() to mean the blog page. There should be an is_blog() function but there isn't.

    The current WP <body> class system recognizes is_front_page() as home and is_home() as blog. Yep, even more confusion. But, that's what we'll be going with permanently.

    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.

    Let's hope this cuts down on some confusion.

  19. Removal of separation between comments and pings

    In 0.6, I introduced the ability to separate comments from pings. This was a feature that was often requested, but the current implementation is crude at best. While the easy checkbox works, it makes things less flexible than they ought to be.

    Currently, the arguments for wp_list_comments() are hardcoded. I'm thinking a filter hook called hybrid_list_comments_args would be better. We'd list all comments/pings together, but users could easily filter out the pings.

    Then, if a people chose to do so, they could hook another instance of wp_list_comments() in a place of their choosing. For example, you could list your pings below the normal comments or opt to put them after of the comment respond form.

    It would keep the files cleaner and it's more in line with the rest of the framework. Plus, child theme authors could do much more with this if they wanted.

  20. I appreciate the clarification (and articulation) of your intentions.

    Given that you want the framework to remain "thin" and potentially get even "thinner" - How about laying the groundwork within the fundamentals to "associate" the various "created" elements (action hooks, widget areas, page_templates, etc.) with an embedded taxonomy - Such it would be possible to "push-off" any customization - away from the core - by building a new and unique class of "designer" plugins - which could then "read" and then "operate" on the elements once the theme framework was "loaded"?

    No matter how "thin" or "well-organized" the framework is - any meaningful customization requires that the "definitional" elements be brought together with the "executable" ones - and the minimal ability to do so - requires that they are identifiable within some sort of name space.... Sandbox does this - but "statically" by defining... and does nothing with respect to code...

    If on "initialization" the framework scanned all the "well-defined" directories for pertnent files, (and perhaps "well-named" elements) and registered those within the taxonomy - then maybe customization could be layered over that with plugins - which could then "generate" the required "custom" stuff...

    Hybrid child themes - as currently implemented wouldn't ever have to reference the taxonomy at all - But it would be there, in case, you wanted to develop some code to manipulate the Hybrid unique elements - and then generate "to be loaded later" - PHP or CSS in the form of a customized child theme.

    The point is - unless you're going to require end-users/developers to manipulate CSS and PHP code - with or without their limited knowledge - and REQUIRE them to understand the relationship between the two - You're going to have to provide a context where those things can be manipulated at runtime by code - that exhibits some intelligence...

    None of this is required if you put the tools outside of of WordPress - but that would be "cheating" - wouldn't it? ...

  21. May you consider backend content workflow enhancements ?

    http://wordpress.org/extend/plugins/more-fields/

  22. Thank-you, John. Appreciated.

  23. Could you explain more though? It'd be nice to have some better options for non-English bloggers.

    Unfortunately, I deleted my thematic child theme but this is what I recall:
    TM uses just one each .mo and .po file in the parent theme. I copied the .po and .mo files from the languages folder into a languages folder in my child theme then modified the syntax in the English file to suit my needs.

  24. I copied the .po and .mo files from the languages folder into a languages folder in my child theme then modified the syntax in the English file to suit my needs.

    This sounds like a more forward-compatible solution. Let me see what I can do. It'd be nice to keep everything within the child theme's /languages folder.

  25. I would like to see the related articles display moved to above the author bio box.

  26. I'm thinking tags and categories should load like this:

    taxonomy-post_tag.php
    taxonomy-post_tag-slug.php

    taxonomy-category.php
    taxonomy-category-slug.php
    It puts them in line with all other taxonomies. It's more organized.

    What should be added to the next major release?
    You answered your own question :)

  27. I would like to see the related articles display moved to above the author bio box.

    There is neither a related articles display nor an author bio box in the Hybrid theme.

  28. Filter hook to disable Hybrid Settings meta box

    Some folks might not like the idea of every author of their blog being able to change the Hybrid Settings on a per-post/page basis. This came up in this forum thread:
    http://themehybrid.com/support/topic/how-to-remove-meta-box-for-posts-with-multi-author-blogs

    A simple true/false filter hook should suffice. Maybe pass the current user ID as a second parameter.

  29. Comment templates by comment type

    I'm thinking of making the theme a bit more atomic by allowing individual comment templates according to the comment type.

    comment.php		/* Base comment template. */
    
    ping.php		/* Pingback/trackback template, which can be overwritten. */
    
    pingback.php		/* Pingback template (overwrites ping.php). */
    
    trackback.php		/* Trackback template (overwrites ping.php). */
    
    $comment_type.php	/* Custom comment types (e.g., tweetbacks). */

    This would probably make it easier to overwrite in child themes for those of you that need that type of functionality.

  30. Remove custom avatar from settings page?

    Currently, you can add a custom comment avatar from the Hybrid Settings page. While this is a neat feature, it doesn't exactly fit in with how other avatars work.

    For example, custom pingback and trackback avatars must be added to the child theme's /images folder, like this:

    /child/images/pingback.png
    /child/images/trackback.png

    I'm thinking it might be better to just do the default avatar the same way:

    /child/images/avatar.png

    One could argue that all three should have a settings box, but that doesn't account for blogs using some type of custom comment type. By moving the avatar setting, the theme could simply look for:

    "child/images/{$comment_type}.png"

    That's one line of code as opposed to several different checks for the type of comment.

    This does several things:

    • Cuts back on the amount of code that runs.
    • Allows child theme developers to add custom avatars.
    • Better supports all comment types (probably making this more forward compatible with future plugins and better support in WP for custom comment types).

Reply »

You must log in to post.

Topic Info