10sexyapples

My apologies. I should have been more clear.

When I create a custom taxonomy, I have the option to register that taxonomy for the following content types:

post, page, attachment and/or link default content types,
as well as for custom content/post types

Currently in the admin area of CMS Press for editing or adding taxonomies, you have the ability for me to select everything listed above for the content type that I would like to register my taxonomy for, except link.

I really need to be able to apply my custom taxonomies to links as well.

It would be super appreciated ~

Hi. I’m back again. This time to request support for link object types in the registration support for the taxonomies ?? purdy please?

On it’s way ??

Hi Scribu,
I saw that you just released 1.2 for QMT, that’s great. I’m going to have to wait a bit before upgrading because I’ve made so many functions associated with the previous version, but, as soon as I have time to go through it all, I will be implementing. Right now, I’m working on using jstree with the widgets in the sidebar ( don’t know if you remember me going on about the length of terms associated with this site, but, it’s vast ).

Everything is working great with it, although I did have to add
<ul><li> . $before_title . $title . $after_title . </li></ul> to make it fully functional with the main header of the taxonomy list.

I think I may try implementing jstree for the taxonomy term list selections in the backend as well – with your category checklist code … as soon as I can get this cookie issue worked out.

When I implement the default cookie options with jstree, I lose the whole script for some reason.

It could be a good idea to point people to jstree for use with QMT. I think they make an extremely powerful combination. I’m just using jstree at its minimum, but, man, there is some serious stuff that can be done between them. Even the checkbox array selection that I was reading about in the forum posts could easily be achieved.

Anywho, if you care to take a look at how they look together, let me know … maybe you can tell me what’s going on with the cookie while you’re at it … heh.

Over and out~

Well, wouldn’t you know. Apparently there was still one stone left unturned and by chance I discovered that the issue in question above had to do with some cryptic, completely illogical combination of post registration, code activation etc… Voodoo or black magic or whatever. Bottom line is I’m not crazy and there is nothing weird happening with CMS Press. Whew. And I was able to get rid of my one random manually coded post type and get it with the rest of the pack in CMS PRess, and the javascript is working *for now – fingers crossed* and the world is a beautiful place again. ??

Sorry for all the false alarm panic and babble above~

I’m getting too close to deadline, so, I have to go ahead and remove the test case scenarios, I’m sorry, and go forward with the manual registration of this custom post type. Please do still reply as soon as you get a chance though, as it would be really super helpful to try to get this sorted out sooner than later okay? pretty pretty please?

Well, turns out for now, I’m going to go ahead and use a post type post as well, so, my urgency dissipated, but, it still would be great to have it be fully compatible with what we can do on our own, instead of being limited in our options if we want to use the CMS Press interface.

I know there are a few things you’ve got hanging around back there that were waiting for 3.0 completion in order to see if they were merged or not as well. I’m sure your eager to get all that settled finally too ?? … I know I am.

I’ve had to do some hacky stuff with rewrites in another function file to interact with the rewrites in your code in order to get an archive page of custom type posts, and I can’t wait to clear out that mess and have it all handled neatly from one place.

On the bug I’ve come across, it’s not a registration problem. I can register fine, and the registration that I’m speaking of is there on my site still at the moment. Will be removing it tomorrow. This is the registration that I’ve had to make manually in my functions file to replace ( tomorrow ) the one that I registered in CMS Press.

// Register glossary terms custom post type
	function create_post_types(){
	$labels = array(
            'name' => _x('Glossary Terms', 'post type general name'),
            'singular_name' => _x('Glossary Term', 'post type singular name'),
            'add_new' => _x('Add New', 'glossary term'),
            'add_new_item' => __('Add New Glossary Term'),
            'edit_item' => __('Edit Glossary Term'),
            'new_item' => __('New Glossary Term'),
            'view_item' => __('View Glossary Term'),
            'search_items' => __('Search Glossary Terms'),
            'not_found' =>  __('No glossary terms found'),
            'not_found_in_trash' => __('No glossary terms found in Trash'),
            'parent_item_colon' => ''
  );

		$args = array(
			'labels' => $labels,
			'description' => 'Indexed definitions for commonly used glossary terms within the site',
			'public' => true,
			'publicly_queryable' => true,
			'show_ui' => true,
			'query_var' => true,
			'rewrite' => array('slug' => 'glossary-term'),
			'capability_type' => 'post',
			'hierarchical' => false,
			'menu_position' => null,
			'supports' => array('title','editor','author','thumbnail','excerpt'));
		register_post_type('glossary_term',$args);
		flush_rewrite_rules();
	}
	add_action( 'init', 'create_post_types');

?>

As you can see, I’m registering on the init as well.

The problem arises when this code:

