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.8 discussion

Justin Tadlock (Key Master)
Posted 3 years ago | Permalink
I wanted to give myself a bit of a break before getting into discussing Hybrid 0.8 There was such a change between the 0.6 and 0.7 branch that I needed to cool off for a bit.

But, it's now time to start thinking about version 0.8. I'll start off by listing some of the things I'd like to see, and I hope we have as much input as we did in the 0.7, which ended up with 149 posts.

Page template name changes

In 0.7, I deprecated all the file names of the custom page templates. What I'd like to do is finish the template hierarchy change by making all page templates begin with page-. This makes things much more organized.

For example, the archives.php file would be changed to page-archives.php, the biography.php template file would be changed to page-biography.php, and so on.

I want people to be able to recognize these as page templates.

Full support of custom post type templates

WP 3.0 is getting massive changes for support of custom post types. I'd like to make sure all post types follow the same pattern as posts and pages do in the template hierarchy. So, the hierarchy would be:
```
{$post_type}-{$custom}.php
{$post_type}-{$post->post_name}.php
{$post_type}-{$post->ID}.php
{$post_type}.php
```
This also goes along with the name changes of the page templates.

Atomic hooks allow more than one argument

Right now, only apply_atomic() allows a single argument (other than the name of the hook). do_atomic() takes in no extra arguments. I'd like to be able to add any number of arguments to either.

If this is all Greek to you, don't worry. This is mostly a developer feature.

Change the byline and entry meta to shortcodes

In 0.7, I introduced the ability to use shortcodes in the byline and entry meta filters, but the default is still a bunch of jumbled up PHP code. Much of this has to do with preserving legacy functions.

But, I'd like to change the functions to shortcodes by default. This helps out with cutting back on code and makes it easier to translate.

Removal of Tabular Data extension

This extension (located in /library/extensions/tabular-data.php) was a legacy file carried over from the earliest days of Hybrid and hasn't been loaded by default in several versions.

The only person I know that actually uses it is me, and I don't even need it anymore.

Continue making the code lighter and more efficient

As with all releases, I want to cut back as much as possible while still offering the same or more functionality.
Jan Egbert (Member)
Posted 3 years ago | Permalink
Byline and entry meta shortcodes
I'd like to be able to use the same shortcode (with different arguments) twice. Right now when I want to list categories and a custom taxonomy, only the first called shortcode get's executed.
```
$byline = '<p class="byline">By [entry-author] [entry-terms taxonomy="category" before=" | "] [entry-terms taxonomy="brands" before=" | "] [entry-edit-link before=" | "]</p>';
```
The above $byline would produce a byline like this:
By Jistun Todlack on January 14, 2010 | WerdPross, Thimy Hebred [entry-terms taxonomy="brands" before=" | "] | Edit

A shortcode for displaying custom fields
This should be pretty easy, but I'd really like this extra shortcode. The get_post_meta() would be a solid base for this shortcode. I believe there are some plugins adding this shortcode.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

RE: Byline and entry meta shortcodes twice

This is already possible in version 0.7.

RE: Shortcode for displaying custom fields

How would you handle a returned array? Shortcodes rely on a returned string, and by using get_post_meta(), we'd only be limiting its functionality to a single-value custom field.
Kyle D (Member)
Posted 3 years ago | Permalink

Allow for NOT in Atomic Hooks

For example, to have my_function called on all pages but ID 12:

add_action("hybrid_not-singular-page-12_before_content", "my_function");

I took a look at the get_context plugin, and it looks like this might be tricky, but I'll throw it out there anyhow.

Hook between posts

Outside of the post div. The area mentioned in this post:

Widget Area between nth and n+1th post on frontpage

Doesn't have to be a widget, as the Hybrid Hooks plugin could widgetize it if necessary, but I think it'd be a handy place to have a hook, and I think you could add it without messing up current sites. The $post_count value within the hook would be handy.
designOdyssey (Member)
Posted 3 years ago | Permalink

OK, I'm biased, but I'd love an "extension" for Buddypress. Given BP1.2 will work on Wordpress 2.9, this might be a good time to do this. BP will likely be stable enough in its functions, setup that this could be warranted.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink
RE: Allow for NOT in Atomic Hooks

