• Hey gang! I realize I’ve been pretty quiet for a while and for that I apologize.

    But know I’m back on the job and want to whip the plugin into shape.

    Just be patient with me. There may be multiple updates coming up in swift succession as I try to get fixes out as quickly as possible.

    Thanks!
    Rachel

    https://wordpress.org/plugins/cpt-onomies/

Viewing 15 replies - 16 through 30 (of 66 total)
  • First, thank you Rachel for continuing to support this plugin. It really is a FANTASTIC solution to more complicated WordPress content relationships.

    With that being said, is there any ETA on getting the plugin fully compatible with Core 4.6.*? A lot of us have client sites that rely on this and it’s currently still partially broken particularly when using get_the_terms().

    I was going to attempt to dig into this myself last weekend but saw you had made some new commits. Again, thank you for your work here, we’re all just hoping to see this plugin brought back up to snuff with 4.6.*.

    For me, the error messages are happening as a result of the add_filter( 'get_object_terms', array( $this, 'get_object_terms' ), 1, 4 ); line in cpt-onomy.php. If I comment out that line, the messages are gone. I tried isolating it further within that function, but the parameters that are set all look correct.

    Has anyone else found a workaround yet?

    Has anyone found a workaround? I’m getting nervous. My server is going to force my 4.6 upgrade in 13 days.

    An update is planned?
    I should look for an alternative?

    Based on the remark by danielshields I only found out that post.php is trying to also process WP_Error instances instead of WP_Term instances. So I am not sure if those were previously filtered out. WP_Error instances of course have no term_id and thus it breaks.

    I have no idea though how to fix that as I am not really too much into the taxonomy part of wordpress. I guess one could filter out the WP_Error instances in cpt-onomies (they are created by a filter I think) but one would need to find the right call to it I guess.

    Hey gang. I didn’t realize there were still issues.

    I’ll read through this tonight and let you know what I find.

    creeser

    (@creeser)

    Rachel, if I can help in any way by testing please let me know. I appreciate you looking into it.

    compujeramey

    (@compujeramey)

    Any word on this? Or section of the code we can looking in to help?

    I was looking around again for a solution to this PHP warning message and came across this thread where @lucastello shares a fix.

    There are 2 instances of the following in cpt-onomy.php:
    $terms[] = $term;

    Change them to include wp_cache_add:

    wp_cache_add( $term->term_id, $term, 'terms');
    $terms[] = $term;

    I hope this helps the rest of you!

    THank you so much for this! I can verify that it worked for me installation

    Since updating to WP 4.7 our sites are broken due to this plugin (which is an awesome plugin, while it worked :P). Page requests result in 500 server errors and give a PHP memory leak. Is this a known bug and will this be fixed in an update?

    For what it’s worth, I’m having the same issue as @alientrick on an existing site. Updated WordPress to 4.7 and instant front end white screens. Admin works fine. Disabling the CPT-onomies plugin only plugin causes the site to display normally again.

    WP debug logs aren’t showing anything, and there is nothing in the error logs on the server.

    Any news on when this will work with 4.7

    Same issue as @alientrick and @tunamaxx. WP changed some things about taxonomies in this latest version so I’m sure this is the problem. In the meantime, I rolled back my WP version to 4.6 and it’s working. Hoping there’s a fix for this plugin so I can use it and update my WP.

    Hey @bamadesigner! Merry Christmas!

    Sorry if I’m adding any salt to wounds, but wanted to confirm that 4.7 really breaks the plugin. 🙁 WP 4.7 added the Rest API to the Core but in the process they removed the filter argument from endpoints. You can reinstitute it back with a plugin, but there’s a major memory drain when trying to browse a custom post type either in the WP Admin backend or via the API in the browser or from a service call. When I disable the plugin my custom post types work fine.

    It looks like several people have volunteered to assist. If you can please provide us with more info, perhaps one of us can help. It seems there’s only one plugin like this and we’re all dependent on it. So let us know how we can help!! Thanks!!

Viewing 15 replies - 16 through 30 (of 66 total)
  • The topic ‘Updates are coming’ is closed to new replies.