mojamba

Please disregard. I found a code error on my part. Everything seems to be working fine now. Great plugin.

Indeed you have, sir! Thanks. Interestingly, before viewing your latest comments here I just updated WP and my various plugins and noticed yours had an update. Then, I went to check it out of curiosity and thought, wow, that is fixed now. Good job. I will update my review accordingly.

Thanks for the response. I would love to provide a link but I cannot because I am still in development mode and using a local XAMPP setup. But, the cutting off the display issue is very repeatable so I would think you can verify it yourself very easily. Simply create a tooltip with a lot of text (I use sometimes to show the excerpt) and create the tooltip near the top of the screen and you will see what we are talking about.

You decided not to implement this?

Glad to help. Actually, I have been using UWPQSF as the foundation for my customized WP site search engine.and have been banging it around to suit my needs for the past 1-2 weeks. Along the way I have learned a lot and have made many changes. I think most or all of these changes could easily be incoporated and would be desired by other users who may not be able to do the coding necesary. I am happy to share all my code if you are interested in reviewing it and incorporating the features you think might be good additions. Below is a list of all the changes I have made so far:

Back-end changes:

• Allow phrase searches (enclosed in quotation marks)
• Added ability to search excerpts (enabled by default but could easily add as a front-end option)
• Added ability to keyword search taxonomy terms (and allow for excluding specific taxonomies)
• Added ability to keyword search comments:

1. user can enable/disable on front-end,
2. user can choose search logic (AND/OR),
3. by default only searches approved comments

• Added ability to search by a date range
• Added support for multi-select taxonomy filtering with hierarchical taxonomy listing (note: required some changes since multiselect creates an array where regular select creates a text variable)
• Allow search logic based on user (front-end) input (currently can set logic for: core search, taxonomy search, comments search)
• Order by relevance (only the basic WP relevance algorithm)
• Search term highlighting for title and excerpt (semi-complicated to deal with allowing HTML tags in excerpts)
• Integrated with Search Meter plugin to record search history

Front-end changes:

• Added display of search term to the results template title (e.g. # Results found for: <search terms>)
• Added multiselect box (integrated with your admin screen)
• Added date range with jQuery datepicker that is cross-browser compatible (core jQuery HTML5 datepicker is not well-supported)
• Added ability for user to select the sort/orderby option
• Added a Relevance option for sorting (on both admin screen and front-end selector)
• Added front-end enable/disable keyword search for taxonomy terms
• Added front-end enable/disable keyword search for comments
• Added front-end selection of search logic to use for keyword search (three separate options: one for core keyword search, one for taxonomy search and one for comments search)
• Added front-end selection of the number of results to show per page

With the exception of the multiselect and relevance sorting (which integrates with the admin screen) I did most of the modifications manually via filters but some/all might make good admin screen options with the ability to select the layout position on the front-end form (as can currently be done with other fields).

Other notes/suggestions:

• You don’t currently apply a filter for tax_query ($get_tax) but this would be helpful for those who want to let users select the search logic (‘relation’, OR/AND). I am doing that now but have to modify the WHERE query whereas it would be cleaner to have a filter to set instead.
• You apply a filter in post_type.php for the Post Type section of the admin screen, but not for the Result Setting and Others section (misc.php). This is, I think, where some new options like comment and excerpt searching, could logically be placed.
• I didn’t do anything worth mentioning with respect to custom post types as they aren’t important to my site, but I think searching and sorting those should be even easier than taxonomies.

Happy to help. By the way, now I think I know why you used the esc_html. Without it the text in the keyword text box won’t display properly after submission. One solution is to modify your $oldvalue (in searchform.php file, two different locations) from:

$oldvalue = (isset($_GET['skeyword'])) ? $_GET['skeyword'] : '';

to:

$oldvalue = (isset($_GET['skeyword'])) ? stripslashes(esc_html($_GET['skeyword'])) : '';

Very helpful, thanks. I was looking to add this feature as well except I want to use a date input type with the jQuery datepicker functionality. Unfortunately, there is an issue with it because some browsers (very notably Firefox) don’t yet support it and thus will default to a basic text input. Thanks to (https://code.tutsplus.com/tutorials/quick-tip-create-cross-browser-datepickers-in-minutes–net-20236) I found a way to work around this compatability issue. Below is my final code. Hope it helps someone.

add_action('uwpqsf_form_bottom','insert_date_input');
function insert_date_input() {
	?>
	<script type="text/javascript">
	jQuery(document).ready(function() {
		var elem = document.createElement('input');
		elem.setAttribute('type', 'date');

		if ( elem.type === 'text' ) {
			$('.MyDate').datepicker({
				showButtonPanel: false,
				showOtherMonths: true,
				selectOtherMonths: true,
				dateFormat : 'yy-mm-dd'
			});
		}

	});
	</script>
	<?php
	$html = sprintf('<input type="date" class="MyDate" name="date[from]" value="%s" placeholder="Between <date>" />?', $_GET["date"]["from"]);
	$html .= sprintf('<input type="date" class="MyDate" name="date[to]" value="%s" placeholder="and <date>" />', $_GET["date"]["to"]);
	echo $html;
}

OK, I think I have it resolved. Here is my new filter code:

add_filter('uwpqsf_get_taxo','searchalltax','',3);
function searchalltax ($taxo, $id, $gettaxo) {
	$savetaxo = get_post_meta($id, 'uwpqsf-taxo', true);
	for ($i=1; $i<=count($savetaxo); $i++) {
		if ( $taxo[$i]['terms'][0] =="uwpqsftaxoall" ) unset ($taxo[$i]);
	}
	return $taxo;
}

This is only for taxonomies (thus using uwpqsf_get_taxo instead of uwpqsf_get_cmf) since I don’t use any custom meta fields but I think the code would be the same, just swapping out the tag (i.e., use uwpqsf_get_cmf).

Thanks. I have been looking into your suggestion but cannot seem to figure it out. Can you provide more details or possibly a code example?

Here’s an update on the code I just posted. It does work fine (so far) except for one major problem. It will NOT work if you select the All option. This is because your get_uwqsf_taxo function doesn’t check this condition in an array situation. In other words, your line of code:
if( $v['term'] == 'uwpqsftaxoall'){

needs to be changed to something like:
if( $v['term'] == 'uwpqsftaxoall' || $v['term'][0] == 'uwpqsftaxoall') {

Doing that fixed everything for me, but since it is part of the core plugin file it is obviously not an upgrade-proof solution.

I am also interested in this topic but, as SJS719 pointed out, the code isn’t complete because terms are not remembered on the front-end. So, I went ahead and modified it to work correctly. I also want to use hierarchical taxonomy listings which your code does not do so I added that feature as well. I am sure my code isn’t the best possible but it seems to work. It would be great if you incorporated it along with an admin screen option to choose hierarchical display or not in a future release. Anyway, here is my final code.

add_filter('uwpqsf_addtax_field_multiselect','multiselect_front','',11);
function multiselect_front($type,$exc,$hide,$taxname,$taxlabel,$taxall,$opt,$c,$defaultclass,$formid,$divclass){
	$eid = explode(",", $exc);
	$args = array('hide_empty'=>$hide,'exclude'=>$eid, 'parent'=>0 );
	$taxoargs = apply_filters('uwpqsf_taxonomy_arg',$args,$taxname,$formid);
    $terms = get_terms($taxname,$taxoargs);
	$count = count($terms);
	$html  = '<div class="'.$defaultclass.' '.$divclass.'" id="tax-select-'.$c.'"><span class="taxolabel-'.$c.'">'.$taxlabel.'</span>';
	$html .= '<input  type="hidden" name="taxo['.$c.'][name]" value="'.$taxname.'">';
	$html .= '<input  type="hidden" name="taxo['.$c.'][opt]" value="'.$opt.'">';
	$html .=  '<select size="4" multiple id="tdp-'.$c.'" class="tdp-class-'.$c.'" name="taxo['.$c.'][term][]">';
		if ( empty($_GET['taxo'][$c]['term']) || in_array("uwpqsftaxoall", $_GET['taxo'][$c]['term']) ) {
			$alloptions .= '<option selected value="uwpqsftaxoall">'.$taxall.'</option>';
		} else {
			$alloptions .= '<option value="uwpqsftaxoall">'.$taxall.'</option>';
		}

		if ( $count > 0 ) {
			$i = 0;
			foreach ( $terms as $term ) {
				if ( isset($_GET['taxo'][$c]['term']) && in_array($term->slug,$_GET['taxo'][$c]['term']) ) {
					$i++;
					if ($i<=1) {
						foreach($_GET['taxo'][$c]['term'] as $slug) {
							$termname = get_term_by('slug',$slug,$_GET['taxo'][$c]['name']);
							$preselected .= '<option value="'.$termname->slug.'" selected="selected">'.$termname->name.'</option>';
						}
					}
				} else {
					$options .= '<option value="'.$term->slug.'">'.$term->name.'</option>';
					$childterms = get_terms($taxname,array('parent'=>$term->term_id ));
					if ( !empty($childterms) ) {
						foreach ($childterms as $childterm) {
							if ( !in_array($childterm->slug,$_GET['taxo'][$c]['term']) ) $options .= '<option value="'.$childterm->slug.'">&nbsp; - '.$childterm->name.'</option>';
						}
					}
				}
			}
		}
		$html .= $alloptions . $preselected . $options;
	$html .= '</select>';
	$html .= '</div>';
	return $html;
}

I have some code that might help, but then again it might just confuse you as well. This assumes you are modifying your theme file, which should always be done via a child theme otherwise you will lose the changes when your theme gets updated. If you don’t know anything about child themes, it is a good idea to learn (WordPress has a good tutorial somewhere), but if you are not interested, perhaps just ignore all that follows. Anyway, if you are going to modify your theme, the most logical place will be in your single.php file or any other places where you are showing the favorites button.

The first thing I will recommend is actually not using a popup but rather displaying a special message box when the favorites button is clicked by a non-user. Doing this will save you the hassle of creating a special page to contain whatever message you wish to display and will probably be a bit more mobile-friendly; you can always add a popup registration link inside that message box if you so desire.

So, here is some code to (1) check if a user is logged in or not; (2) add a special div with your message and show it if the favorites button is clicked by a non-user; and (3) let you insert a shortcode for your Codecanyon’s UserPro plugin, assuming it offers a popup login/register option (otherwise, just link to your register page).

<script type="text/javascript">
jQuery(document).ready(function() {
   $('.showfavsdiv').click(function() {
		jQuery('#register-warning').show();
		return false;
	});
});
</script>
<?php
$user_id = get_current_user_id();
if ($user_id) {
	echo do_shortcode('[favorite_button]');
} else {
	?>
	<a href="#" class="showfavsdiv" alt="members-only feature alert">
	<?php echo do_shortcode('[favorite_button]'); ?>
	</a>
	<div id="register-warning" style="display:none;">Only logged-in members can save favorites. Registering is free and easy.
	<?php echo do_shortcode('[your UserPro plugin shortcode can go here]'); ?>
	</div>
	<?php
}

Assuming you are still only interested in a popup, here is code fairly similar to the code above but that will launch a popup instead of showing a special message div. Note that you can simply edit the height and width to suit your needs.

<script type="text/javascript">
jQuery(document).ready(function() {
   $('.popup').click(function() {
		var NWin = window.open($(this).prop('href'), '', 'scrollbars=1,height=400,width=400');
		if (window.focus) {
			NWin.focus();
		}
		return false;
	});
});
</script>
<?php
$user_id = get_current_user_id();
if ($user_id) {
	echo do_shortcode('[favorite_button]');
} else {
	?>
	<a href="/must-login-message/" class="popup" alt="members-only feature alert">
	<?php echo do_shortcode('[favorite_button]'); ?>
	</a>
	<?php
}

Hopefully that will help you, or if not you, someone else that comes along and is interested in this topic.

For anyone interested in this thread, I have figured it all out. Here is a modified (generalized) version of the function I wrote. Obviously, your SQL statements will be different depending on how your legacy favorites information is stored.

function migrateFavorites() {
	global $wpdb;

	$userstable = $wpdb->prefix . "users";
	$usermetatable = $wpdb->prefix . "usermeta";
	$postmetatable = $wpdb->prefix . "postmeta";

	// ---------------------------------------------------------------------
	// --- Find and loop through each user with favorites
	// ---------------------------------------------------------------------
	$sql = $wpdb->prepare("SELECT * FROM <table> WHERE ...");
	$results = $wpdb->get_results($sql);
	if (!$results) {
		echo msg("No users found to migrate","warning");
	} else {
		$count = 0;
		foreach($results as $result) {
			$count++;
			$username = $result->username;
			$user_id = $result->ID;
			$usermeta = get_user_meta($user_id, "simplefavorites", true);
			// -----------------------------------------------------------------
			// --- Get all favorites for this user
			// -----------------------------------------------------------------
			$sql = $wpdb->prepare("SELECT * FROM <table> WHERE ...");
			$getfavorites = $wpdb->get_results($sql);
			$newposts = array();
			foreach($getfavorites as $favorite) {
				$post_id = $favorite->post_id;
				$newposts[] = intval($post_id);
				// -------------------------------------------------------------
				// --- Increment the favorites count for this content_id
				// -------------------------------------------------------------
				if ( ! add_post_meta( $post_id, 'simplefavorites_count', 1, true ) ) {
					$postmeta = get_post_meta($post_id, 'simplefavorites_count');
					$newcount = $postmeta[0] + 1;
					update_post_meta ( $post_id, 'simplefavorites_count', $newcount );
				}
			}
			// -----------------------------------------------------------------
			// --- Now add or update usermeta table
			// -----------------------------------------------------------------
			if (!$usermeta) {
				$favorites[] = array(
					'site_id' => intval("1"),
					'posts' => $newposts
				);
			} else {
				$favorites = $usermeta;
				$existing_posts = $usermeta[0]['posts'];
				$allposts = array_merge($existing_posts, $newposts);
				$allposts = array_unique ($allposts);	// --- avoid duplicate posts
				$favorites[0]['posts'] = $allposts;
			}
			$error = update_user_meta( $user_id, 'simplefavorites', $favorites );
			if ( get_user_meta($user_id, 'simplefavorites', true ) != $favorites ) {
				echo msg ("An error occurred' favorites","error");
			} else {
				echo msg ("Finished migrating $count users' favorites","#666");
			}
		}
	}
}

OK, solved myself. I need to use the register_form hook not the login_head hook.

I had similar problems, mostly due to some errors that were occurring after the registration process completed (e.g., if you are using LWA in conjunction with another registration/members related plugin). In my particular case it was related to customized email responses that weren’t working quite right. Assuming the same is true for you, it isn’t really this plugin’s fault, though it would be nice if LWA accounted for post-registration errors.