I understand the reasoning and usefulness behind this idea, but it's just not feasible.

Let's suppose you have exactly 100 pages published. For this to work, every atomic hook would produce 99 - 100 hooks for "not" pages (depending on what is being viewed).

For example:
```
hybrid_not-singular-page-1_before_content
hybrid_not-singular-page-2_before_content
hybrid_not-singular-page-3_before_content
hybrid_not-singular-page-4_before_content
hybrid_not-singular-page-5_before_content
hybrid_not-singular-page-6_before_content
hybrid_not-singular-page-7_before_content
hybrid_not-singular-page-8_before_content
hybrid_not-singular-page-9_before_content
hybrid_not-singular-page-10_before_content
...
```
And so on. That's just dealing with pages. And, we're only looking at a single atomic hook here. We're not even looking at other "not" scenarios. I could imagine this just breaking a ton of sites because of the load.

RE: Hook between posts

I agree that this would be useful. But, I've got to figure out a way to add this outside of the templates, which I'm not sure if it's possible to do this outside of templates. If it must be added to templates, the hook wouldn't work with a ton of sites that already use templates in their child themes (e.g., Hybrid News' front-page.php, Old School's showcase.php, custom templates already made).
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

RE: BuddyPress

I definitely plan on adding some BuddyPress functionality.

Right now, I'm just trying to figure out what's specific to the BuddyPress themes and what's specific to the plugin that needs to stay in the themes.

Ideally, Hybrid would be just another BuddyPress or WordPress theme. I believe it should handle both scenarios.
Kyle D (Member)
Posted 3 years ago | Permalink

RE: Allow for NOT in Atomic Hooks

Ya, I looked at the current function, and figured it wouldn't be feasible as it is currently written for just the reasons you stated. Thought maybe you had some notion on how to get the context in a different fashion.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink
BuddyPress integration

I spent the entire weekend playing around with BuddyPress trunk. Well, most of the weekend anyway. I learned a few things:
1. I really don't understand half of it because I haven't used it.
2. The codebase seems a bit unstable in terms of direction (theme-wise).
3. There's next to nothing in documentation.
4. Adding in BuddyPress templates is like coding an entirely new theme.
With that in mind, when BuddyPress integration will be available is up in the air. It may be version 0.8, 0.9, or 1.0. I just don't want to make any promises yet. I may test out compatibility with a child theme or even make a plugin. Mostly, I think there needs to be a pre-BuddyPress integration period with loads of testing and ideas thrown around.

I'll probably open a separate topic for BuddyPress to keep the discussion in one place.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink
WordPress 3.0 Menu Management

Menu management will be coming in WP 3.0, and I'm sure most folks will want to take advantage of this. So, I'll go through some of the pros and cons and list some ideas.

To see what the heck I'm talking about, check out the Trac ticket and/or the video:
http://core.trac.wordpress.org/ticket/11817 (Trac ticket)
http://wpdevel.wordpress.com/2010/01/17/menu-management-ui/ (Video)

Problems

I suppose the biggest issue is going to be backwards compatibility with the current system for displaying a page menu and the new system. Old CSS classes and IDs wouldn't work for the new menu.

The new system will lend itself well to a more "generic" menu that houses any type of items (pages, categories, tags, etc.). A name change is in order for that reason alone. At the same time, I need to take advantage of the features and functionality of the new Menu API that's offered.

So, my solution to the problem right now is to offer a checkbox on the Hybrid Settings page that allows users to move to the new system or use the old system. This will probably need to stay until v.1.2 or so.

Features
- Menu creator built straight into WP isn't enough for you?
- Atomic hooks for any type of menu you want to build.
- Drop-down CSS and JavaScript that works with any menu you create.
Laying the code out

Once the new system is in place, you'll get something like this:
```
<div id="<?php echo $menu_id; ?>" class="menu-container">

	<?php do_atomic( "before_{$menu_id}" ); ?>

	<div class="menu">

		<ul class="sf-menu">
			<li><a href="#" title="Example">Menu Item</a></li>
		</ul>

	</div>

	<?php do_atomic( "after_{$menu_id}" ); ?>

</div>
```
Ideas and suggestions

