WPML File Attachments
WordPress stores file attachments according to the ID of a particular post object, while WPML translates posts by changing the post object ID according to the user’s language.
See WPML function documentation for wpml_original_element_id:
$element_id would be the ID of the translated post object currently being viewed.
$original_id (the value returned and stored in their example) would be the ID of the original post object, to which the PDF file is attached.
If your file field is named pdf_file:
WordPress core should return the URL of the file with:
$file_url = wp_get_attachment_url( get_post_meta( $original_id, 'pdf_file', true ) );
Or with Pods API:
$file_url = pods( 'name_of_post_type', $original_id )->field( 'pdf_file' );
Or Pods API displaying a link to the file:
echo pods( 'name_of_post_type', $original_id )->display( 'pdf_file' );
Formatting Functions
The syntax for formatting functions is {@name_of_field,name_of_function}
See Date Format Output Filter for Magic Tags for an example date format filter.
If the function is named my_date, then add my_date to the comma-separated list Display callbacks allowed near the bottom of Pods Admin > Settings
The linked example uses date() to specify one format. In multilingual contexts, WP’s date_i18n combined with WPML’s date format translation may be beneficial.
Registering Page Builder Widgets
This might depend on multiple things when translating within page builders…
Generally, “Pod not found” means that the widget was unable to identity the Pod name automatically. Manually setting the widget’s “Pod name” might fix this, but if the theme or translation system are changing the context, it may or may not then have trouble identifying the ID of the specific object to display automatically if that is not set.
On the Pods end, Pods needs to know what type of content to display (the Pod name, post type, taxonomy name), and what specific content of that type to display (the ID or slug of a post, a taxonomy term, or the result of a query).
When translation systems or page builders rewrite or otherwise change the WordPress templating system, it can cause integrating plugins to need manual rewiring to identify what content goes where (things which would normally work automatically then require custom solutions).
Some information on the requirements of WPML’s approach can be found at https://wpml.org/documentation/support/language-configuration-files/how-to-register-page-builder-widgets-for-translation/
orderby
Check the expected syntax of orderby at https://docs.pods.io/code/pods/find/ — it is a full MySQL orderby statement, not just a field name, e.g.,:
t.post_name DESC
t.post_date ASC
…where t is the primary table being queried (wp_posts, wp_terms)
name_of_date_field.meta_value ASC
…where name_of_date_field is a custom field name, not prefixed by t.
