neosan

hello @rankmathsupport ,
I come back to you to confirm that there is potentially a problem
I can’t determine where it comes from but I notified pods
in reality you confirmed that it works and it is (probably under ACF or another plugin ) what i tested and it worked the first time

see the image

in pods there was the update 3.2.4 – July 15th, 2024
Feature: Add support for Post Types that have associated Taxonomies to have a Relationship field which will automatically sync to the corresponding taxonomy on save.

can you do the test and confirm that rankmath really sees the pods terms and the snippet works?Technically you should do it without worries, if it works

if not are you able to understand what instructions are missing to make it functional?
it may be possible that we need another code snippet for pods ?

looking forward to hearing from you

• This reply was modified 3 months, 2 weeks ago by neosan.

hello @sc0ttkclark
sorry for the delay I took a few days of vacation ??
I just tested, it doesn’t work, I can’t understand what I have to enter in the field
taxonomies or CPT

the snippet gives me an error

it didn’t work for me ,I spent two hours struggling to understand where the problem is
I saw that there were some bugs on pods these last updates so I imagine that’s why?

By chance
I noticed a strange behavior and a possible confirmation that all the codes do not work correctly or an important instruction is missing

by installing an SEO plugin (rankmath in my case)
they have a series of useful snippet codes to update/add certain terms or categories in Focus Keyword

/**
 * Function to update Rank Math Focus Keywords for properties using specified taxonomies
 */
function update_property_focus_keywords() {
    $properties = get_posts(array(
        'post_type'      => 'property',
        'posts_per_page' => -1,
        'post_status'    => 'publish'
    ));

    $taxonomies = array('property-status', 'property-type', 'property-city');

    foreach ($properties as $property) {
        // Check if Focus Keyword is already set
        if (!get_post_meta($property->ID, 'rank_math_focus_keyword', true)) {
            $keywords = array();

            // Get terms for each taxonomy
            foreach ($taxonomies as $taxonomy) {
                $terms = get_the_terms($property->ID, $taxonomy);
                if ($terms && !is_wp_error($terms)) {
                    foreach ($terms as $term) {
                        $keywords[] = strtolower($term->name);
                    }
                }
            }

            // Update Focus Keyword if we have keywords
            if (!empty($keywords)) {
                $focus_keyword = implode(', ', array_unique($keywords));
                update_post_meta($property->ID, 'rank_math_focus_keyword', $focus_keyword);
            }
        }
    }
}

// Hook the function to run when WordPress initializes
add_action('init', 'update_property_focus_keywords');

on pods to my great surprise nothing is detected (including with all the codes available on this post)

in doubt I posted the question to support
they confirm that everything works…?

I redo the test on my own pods installation > nothing works
I redo the test on an ACF installation > everything works

I think we have another proof that pods does not really attach the taxonomies like ACF there is something missing but which one?

I hope this will help you understand what is wrong

HI
after careful consideration and documentation, it seems that wordpress does not give a specific limit to how many parent > child ( Source google AI)

Limit on Parent-Child Levels

WordPress itself doesn’t impose a strict limit on the depth of taxonomy hierarchies. However, there are practical considerations to keep in mind for optimal performance and usability:

• Navigation and User Experience: With a very deep hierarchy (more than 3-4 levels), navigating through terms in the admin area and on the frontend can become cumbersome. Users might find it challenging to locate specific terms within a complex structure.
• Database Performance: Deep hierarchies can lead to more complex database queries, potentially impacting performance for large datasets of terms. However, modern database engines can handle hierarchical structures efficiently in most cases.

Best Practices:

• Aim for 3-4 Levels: As a general guideline, strive for a maximum depth of 3-4 levels in your taxonomy hierarchies. This ensures clarity, maintainability, and good user experience.
• Evaluate Complexity: Consider the nature of your content and the relationships between terms. If more granular categorization is truly necessary, you can explore alternative strategies like custom fields or a combination of taxonomies with a shallower hierarchy.
• Regular Review and Pruning: Over time, your taxonomy might grow. Periodically review and prune unused or redundant terms to keep the structure streamlined.

Performance Impact:

While the depth of the hierarchy itself won’t cause a significant performance bottleneck in most cases, the number of terms within each level can influence query complexity. It’s generally recommended to keep the number of terms in each level reasonable to maintain optimal database performance.