A lot of this is just hypothetical at this point. Code needs to be written. Things need to be tested. And so on.

Now's a perfect time to offer any ideas you have about this because we're in an extremely early stage of its development.
Kyle D (Member)
Posted 3 years ago | Permalink

Re: WordPress 3.0 Menu Management

I don't tend to do anything too elaborate w/ my navigation - but perhaps there be a need for a hook wrapping the outside of the div you mentioned above? Or do you think that'll be something better handled with some of the other hooks?
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

RE: Wrapper hook for menus

This would already be taken care of because the menu itself would need to be "hooked" somewhere. So, that same hook would be available for anything you'd want to add before or after the entire menu.
designOdyssey (Member)
Posted 3 years ago | Permalink

RE: Buddypress Integration

I agree with your comments and look forward to the separate thread. I've been following Andy's responses to my questions - http://buddypress.org/forums/topic/buddypress-theme-with-wptheme#post-32424 and http://buddypress.org/forums/topic/buddypress-theme-with-wptheme#post-32593

Also, I "talked" to Ron and he said his Buddymatic version for Hybrid was based on 0.6.2 and that WP.org might not release it because it was so close to Hybrid. If I get a copy, I'll tear through it and see what he did. Sounds like he made new Hybrid Templates with the BP functionality he needed 'stolen' from the original BP templates. That would create the need for rewriting those templates when BP is "upgraded."
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink
Post-by-post layouts

One of the things I originally had decided not to go with when creating Hybrid (but had considered) was the idea of choosing a layout on a per-post basis. Those of you in the WP loop have probably heard about another framework that's going to do this (Genesis).

In general, I'm entirely against making this a default because the framework would be putting an additional style burden on child-theme authors, making it a feature they must cater to. The ability to create whatever type of child theme you want is something I won't sacrifice for a few bells-and-whistles.

What are per-post layouts?

Basically, in the "Hybrid post/page settings" box, there'd be a way to select 1 of 6 different layouts:
- 1 column
- 2 columns, content left
- 2 columms, content right
- 3 columns, content left
- 3 columns, content right
- 3 columns, content centered
Then, when on the singular view of that post/page on the front end of the site, it'd have that layout. Pretty neat, right?

Idea on how to do this w/o sacrificing my principles

In WordPress 2.8, two new functions were added called add_theme_support() and current_theme_supports().

So, if a child theme developer wanted to support this feature, they'd add this to their child theme:
```
add_theme_support( 'post-layouts' );
```
Then, Hybrid could check current_theme_supports( 'post-layouts' ) to see if it's enabled.

What do you think?

This idea isn't set in stone yet. It's just something I'm toying around with.
Kyle D (Member)
Posted 3 years ago | Permalink

Reading about this Genesis feature definitely piqued my interest. I like your idea of having it be something optional. That way child theme authors that do want to add the feature are able to.

Can you maybe explain the difference between this and post templates down the road?
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

Can you maybe explain the difference between this and post templates down the road?

That's a good question and one I've been struggling with.

Post layouts can be done in two ways: 1) Use a custom template. 2) Use the post layouts idea above.

With templates, there'd be no need to check for this within Hybrid. The child theme would simply have the template or not.

Here's the real benefit of post layouts as opposed to templates: What happens when you want to use the "Archives" template to show your archives yet have three columns as opposed to two? With post layouts, you could use any template in conjunction with the layout you want.

In my opinion, templates should deal more with function than with form. Of course, there are cases where it needs to do both or just deal with form.

The biggest advantage of using post layouts is also its biggest flaw. Let's suppose you selected the "No Widgets" template and used the "Three Columns, Content Left" post layout? These don't mix so well because the widgets would've made up two of those columns.

Another disadvantage I see is that if a child theme added support for post layouts, it would need to support all of them. It wouldn't just get to pick and choose a couple. But, I'm going to look into some solutions for this.
Jan Egbert (Member)
Posted 3 years ago | Permalink

One extra context aware hook

not-home

Would make something like this possible: add_action ( 'hybrid_not-home_before_entry', 'my_byline');

For an example of a situation this would be useful see this post: http://themehybrid.com/support/topic/removing-categories-beneath-header-in-hybrid-news
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

