How can I exclude certain WordPress Page categories from being indexed in Algolia?
First of all, I would recommend you stick with the new version of the plugin. At the time of writing this, the latest version is 0.2.5. Indeed the old version (0.0.1) will not be supported anymore.
Regarding your question, it is indeed possible to filter what posts you would like to push to Algolia and make searchable.
What I understand from your question is that you have pages assigned to categories, and you would like to avoid making pages from certain categories come up in search results. If these initial statements are wrong, please comment on this answer and I'd gladly push an update!
You can hook into the decision of indexing a post by using WordPress filters.
In your case, if you are willing to exclude the pages from the searchable_posts index you could use the algolia_should_index_searchable_post filter.
If you are willing to exclude the pages from the posts_page index, you could use the algolia_should_index_post filter.
Here is an example of how you could exclude all pages of a list of categories identified by their IDs.
<?php
// functions.php of your theme
// or in a custom plugin file.
// We alter the indexing decision making for both the posts index and the searchable_posts index.
add_filter('algolia_should_index_post', 'custom_should_index_post', 10, 2);
add_filter('algolia_should_index_searchable_post', 'custom_should_index_post', 10, 2);
/**
* #param bool $should_index
* #param WP_Post $post
*
* #return bool
*/
function custom_should_index_post( $should_index, WP_Post $post ) {
// Replace these IDs with yours ;)
$categories_to_exclude = array( 7, 22 );
if ( false === $should_index ) {
// If the decision has already been taken to not index the post
// stick to that decision.
return $should_index;
}
if ( $post->post_type !== 'page' ) {
// We only want to alter the decision making for pages.
// We we are dealing with another post_type, return the $should_index as is.
return $should_index;
}
$post_category_ids = wp_get_post_categories( $post->ID );
$remaining_category_ids = array_diff( $post_category_ids, $categories_to_exclude );
if ( count( $remaining_category_ids ) === 0 ) {
// If the post is a page and belongs to an excluded category,
// we return false to inform that we do not want to index the post.
return false;
}
return $should_index;
}
More information about extending the Algolia Search plugin for WordPress can be found on documentation: Basics of extending the plugin
Update:
The code has been updated to ensure it doesn't exclude a product if it is associated to multiple categories and not all of them are excluded.
Related
I'm using the following code to hook a product update in woocommerce:
add_action('woocommerce_update_product', 'on_update_product', 10, 2);
function on_update_product($product_id, $product){
// code here
}
Is there a way to check if certain fields have changed, compared to the previously stored version of the product?
Thanks!
The best way to do this that I know is with hashes.
add_action('woocommerce_update_product', 'on_update_product', 10, 2);
function on_update_product($product_id, $product){
//create a hash from data you want to track
$hash = md5(json_encode([
$product->get_name(),
$product->get_price(),
"etc....."
]));
//get the hash before the product update
$hashBefore = get_post_meta( $product_id, "hashKey", true );
//check if de hash is diffrend
if ($hash !== $hashBefore) {
// Store the new hash
add_post_meta($product_id, "hashKey", $hash);
// exicute your code
// .....
}
// you can duplicate this process if you want to track individual fields
$hash2 = md5(json_encode([
$product->get_sku(),
]));
$hashBefore2 = get_post_meta( $product_id, "hashKey2", true );
if ($hash2 !== $hashBefore2) {
add_post_meta($product_id, "hashKey2", $hash2);
}
}
To get data out of the product object check this resource:
https://businessbloomer.com/woocommerce-easily-get-product-info-title-sku-desc-product-object/
I hope this suits your situation
I would recommend hooking to another action. I use it to identify changes in orders, but it actually can use for any woocomercce related object types (orders, products, coupons, subscriptions etc.)
woocommerce_before_[objectName]_object_save
for your purpose you can use:
add_action('woocommerce_before_product_object_save', 'identify_product_change', 100, 2);
function identify_product_change($product, $data){
$posted_info = $_POST; // Use this to get the new information
$price = $product->get_price(); //Example of getting the "old" product information
}
Having that said, you need to be careful, since this hook may be initiated from different triggers (some background processes etc). You may want to have some caution measurements:
use $_POST['action'] == 'editpost' to make sure the action is an
actual "Update" click from the admin edit page.
use (is_admin()) to limit it only to admin area
you can use (!defined('DOING_CRON')) to make sure it won't run on any cron execution
and you can use (!defined('DOING_AJAX')) to make sure it won't run on ajax calls
this way you can limit it only to the exact action you wish to catch.
I have one custom post type I use for some text blocks on a page built using uncode theme. I need these blocks to be public so they display on the page but I want to stop them appearing in search results.
The search.php isn't like a normal wordpress search file, it is the uncode-theme file and doesn't have normal queries in I don't think so I'm thinking I need a function maybe?
Can anyone please advise how to achieve this?
The CPT is 'staticcontent'
Thanks!
The answer here depends on whether you're creating the CPT via your own code, or if another plugin is creating the CPT. See this link for a great explanation of both approaches:
http://www.webtipblog.com/exclude-custom-post-type-search-wordpress/
The basic gist is this:
If you're creating your own CPT, you can add an argument to the register_post_type() call of 'exclude_from_search' => true
If another plugin / theme is creating the CPT, you need to set this exclude_from_search variable later on, as part of a filter to the CPT, as such:
// functions.php
add_action( 'init', 'update_my_custom_type', 99 );
function update_my_custom_type() {
global $wp_post_types;
if ( post_type_exists( 'staticcontent' ) ) {
// exclude from search results
$wp_post_types['staticcontent']->exclude_from_search = true;
}
}
I don think accepted answer is correct. exclude_from_search prevents all $query = new WP_Query from returning results.
The core says:
...retrieves any type except revisions and types with
'exclude_from_search' set to TRUE)
This is a common problem and mixup with the front end search results page v.s. search posts in the database.
Presenting content using custom queries on front end, needs exclude_from_search = false or use another approach and get the content by id directly.
You need to filter the search front end mechanism instead. This is a true Exclude Post Types From Search, without manually re-build "known" types:
function entex_fn_remove_post_type_from_search_results($query){
/* check is front end main loop content */
if(is_admin() || !$query->is_main_query()) return;
/* check is search result query */
if($query->is_search()){
$post_type_to_remove = 'staticcontent';
/* get all searchable post types */
$searchable_post_types = get_post_types(array('exclude_from_search' => false));
/* make sure you got the proper results, and that your post type is in the results */
if(is_array($searchable_post_types) && in_array($post_type_to_remove, $searchable_post_types)){
/* remove the post type from the array */
unset( $searchable_post_types[ $post_type_to_remove ] );
/* set the query to the remaining searchable post types */
$query->set('post_type', $searchable_post_types);
}
}
}
add_action('pre_get_posts', 'entex_fn_remove_post_type_from_search_results');
And remark $post_type_to_remove = 'staticcontent'; can be changed to fit any other post type.
Please make a comment if Im missing something here, I cant find another way to prevent post type scenarios like this, showing content by query but hide from search/ direct access to front end users.
First of all, the answer by Jonas Lundman is correct and should be the accepted answer.
The exclude_from_search parameter does work incorrectly - it excludes the post type from other queries as well.
There is a ticket on WP issue tracking system, but they have closed it as wontfix because they cannot fix this without breaking the backwards compatibility. See this ticket and this one for more details.
I've added additional checks to the solution proposed by Jonas Lundman, because:
in real setups there can be other plugins trying to modify the search query, so simply replacing the post_type may cause unexpected results.
I think it's more flexible to use an array of post types to exclude.
add_action('pre_get_posts', 'remove_my_cpt_from_search_results');
function remove_my_cpt_from_search_results($query) {
if (is_admin() || !$query->is_main_query() || !$query->is_search()) {
return $query;
}
// can exclude multiple post types, for ex. array('staticcontent', 'cpt2', 'cpt3')
$post_types_to_exclude = array('staticcontent');
if ($query->get('post_type')) {
$query_post_types = $query->get('post_type');
if (is_string($query_post_types)) {
$query_post_types = explode(',', $query_post_types);
}
} else {
$query_post_types = get_post_types(array('exclude_from_search' => false));
}
if (sizeof(array_intersect($query_post_types, $post_types_to_exclude))) {
$query->set('post_type', array_diff($query_post_types, $post_types_to_exclude));
}
return $query;
}
I am relatively new to woocommerce development so I am sorry if this question might be too trivial but I need help.
I need in my application a way to make some checks when an admin makes changes to a product in woocommerce.
For example, I want to create a log file of all the changes that occurred on products. Who made them, when and what was the change (price, inventory, description, etc.).
I understand that there are hooks in woocommerce that I can use. Which ones can help me do something like that?
Use post_updated hook for this purpose, place the following code in your functions.php
function product_update_handler( $id, $before_data, $after_data ) {
if( $before_data->post_type == "product" ) {
$current_user = wp_get_current_user();
error_log( $before_data->post_title ." has been updated by ".$current_user->user_login );
}
}
add_action('post_updated', 'product_update_handler', 0, 3);
you have two product objects ( before update, after update ) with the above hook, you can compare both object and log the changes.
Does anyone have any idea how to add custom meta fields while making categories and fetch them in the loop in WordPress? I was wondering how to do that without hacking the WordPress core, but if I do – it won't become a hindrance to update WordPress in the future.
A plugin I have found that comes close is Wp-Category-Meta, but it doesn't have the ability to add checkboxes as fields in Edit Categories.
This will be very useful as users can make certain categories "featured", and then the code can use that meta value in the loop to style "featured" categories differently.
The problem:
Wordpress does not have a structure nor method to store "meta" values for taxonomies.
UPDATE 2017: WP 4.4+ has "term meta"!
For working with term metas use these:
update_term_meta()
get_term_meta()
delete_term_meta()
add_term_meta()
The Actions below are still valid though! :)
Additional reading: 4.4 Taxonomy Roundup
Solution for WP version <= 4.3.x and COMMON actions
Actions:
create_category and edit_category for category edit
category_add_form_fields and category_edit_form for category form fields
There are more actions than I've presented, but they seem to be deprecated (according to developer.wordpress.org).
The reason I chose the actions that I chose:
- They work on WordPress 4.4.2
- Due to lack of documentation I assumed these are the new ones replacing the deprecated ones...
Functions:
get_option( $option, $default );
update_option( $option, $new_value, $autoload );
update_option has two great abilities:
a) It craetes the option when such option does not exist yet
Unless you need to specify the optional arguments of add_option(),
update_option() is a useful catch-all for both adding and updating
options.
b) $new_value can be an integer, string, array, or object.
You may ask, why to use array/object? ...well, because each option = 1 database row => you probably want to store your category options in one row :)
The CODE
function my_category_form_fields($tag_object){
//output/display extra form fields, e.g. by echo ...
//ADD EXTRA SPECIFIC FIELD TO LATER CHECK IF IT'S CATEGORY SAVE/EDIT!
//(see note at 'edit_category' action...)
if( !empty($tag_object['term_id']) ){
//edit category form specific
//...load existing options with get_option( $option, $default );
} else {
//create category form specific
}
}
function my_category_save(){
//CHECK FOR YOUR EXTRA SPECIFIC FIELD TO CHECK IF IT'S CATEGORY SAVE/EDIT
//(see note at 'edit_category' action...)
//SECURITY CHECK
if( empty($_POST['EXTRA_SPECIFIC_FIELD']) || ! current_user_can('manage_categories') )
return null;
//save your form values using update_option()
//Recommendation:
//Add "category_" prefix and $category_id to your option name!
}
add_action( 'create_category', 'my_category_save', 10, 1 );
//Runs when a category is updated/edited,
//INCLUDING when a post or blogroll link is added/deleted or its categories are updated
//(which causes the count for the category to update)
add_action( 'edit_category', 'my_category_save', 10, 1 );
add_action( 'category_add_form_fields', 'my_category_form_fields', 10, 1 );
add_action( 'category_edit_form', 'my_category_form_fields', 10, 1 );
Create or Edit?
You might wonder whether you are creating or saving a category - this not documented yet (as far as I know), but from testing:
Edit save => $tag_object is object and contains some properties, most notably:
term_id
taxonomy
filter
Create save => $tag_object is just a regular string "category" - I guess this might change in the future...
General taxonomy
There are also actions like these for taxonomies in general - check these actions.
Jaz,
It looks like the plugin you mention in your original question has been updated to include a checkbox field (included in v1.2.3)
I think the Category SEO Meta Tags plugin will help you.
There is an updated and refactured version of this plugin to be found here:
https://wordpress.org/plugins/custom-taxonomy-category-and-term-fields/
Also added a WYSIWYG editor fieldtype.
I'm using WordPress to make my users make their own website/blog. I have a set up that I'm cloning out to all the users with some special user-roles and standard plugins.
However, some of the plugins are not supposed to be changed or inactivated by the users.
Is their any way to select which plugins different user roles are allowed to use? Or a easy way to hide some plugins in the plugins-page but still have them working as normal?
Maybe there's some plugin that helps me to do this?
You could write a plugin that uses the "all_plugins" filter hook to remove from the array plugins that you don't want displaying for a certain user. Something like this:
$plugin_credentials = array(
'bob' => array(
'Hello Dolly' => 1
),
'jim' => array(
'Akismet' => 1,
'Hello Dolly' => 1,
),
'admin' => "**ALL**"
);
function plugin_permissions($plugins)
{
global $current_user, $plugin_credentials;
$username = $current_user->user_login;
if ($plugin_credentials[$username] == "**ALL**")
return $plugins;
$viewable_plugins = array();
foreach ($plugins as $plugin) {
if (isset($plugin_credentials[$username]) &&
isset($plugin_credentials[$username][$plugin['Name']]) &&
$plugin_credentials[$username][$plugin['Name']] == 1) {
array_push($viewable_plugins, $plugin);
}
}
return $viewable_plugins;
}
add_filter('all_plugins', 'plugin_permissions');
Managing the user permissions in the plugin itself is not ideal, but it is probably easiest. You can expand on that idea to create admin pages for managing the users and their viewable plugins in a database table somewhere.
Each plugin will usually specify their own role/permission, which you can see if you look at their add_submenu_page() or such function calls. You can create new roles for those plugins and replace the one specified by the author, but it will also break the changes if you upgrade the plugins.
You should stratify the users. Make sure that the Admin user(s) are trusted and know not to fiddle with what they don't understand. The others should be limited to their roles. Authors, editors, etc. For example, if they're just a part of the site to write articles, then they don't need to see the rest of it. Make them an author and be done with it.
This is part of client education. If its a smaller client with less stratified roles, then make them two accounts. Tell them "this is the account you administer the site with, you'll be using this rarely. And this is the account that you'll use most of the time to write and edit. You can do all of your daily tasks here and will most likely never need the administrator account". You won't always have luck with this approach, but its less time and effort invested in crap you shouldn't be wasting time on.
I've done a new version based on #spuriousdata Answer. This one uses the plugin slugs (file name minus the extension) to build the list of restrictions. This way is easier as we can unset the array using the first level $keys.
Configuration instructions in the code itself.
<?php
/**
* Plugin Name: Limit Plugins by User
* Plugin URI: http://stackoverflow.com/q/14340131/1287812
* Description: Show selected plugins for specific users.
* Based on the code by spuriousdata, http://stackoverflow.com/a/3713985.
* Author: brasofilo
* Author URI: http://wordpress.stackexchange.com/users/12615/brasofilo
* Version: 1.0
* License: GPLv2 or later
*/
add_filter( 'all_plugins', 'plugin_permissions_so_3707134' );
/**
* Filter the list of plugins according to user_login
*
* Usage: configure the variable $plugin_credentials, which holds a list of users and their plugins.
* To give full access, put a simple string "ALL"
* To grant only for some plugins, create an array with the Plugin Slug,
* which is the file name without extension (akismet.php, hello.php)
*
* #return array List of plugins
*/
function plugin_permissions_so_3707134( $plugins )
{
// Config
$plugin_credentials = array(
'admin' => "ALL",
'other-admin' => array(
'akismet',
),
'another-admin' => array(
'akismet',
'hello',
),
);
// Current user
global $current_user;
$username = $current_user->user_login;
// Super admin, return everything
if ( "ALL" == $plugin_credentials[ $username ] )
return $plugins;
// Filter the plugins of the user
foreach ( $plugins as $key => $value )
{
// Get the file name minus extension
$plugin_slug = basename( $key, '.php' );
// If not in the list of allowed plugins, remove from array
if( !in_array( $plugin_slug, $plugin_credentials[ $username ] ) )
unset( $plugins[ $key ] );
}
return $plugins;
}