Dankicity

Ok, I lied. To get rid of all the debug errors:
class-wp-typography.php
line 707

add_options_page($this->pluginName, $this->pluginName, 'manage_options', strtolower($this->pluginName), array(&$this, 'get_admin_page_content'));

line 856

if(isset($adminFormControl["fieldset"]) && $adminFormControl["fieldset"] != $fieldsetID) {

lines 869-874

isset ($adminFormControl['control']) ? $adminFormControl['control'] : 'input',
isset ($adminFormControl['inputType']) ? $adminFormControl['inputType'] : 'text',
isset ($adminFormControl['labelBefore']) ? $adminFormControl['labelBefore'] : NULL,
isset ($adminFormControl['labelAfter']) ? $adminFormControl['labelAfter'] : NULL,
isset ($adminFormControl['helpText']) ? $adminFormControl['helpText'] : NULL,
isset ($adminFormControl['optionValues']) ? $adminFormControl['optionValues'] : NULL

parseText.php, line 64

// abort if a simple string exceeds 500 characters (security concern)
if(!is_array($rawText)){
	if(preg_match("@\w{500}@s",$rawText)){
		return;
	}
}

ok nevermind…. if you start trying to work through making this not show up in debug mode it just gets worse. Almost completely unusable and even though it is was a good plugin and on my list of required plugins… deleted.

Thanks, I’ll give it a whirl.

Thanks for the reply. And I neglected to say thanks in the first place for the plugin ~ as the pre 3.3 ones don’t work anymore.

1. Understood.
2. That will work. But to follow up on the guessing the types and for the options page, a bit of code I used in an ordering plugin.

$allowed_post_types  = get_option( 'ptorder_post_types' );
$post_types          = get_post_types();

$banned_post_types = 'page,revision,attachment,nav_menu_item';
$usable_post_types = array();

if ( !isset($allowed_post_types) || empty($allowed_post_types) || $allowed_post_types == 'all' )
	$allowed_post_types = implode(',', $post_types);

foreach( $post_types as $post_type_name ) {
	if ( strpos($banned_post_types, $post_type_name) !== false ) // would probably want to replace strpos as it can find similar post types
		continue;

	$usable_post_types[$post_type_name] = $post_type_name;
}

Results in an array with all ‘valid’ post types with taxonomy capability.

Combine that with something like the link below would collect the taxonomies for all post types to be used in the filter names.

https://wordpress.stackexchange.com/questions/20574/how-to-get-all-taxonomies-of-a-post-type

They did before right? I don’t think setting that save action would do it.

[edit: do a search for one of the titles just to make sure]

Method 1 — Add this to your register_post_type

'has_archive' => 'states',
'rewrite' => array('slug' => 'state'),

and add a button to your menu for your.domain.tld/states/ — I believe that will automatically go through the “template hierarchy” and use archive.php, I haven’t gone that route in awhile.

Method 2 — Bit more complex but lets you give the page an intro
Still add those lines but set ‘has_archive’ => false. Create a new page and set it’s template to a custom page template. Then, inside that template, below the get_template_part do a WP_Query while setting it’s post_type to ‘states’. And again, add a menu button to that page.

eh eh… good stuff.

add_action( "save_post", "my_cpt_save_post", 10, 2 );

Had an extra parenthesis in my example that left the 10, 2); part dangling by its lonesome.

–{ As I rush to check that I didn’t just put the same error in a client’s websites )– lol

2nd’d

Just went from a local wamp install to remote and it took me the last hour (because of load times) to figure out that this plugin was the culprit.

— Just did a fresh DB install to test it out. Goes from 1.2 seconds load time to 18 seconds with this installed. Thank gawd it wasn’t my terrible programming!

I’ll try your fix and see if it speeds back up.

[updated]
Yea that does speed it up but it’s still taking a full second longer to load. Not nearly as bad but bad enough for me to click Delete.

After looking a bit at the code, there is no need to run anything from the plugin if you’re not in the admin so I did:

in media-categories.php line 81

function mc(){
	if (is_admin())
		$this->__construct();
}

And now it only adds that extra second to the admin side.

Simple Typo. Put the last endif back in and swap out
<?php if (!is_front_page() ); ?>
with
<?php if ( !is_front_page() ) : ?>

Ahh figured it out. It was being assigned too late. I missed the bit in the codex

Registering the hook inside your plugins_loaded hook is too late and it won’t run! (Even when it seems to work for register_deactivation_hook until the wp_loaded hook.)

and the wp_schedule_event had me confused because of:

function my_activation() {
	if ( !wp_next_scheduled( 'my_hourly_event' ) ) {
		wp_schedule_event(time(), 'hourly', 'my_hourly_event');
	}
}
add_action('wp', 'my_activation');

Made me think wp was the point in which activation was triggered.

is_home refers to the blog’s home. For a static front page you’re looking for is_front_page()

Just whether or not you want the default term to be given to every post regardless. Like, if you gave it the term Ohio in the editor, would you still want it to be included in US-States?

Bit too much detail here but it’s bad for SEO to have it under multiple hierarchical categories/terms as search engines see that as duplicate content.

Think wp_set_object_terms would do the trick when used inside the save_post action’s callback.

<?php
function my_cpt_save_post ( $post_id, $post = null ) {
	if ( !$post ) $post = get_post($post_id);
	if ( !current_user_can( 'edit_posts', $post->ID ) ) return;
	if ( 'state' != $post->post_type ) return;
	if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) return;

	wp_set_object_terms( $post->ID, 'us-states', 'state' );
}
add_action( "save_post", "my_cpt_save_post"), 10, 2 );
?>

from
https://codex.www.ads-software.com/Function_Reference/wp_set_object_terms

just make sure the term actually exists first
https://codex.www.ads-software.com/Function_Reference/term_exists
&
https://codex.www.ads-software.com/Function_Reference/wp_insert_term

[edit] and you’ll probably want to check if the post has any terms already assigned before you give it the default.

No idea what I was did yesterday or why it would work when I commented out those lines. The issue had nothing to do with my plugin. YAY!

The big thanks goes out to “Fix RSS Feed” plugin that I swear had been turned off and checked to make sure it wasn’t the culprit….but it was.

$filter .= $_POST[‘cats’];
should be
$filter[] = $_POST[‘cats’];

and add an !empty($_POST[‘cat’]) to the if statement

I’m assuming your going to use checkboxes and a submit to cause the action of refreshing.

Give each checkbox a name attribute with the category your wanting to filter through.
<input type="checkbox" name="cats" value="123" /> Cats
// 123 is the id of the category.
Then before the form, check to see if $_POST has a value for those
fields.

<?php
$filter = array();
if ( isset($_POST['cats']) ) {
	$filter .= $_POST['cats'];
}
$categories = implode(',', $filter);
 ?>

[form stuff]
<?php $my_posts_loop = new WP_Query(array('post_type' => 'post', 'cat' => $categories ));?>
[loop stuff]

If you’re trying to do it on a built in page, like the blog index, then you need to update the query_vars through a filter/actions — not sure which it is… pre_get_posts or something.

Should get you started and there might be a typo or something in there. Heading out the door.