_JamesW

Hi, does anyone have a way of changing the email recipient based on input, as we could with wpcf7_before_send_mail?

Still using 3.8.1 to preserve that functionality! But obviously don’t want to stay on an outdated version.

Hi, when I went back and set up a test case from scratch I figured out what was going on.

All of my custom content types are grouped under a submenu (using Parent Menu ID). I had set up that submenu with edit_posts as the required capability. It seems that this permission governs access to the pods listing page of any pods under it. By creating a new capability for everyone who might be able to view that menu, I can get the result I wanted.

I do think the way it’s working is a bit odd:
{site}/wp-admin/edit.php?post_type=testpod
will work if I have access to testpod and it’s not in a submenu.
If I move it under a submenu that I don’t have capability for, that same url no longer works.
However I still see the menu and the link (as long as I have edit_testpods).
So the menu permission is affecting my ability to use the pod listing, but not my ability to see the menu.

Anyway, that’s just minor oddness. The main problem was my submenu permissions.

Thanks!

Hi,
It’s using Advanced Content types without any custom code, and I was able to reproduce it with a clean install as follows:
– Created a new pod ‘atest’, content type: advanced content type.
– Named it, did not add any fields (so I just have out of the box fields name, date created, date modified, author, permalink)
– Went to admin ui tab and checked ‘date created’ under the search filters tab.
– Created a record to test with.
– In the manage atest screen, clicked on advanced filters, date created from and to are there and functional.
– Edit the date created field, advanced tab, checked ‘make field read only in ui’ and saved.
– Back to manage atest screen, advanced filters, date created from and to are still there but are now read only. So while my intention was just to stop it from being edited, I have now prevented admins from filtering on it.

Thanks!

I think for me the system for retrieving records would be the main thing.
The notation for field names for example, is tied to the underlying data structures and storage methods. So it’s quite easy to have problems in a lookup that aren’t immediately apparent. I know it’s a very difficult thing to have arbitrary data structures stored in multiple different ways, yet present a universal structure for querying them – but it would be nice 🙂

Right now it seems like I get back way more information that I need (with sql I would literally get one field value, with pods I get every piece of metadata about every field) – but not quite enough information to simplify the query (if it’s going to look up all that metadata anyway, why does it need me to be explicit about how each field is stored?).

Hope that makes sense! None of the issues I have with pods ever stop me from accomplishing what I set out to do – it always does the job. And I’ve certainly had similar issues with other similar systems like CCK. But there’s always something!

Just an extra note, the above was when uploading through the media tab.

If uploading directly in a post it actually shows an error message and does not allow you to insert it (but it has been uploaded if you check the media gallery).