multilingual-wp
multilingual-wp copied to clipboard
Compatibility with custom fields
As far as I understood from the the description this plugin creates a new page for every language but the custom fields cannot be translated/edited only the content.
I use Advanced Custom Fields http://www.advancedcustomfields.com/ for all my projects and a compatibility with custom fields will be very welcomed.
Basically I plan to allow the usage of quicktags/shortcodes anywhere that native implementation is not achieved(any custom fields, theme options, etc).
The only thing that could cause an issue is that the value of the custom field will have to go through either do_shortcode()
(or applying any filter that has this hooked like the_content
for instance), or through one of the translation functions - __()
, _e()
, esc_attr__()
, etc. If you display the fields via the template tags, then you shouldn't have any problems implementing that, I just don't know whether the fields value is passed through one of the above filters/functions when displayed via a shortcode.
I'll make sure to test that out at some point :)
For now, I will create multiple custom fields for every language and display them using the translation functions. Thank you.
I am thinking to develop my current site using this plugin, this way I can test it and give you feedback. Do you think there will be issues with the upgrade when the final version is out?
So, you shouldn't have problems with the posts/pages - since they're pretty much done(I mean if any bugs are found they'll be fixed). I still haven't implemented the Taxonomy translations/different URL's, but for now I assume you'll be able to use the quicktags and since I'll be making a migration tool from qTranslate, I'll also add that in there too.
PP: I still haven't hooked my translating functions to most of the filters, but I'll try to do that as soon as I can.
Just saw that the functions are not yet hooked to the menu. I will be out of town for a few days, after the trip I will test this plugin and give you feedback.
Sorry I got the wrong issue in the commit message.
What do you mean by that the functions are not yet hooked to the menu? Posts/pages were working before the last commit and after it you can use quicktags/translation shortcodes in Custom Item's titles(I'm still thinking how to allow different URL's for each language in Custom Menu Items) :)
I tried to use wp_list_pages and wp_nav_menu but the page/post titles remain unchanged if the language is switched.
I also created a post in Advanced Custom Fields forum asking for some help regarding the compatibility between ACF and Multilingual WP. http://support.advancedcustomfields.com/discussion/comment/16336
ed876c502f90fa8f161c12a0bf76f7e0a8064e39 fixes the issue with the pages not being filtered properly from wp_list_pages
.
da29018675ca09903bc81a9f26d8399a30ff145f fixes the wp_nav_menu
issue.
I played around trying to find the best solution for this issue and now an idea on how this functionality can be achieved just popped into my mind. An option to change the behavior of the language buttons in Multilingual WP not to switch between editors but to switch between the created pages. When you click on another language to automatically save a draft and when you update one language to update all related pages.
Thanks for the previous update.
Hmm... Currently this won't work - since basically the related posts store the title/content/slug. When a page in a specific language is requested, I simply override the $post
object by changing only the title/content/slug - this way the ID remains the same, so you can still get the meta fields for the original post as well as you can also perform other manipulation(like getting posts that are child posts of the current post, etc).
Like I said - the simplest implementation that I see is to use shortcodes/quicktags in the custom fields - of course this won't work for select fields, image fields, etc.
When I have time though, I might look into making an add-on for ACF that will give a better way of incorporating the multilingual support.
Currently there's an ongoing project that would create a unified API for creating custom fields, theme options and all kinds of form interfaces for WordPress. Ideally everyone should start using the built-in API once it gets into core(so hopefully plugins like ACF and all the other Custom Fields frameworks) - that would make it much easier for me to implement a solution that works for everyone out of the box, instead of having to do countless extra plugins for compatibility with all of the Custom Fields frameworks out there.
I opened a ticket at the project(ericandrewlewis/wordpress-metadata-ui-api#10) to see if there are plans on implementing some sort of filtering that would make this possible.