Devtard

Hello. You’d have to use a loop (e.g. the one at line 5037 in v1.8.1) to go through the whole keyword set list and check whether each item already exists as a tag in WP (using this conditional tag https://codex.www.ads-software.com/Function_Reference/term_exists).

Hey, could you please create a screencast showing the unwanted behavior or take a few screenshots, so that I have a better idea of what’s going on? You can send it to my Gmail address (I use the same handle there) if you want to. Thank you.

Hello.

I have created custom post type with WP-Types.com, I am trying to set custom post type named “book-chapter” along with default post type “post”. I put both post type comma separated but after saving the changes plugin interface shows only one post type.

This might mean that the custom post type you submitted doesn’t exist. If APT fails to verify that the post type is actually registered in WP, it won’t be saved. Is the plugin or whatever you’re using for registering the post type active?

Another small problem is with comma separated values in “Allowed Post Types” and “Allowed Post Status”. Plugin is not trimming left and right spaces in comma separated values entered in these boxes. Example, I put “publish, draft” in Allowed Post Status, plugin will read it as “publish” and ” draft” (note the leading space in word draft) and shows error that ” draft” is not a registered post status. Then I tried putting “publish,draft” and it works.

Thanks for letting me know, I’ll fix this in the next version.

Yup. Unfortunately, I’ve been kinda busy lately, and have no idea when it’s going to be released. So if you need this feature ASAP, I can send you the code. But, you know, while I think it should work fine, it hasn’t been properly tested etc.

Something like this is already implemented in the development version.

While the plugin still doesn’t have the ability to analyze taxonomies and other metadata (although this functionality will be added as well at some point in the future), it’s possible to tell the plugin to add terms from specific configuration groups to posts if keyword sets from (other) groups are found.

So yes, this should be doable. Configuring the plugin might take some time, though – it would depend on how many KW sets/groups you use. I can send you the latest version if you’re interested.

Interesting idea. I’ll add it on my to-do list for the next version.

Yup, this (implemented as logical operators for related keywords) is planned as well.

Something like this is actually already on my to-do list. I’m planning to include a logging feature which would record everything the plugin does. That should make debugging etc. much easier.

You’re welcome ??

Wow, awesome! ?? Sorry for not being able to reply sooner. I just realized that I’ve actually dealt with this issue already, but completely forgot about it – my apologies.

This is what the loop looks like in the development version:

$apt_number_of_added_terms_all_taxonomies = 0;

### ADDING TERMS TO THE POST according to their taxonomies
foreach($apt_taxonomies_with_found_terms_array as $apt_single_taxonomy_with_found_terms_array){
	$apt_number_of_added_terms_single_taxonomy = count($apt_single_taxonomy_with_found_terms_array[1]); //for debugging

	if($apt_number_of_added_terms_single_taxonomy > 0 and ($apt_settings['apt_old_terms_handling'] == 1 or $apt_settings['apt_old_terms_handling'] == 3)){ //if terms were found by the plugin; if the post has no terms, we should add them - if it already has some, it won't pass one of the first conditions in the function if $apt_settings['apt_old_terms_handling'] == 3
		wp_set_object_terms($apt_post_id, $apt_single_taxonomy_with_found_terms_array[1], $apt_single_taxonomy_with_found_terms_array[0], true); //append terms
	}
	if($apt_settings['apt_old_terms_handling'] == 2){
		if($apt_number_of_added_terms_single_taxonomy > 0){ //if the plugin found some keywords, replace the old terms - otherwise do not continue!
			wp_set_object_terms($apt_post_id, $apt_single_taxonomy_with_found_terms_array[1], $apt_single_taxonomy_with_found_terms_array[0], false); //replace terms
		}
		else{ //no new terms/keywords were found
			$apt_current_taxonomy_terms = wp_get_post_terms($apt_post_id, $apt_single_taxonomy_with_found_terms_array[0], array('fields' => 'names'));
			$apt_current_taxonomy_term_count = count($apt_current_taxonomy_terms);

			if(($apt_settings['apt_old_terms_handling_2_remove_old_terms'] == 1) and ($apt_current_taxonomy_term_count > 0)){ //if no new terms were found and there are old terms, remove them all
				wp_delete_object_term_relationships($apt_post_id, $apt_single_taxonomy_with_found_terms_array[0]); //remove all terms
			}
		} //-else
	} //-if the user wants to replace old terms

	$apt_number_of_added_terms_all_taxonomies += $apt_number_of_added_terms_single_taxonomy;
} //-foreach

Originally I planned to release v1.9 ASAP, but unfortunately haven’t been able to get to it yet. There are still many things that need to be modified and implemented.

Thanks.

Unfortunately, I was unable to recreate the bug you reported, and also failed to find a hook that would be triggered only when importing new posts. But here’s what you can do regarding the second issue:

Find the function “apt_single_post_tagging” in the main PHP file and put there the following code (e.g. somewhere around the line 2861):

global $pagenow;

if($pagenow == 'admin-ajax.php'){
	return;
}

This should stop the tagging function from being run when the Quick Edit feature is used.

Hi. Could you please export all data from APT and send it together with some sample post to my Gmail address (I use the same handle)? I’ll try to recreate the issue.

Yes, I suppose you should be able to edit the terms – that makes sense when APT is set to run only when importing posts. I haven’t looked into this, but it’s possible that the same hook used by APT for handling imported posts (“wp_insert_post”) is also used by WP when updating posts using the “Quick edit” feature. You should still be allowed to edit terms when using the post editor. Right?

I’ll add the hook-related issue on my to-do list.

Hi, unfortunately I don’t have access to the source code of this plugin; try contacting its developers.

When recurring bulk tagging events are enabled, APT should automatically create a new one-time cron job after finishing the last one. There shouldn’t be multiple scheduled events at once.

What exactly is happening in your case? When are these cron jobs being created if not after the last scheduled bulk tagging event occurs?

Sure. I’ll add it on my to-do list.

Okay. In that case, I’ll need access to your settings, keyword sets and some sample post content (and maybe a screenshot of your post editor page where wrong terms can be seen in the tags/category section), so that I can try to replicate the issue. Could you please export all this stuff and send it to my email?