RE: One extra context aware hook

See my post above about "not" scenarios:
http://themehybrid.com/community/topic/hybrid-version-08-discussion#post-2395
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

Get the Image update

In rare cases, when listing a custom taxonomy or some other type of post list, attachments themselves are the "posts" being shown. It makes sense that an image for an image attachment would be shown. But, it's not (don't know of any image plugin that does this).

The newer version of the script will grab the image for the image attachment when listing attachments.

Confused? Just know that it's a good thing.

For those of you that list attachments (maybe you have a "person" taxonomy or something), the script will definitely show a thumbnail alongside it now.

I may push this update in Hybrid 0.7.2 since it's only a few lines of changes, and the plugin version will be getting this update soon.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

Deprecating hybrid_page_nav()

I just want to officially note that hybrid_page_nav() will be deprecated in 0.8. This also includes the hybrid_before_page_nav and hybrid_after_page_nav hooks.

Don't worry though. This functionality will probably be in the theme somewhere close to forever.

See my earlier discussion on the new WP menu system for the "why" behind this decision:
http://themehybrid.com/community/topic/hybrid-version-08-discussion#post-2399
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink
Handle all "comments are closed" scenarios the same

Currently, posts and pages are handled slightly differently when these conditions are met:
- Post doesn't have comments.
- Comments are closed.
- Pingbacks and trackbacks are closed.
Posts display a message, and pages display nothing.

With the introduction of custom post types in WP 3.0, I think it best to handle comments uniformly across all post types. I believe the best way is to handle it how pages are currently handled — display nothing. If someone did want to add a message, it would be pretty simple. Plus, it's much easier to add new code than to take away preexisting code.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

Hooking shortcode creation to "init"

Shortcodes currently just exist in a file called shortcodes.php. Without a bunch of testing, it's tough to figure out when they're loaded.

I'm creating a new function called hybrid_add_shortcodes(), which will be added to the init action hook.

So, if you need to use remove_shortcode() to remove one or more of the shortcodes, you can know exactly what point to fire your custom function.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

Making the sub-nav-indicator display on menus by default

Hybrid uses a jQuery plugin called Superfish. By default, Superfish adds indicators for sub-menus. Right now, these are turned off within the theme.

I'm thinking it would be great to have these turned on because turning them on now requires the user to write new JavaScript code. Whereas, this can be turned off via CSS. I'm guessing it's much easier to add CSS code than JavaScript.

Plus, you could easily design your own arrow styles and do some different stuff. More flexibility is always good, right?

This change would make menus look like:

Home About Top-Level 1 » Top-Level 2

I've already tested this with several child themes, and it wouldn't cause any damage.
rickybuchanan (Member)
Posted 3 years ago | Permalink

"Handle all "comments are closed" scenarios the same" - Yes please. It's been bugging me that this is different with posts/pages but I haven't been able to figure out how to fix it easily.

With shortcodes, I've always put mine in functions.php - is this not the canonical way to do it?

All of this sounds very exciting, BTW. I'm not so fussed about the menus as I tend to use very simple menus and I've widgetized most of them anyway for ease of updating and so they don't automatically pick up new pages when I'm not expecting it. I may switch back to a native system if it's made easy to manage.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

With shortcodes, I've always put mine in functions.php - is this not the canonical way to do it?

Yes, that's how to do it. I'm referring to the code within the Hybrid theme. I just want to hook them at a specific point so they can easily be removed if needed.
Thomas Clausen (Member)
Posted 3 years ago | Permalink

I still think we have a little SEO fruit to be picked here: http://themehybrid.com/community/topic/metadescription#post-2334
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

@Thomas Clausen

I'm still thinking over the idea. One of the problems sometimes is that grabbing the content conflicts with plugins that don't appropriately check for in_the_loop() before running their filter functions (filters on the content). Then, the plugin authors blame the theme, even though it's the plugin's issue. I've already had to go through a bunch of headaches with dealing with this in the past. Though, I may look into just using the global $post, but that has its own problems and limitations as well.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink
#content ID now officially moved to the template files

