Community Forums › Forums › Archived Forums › General Discussion › Why you shouldn't fear updating to Genesis 2.0 [from 1.9, but should from 2.0RC2
- This topic has 20 replies, 8 voices, and was last updated 10 years, 8 months ago by Mealtog.
-
AuthorPosts
-
August 7, 2013 at 7:46 pm #54786jb510Member
It's funny reading this http://www.studiopress.com/news/updating-genesis-2-0.htm on why you shouldn't fear updating to Genesis 2.0 from 1.9, but if you ran 2.0RC2 you should.
It baffles me that after Release Candidate 2 something as fundamental as how HTML5 is invoked would get changed effectively breaking ANY site running Genesis 2.0 RC1 or 2. Worse without an change log or notice. What does release candidate mean these days?
FYI,
add_theme_support('genesis-html5');
has been changed to
add_theme_support('html5');IF you were running a release candidate you need to change that or you won't get HTML5 markup and your CSS targeting that markup won't work.
Also be aware that .navigation has been changed to .pagination....
Dear StudioPress - It'd be really nice if we could get a changelog from 2.0RC2 to 2.0 of these major non-bug fix type changes. (yes I sent them an email).
August 7, 2013 at 8:56 pm #54797jb510MemberMore changes between RC2 and final... Hooks got explicit priorities instead of all being on 10 and falling down in order (which was way easier to unhook):
For example
add_action( 'genesis_entry_header', 'genesis_post_info';
is now
add_action( 'genesis_entry_header', 'genesis_post_info', 12 );Hence to remove it you need the priority:
remove_action( 'genesis_entry_header', 'genesis_post_info', 12 );same for:
remove_action( 'genesis_entry_header', 'genesis_do_post_format_image', 4 );
remove_action( 'genesis_entry_content', 'genesis_do_post_image', 8 );
remove_action( 'genesis_entry_content', 'genesis_do_post_content_nav', 12 );
remove_action( 'genesis_entry_content', 'genesis_do_post_permalink, 14 );
remove_action( 'genesis_after_entry', 'genesis_do_author_box_single', 8 );
August 7, 2013 at 8:59 pm #54798taylorishereMemberFor someone who is a bit new to poking around the engine of Genesis, how would someone fix general issues of the differences between RC2 and 2.0?
(where/how do I change the html5 theme support?)
August 7, 2013 at 9:01 pm #54800Robert NeuMemberBill Erickson posted a nice list of the changes from RC2 and 2.0. You can check it out here: http://www.diffchecker.com/k1j3cwz7
Basically you just need to check your theme for the items in red and make sure they are updated to the items in green.
August 7, 2013 at 9:02 pm #54801AnitaKeymaster@taylorishere, someone sent this to me and it's pretty cool. Look for items on the left and fix it with the right - http://www.diffchecker.com/k1j3cwz7.
Love coffee, chocolate and my Bella!
August 7, 2013 at 9:37 pm #54816jb510MemberBill to the rescue, hadn't seen that. It's neater than what I wrote up here:
I wrote this up: http://www.wanderingjon.com/2013/08/07/breaking-change-from-genesis-2-0-release-candidate-2-to-final/
August 8, 2013 at 1:44 am #54830Gary JonesMember(Usual disclaimer - I don't work for StudioPress so this isn't an official statement, though I was one of the contributing developers for Genesis 2.0)
Your point is entirely valid jb510.
Before work on Genesis 2.1 gets too far along, we're going to nail down the workflow so that this doesn't happen again, though there were mitigating circumstances on this occasion.
The constant delay of WP 3.6 caught SP out - my whiteboard still has a note that the final release date should have been 15 May, but clearly that didn't happen. What was put out there as RC1 and RC2 should really have been beta 3 and 4, but I think SP were chomping at the bit to get something released and the understanding of the "beta" and "RC" terms got lost. The extended delay in WP 3.6 did allow us to find and fix other bugs and make other improvements during RC2 that won't have been identified here, and the end result is something that is more stable.
In the case of the genesis-html5 to html5, it was only brought to our attention during RC2 that WordPress itself was going to be using this theme support key. I'm not sure how we all missed it. There was a discussion and several developers had opposing views on whether to change it at this late stage or not.
Pagination class names was more of a design choice. A lot of effort had gone into all of the modular-based class names, but pagination seemed to have been missed out. It was the last remaining section to address, and bring into line with the rest of the code - it would have been a shame not to have it improved.
The overriding factor for both of these though, was that Genesis 2.0 was such a big release, that we wanted it to be done right - once 2.0 is out there, then genesis-html5 and .navigation (for HTML5 output) were going to be needed to be supported forever.
Any developers that use pre-final releases should *know* that things might change, and it was felt that inconveniencing those X,000 early adopters was worth it for the sake of having these brand new features was right for 100,000 users forever more.
Genesis 2.0 was unique, in that it allowed us to make what would otherwise have been breaking changes, by putting all of the new stuff within the genesis_html5() conditional. To go and rewrite 3 years of doing bits wrong is not an easy task, but it was our once chance to do it, and it should have been done right.
G 2.1 should see us going back to a more usual workflow / release naming pattern (I hope).
WordPress Engineer, and key contributor the Genesis Framework | @GaryJ
August 8, 2013 at 1:49 am #54831Gary JonesMemberIn terms of the changes to priorities, here's my ticket description for getting these changed:
----
This is the current list of entry hooks (as per the reset loop function):
add_action( 'genesis_entry_header', 'genesis_do_post_format_image', 5 ); add_action( 'genesis_entry_header', 'genesis_entry_header_markup_open', 5 ); add_action( 'genesis_entry_header', 'genesis_entry_header_markup_close', 15 ); add_action( 'genesis_entry_header', 'genesis_post_info' ); add_action( 'genesis_entry_header', 'genesis_do_post_title' ); add_action( 'genesis_entry_content', 'genesis_do_post_image' ); add_action( 'genesis_entry_content', 'genesis_do_post_content' ); add_action( 'genesis_entry_content', 'genesis_do_post_permalink' ); add_action( 'genesis_entry_content', 'genesis_do_post_content_nav' ); add_action( 'genesis_entry_footer', 'genesis_entry_footer_markup_open', 5 ); add_action( 'genesis_entry_footer', 'genesis_entry_footer_markup_close', 15 ); add_action( 'genesis_entry_footer', 'genesis_post_meta' );
If someone wants to put something between two items that are next to each other (say, between post image and post content, or between post info and post title (which are in the wrong order here btw)), then they currently have to do a
remove_action()
so that it can be added back in with different priorities set, to "make space". If you want to add in something between post content and post permalink, you either need to make image have a priority of, say, 5 and content, say, 7, then hook your custom function in at 8 or 9, or unhook and rehook the permalink and content nav to something greater than 10.That's not particularly friendly. We can avoid that.
Could we make each section a bit more like the entry footer-related priorities? The main element at priority 10, then items before and after it to have lower or higher priorities, with a gap so other stuff can be hooked in as well? e.g.:
add_action( 'genesis_entry_header', 'genesis_do_post_format_image', 4 ); add_action( 'genesis_entry_header', 'genesis_entry_header_markup_open', 5 ); add_action( 'genesis_entry_header', 'genesis_do_post_title' ); add_action( 'genesis_entry_header', 'genesis_post_info', 12 ); add_action( 'genesis_entry_header', 'genesis_entry_header_markup_close', 15 ); add_action( 'genesis_entry_content', 'genesis_do_post_image', 8 ); add_action( 'genesis_entry_content', 'genesis_do_post_content' ); add_action( 'genesis_entry_content', 'genesis_do_post_permalink', 12 ); add_action( 'genesis_entry_content', 'genesis_do_post_content_nav', 14 ); add_action( 'genesis_entry_footer', 'genesis_entry_footer_markup_open', 5 ); add_action( 'genesis_entry_footer', 'genesis_post_meta' ); add_action( 'genesis_entry_footer', 'genesis_entry_footer_markup_close', 15 );
That leaves the main item at 10, the opening and closing markup wrappers at 5 and 15, and everything else on the next even number above or below the 5, 10, or 15 priority function. **I can now hook something into to
genesis_entry_content
at priority 9 or 11, without having to start un-hooking and re-hooking existing functions.**The lines are re-arranged to be in priority order here to make them easier to follow. It would be great if the corresponding functions (and therefore the
add_action()
calls found just above each function) could do the same withinlib/structure/post.php
- at the moment for instance,genesis_post_info()
is located next to the footer opening markup function.-----
Does that make the reasoning clearer? The end result is something that makes adding in new items between existing ones FAR easier - and again, if this went live with no priorities, there would be no chance to fix it later.
WordPress Engineer, and key contributor the Genesis Framework | @GaryJ
August 8, 2013 at 2:19 am #54835jb510MemberThanks Gary. Bill chimed in too elsewhere. I appreciate both explanations.
The thing is, I totally understand WHY these changes were made, it was pretty obvious once I found and looked at the actual changes. It also makes total sense to make those changes now. What I don't get is not putting out a single note about those changes before dropping 2.0 on folks.
I heard rumors about the genesis-html > html change and the .navigation > .pagination change so neither of those caught me too off guard but the hook changes hit me completely out of the blue.
I'm sure I wasn't alone in making the assumption after the tiny changes between RC1 and RC2 that Final wouldn't totally fubar things. It's crying over spilt milk at this point, but a little heads up would have been nice. It would have made the difference between fixing things in a “holy crap why is this !@$#@! broken” mode rather than “Oh, I need to fix these 5 little things before updating” mode. Obviously the former isn't pleasant and here could have totally been avoided.
August 8, 2013 at 5:43 am #54849russelljMemberRe: Proliferation Of Action Hook Priorities
Thanks Gary for documenting this.
I would like to propose that StudioPress look at getting rid of the action hook priorities completely and maybe add more hooks instead as this would be much cleaner and less prone to error.
<rant>
My belief is that priorities should ideally not appear in a theme framework at all. They should only be a tool for the plugin developer, or the theme designer or the end user to make tweaks - they do not belong in the core.You do not find the WordPress code itself peppered with hook priorities... Priorities should be the option of last resort due to their arbitrary nature.
</rant>But otherwise, Genesis 2.0 rocks!
I am loving HTML5 (navs, asides, sections, headers and footers and especially the new rant tag)
Check out my port of Magazine on HTML5. Using Eric Hamm's excellent XTML5 to HTML5 CSS converter it was a piece of cake.
August 8, 2013 at 7:47 am #54874Gary JonesMemberI would like to propose that StudioPress look at getting rid of the action hook priorities completely and maybe add more hooks instead as this would be much cleaner and less prone to error.
At this moment in time, it's not going to change. We hook in so many things, that creating individual hooks for them would be pointless. You'd end up with something like:
... do_action( 'genesis_entry_content_image' ); do_action( 'genesis_entry_content' ); do_action( 'genesis_entry_content_permalink' ); do_action( 'genesis_entry_content_content_nav' ); ...
Not only is that unmaintainable, if I want to move the content_nav to between the image and content, then I'm going to have the content_nav function attached to something that isn't the content_nav hook.
What we currently have makes sense - we have a hook for the entry header, a hook for the main entry, and a hook for the entry footer. The former and latter are separate, as they are in their own markup (<header> and <footer>).
re: rant - an interesting viewpoint, but there's nothing in the Plugin API that suggests who can and who can't use priorities. In the case of Genesis, it's Genesis that provides the bulk of the default output markup - so naturally, if someone wants to rearrange that markup, they need a way to do so. Individual hooks aren't sensible, as above, so that leaves priorities. Without priorities, you end up with the exact situation that my ticket description covers. Priorities give more flexibility with manipulating markup.
WordPress Engineer, and key contributor the Genesis Framework | @GaryJ
August 8, 2013 at 8:55 am #54907russelljMemberYou make a strong argument (and I guess that means you're right).
In terms of elegance it just feels a little like we have gone back to Assembler coding or GoTo Statements, where arbitrary numbers like 9,11,12,13 mean something.
Seems I am stuck with having to remember facts that the genesis_do_post_permalink happens at 12
Maybe, when the only option left is to reclassify priority as a float, then we'll find a better way.
My preference would be using something like the following that uses explicit ordering (and no numbers)
add_actions('genesis_entry_header', array('genesis_do_post_format_image', 'genesis_entry_header_markup_open', 'genesis_do_post_title','genesis_post_info', 'genesis_entry_header_markup_close')); ย add_actions( 'genesis_entry_content', array( 'genesis_do_post_image', 'genesis_do_post_content' , 'genesis_do_post_permalink','genesis_do_post_content_nav' )); ย add_actions( 'genesis_entry_footer', array('genesis_entry_footer_markup_open', 'genesis_post_meta', 'genesis_entry_footer_markup_close'));
Obviously, this is a work in progress....
August 8, 2013 at 8:58 am #54909David ChuParticipantGary,
A BIG thanks for those detailed explanations to those of us who are often starved for information. Double-big thanks, as you're not an official staff member.You are certainly a lynchpin of Genesis 2 and all other Genesis activities!
Best, Dave
Dave Chu ยท Custom WordPress Developer – likes collaborating with Designers
August 8, 2013 at 10:30 am #54970Gary JonesMemberDavid - you're welcome ๐
russellj -
You make a strong argument (and I guess that means you’re right).
The fact you're suggesting an alternative doesn't mean there's a simple right and wrong answer - only positives and negatives of each, which have to be weighed.
In terms of elegance it just feels a little like we have gone back to Assembler coding or GoTo Statements, where arbitrary numbers like 9,11,12,13 mean something.
The numbers used for priorities are arbitrary already - why did WP pick 10 as the default? Why not 100? Or 0, and let earlier ones be negative?
Seems I am stuck with having to remember facts that the genesis_do_post_permalink happens at 12
You also have to remember that the callback is called genesis_do_post_permalink, and that the hook is called genesis_entry_content. My ticket description does hint at the logic you can follow:
"That leaves the main item at 10, the opening and closing markup wrappers at 5 and 15, and everything else on the next even number above or below the 5, 10, or 15 priority function."
So in the case of entry, you know the main content is at 10, then there's the image before it (8) and permalink after it (12), then post nav after that (14).
My preference would be using something like the following that uses explicit ordering...
I've never seen add_action() calls using arrays before - if it's possible, then that's something I should go and look up! The point still remains though - if your code was used, how would I insert something between the post content and post permalink?
WordPress Engineer, and key contributor the Genesis Framework | @GaryJ
August 8, 2013 at 11:39 am #55007jb510MemberI'm fine with having priorities. I saw an elegance to not having priorities in genesis core since it meant I didn't have to think about where to unhook things from. I could just unhook it and add it back with a priority. This did sometimes mean unhooking multiple actions to squeeze someone in between, but as Gary said there are positives and negatives either way.
In practice I have a code snippet of the loop resets and just drop that in then whittle it down to the few I need to move/replace.
Side note: seems like a framework function to move things might be handy, although maybe not considering what i just came up with in my head for it looks maybe harder to read then the standard remove/add combo. move_action(array($function,$hook,$priority),array($funtion, $hook, $priority)
or
move_action(array(
array($function,$hook,$priority),array($funtion, $hook, $priority)),
array($function,$hook,$priority),array($funtion, $hook, $priority))
)
August 8, 2013 at 3:18 pm #55093russelljMemberMy add_action with an array is vapour-ware, it is just my idea of how add_action could be extended (in a world without priorities)
For example, to add your cool new stuff into the list you just add it to the array of actions as follows:
remove_all_actions( 'genesis_entry_content'); add_action( 'genesis_entry_content', array( 'genesis_do_post_image', 'genesis_do_post_content' , 'your_new_cool_stuff', 'genesis_do_post_permalink','genesis_do_post_content_nav' ));
To me this is intuitive and flexible: I want to redefine entry_content so I kill the old entry_content and define the new. This works for adding stuff, removing stuff and reordering stuff.
And if I want to change any of the elements, then I can use a filter - assuming each function has an associated filter hook where you can override its behaviour.
For example, if I want to change how the permalink is rendered, I add a filter. This assumes the last thing the genesis_do_post_permalink function does is:
return apply_filters('genesis_post_permalink', $permalink);
Genesis of course already supports this way of overriding components.
August 8, 2013 at 3:54 pm #55106MealtogMemberok, the technical changes that needs to be edited seems a bit overwhelming and more importantly, manual editing may lead to issues later since it was not done through automation. Here I thought running RC2 would help us transition easier when 2 was released and now this. Should have stuck to 1.9 and waited.
If I wanted to avoid all the technical edits, is it easier to uninstall Genesis and Child theme and re-install WP3.6, using the Reinstall Button for WP and then reinstall Genesis 2 + child theme? We are not too far along in dev and I can probably reconfigure everything from scratch within a day's work.
Where would we completely uninstall Genesis and start from scratch?
Any thoughts would be most helpful. ๐
August 8, 2013 at 4:54 pm #55122MealtogMemberBy the way, I am looking at: http://www.diffchecker.com/k1j3cwz7
Is this functions.php for Genesis or the Child Theme or both?
This almost seems easier to start from scratch for those of us still starting a new site. Yikes.
August 9, 2013 at 2:13 am #55176Gary JonesMemberTo me this is intuitive and flexible: I want to redefine entry_content so I kill the old entry_content and define the new. This works for adding stuff, removing stuff and reordering stuff.
And what happens if my social buttons plugin wants to add something in there as well? How will the plugin know what the child theme has set as all of the callbacks, in order? How will the child theme know to let the plugin have its chance at hooking in something?
I really admire that you're trying to innovate - WordPress wouldn't be where it is today without it - but I think there's one or more inherent flaws in your idea still to address, compared to the system we currently have.
WordPress Engineer, and key contributor the Genesis Framework | @GaryJ
August 9, 2013 at 2:17 am #55177Gary JonesMember@Mealtog - there's really no need to start again - the change from RC2 to final is add_theme_support( 'genesis-html5' ) to add_theme_support( 'html5' ). If your style sheet covers the .navigation selector, then change it to .pagination. If you were moving some elements around by changing hooks, then you might need to look at the new priorities, but they are simply changing the priorities on what you already have.
The diff that you linked to gives an example of the child theme changes, if you were using any of the bits I've just mentioned.
WordPress Engineer, and key contributor the Genesis Framework | @GaryJ
-
AuthorPosts
- The forum ‘General Discussion’ is closed to new topics and replies.