Conclusion:

While there’s no absolute limit on parent-child levels in WordPress taxonomies, aiming for a depth of 3-4 levels is a good starting point to balance structure, usability, and performance. If your content requires more granular categorization, explore alternative strategies. Regularly review and prune your taxonomies to keep them efficient.

By following these guidelines, you can establish a well-organized taxonomy structure that enhances the user experience and maintains good performance on your WordPress website.

so based on this information I have redone a projection on limit of 3
let’s imagine that we have

Something like this

Parent 1
└── Parent 2
└── Parent 3

or 

Parent 1
└── Parent 2
    └── Parent 3

it’s just a test
I don’t have the possibility to create this list view (v.2) or grid view(v.1) to test it.
but let’s imagine for a moment that we have the possibility to test it
what will it look like? what will happen?
let’s see it on our figma prototype let’s try to see what it will look like

List view (v.2)

Grid View (v.1)

we started with a simple customization of the list to end up in an interesting problem of how to display hierarchical data, unfortunately I can’t ignore this problem now, maybe you too when reading this,
every time I think about it now why can’t we do it,
and what could really technically prevent us from doing it… does wordpress still hide limitations that I don’t know about?
maybe a database architecture or things that are too technical that I don’t know about, that’s why the forum exists, so I’ll let the dev speak about their vision

@sc0ttkclark

Thank you for your message and contribution
Everything appears to be in order. If feasible and without any significant issues, making ‘Update Taxonomies’ optional as envisioned here would be an excellent addition.
It would provide greater flexibility to choose which field to update and archive this snippet.

If you ever decide to address the parent/child issue that the Relationship Field doesn’t currently manage

You’ll need this feature to test whether everything is proceeding as planned.
Update Taxonomies and Assign Parent Terms on Post Save

// Define the CPT name as a constant
define( 'MY_CPT', 'property' );

/**
 * Update Taxonomies and Assign Parent Terms on Post Save (Optimized)
 *
 * This function performs two main tasks when a post of the specified CPT is saved:
 *  1. Updates the post's taxonomies based on assigned terms from Pods fields.
 *  2. Assigns parent terms for the assigned taxonomies, ensuring a complete hierarchy.
 *
 * It takes the following arguments:
 * - $pieces: An array containing post data from Pods API (assuming Pods plugin is used).
 * - $is_new_item: A boolean indicating if it's a new post.
 * - $id: The ID of the post being saved.
 */
add_action( 'pods_api_post_save_pod_item_' . MY_CPT, 'update_taxonomies_and_assign_parents', 10, 3 );

function update_taxonomies_and_assign_parents( $pieces, $is_new_item, $id ) {

  // Array of taxonomies and their corresponding Pods field names
  $taxonomies = array(
    'property-status' => 'p-status',
    'property-type' => 'p-type',
    'property-city' => 'p-city',
    'property-feature' => 'p-feature',
    // ... Replace with additional taxonomies (if needed)
  );

  // Process Taxonomies (Update Post Terms)
  foreach ($taxonomies as $taxonomy => $field_name) {
    $terms = isset( $pieces['fields'][$field_name]['value'] ) ? $pieces['fields'][$field_name]['value'] : null;

    if ( !empty($terms) ) {
      if ( !is_array($terms) ) {
        $terms = explode(',', $terms); // Convert comma-separated string to array
      }
      $terms = array_map('intval', $terms); // Convert each term to integer
    }

    // Update post terms using retrieved term IDs
    wp_set_object_terms( $id, $terms, $taxonomy, false );
  }

  // Assign Parent Terms for Assigned Taxonomies
  assign_parent_terms($id, get_post($id)); // Pass post object to the function
}

