PHP Fatal error: Cannot unset string offsets.... qtx_configuration.php on line 143
picasso opened this issue · comments
Version: 3.2.9.8.4
PHP Fatal error: Cannot unset string offsets in ..... /plugins/qtranslate-x/admin/qtx_configuration.php on line 143
It happens when I try to save a new post of custom type with additional fields... one of these fields is empty... and in processing of this empty field in qtranxf_collect_translations - fatal error happens...
I think you should add a check before processing the field in qtranxf_collect_translations
hope this helps to improve the plugin. I like it.
Is that error reproducible or just one time occurrence?
I can only think about some kind of incompatibility with earlier versions of PHP?
What kind of check I could possibly do here? Two lines above there is a check "if(isset($texts['sep'])){" and then it cannot unset it? It is a puzzle ... The only thing which comes to my mind is that variable $texts is a reference, which is set above at line "$texts = &$q_request;" Maybe earlier versions of PHP could not unset referenced variables?
I am glad I did not release 3.3 yet. This one would be important to figure out.
Could you change the code, to get rid of referenced variable $texts, like this:
$q_request[$edit_lang] = $request; if(isset($q_request['sep'])){ $sep = $q_request['sep']; unset($q_request['sep']); }else{ $sep = '['; } $text = qtranxf_join_texts($q_request,$sep);
instead of this code:
$texts = &$q_request; $texts[$edit_lang] = $request; if(isset($texts['sep'])){ $sep = $texts['sep']; unset($texts['sep']); }else{ $sep = '['; } $text = qtranxf_join_texts($texts,$sep);
Although, it is unbelievable it would help, but what else would? Please, let me know the result or maybe let me access that server, if possible. Thank you very much.
I might know what that is. Please, hold with your testing until I push an update - I will let you know.
Is that error reproducible or just one time occurrence?
100% reproducible.
I can only think about some kind of incompatibility with earlier versions of PHP?
I do not think so. My site is hosted on WPEngine.com
I think they have the latest version.
What kind of check I could possibly do here? Two lines above there is a check "if(isset($texts['sep'])){" >and then it cannot unset it? It is a puzzle ...
For me it's also a puzzle. I've seen all these ISSET and I do not understand how the code could proceed until UNSET()...
I put some logging before call of qtranxf_collect_translations
and before the call variable $r is '<'
[Fri Apr 10 07:14:51 2015] [log] REQUEST[qtranslate-fields][ wpcf[program ]: <, referer: http://truewine.wpengine.com/wp-admin/post-new.php?post_type=event
[Fri Apr 10 07:14:51 2015] [log] q_request=, referer: http://truewine.wpengine.com/wp-admin/post-new.php?post_type=event
[Fri Apr 10 07:14:51 2015] [error] PHP Fatal error: Cannot unset string offsets in /nas/wp/www/cluster-3217/truewine/wp-content/plugins/qtranslate-x/admin/qtx_configuration.php on line 153, referer: http://truewine.wpengine.com/wp-admin/post-new.php?post_type=event
Maybe it's because the name of field is wpcf[program]? As you can see the closing ']' was lost from the name of field...
The code for logging looks like this:
error_log('REQUEST[qtranslate-fields][' .$nm. ']: '.$r);
Could you change the code, to get rid of referenced variable $texts, like this:
I've tried but the result is the same.
or maybe let me access that server, if possible
I can, but it's in Russian... will you be able to navigate there?
If you still need it - tell me and I'll create an user for you.
I've made some more tests. And even if this field is not empty - result is the same.
I suspect that the name of the field is the main reason.
This name is generated by Types plugin. It's not my invention :)
Hi Dmitry, @picasso, please try the latest from GitHub: https://github.com/qTranslate-Team/qtranslate-x/archive/3.2.9.8.5.zip Does it still have a problem?
Hi @johnclause,
thanks for the update.
Now it works, there is no fatal php error.
But now I have another problem - 3 fields which are attributes of custom post type Event after Save return as empty. They were filled before I press Update button but after refresh they are empty.
here is html for the first field 'start date' (I've copied it from Firebug after all scripts are completed):
<div class="js-wpt-field-item wpt-field-item">
<label for="post-textfield-3-1428662145" class="wpt-form-label wpt-form-textfield-label">Start Date*</label>
<input type="text" data-wpt-id="" data-wpt-type="textfield" title="Select date" readonly="readonly" style="display: inline; width: 150px; position: relative; z-index: 999999;" class="js-wpt-date wpt-form-textfield form-textfield textfield hasDatepicker" value="" name="" id="post-textfield-3-1428662145-103">
<img class="ui-datepicker-trigger" src="http://truewine.wpengine.com/wp-content/plugins/types/embedded/common/toolset-forms/images/calendar.gif" alt="Select date" title="Select date">
<input type="hidden" data-wpt-name="wpcf[start-date][datepicker]" data-wpt-id="wpcf-start-date-datepicker" data-wpt-field-title="Start Date*" data-wpt-validate="{"required":{"args":{"1":true},"message":"This field is required"},"dateADODB_STAMP":{"args":{"1":true},"message":"Please enter a valid date"}}" data-wpt-type="date" data-ts="" class="js-wpt-date-auxiliar wpt-form-hidden form-hidden js-wpt-validate" value="1428710400" name="wpcf[start-date][datepicker]" id="post-hidden-1-1428662145">
<input type="button" style="" value="Clear date" class="button button-secondary js-wpt-date-clear wpt-date-clear">
</div>As you can see there are no your hidden inputs for different languages. But I can see them in other field - program for example:
<div class="wp-editor-container" id="wp-wpcf-program-editor-container">
<input type="hidden" name="qtranslate-fields[wpcf][en][program]" class="hidden" value="">
<input type="hidden" name="qtranslate-fields[wpcf][ru][program]" class="hidden" value="Программа">
<textarea id="wpcf-program" name="wpcf[program]" cols="40" autocomplete="off" rows="10" class="wpt-wysiwyg wp-editor-area qtranxs-translatable">
[:ru]Программа[:]
</textarea>
</div>one more example from Firebug where there are no hidden inputs from qtx
<div class="js-wpt-field-item wpt-field-item">
<div class="form-item form-item-textfield wpt-form-item wpt-form-item-textfield" id="post-textfield-5-1428662145-wrapper">
<label for="post-textfield-5-1428662145" class="wpt-form-label wpt-form-textfield-label">
Price*
</label>
<input type="text" data-wpt-name="wpcf[price]" data-wpt-id="wpcf-price" data-wpt-type="textfield" class="wpt-form-textfield form-textfield textfield js-wpt-validate" data-wpt-field-title="Price" data-wpt-validate="{"required":{"args":{"1":true},"message":"This field is required"},"number":{"args":{"1":true},"message":"Please enter numeric data"}}" value="" name="wpcf[price]" id="post-textfield-5-1428662145">
</div>
</div>I am not sure why they became empty, hopefully it is unrelated to q-X. Could you confirm?
q-X enables translations on certain fields by default, read FAQ, topic "Is it possible to translate theme custom fields?". The rest of the fields are untouched unless their id or classes are listed in option "Custom Fields".
Does this answer your concern?
I just reverted to version of QTX 3.2.9 and everything works without any problems. All my custom fields are saved and returned after Update.
So the reason why these fields were empty - new version of QTX 3.2.9.8.5
because all other parts of the code - the same.
I would like to help you to find the reason of this issue because I like the new concept of QTX (which is implemented in 3.3) and it really helps me with my integration. I do not like to return to 3.2.9.
So if you tell me where to check - I certainly will do it.
here you ca see the result of qtranxf_dbg_log('qtranxf_collect_translations_posted: REQUEST: ',$_REQUEST);
qtranxf_collect_translations_posted: REQUEST: array (
'_wp_http_referer' => '/wp-admin/post.php?post=1228&action=edit&message=10',
'action' => 'editpost',
'originalaction' => 'editpost',
'post_type' => 'event',
'original_post_status' => 'draft',
'post_ID' => '1228',
'meta-box-order-nonce' => '71512b41ab',
'closedpostboxesnonce' => '52718054db',
'qtranslate-fields' =>
array (
'post_title' =>
array (
'en' => 'Tuscany',
'ru' => 'Тоскана',
),
'content' =>
array (
'en' => 'about',
'ru' => 'кое-что',
),
'wpcf' =>
array (
'en' =>
array (
'program' => 'some days',
'terms' => '',
),
'ru' =>
array (
'program' => 'Программа',
'terms' => '',
),
),
),
'post_title' => 'Tuscany',
'content' => 'about',
'save' => 'Save Draft',
'wp-preview' => '',
'hidden_post_status' => 'draft',
'post_status' => 'draft',
'hidden_post_password' => '',
'hidden_post_visibility' => 'public',
'visibility' => 'public',
'mm' => '04',
'jj' => '11',
'aa' => '2015',
'hh' => '15',
'mn' => '26',
'ss' => '41',
'hidden_mm' => '04',
'cur_mm' => '04',
'hidden_jj' => '11',
'cur_jj' => '11',
'hidden_aa' => '2015',
'cur_aa' => '2015',
'hidden_hh' => '15',
'cur_hh' => '15',
'hidden_mn' => '26',
'cur_mn' => '26',
'original_publish' => 'Publish',
'wpcf' =>
array (
'year' => '',
'start-date' =>
array (
'datepicker' => '1428796800',
),
'end-date' =>
array (
'datepicker' => '1428969600',
),
'price' => '2500',
'program' => 'some days',
'terms' => '',
'url' => '',
'lat' => '',
'lng' => '',
'zoom' => '',
),
'post_name' => 'tuscany2015',
'_wpcf_relationship_items_per_page' => '5',
'wpcf_pr_belongs' =>
array (
1228 =>
array (
'region' => '0',
),
),
'qtrans_edit_language' => 'en',
'qtranslate-admin-general' => '1',
'qtranslate-admin-advanced' => '1',
'qtrans_admin_language' => 'en',
'qtrans_front_language' => 'en',
)as you can see the filleds start-date and end-date are filled but they will be empty when request will be processed.
I suspect that it's connected with name of these fields - name="wpcf[start-date][datepicker]"
Maybe it will give you some ideas about what happens...
I see, part of array wpcf is translatable and other part is not. What a case ...
2 of these fields - date and 3rd one - numeric. These fields should not be translated. It's ok.
But they should not be damaged (means emptied) as well.
Yes, I understood. I am now re-designing it once again like this (xx is a language code):
Original field name: fnm[a][b][]
qtx name: qtranslate-fields[fnm][a][b][xx][]
instead of qtranslate-fields[fnm][xx][a][b][], like it is now.
Other possible cases will be:
Simple name:
Original field name: fnm
qtx name: qtranslate-fields[fnm][xx]
Simple hash:
Original field name: fnm[a]
qtx name: qtranslate-fields[fnm][a][xx]
Can you think of anything which is not covered by these cases? Can you think of a way to get in trouble again with this design?
Hi Dmitry, @picasso: the very latest seems good in other places: https://github.com/qTranslate-Team/qtranslate-x/archive/3.2.9.8.8.zip, please try and let me now. Thank you very much.
Hi @johnclause,
thanks! Now everything works like a charm! At least in my code :)
I also tested it with all different custom types which are used in my project (12 custom types) and it works with all of them.
So I think you did a good job. Thanks!
We may close this issue.
Good! Let us be in touch, Dmitry, thank you!