Viewing 11 replies - 76 through 86 (of 86 total)
  • Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Grrr. I will conquer these issues. I just don’t know how yet *cries*

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    VPR and anyone else, who wants to perform a test for me?

    Hi Michael,

    What do you need?

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Vengador, if you would be so kind to help test changing the priority on this line, around line 95 of custom-post-type-ui.php from 11 to 10.

    add_action( 'init', 'cptui_create_custom_post_types', 11 ); //Priority 11 so that the taxonomies are registered first.

    and see if that helps fix rewrite issues if you’re still having them.

    It will need to be on the latest version of the plugin, in case you reverted for the time being.

    Bad news ?? It doesn’t work in my case.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    I forget if you’ve emailed me your export settings before, but would you be willing to send them my way? Just visit the Import/Export section and use the Post types tab. michael @ webdevstudios . com

    Hi Michael, Thanks for all your help sorting this stuff out. I have been following this thread, and so far I’m able to remedy the 404 issue by re-saving the CPTs, BUT periodically they become disconnected again, and the 404 comes back. I have not been able to ID anything specific that causes this to disconnect again anad again, and re-saving the CPT’s does reconnect everything, but it continues to be an issue for whatever reason.

    What I have noticed is that it seems to be specific to the single view (single-CPTname.php). CPTs are pulled in to other areas of the site just fine, and DO work even when the single view gets a 404. Not sure if this clue helps or not, but hoping you have some ideas on all this? Thanks so much!

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    CloudburstDesign, have you tried the priority change from my last reply in this thread? I wager it’s still a query/permalink issue.

    FWIW the latest version (1.0.8) still doesn’t work on me. Let me explain my situation a bit better.

    On the site I have custom post type permalinks configured as https://example.com/brand/test/ and with subpages for those (https://example.com/brand/test/subpage/). I also have another plugin that handles mapping separate domains to brand sites so the sites can have URL’s like https://test.com/subpage/. When the user accesses that URL the system checks the custom domain based on mapping rules in the database and returns the correct WordPress post id with correct layout and content. This works just fine with older versions (I’m now using 0.8.5).

    With the newer version of the plugin the permalinks are somehow messed up so that when I call get_permalink() for https://test.com/subpage/ it returns “https://example.com/test/subpage/”. That means that the function never passes the part where I check if the url has “brand” in it and I get a 404 error. I can work around this by using get_post_type() but after that when I rebuild the full URL and check the ID of that with url_to_postid() the function returns the ID of https://example.com/ and all brand subpages show the content of the main site’s front page. Again this works correctly with the old version of the plugin.

    I have flushed permalinks multiple times and also saved all post types and taxonomies without changes to see if that fixes the problem. That fixed the multiple PHP notices I got from the plugin but not the main issue.

    Please try to solve this problem so that I don’t have to resort to using an older version of your excellent plugin.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    I’m honestly not sure why it’s failing you still with that usecase, so I don’t know what I would need to do to get it fixed. It sucks for me to say, but I don’t know. I’ve looked over the spot that registers based on settings multiple times, and as far as I can see, it’s presently matching up the best it can at the moment based on provided values, php value types, and WP defaults when nothing is set. It’s also mixing things between other plugins, which can introduce conflicts.

    This isn’t me deflecting blame, but something in your setup isn’t matching up like it needs to be, but we don’t know what yet or why.

    Hey guys,

    This issue was fixed for me in 1.0.8 version. Thanks Michael for your great work!!

Viewing 11 replies - 76 through 86 (of 86 total)
  • The topic ‘Updated and now 404’ is closed to new replies.