// Function to assign parent terms (placed outside the original function)
function assign_parent_terms($post_id, $post) {
  // Check if the post type is the defined constant
  if ($post->post_type !== MY_CPT) {
    return;
  }

  // Get all taxonomies associated with the 'property' post type
  $taxonomies = get_object_taxonomies($post);

  // Loop through each taxonomy
  foreach ($taxonomies as $taxonomy) {
    // Get the assigned terms for the current taxonomy
    $terms = wp_get_object_terms($post_id, $taxonomy);

    // Loop through each assigned term
    foreach ($terms as $term) {
      $parent_id = $term->parent;

      // Loop through parent hierarchy until a top-level parent is reached
      while ($parent_id && !has_term($parent_id, $taxonomy, $post)) {
        // Assign the parent term to the property efficiently using bulk assignment
        wp_set_object_terms($post_id, array($parent_id), $taxonomy, true);

        // Get the parent ID of the current parent for the next iteration
        $parent_id = get_term($parent_id, $taxonomy)->parent; // Optimized way to get parent ID
      }
    }
  }
}

// Hook the function to the 'save_post' action with appropriate priority
add_action('save_post', 'assign_parent_terms', 11, 2);

But that’s a topic for another post.
Happy coding!

after a little thought if there is a possibility of customization it will have to be in the list view and the dropdown view
we will assume that pods finally has the ability to differentiate between parent and child terms
we imagine that we have an insane amount of terms and parents and categories of all kinds in a database or in a taxonomy

I did some tests on figma to allow me to visualize what this modification should or could look like

I took the example of airbnb each post has a quantity of amenities and each represented by an expressive icon with a description that also seems personalized and each in its category

Prototype List View input custom

optional idea
I also thought of a completely new possibility
Relationship Field > [New] Grid View

let’s imagine that you have an insane amount of spare parts or car brands or stuff that is very hard to represent by text or reference only
and you need visual contact and see a representation or an image or anything clue to facilitate the identification task

1 Concept Relationship Field > [New] Grid View
2 Single select Relationship Field > [New] Grid View
3 Hierarchical Relationship Field > [New] Grid View

grid view can be a whole new way to work with pods to display a large quantity with a more UI friendly and modern interface

• This reply was modified 4 months, 2 weeks ago by neosan.

thanks to @pdclark for his help and explanations ??
after a few days of testing and stress test (my test site didn’t explode and I survived ??) this may be useful to someone else one day

This code snippet defines a function called my_enhanced_post_update that triggers whenever a post of the custom post type (CPT) specified in $my_cpt (replace with your actual CPT name) is saved using the Pods framework—a popular content management framework for WordPress.
Key Features:

1. Taxonomy Updates:
   • Maintains relationships between posts and taxonomies.
   • Defines an array $taxonomies that maps taxonomy names to their corresponding Pods field names.
   • During post save, retrieves term IDs from the designated Pods fields for each taxonomy.
   • Uses wp_set_object_terms to update the post’s assigned terms based on the retrieved IDs.
2. Featured Image Handling (Optional):
   • Allows setting the featured image based on the first image in a multi-select Pods field named $featured_image_field_name (configurable).
   • Checks the $enable_featured_image argument (defaults to true) to enable/disable this functionality.
   • If enabled and the field exists, retrieves image IDs from the field.
   • Sets the first image’s ID as the featured image using set_post_thumbnail.
   • If the field is empty or disabled, checks for existing featured images and removes them using delete_post_thumbnail.

Equivalence to ACF Save Terms:

• Core Functionality:
  • Both achieve the same core functionality of associating terms with posts upon saving.
• Implementation Differences:
  • This code leverages Pods for data retrieval and manipulation, whereas ACF provides its own mechanisms.
  • Optional featured image handling is a separate feature in ACF.
• Customizability:
  • Both allow for customization through configuration options (taxonomy mappings, field names, featured image behavior).

Explanation for Someone Familiar with ACF Save Terms:

Imagine you’re using ACF and have created custom fields for taxonomies and a multi-select image field. When you save a post:

• Taxonomy Updates:
  • Similar to ACF Save Terms, this code retrieves term selections from the designated Pods fields (analogous to ACF fields).
• Featured Image:
  • If you have ACF’s “Save as Featured Image” option enabled for the image field, this code achieves the same by setting the first image as the featured image.

In essence, this code provides a Pods-based alternative to ACF’s functionality of saving terms and optionally setting featured images for your custom post type.

Feel free to adjust or add any additional details as needed! ??

// Define the CPT name (replace with your actual CPT name)
$my_cpt = 'property';

