I found the issue and all works are should now. Was in the html check box and which $instance and ref. IDK how to explain it, but basically it totally works as should.
Subject: wp-hackers Digest, Vol 114, Issue 5
Date: Mon, 7 Jul 2014 12:00:01 +0000
Send wp-hackers mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.automattic.com/mailman/listinfo/wp-hackers
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of wp-hackers digest..."
1. Re: Admin dashboard > category box wish list. (Haluk Karamete)
2. extended Genesis Featured Widget Amplified new $instance
array elements not making it to and saving in update() (Adam LaBarge)
3. Re: extended Genesis Featured Widget Amplified new $instance
array elements not making it to and saving in update()
(Remkus de Vries | Forsite Media)
4. Re: Incorrect documentation for register_post_status
(Pascal Birchler)
5. by passing the entire template hierarchy (Haluk Karamete)
6. Re: Incorrect documentation for register_post_status
(Nikola Nikolov)
----------------------------------------------------------------------
Message: 1
Date: Sun, 6 Jul 2014 10:57:10 -0700
Subject: Re: [wp-hackers] Admin dashboard > category box wish list.
Content-Type: text/plain; charset=UTF-8
Answering my own,, sharing for-what-it's-worth!
(1) and (3) of my original wish list taken care of.
I have some sense that wish #2 is impossible without the term_meta. so
leaving that as 'wishful-thinking' and moving on.
here we go...
# keep the category hierarchy on the post editing screen as original
# and expand the category meta box vertically so not we see no scrollbars
# code inspired by
# 1) http://wordpress.org/plugins/category-checklist-tree/
# 2) http://wordpress.org/plugins/category-checklist-expander/
# keep the category hierarchy on the post editing screen as original
add_filter( 'wp_terms_checklist_args', 'blp_checklist_args' ) ;
function blp_checklist_args( $args ) {
$args['checked_ontop'] = false;
return $args;
}
# and expand the category meta box vertically so not we see no scrollbars
add_action( 'admin_head', 'blp_category_scroll_bar_be_gone' );
function blp_category_scroll_bar_be_gone() {
global $wp_version, $pagenow;
if ( !in_array( $pagenow, array( 'post.php', 'post-new.php' ) ) )
return;
?>
<style>
#categorydiv div.tabs-panel, #linkcategorydiv div.tabs-panel {
height: auto; max-height: none; }
</style>
<?php
}
Hello everybody...
On Wordpress dashboard, at the "categories" section, I have 3 basic
questions. I'd appreciate any lending hands.
(1) How do I change the length of that area so I can display all my cats -
eliminating the need for the vertical scroll-bar?
(2) How do I ensure that the __top level items__ are listed in an order I
specify (or even better in the order they were created - sorted by their
TTID) ?
currently, out of the box WordPress displays them in an alpabetical
order.
and finally,
(3) is there a simple trick to tell WordPress to keep the checked terms in
their own original hierarchical spot - rather than by moving them to the
top as currently?
------------------------------
Message: 2
Date: Sun, 6 Jul 2014 18:47:05 +0000
Subject: [wp-hackers] extended Genesis Featured Widget Amplified new
$instance array elements not making it to and saving in update()
Content-Type: text/plain; charset="iso-8859-1"
Hello -
In a nutshell: I'm extending a plugin widget class, adding new elements to defaults array and $instance, making a check box, and trying to save check box settings. But no saving is happening.
Extended: I'm working on extending the Genesis Featured Widget Amplified (gfwa) plugin. Currently, at least with version 0.8.1, the widget will not ignore sticky post and if there are sticky post, it will blow out the user defined post limit. (ie, 4 sticky post, user limit set to 4, so 8 post show up in the widget output, not 4 - this kind of defeats the purpose of a limit).
So far I have, i think, everything set up correctly. But something is wrong because when I var_dump the inputs of update($instance, $old_instance), neither have the new defaults array elements.
I have extended the original class, updated widget() to account for ignore sticky and set a real limit on the while loop, added my check box to the form(), but no luck in saving.
The code for this is rather long, so I've put it up on github:https://github.com/adamplabarge/apl_gfwa_extended/blob/master/apl_gfwa_extended.php
Thanks any help and or suggestions. And open to code critique.-adam
------------------------------
Message: 3
Date: Sun, 6 Jul 2014 21:01:30 +0200
Subject: Re: [wp-hackers] extended Genesis Featured Widget Amplified
new $instance array elements not making it to and saving in update()
Content-Type: text/plain; charset="utf-8"
Nick?s plugin hasn?t been updated for more than two years, so for starters you?re probably better off extending Travis' https://github.com/wpsmith/genesis-sandbox-featured-content-widget
Hello -
In a nutshell: I'm extending a plugin widget class, adding new elements to defaults array and $instance, making a check box, and trying to save check box settings. But no saving is happening.
Extended: I'm working on extending the Genesis Featured Widget Amplified (gfwa) plugin. Currently, at least with version 0.8.1, the widget will not ignore sticky post and if there are sticky post, it will blow out the user defined post limit. (ie, 4 sticky post, user limit set to 4, so 8 post show up in the widget output, not 4 - this kind of defeats the purpose of a limit).
So far I have, i think, everything set up correctly. But something is wrong because when I var_dump the inputs of update($instance, $old_instance), neither have the new defaults array elements.
I have extended the original class, updated widget() to account for ignore sticky and set a real limit on the while loop, added my check box to the form(), but no luck in saving.
The code for this is rather long, so I've put it up on github:https://github.com/adamplabarge/apl_gfwa_extended/blob/master/apl_gfwa_extended.php
Thanks any help and or suggestions. And open to code critique.-adam
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
------------------------------
Message: 4
Date: Mon, 7 Jul 2014 09:26:31 +0200
Subject: Re: [wp-hackers] Incorrect documentation for
register_post_status
Content-Type: text/plain; charset=UTF-8
How does your code look like? It seems like setting the `public` argument
https://github.com/WordPress/WordPress/blob/3.9-branch/wp-includes/query.php#L2810
I had to add a new custom post status and so I looked-up the documentation
for the register_post_status()
<http://codex.wordpress.org/Function_Reference/register_post_status>
function and adjusted the sample code from there.
I found a way to add the post status to the status drop-down on the
add/edit posts screens and changed the status of one of the posts.
It all worked as expected - the post status was now updated for that post.
Then I went back to the posts screen for my custom post type and I saw the
post status link on top, showing me that there's 1 post with that post
status. That's also correct.
However the post disappeared from the list of posts, even though I've set
"show_in_admin_all_list" to true in the arguments for the post status.
So I looked around and found out that in /wp-includes/query.php on line
#2819
<
https://github.com/WordPress/WordPress/blob/3.9-branch/wp-includes/query.php#L2819
,
WordPress is getting registered post statuses with show_in_admin_all_list =
true AND protected = true
The *protected* argument is not documented anywhere, but after I set that
to true in my arguments list, the post appeared again.
I would go in and document that myself, but I really have no clue what
*protected* is used for and I don't want to advise people to add it in just
because it works.
If anyone has more insight, I'd be happy to hear it.
Nikola
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
------------------------------
Message: 5
Date: Mon, 7 Jul 2014 02:34:54 -0700
Subject: [wp-hackers] by passing the entire template hierarchy
Content-Type: text/plain; charset=UTF-8
Is there a way to by pass the great system known as the WordPress Template
Hierarchy so that WordPress shoots the ball straight to the last resort
which is index.php?
------------------------------
Message: 6
Date: Mon, 7 Jul 2014 14:43:16 +0300
Subject: Re: [wp-hackers] Incorrect documentation for
register_post_status
Content-Type: text/plain; charset=UTF-8
That's the thing - I don't want posts with that status to be public.
However, in theory(according to the documentation), setting
"show_in_admin_all_list" to true should make posts with that post status
visible in the "All" section of the posts list.
What I'm not sure about is what the "protected" property of a post status
is used for.
How does your code look like? It seems like setting the `public` argument
https://github.com/WordPress/WordPress/blob/3.9-branch/wp-includes/query.php#L2810
I had to add a new custom post status and so I looked-up the
documentation
for the register_post_status()
<http://codex.wordpress.org/Function_Reference/register_post_status>
function and adjusted the sample code from there.
I found a way to add the post status to the status drop-down on the
add/edit posts screens and changed the status of one of the posts.
It all worked as expected - the post status was now updated for that
post.
Then I went back to the posts screen for my custom post type and I saw
the
post status link on top, showing me that there's 1 post with that post
status. That's also correct.
However the post disappeared from the list of posts, even though I've set
"show_in_admin_all_list" to true in the arguments for the post status.
So I looked around and found out that in /wp-includes/query.php on line
#2819
<
https://github.com/WordPress/WordPress/blob/3.9-branch/wp-includes/query.php#L2819
,
WordPress is getting registered post statuses with
show_in_admin_all_list =
true AND protected = true
The *protected* argument is not documented anywhere, but after I set that
to true in my arguments list, the post appeared again.
I would go in and document that myself, but I really have no clue what
*protected* is used for and I don't want to advise people to add it in
just
because it works.
If anyone has more insight, I'd be happy to hear it.
Nikola
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
------------------------------
Subject: Digest Footer
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
------------------------------
End of wp-hackers Digest, Vol 114, Issue 5
******************************************