You must be a logged-in exclusive member to view this reply.
Topic Info
- 149 posts
- Started 1 year ago by Justin Tadlock
- Latest reply from Justin Tadlock
- RSS feed for this topic
Hybrid version 0.7 discussion
-
-
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.
-
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 ?
-
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).
-
You must be a logged-in exclusive member to view this reply.
-
In re
.pofile: 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.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
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.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
@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.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
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? ...
-
May you consider backend content workflow enhancements ?
-
Thank-you, John. Appreciated.
-
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. -
You must be a logged-in exclusive member to view this reply.
-
I would like to see the related articles display moved to above the author bio box.
-
I'm thinking tags and categories should load like this:
taxonomy-post_tag.php
taxonomy-post_tag-slug.phptaxonomy-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 :) -
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
-
You must be a logged-in exclusive member to view this reply.
Reply »
You must log in to post.