/**
 * Update Taxonomies and Featured Image on Post Save (Optimized)
 *
 * This function takes the following arguments:
 * - $pieces: An array containing post data from Pods API.
 * - $is_new_item: A boolean indicating if it's a new post.
 * - $id: The ID of the post being saved.
 * - $cpt_name: The name of the custom post type (CPT).
 * - $enable_featured_image (default: true): A boolean to control 
 *   whether to process the featured image functionality.
 *   - Set to true to enable featured image setting based on the gallery field.
 *   - Set to false to disable featured image setting altogether.
 *
 * It iterates through defined taxonomies and their corresponding Pods field names,
 * retrieves term IDs from those fields, and updates the post's taxonomies.
 * It also handles setting (or removing) the first image from a multi-select field
 * as the featured image, based on the $enable_featured_image argument.
 */
add_action( 'pods_api_post_save_pod_item_' . $my_cpt, 'my_enhanced_post_update', 10, 5 );

function my_enhanced_post_update( $pieces, $is_new_item, $id, $cpt_name, $enable_featured_image = true ) {

  // Array of taxonomies and their corresponding Pods field names
  $taxonomies = array(
    'property-status' => 'p-status',
    'property-type' => 'p-type',
    'property-city' => 'p-city',
    'property-feature' => 'p-feature',
    // ... Replace with additional taxonomies (if needed)
  );

  // Featured image field name (assuming multi-select, images only)
  $featured_image_field_name = 'gallery';

  // Process taxonomies
  foreach ($taxonomies as $taxonomy => $field_name) {
    $terms = isset( $pieces['fields'][$field_name]['value'] ) ? $pieces['fields'][$field_name]['value'] : null;

    if ( !empty($terms) ) {
      if ( !is_array($terms) ) {
        $terms = explode(',', $terms);
      }
      $terms = array_map('intval', $terms);
    }

    // Update post terms using retrieved term IDs
    wp_set_object_terms( $id, $terms, $taxonomy, false );
  }

  // Process featured image (if applicable and enabled)
  if ( $enable_featured_image && array_key_exists( $featured_image_field_name, (array) $pieces['fields'] ) ) {
    $images = $pieces['fields'][$featured_image_field_name]['value'];

    // Check if there are any images in the gallery field
    if ( !empty($images) && is_array($images) ) {
      $attachment_id = array_keys( $images )[0];
      set_post_thumbnail( $id, (int) $attachment_id );
    } else {
      // Check if a featured image is already set
      $has_featured_image = has_post_thumbnail( $id );
      if ( $has_featured_image ) {
        delete_post_thumbnail( $id );
      }
    }
  }
}

• This reply was modified 4 months, 2 weeks ago by neosan.

Hello @pdclark ,thanks for your code and the support
I just tested your code and it works well
I was able to Set the first image of the multi-select field as featured image
So far everything is fine, I put the code and I setlect my taxonomies (pods relationship) and I save the post,
to my great surprise i notice that the pods field relationships are not connected to the taxonomies or do not update them, which is strange coming from ACF which does it naturally and logically.

so I find myself digging through all of wordpress in all the pods options for hours, thinking that I must have done something stupid, until I did a test wp clean install and I understood that the problem comes from pods and this google link gives an explanation
Update Taxonomy from Value Stored in Relationship Field

at this stage I am totally lost I no longer understand how pods works and the logic behind it
so I need to give content to analyze and a scenario to understand for the devs to find the most suitable solution for the future

so I asked google gemini AI to analyze all the codes and give me a solution,
several tests later I end up with a giga code..
// Function for updating taxonomies and setting featured image
// Function to assign parent terms
everything works fine (see here)

I’m not a dev and I already have a headache with all this code ??I feel like I’m playing with a bomb if one day something changes my site explodes? so I asked gemini ??to simplify and explain everything, I hope it can help to understand how to make these options clickable directly in the options> fields in pods
I put the code at the end of the message

One detail that I noticed is that in the relationship field it does not visually display who is parent and child as (seen here) (ACF do it )
and one last observation, I activated Allow Add New > Taggable for my fields, so if I create a new term and save the post,
it does not take it into account, you have to save again, so 2 saves to see it apply, I don’t know if this bug is known or not.
but in any case if a pods dev comes to read this document he can take it as a reference to reproduce the scenario

i think i provided enough content to analyze to create a real ticket on github and a real discussion on whether we should improve all these points or wait for my site to explode on its own with all this code ??

/**
 * Update Taxonomies for Properties with Multiple Selections and Set Featured Image
 */

// Function for updating taxonomies and setting featured image
function my_property_update( $pieces, $is_new_item, $id ) {

  // Define taxonomies and pods fields (what data to update)
  $taxonomies = array(
    'property-type' => 'p-type',
    'property-status' => 'p-status',
    'property-feature' => 'p-features',
    'property-city' => 'p-city', 
    // Add the new taxonomy
  );

  // Loop through each defined taxonomy
  foreach ( $taxonomies as $taxonomy => $field_name ) {
    // Get the taxonomy data from the submitted data (pieces)
    $terms = $pieces['fields'][$field_name]['value'];

    // Sanitize and format the taxonomy data
    if ( empty( $terms ) ) {
      $terms = null; // Set to null to avoid errors if no data is provided
    } else {
      if ( ! is_array( $terms ) ) {
        $terms = explode( ',', $terms ); // Convert comma-separated values to an array
      }
      $terms = array_map( 'intval', $terms ); // Ensure all terms are integers (IDs)
    }

    // Update the property with the sanitized taxonomy terms
    wp_set_object_terms( $id, $terms, $taxonomy, false );
  }

  // Set the first image of the multi-select field as featured image (if applicable)
  $gallery_field_post_type = 'property';
  $multi_select_image_field_name = 'p_gallery';

  // Check if the multi-select image field exists, has values, and is not empty
  if (
    array_key_exists( $multi_select_image_field_name, (array) $pieces['fields'] ) &&
    is_array( $pieces['fields'][ $multi_select_image_field_name ]['value'] ) &&
    ! empty( $pieces['fields'][ $multi_select_image_field_name ]['value'] )
  ) {
    // Get the ID of the first image in the multi-select field
    $first_image_id = array_keys( $pieces['fields'][ $multi_select_image_field_name ]['value'] )[0];
    // Set the first image as the featured image for the property
    set_post_thumbnail( $id, (int) $first_image_id );
  }
}

// Function to assign parent terms (optional, adjust as needed)
function assign_parent_terms($post_id, $post) {
  // Check if the post type is 'property' to avoid unnecessary processing
  if ($post->post_type !== 'property') {
    return;
  }

  // Get all taxonomies associated with the 'property' post type
  $taxonomies = get_object_taxonomies($post);

  // Loop through each taxonomy
  foreach ($taxonomies as $taxonomy) {
    // Get the assigned terms for the current taxonomy
    $terms = wp_get_object_terms($post_id, $taxonomy);

    // Loop through each assigned term
    foreach ($terms as $term) {
      // Get the parent ID of the current term
      $parent_id = $term->parent;

      // Loop through parent hierarchy until a top-level parent is reached
      while ($parent_id && !has_term($parent_id, $taxonomy, $post)) {
        // Assign the parent term to the property efficiently using bulk assignment
        wp_set_object_terms($post_id, array($parent_id), $taxonomy, true);

        // Get the parent ID of the current parent for the next iteration
        $parent_id = get_term($parent_id, $taxonomy)->parent; // Optimized way to get parent ID
      }
    }
  }
}

// Action hooks for saving property posts with correct priority
add_action( 'pods_api_post_save_pod_item_property', 'my_property_update', 10, 3 );
add_action( 'save_post', 'assign_parent_terms', 11, 2 );

thanks it seems to work
can we hope for a generous and positive gesture from you to push for its integration into the logic of roles manager ? or settings ? to be able to hide all traces of SEO scores in the backend. This will prevent us from pasting snippets on several sites and using snippet plugins

I redid a test on a clean installation
WP 6.1.1 / PHP 8.0.x / Rankmath free

Plugins
I see two rankmath folders now. but the sequence is not correct there should be only one rankmath folder on top of the 3 fields. by checking it it should hide its fields.
but it’s even stranger something is not correctly detecting the sequence and the order of the items
we have two rankmath folders at the bottom and the 3 fields at the top in contact info.
click on Update Profile Features> Refresh profile items. Has no power to correct the order

image 1
imagine 5 plugins that add items and the sequence is random we will end up in total confusion something is not correctly detecting the order of the items
I hope that this data will be sufficient to initiate a fix on the detection code

tested on localhost with
laragon 6.0
php 8.0.28
PublishPress Capabilities 2.7.0
Rankmath Free 1.0.110.2

• This reply was modified 1 year, 8 months ago by neosan.

@rizaardiyanto
yes I’m always sure to always use the latest version before posting
the bug still exists regardless of the versions used

@rizaardiyanto
negative boss! we don’t have the visual of the target
I do not see it
it should exist at the location of the cross
visual confirmation
full image

you seem to have the empty folder bug too
under application passwords
something does not go as planned
we will wait for further instructions

• This reply was modified 1 year, 8 months ago by neosan.
• This reply was modified 1 year, 8 months ago by neosan.
• This reply was modified 1 year, 8 months ago by neosan.

@bungeshea
It’s a miracle ! it’s worked
thanks for the fix

Hi @mbis
I notified the devs behind jetformbuilder on github and the request was considered in the listing. we can soon hope for a hook or a code refinement update at plugin level to make compatibility possible between the two by default
I hope so ??</img>

Hello @rizaardiyanto and happy new year
I managed to make the code work I had not copied and pasted well

//* Hide this administrator account from the users list
add_action('pre_user_query','site_pre_user_query');
function site_pre_user_query($user_search) {
	global $current_user;
	$username = $current_user->user_login;
 
	if ($username == 'admin') {
	}
 
	else {
	global $wpdb;
    $user_search->query_where = str_replace('WHERE 1=1',
      "WHERE 1=1 AND {$wpdb->users}.user_login != 'admin'",$user_search->query_where);
  }
}

//* Show number of admins minus 1
add_filter("views_users", "site_list_table_views");
function site_list_table_views($views){
   $users = count_users();
   $admins_num = $users['avail_roles']['administrator'] - 1;
   $all_num = $users['total_users'] - 1;
   $class_adm = ( strpos($views['administrator'], 'current') === false ) ? "" : "current";
   $class_all = ( strpos($views['all'], 'current') === false ) ? "" : "current";
   $views['administrator'] = '<a href="users.php?role=administrator" class="' . $class_adm . '">' . translate_user_role('Administrator') . ' <span class="count">(' . $admins_num . ')</span></a>';
   $views['all'] = '<a href="users.php" class="' . $class_all . '">' . __('All') . ' <span class="count">(' . $all_num . ')</span></a>';
   return $views;
}

but that does not change the fact that it will be great if it was supported directly in a scenario where we would like for example to also hide editor and admin roles from authors etc.
in your link it talks about publishpres Permissions things that I don’t understand since capabilities already does by default what I want, my client role editor does not have the right to create higher roles or admin.
we would ideally just to allow this kind of hide in capabilities directly in the plugin . since it already does what Permissions does

it would be counter-productive and illogical to install two plugins to perform this single action
publishpress capabilities replaces my ex role editor plugin very well, he just need more.. Capabilities ??

• This reply was modified 1 year, 10 months ago by neosan.

hello,
thanks @gripgrip
I see that you have just reduced the box which does not solve the problem but tries to hide it.

let me explain the situation to you in detail, let’s try to understand each other ok?

In each wordpress installation that I do, the first thing that I install is publishpress capabilities, basically it allows me to regain control over my wordpress installation and to purify and eliminate all boxes and all menus and options not necessary for my clients

This guarantees clarity and a focus on the main tasks which are writing, filling out ACFs and posting.

Until today for years no plugin makes me advertise where I master my control over the WordPress backend.

This is why today I force myself to write you this message which should not normally exist because this situation is exceptional and unique

So technically our story has evolved and it’s no longer just a box story but it’s become a conflict of interest now

– the interest of wpcode in proposing advertising to live and evolve and monetize its plugin

– and the interest of users (me) to keep control over their WordPress installation and not be invaded by ads in their comfort zone

technically it’s like you walked into my room and put up a big ad poster without asking me anything. and you tell me, you can tear it off if you don’t like it.
you understand ?

As said before I suggest that you and your team get together to do the necessary and abandon this idea and localize the ad inside the plugin
As practiced by the majority of plugins

Your ad is noble and cool in form but it does not have the desired effect because it is not where it should be.

I hope you will take the time to convey my message to all the people at wpcode who insist on keeping this uncomfortable situation for all of us.