I have a custom post type 'content-panels' that has a many-to-many relationship with Pages.
I would like the order of the Content Panels to be different on a page-by-page basis, so I have created a numeric custom field ('position-of-content-panel-on-page') that is associated with the intermediary post type: 'content-panel-page'.
I have successfully set the order number for the Content Panels (different for each page). The problem I have is that I need Views to output the Content Panels in the order dictated by the same intermediate custom field.
Solution:
You need to setup a post view:
- Query posts of intermediary post type 'content-panel-page'
- Order the results by custom field 'position-of-content-panel-on-page'
- Filter by post type relationship between 'content-panels' and 'Pages'.
- In view's loop, display related "Content Panels" post information
Problem:
Client has a parent View which iterates over some posts and includes nested Views in its output. If none of the nested Views have any results, the parent View should not output anything for that iteration.
Solution:
Set up the parent View with CSS so that for each iteration nothing is displayed.
Then add JS to the nested Views in the wpv-items-found section but outside of the wpv-loop tags which sets the display property of the parent to 'block' so that the content becomes visible.
The parent View can generate a wrapper for each iteration with a unique class name, like so:
<div class="results-container-[wpv-post-id]">
The nested Views can then target that unique class name like so:
Problem: When Types is active, I see several malware scripts appear in the network activity on my site, as well as in webpagetest.org tests. The following domains appear in the asset list:
- tags.bluekai.com
- match.adsrvr.org
- aa.agkn.com
- dis.us.criteo.com
- bcp.crwdcntrl.net
Solution: In this case, it appears a Trip Advisor widget was responsible for these requests. The widget only appeared when Types was active, so it seemed as though Types was responsible for the malware.
Problem: I would like to display the parent taxonomy term name on the child term's archive page.
Solution: There's not a way to do this with shortcodes alone, so you'll need to use Views or you can write your own custom code. The Views approach is described below.
- Create a new View of your taxonomy, filtered by taxonomy term ID, where the term ID is provided by a shortcode attribute "ids".
- In the Loop Output editor, place the taxonomy title shortcode or the taxonomy link shortcode - this will be used to display the parent term so format it however you would like.
- Place this View inside your taxonomy WordPress Archive's Loop Output editor, outside of the wpv-loop tags, but inside the wpv-items-found tag.
- Add the "ids" shortcode attribute to the View's shortcode, and use the wpv-taxonomy-archive tag to supply the value of the parent term ID:
So you're accessing the parent term ID with the wpv-taxonomy-archive tag, and using that value to define the filter for another View. This is called passing arguments into a View.
En Toolset erratas, documentamos problemas conocidos y sus soluciones. Ahorre tiempo consultando allí primero y viendo si el suyo es un problema conocido. Mantenemos la lista corta. Hacemos lo mejor que podemos para resolver todos los problemas conocidos con cada lanzamiento de los plugines de Toolset.
Política de soporte
Nuestro personal le ayudará a usar los plugines de Toolset correctamente, le proporcionará la información que necesite, le ayudará a resolver problemas y lo asesorará con respecto a las mejores prácticas.
Sírvase asegurarse de incluir solamente un tema en cada solicitud de soporte.
