• Hello,
    I almost managed to customize the display of relationship field > List View input
    based on this post found here

    by chance by following the logic of the code and a little help from IA
    I want to do the same thing but the informations is in a (property-feature) taxonomy and all the fields are pods (we stay in pods 100%)
    I tested and I was able to display the IDs and term_description, but not my others fields image or another field (pods)

    Before code

    add_filter(
    'pods_field_pick_data',
    function ($data, $name, $value, $options, $pod, $id) {

    $relationship_field_name = 'p-feature'; // Replace with your actual relationship field name
    $post_type = 'property'; // Replace with your CPT name

    if (false !== strpos($name, $relationship_field_name)) {
    foreach ($data as $id => &$label) {
    $pod = pods($post_type, $id);

    $feature_category = $pod->field('feature_category');
    $feature_image_id = $pod->field('feature_image');

    // Ensure feature image exists and is a valid image ID
    if ($feature_image_id && wp_attachment_is_image($feature_image_id)) {
    $feature_image_url = wp_get_attachment_url($feature_image_id);

    // Check if image format is SVG (ensure proper MIME type check for SVG)
    if (strpos(get_mime_type($feature_image_id), 'image/svg+xml') !== false) {
    $feature_image_url .= '.svg'; // Append .svg if image is SVG
    }
    } else {
    $feature_image_url = ''; // Set to empty string if not a valid image
    }

    $term = get_term($id); // Get term object using term ID
    $term_description = $term->description; // Get term description

    $label = sprintf(
    '%s - %d - %s - %s - %s',
    $label, // Term name (already set in $data)
    $id,
    $feature_category,
    $feature_image_url,
    $term_description // Add term description
    );
    }
    }
    return $data;
    },
    10,
    6
    );

    After code
    as you can see I have not managed to display the images attached to my tax (svg),
    how can I display or adjust them ?
    if you have a solution to achieve this result please share it

    Desired result

    note that pods cannot at the time I write this post differentiate between parent terms and child terms everything is offered in raw list,
    if I have the possibility of reorganizing my lists by the bars I do not need the arrows
    it overloads the content and confuses the end user we do not have control over that at the moment, you have to inject a css
    .pods-list-select-item__move-buttons {display: none!important;}

    a possibility to deactivate the rerange for parent terms would be welcome or even deactivate them (gray display) maybe even hide them I let you imagine the disaster of changing the order of parent terms ??

    • This topic was modified 4 months, 2 weeks ago by neosan.
    • This topic was modified 4 months, 2 weeks ago by neosan.
Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter neosan

    (@nreljed)

    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.
    Thread Starter neosan

    (@nreljed)

    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

Viewing 2 replies - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.