Viewing 15 replies - 61 through 75 (of 104 total)
  • Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    @thomaskdev not quite following what you’re requesting, but at the same time it sounds less like a feature request and more like a general support question. Can you start a fresh thread and also provide more details of what you’re trying to achieve?

    Yes s?re, I have created a new topic to my question.
    Link here : https://www.ads-software.com/support/topic/from-free-version-to-polylang-pro/

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    @thomaskdev looks like you linked me to a Polylang thread.

    Ability to disable a CPT or Taxonomy without deleting it.

    I am using CPT UI to create the code for plugins and I need to temporarily disable a post type or taxonomy in CPT UI while I test my code. But I don’t want to delete it until I know my code is working.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Hey Dave, I think this may already be possible without having to do any changes to the plugin.

    I copy/pasted the “get code” details into my dev site’s active theme’s functions.php and those took over, without losing any of my settings for CPTUI.

    Basically, it’s a case of whichever version registers the slug last, has its settings used. Theme functions.php is run later than a plugin file, so the init hooks there get loaded later and thus end up getting the preferred treatment.

    Alternatively, it should be possible to unregister the ones we register in the plugin, using unregister_post_type() / unregister_taxonomy() with the following hooks we’ve provided. Do note I haven’t actually tested this out, but logically it should work:

    /**
     * Fires after the completion of the post type registrations.
     *
     * @since 1.3.0
     *
     * @param array $cpts Array of post types registered.
     */
    do_action( 'cptui_post_register_post_types', $cpts );
    
    /**
     * Fires after the completion of the taxonomy registrations.
     *
     * @since 1.3.0
     *
     * @param array $taxes Array of taxonomies registered.
     */
    do_action( 'cptui_post_register_taxonomies', $taxes );
    

    Both run after we’ve gone through and registered all of CPTUI’s saved post types/taxonomies.

    Thanks. I’d still like to disable a CPT or Taxonomy in CPT UI so that I can use it to clone later without being active.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Hi Michael,

    Thanks for your awesome plugin !
    I’m using it on a multilingual website with WPML and the WPML support noted somehting while helping me debug their breadcrumbs :

    In CPTUI > Add / Edit Post types > Edit Post types tab > Name_of_the_CPT, we needed the Has Archive parameter to be false. Even if it was, WPML still saw it as true.
    We had to empty the field Slug just underneath (as long as there was something in it, the false parameter was ignored).

    WPML support suggested that I reported this, so here I am ??

    Thanks and have a nice day !

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Logically, how we’re doing it does make sense. Something was provided for the custom archive slug, so it should be used. We don’t strictly rely on the true/false value for the rest.

    Current code for that parameter:

    $has_archive = ( isset( $post_type['has_archive'] ) ) ? get_disp_boolean( $post_type['has_archive'] ) : false;
    if ( ! empty( $post_type['has_archive_string'] ) ) {
    	$has_archive = $post_type['has_archive_string'];
    }
    

    We default to false, if nothing is provided in the settings, whether that setting says true or false. Then if there’s a string to use, we automatically use that.

    However, I can also see the logical sense of doing an extra check for “true” AND a string to use.

    I’m going to open an issue for that one for consideration.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Ability to add taxonomy to woocommerce product variations.

    I am currently using this plugin to add a Colors taxonomy to my products, which my users can use to filter the products list. I’m using another plugin that allows product variations to show up in the product list. However, since the taxonomy is assigned to the product and not the variations, when using the filters none of the variations show up.
    After messing with the database I was able to assign a color to a variation, and it then showed up in the product list when using filters, I just don’t have any way of actually adding taxonomies to the individual product variations outside of modifying the database.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    I believe the WooCommerce variations part is going to be well above and beyond what CPTUI strives to be for. The biggest hurdle there is the fact that variations aren’t a post type themselves. It’s all post metadata on the product post. Sadly, I don’t have an answer for this beyond that much.

    Thanks, I can understand it being beyond what this plugin is for. Though when i look in the posts table, product_variation is its own post_type, plus each variation has its own entry in the posts table. I can also assign my existing taxonomy data to them by swapping the product’s post_id with the variation’s post_id. Ill just have to figure out how to modify it to get what im looking for, any help to point me in the right direction would help though. Thanks again.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Hmm. Missed seeing that post type. I was looking at and seeing the _product_attributes meta key.

    Sample value:

    a:1:{s:5:"color";a:6:{s:4:"name";s:5:"Color";s:5:"value";s:10:"blue | red";s:8:"position";i:0;s:10:"is_visible";i:1;s:12:"is_variation";i:1;s:11:"is_taxonomy";i:0;}}
    

    Something to keep in mind is if those post types are made public or not, and similar other details that may be playing a part in everything.

    This is more like an improvement request: Currently, you can link post types to taxonomies from either the post page edit screen or the taxonomy edit screen. This is good. However, if you unlink it from one screen, it doesn’t unlink it from both, and it remains linked until you go to whichever end you didn’t use to update the association.

    Also, if you’ve created a custom post type, you can’t see which taxonomies you’ve already linked it to in the taxonomy screen, so you’re likely to double link it just to make sure both taxonomies are there… and vice versa.

    This may not be a problem for most users, but I’m developing a complex site, and this is doing my head in. Then again, couldn’t survive without this plugin! ??

Viewing 15 replies - 61 through 75 (of 104 total)
  • The topic ‘Feature requests’ is closed to new replies.