Plugin Author
Gunu
(@grafcom)
@beta2k,
first try the latest Beta version of qTranslate X
Download it here
And see if this makes a difference
Thread Starter
Beta2k
(@beta2k)
i just tried it.
strange, behavior is slightly different, but still not correct:
initial values:
english: valueENG
german: valueGER
then i edit the english version to “valueENG2” and hit update.
resulting values:
english: valueENG2
german: valueENGvalueGER
so the old english-value gets prepended (before it has been appended) to the german-value.
Plugin Author
Gunu
(@grafcom)
@beta2k,
please note that i also made this change: https://wordpress.org/support/topic/language-switcher-for-custom-fields?replies=3
How does it work if this adjustment is, temporarily, turned off?
Thread Starter
Beta2k
(@beta2k)
unfortunately still the same behavior.
old value of language A gets prepended to value of language B after updating a field of language A.
any idea on which side the bug occurs?
FWIW: as already said, please note that i use “Advanced Custom Fields: qTranslate” plugin and that i use the “qtranslate field types” which are made available by “Advanced Custom Fields: qTranslate” plugin. then i use the language switcher which appears in the admin menu to switch between languages to edit the custom fields accordingly.
screenshot of the admin interface when editing custom fields for my custom post type: http://i.imgur.com/kPBjtCs.png
FWIW2: i am aware that custom fields (without the need of “ACF: qTranslate” plugin) are already multilanguage-capable. however, for my customer, i prefer to have the language switcher buttons when editing custom fields. so this is the main reason why i installed “ACF: qTranslate”.
FWIW3: maybe some other plugin interfering? however, i think that’s not the case. for the sake of it, a screenshot of my plugin page: http://i.imgur.com/6MUpXNv.png
Thread Starter
Beta2k
(@beta2k)
i did some more debugging. i used the chrome console to monitor the http-requests which is issued after i hit the update button.
after hitting update i observe an http-GET request to the following url + parameters:
/post.php?post=113&action=edit&message=1
the content of this call is the html-content of the admin-page i was editing. there i can see the following html regarding the edited custom field: http://pastebin.com/MhBBHMDx
especially see line 9: value="oldENoldDE"
here you can see that already here the oldEN
value gets added in front of the oldDE
value.
i dont know if this has any further implications for debugging. but it seems strange to me that already when hitting the “update” button, there seems to be the wrong information associated to the input-field, i.e, oldENoldDE
.
edit: please note, that i am not sure which kind of information we can draw from above. i just saw that before that call there is also a POST call to /post.php
without any further parameters.
this call also contains data which seems to have the correct info of the fields:
fields[field_550f3af9b9cf0][en]:newEN
fields[field_550f3af9b9cf0][de]:oldDE
Thread Starter
Beta2k
(@beta2k)
sure, i already wrote you an email. let me check if i got your address right.
Plugin Author
Gunu
(@grafcom)
correct, delete image please
I suggest to take this issue to the author of ACF qTranslate. I see that he created <input> fields with ‘data-language’ attribute and with the same id:
<input type="text" data-language="en" value="" id="acf-field-testfieldqtranstype" class="qtranslate_text" name="fields[field_55340446e62d5][en]">
<input type="text" data-language="de" value="" id="acf-field-testfieldqtranstype" class="qtranslate_text qtranxs-translatable current-language" name="fields[field_55340446e62d5][de]">
I am not aware of what he is doing there, but this does not make much sense to me. Please, ask him to re-design this part taking advantage of the new q-X framework. I guess he does not need to do anything special anymore, his fields should work as is, without any special tricks.