A few versions back, it was decided that <div id="content"> and its closing </div> needed to be in the main template files (like page.php and post.php) and not in header.php and footer.php. This allows for more flexible designs.

So, the #content ID was deprecated in favor of using the .content class for styling.

To handle the transition, this function was called in header.php and footer.php:
```
<?php hybrid_content_wrapper(); ?>
```
What's changing?

The mentioned function is being removed from header.php and footer.php. So, <div id="content"> will no longer be output by it.

In other templates, we have this:
```
<div class="hfeed content">
```
This will be changing to:
```
<div id="content" class="hfeed">
```
Continuing the transition

In order to continue this transition for a few more versions, I'll continue using .content for styling purposes.

In version 1.0 or 1.1 or so, I'll probably move back to using #content.

Either way, both .content and #content will be interchangeable. You can use either one you want.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink

Removed functions from deprecated.php

Functions that were "removed" and placed in deprecated.php from the 0.2 and 0.3 branch will be completely removed from the theme.

I'm thinking that 5 branches is plenty enough time to get rid of the functions, especially since they only output a theme-based error message.

What does "deprecated" mean?

When a function becomes deprecated, it's placed in the /library/legacy/deprecated.php file. The function itself still works perfectly fine for the next few versions.

Some functions are "deprecated" for a long, long time. For example, when hybrid_page_nav() is deprecated in version 0.8, it'll probably be usable for maybe 10+ major updates. Other functions may only be deprecated for a couple of versions.

What does "removed" mean?

When I remove a function, I don't literally remove it from the theme. Instead, the functionality of the function is removed and replaced with an error message. So, if the function is called, you'd see something like this:

function_name() — This function has been removed or replaced by another function.

Now, I've decided after 5 major branches of being in "removed" status, the function should be completely deleted from the theme. So, in version 0.8, all functions removed from version 0.3 and earlier will really be removed from the theme.

Why remove functions at all?

Technically, the functions could remain forever, but I like to keep things as lightweight as possible. There's no point in loading a lot of PHP functions that can't be used.

It'd be great if one day we didn't have to load deprecated.php at all (highly unlikely). But, I'd like to at least get to a point where there's not 500+ lines of code we don't need.
Justin Tadlock (Key Master)
Posted 3 years ago | Permalink
RTL (right-to-left) Stylesheet

I removed the rtl.css stylesheet a while back because there wasn't any community traction for it. I'd really love to get this incorporated into the theme again.

Of course, I don't speak or write in any right-to-left languages, so it's kind of tough for me to understand how to best design for this.

My ideas so far

I think the easiest route would be to create a rtl.css stylesheet that would be loaded after screen.css and "fixes" any text direction and float issues. There'd also be a rtl.css file in the root Hybrid directory, that when loaded for right-to-left languages, would look like this:
```
/* Get base CSS */
@import url('library/css/21px.css');

/* Get layout CSS */
@import url('library/css/2c-l-fixed.css');

/* Get plugins CSS */
@import url('library/css/plugins.css');

/* Get drop-downs CSS */
@import url('library/css/drop-downs.css');

/* Get default CSS */
@import url('library/css/screen.css');

/* Get RTL CSS */
@import url('library/css/rtl.css');
```
An alternative would be to completely recreate another screen.css file, calling it rtl.css still. The stylesheet loaded would look like this:
```
/* Get base CSS */
@import url('library/css/21px.css');

/* Get layout CSS */
@import url('library/css/2c-l-fixed.css');

/* Get plugins CSS */
@import url('library/css/plugins.css');

/* Get drop-downs CSS */
@import url('library/css/drop-downs.css');

/* Get RTL CSS */
@import url('library/css/rtl.css');
```
The first option would probably be easiest because it's less code to deal with.

But, another option would be to create an extremely basic rtl.css stylesheet that could be ported into other child themes. Maybe with just a few basic style rules.

Anyone want to give it a shot?

You wouldn't be expected to maintain it or anything. Once it's done, I'll continue to maintain the stylesheet through any design changes.

All that really needs to be done is getting the basics down. It needs to be a sort of example for others that are looking to do the same.

Reply »

You must log in to post.

Hybrid version 0.8 discussion

Reply »

Topic Info

Topic Tags: