I just tested this thoroughly yesterday again and have sent a report to the developers to confirm the behaviour, so we can then document this as well.
Here is what I have found in my tests:
In Notifications that are deferred (sent on post-expiration, or when the post status changes), Types and Views ShortCodes require an ID to be set, so to return the expected data in notifications, otherwise, they will not render any data at all.
Test Results:
1. On an "Add Post" form, notifications sent when the form is submitted will send expected results for ShortCodes (both Types and Views) without ID specification. Specifying the ID also will not break them.
Example: [wpv-post-title], [wpv-post-title item="%%POST_ID%%"]
2. When Notifications are deferred either by expire or post status change, then both Views and Types fields will not return any result if no ID is passed.
To fix this you need to pass an ID, populated with the placeholder of Forms, for example:
[wpv-post-title item="%%POST_ID%%"]
3. In a "Add User" Form, the Views "User ID" ShortCode will NOT deliver the new created user ID.
Form Placeholder and Types Fields ShortCodes instead do deliver data of the user created by the form, without specifying an ID.
This should be expected and can be solved by adding the User ID to the View's ShortCodes. But that is also not documented
Example:
[wpv-user field="ID" id="%%USER_USERID%%"].
Additionally, USER_USERID here is missing from the GUI, while other user data can be found.
I have tested above both with Views and Types Fields/ShortCodes.
Now, the first link provided (DropBox) is an RTF file.
THe second link throws an error:
"Es tut uns Leid, die von Ihnen gesuchte Seite konnte nicht gefunden werden."
(We are sorry, the website could not be found)
The third file was the backupbuddy.php script, but now it asks for the "Upload a Backup" (which I assume should be the second file sent by you).
Could you provide that file again?
