Hello,
This is a general question about using Toolset Views Content Templates for building pages.
What methodology do you recommend to meet both requirements:
- A client with limited access can manage the page content
- The page can be easily translated with WPML
Thanks, Volo
Hi Volo, we have some documentation about translation workflow here:
https://toolset.com/documentation/translating-sites-built-with-toolset/
and specifically content templates translation here:
https://toolset.com/documentation/translating-sites-built-with-toolset/translating-content-templates-wordpress-archives-views-cred-forms/
As far as client access, you would need to know what specific types of access you would like to grant the client: Add / Edit / Delete posts, only certain post types, in only certain languages, can they translate existing content, translate only new content, etc... Lots of possibilities here that are managed by either Access, or WPML, or a combination of both. Any more specific details you can provide me would be helpful.
Hi Christian,
I will try to rephrase my issue to better point the actual pain.
When I develop a website with WordPress, I use the text editor (not the visual one) to create the pages and use HTML tags, indent the code, etc. See print screen. It is an easy solution to translate the content: I only need to create the translated pages with WMPL.
The problem comes when the client needs to manage the page content itself. He usually isn't familiar with HTML tags and rather likes to use the visual editor, which messes up the page display while switching from one editor to the other. I then think I shouldn't use HTML tags in the main page editor and create a Content Template for each page using the Toolset editor to write the HTML and the texts. The pages content is left empty. This isn't an easy solution to allow the client to manage the content nor an easy solution to manage the translation. The texts are wrapped in [wpml-string context="wpv-views"] shortcodes and translations need to be adapted every time the original language string is updated.
Do you understand my pain? Better, do you have a solution? 🙂
Regards, Volo
Volo I think I understand your problem a bit better. I think that you should keep the Page's content in place, and you should not write all your text in the Content Template. You would use shortcodes like [wpv-post-title] and [wpv-post-body] in your Content Template, along with all your custom markup. This way, a Page is easily translated with WPML, and your Content Template html markup will not be broken in an editor. The Content Template link I mentioned has this example:
<h2>[wpv-post-title]</h2>
[wpv-post-body]
<div class="house-size">[wpml-string context="wpv-views"]Size:[/wpml-string] [types field="size"][/types]</div>
<div class="house-area">[wpml-string context="wpv-views"]Area:[/wpml-string] [types field="size"][/types]</div>
The strings "Size:" and "Area:" will be translated only once per language using String Translation. They will not need to be modified when your page's content changes. Does this help?
Hi Christian,
I understand your point and, in the same time, it does not solve the following use case that I am facing in almost all my website developments: using the Bootstrap grid to display the page content responsively.
Is the Layouts plugin the only solution here?
Regards, Volo
Hi Volo,
Do I understand correctly: You would like your page content, i.e. wpv-post-body, to include a custom grid-based Bootstrap layout. You do not want your editors to break the markup for this grid system when they modify content.
If this is the case, then it might be best to break apart your wpv-post-body content into multiple custom fields. For example, you could have a custom field for a subtitle, an image slider, a blockquote, a View, etc. Then you can arrange these custom fields into a grid as you see fit. You could define that structural markup in your Content Template, and include shortcodes to represent each custom field. Editors would modify the content of individual custom fields rather than the structural markup. This approach works well if your posts have a consistent grid structure.
Even with the Layouts plugin, you'll need to break apart your wpv-post-body content into multiple custom fields to accomplish what you want. When you place content from your post in a Layout cell, you place the entire wpv-post-body in a cell rather than individual parts of its content. Does that make sense? So with either approach, in order to place content in grids spanning across multiple cells, the content must be broken up into individual pieces, i.e. custom fields. Otherwise, the markup that represents your grid and cell structure will appear in content editors.
Hi Christian,
Yes this is it.
I understand the concept of your solution (break apart the wpv-post-body content into separated custom fields). I still need to figure out how to do it in practice though.
Regards, Volo
