1 - When you create a new Repeatable field group and give it a name, that is the same as an existing post type, it causes the original post type content non accessible from the back end. After changing the name of the Repeatable field group the problem was fixed and all the original post data appears to be fine.
Solution - There should be a system check when you create (save) a new Repeatable field group and visa versa New Post Type, to make sure that the name is not already being used.
2 - When submitting a new Repeatable field group post on the front end using a form, if you do not assign a post title it causes a critical error. The post does not appear on the back end. So you can not edit or delete it. However it does appear on the front end in a view, so I was able to edit or delete it that way. After doing so every thing seems to be working fine.
Solution - Post title should be an automatic required field ?
Looking forward to hearing your thoughts and opinions. Thanks
I checked the above on my own test site and I couldn't reproduce either of the issues.
In Screenshot 1 you can see what happened when I tried to add a RFG which used the slug of an existing post type.
In Screenshot 2 you can see what happened when I tried to register a new CPT with the same slug as had been used by an existing RFG.
And in Screenshot 3 you can see what happened when I tried to submit a form to publish an RFG without supplying a title.
If these things are occurring on your site you'd need to make sure your plugins were up-to-date, and to eliminate possible conflicts by deactivating all plugins except Types and Forms and switching to a default theme.
If you still see the same problems we'd need a copy of your site to investigate further. You could use Duplicator, as described here: hidden link
Or you may find All in One WP Migration easier to use, just be sure to exclude the media library as well as plugins and theme when creating the package to reduce its size.
You can share a link to the archive on dropbox or similar here, the link will be hidden from other users.
I get the same as you if I use the same slug. But I don't think its the slug that is causing the issue.
On you sample keep the post type the same as Screenshot 2.
Now in your RFG use Items as the group name and items as the slug. This should cause the problem.
It looks like if you use the plural name of the post type as the name and slug on the RFG the problem will occur.
With this set up then try to make a post (without a post title) and I hope you should get the critical error.
I still can't reproduce the problem. I set up a brand new test site just to be sure.
I created a CPT "Items" (slug "item"), and added a field group to it which includes an RFG "Items" (slug "items").
I had no problems editing posts in the back end, and a front-end form to publish RFGs couldn't be published without providing a title, and no error was thrown.
I don't mean to dismiss it, but given that this is a usability which you've already bypassed yourself, which no-one else has reported, and which I cannot reproduce, and not sure it merits pursuing much further.
If you want to, I'll need exact steps to reproduce it.
I can put up with issue #2 as it has only happened once and only on the very first test post.
However issue #1,
I have narrowed down the problem further.
My understanding is that RFG's are basically just another post type, but a child of its parent. You can not access it from the admin menu like other CPT , but only from the parent post.
Now this coding to remove access from the admin menu is somehow my problem. If you give a RFG a "group name" that is the same as a CPT "plural name" it will remove access from the admin menu for the CPT. You can still edit each post, if you know the link, or access it from the front. You just can not access the directory of the CPT, even if you know the link.
Why not have it based on the slug ? OR do a check so you don't duplicate the names. On the other hand if its a conflict with another plugin, I have not found it yet.