function red_glossary_parse($content){

	//Run the glossary parser
	if (((!is_page() && get_option('red_glossaryOnlySingle') == 0) OR
	(!is_page() && get_option('red_glossaryOnlySingle') == 1 && is_single()) OR
	(is_page() && get_option('red_glossaryOnPages') == 1))){
		$glossary_index = get_children(array(
											'post_type'	=> 'glossary_term',
											'post_status'	=> 'publish',
											));
		if ($glossary_index){
			$timestamp = time();
			foreach($glossary_index as $glossary_item){
				$timestamp++;
				$glossary_title = $glossary_item->post_title;
				$glossary_search = '/\b'.$glossary_title.'[A-Za-z]*?\b(?=([^"]*"[^"]*")*[^"]*$)/i';
				$glossary_replace = '<a'.$timestamp.'>$0</a'.$timestamp.'>';
				$content_temp = preg_replace($glossary_search, $glossary_replace, $content);
				$content_temp = rtrim($content_temp);

					$link_search = '/<a'.$timestamp.'>('.$glossary_item->post_title.'[A-Za-z]*?)<\/a'.$timestamp.'>/i';
					if (get_option('red_glossaryTooltip') == 1) {
						$link_replace = '<a class="glossaryLink" href="' . get_permalink($glossary_item) . '" title="Glossary Term: '. $glossary_title . '" onmouseover="tooltip.show(\'' . addslashes($glossary_item->post_content) . '\');" onmouseout="tooltip.hide();">$1</a>';
					}
					else {
						$link_replace = '<a class="glossaryLink" href="' . get_permalink($glossary_item) . '" title="Glossary Term: '. $glossary_title . '">$1</a>';
					}
					$content_temp = preg_replace($link_search, $link_replace, $content_temp);
					$content = $content_temp;
			}
		}
	}
	return $content;
}

//Make sure parser runs before the post or page content is outputted
add_filter('the_content', 'red_glossary_parse');

attempts to add the javascript to the links that it creates with the custom post type terms found.

It finds the glossary_term terms, and it assigns the css, and html
to them, but, it will not run the javascript on them.
It’s really baffling to me why this is happening, but, alas, it is, and the only constant is CMS PRess.

If I register the post type in my functions file manually, the javascript works. If I register the post type within the plugin that the code above is taken from, it works. If I register it in CMS Press, the javascript hover function does not work.

I’m really stumped on this as it makes no sense to me whatsoever. I thought you might have some insight?

Like I said, if I have to, I’ll keep it manually coded, but, it just bums me out because I wanted to have a clean interface. I did have all of post types manually coded and was updating them daily as new things were coded in core, but, at a certain point and when it looked like CMS Press was going to be THE one that would handle all of this the best … and because you were doing so much of the coding in core anyway … I removed everything that I had done and redid it all through CMS Press. Long story, but, I’m sure you know what I’m talking about ??

Who knows, maybe you’ll take one look at this and immediately know what’s wrong … I can dream no?

Okay, never mind that last comment. It was due to a revision hanging on that had the post type assigned. My apologies.
I have run across a different problem though, and wanted to ask if you could possibly shed some light on it.

I am implementing some code which runs some javascript on a custom post type to create a mouseover event. If I register the custom post type within the code for the mouseover, it works fine. If I register the custom post type from my functions.php file, it works fine.

However, if I register it with CMS Press, it doesn’t not work at all.
It’s a pretty serious bug for me, as I’m sure it would be for anyone trying to use this type of functionality, and it took two days to track down that it was something that was happening in the registration of the post type via CMS Press.

I can only imagine the troubleshooting nightmares some folks might come across if this isn’t figured out, so, I have left the different options active on my site right now in case you want to take a look and troubleshoot the bug easily while everything is there.

Please email me if you would be interested in doing this as I’m in development right now and can give you a login, but, I need to have the site completed in a matter of days, so, the opportunity won’t be available but for a day or so. In which case, I will just have to give up the consistency of the site and register this particular custom post type outside of CMS press.

I really don’t want to do that, so, hoping to hear from you ??

Wanted to give you a head’s up as well that when I deleted a custom post type from the cms press admin, it deleted from the cms press page, but, remained in the database. I could swear there was talk about some sort of unregister_post_type, but, I either forgot what it was or can’t find it. Do you know the proper way to remove these from the database?

Hi there. Me again. Well, with your last couple updates I was able to get rid of all of my hacks in your plugin, but, darnit, I have finally moved into using some page type custom post types and now I’m in a pickle again. There is no option to select hierarchical for page type custom post types and no page-attribute in the support array. I’m wondering if you might have a chance to add those in when you get a chance pretty please? For now, I’ll just hack in there again to add them and wait … patiently … ahem … did you add it yet? heh. Seriously, I’m only kidding.

Most excellent help!!! Thanks so much!!

Yes, you would be correct. I’ll check that link right now.

thanks for all your help

yay.

Well, turns out the $_GET didn’t work, nor did several other options that seemed like they should, what did finally work was this-

if ( get_query_var('post_type') === 'lesson' ) {
return 'lesson';

yay!!