This will get rid of the message, but will it work correctly? Maybe something else is needed to be modified? I think they define ‘DOING_CRON’ constant in this case to be able to detect this case, do they? Maybe we should simply disable the whole plugin, return from the function init_language in the beginning all together? Could you try that? I cannot see why qtx would be needed on a cron job? Does it make sense to run cron with specific language like wp-cron.php?lang=xx, will people ever want to do so? Could you do a bit of investigation and let us know? Thanks a lot!
Hi, John, thanks for the quick reply. QTX is needed in cron jobs that process anything multilingual.
PHP doesn’t guarantee $_SERVER[‘HTTP_HOST’] to be set in any case, so the above fix may be a good practice in any case, covering more cases in addition to when DOING_CRON is true.
I haven’t had time to investigate how $host is used inside QTX yet, but I’d expect that the code handles $host not being set correctly already. Without PHP notices enabled it just gets silently assigned a non-value, and I’d assume if the code currently handles a non-value, it may or may not handle empty string equally (depending on whether the value is checked with either strlen() or empty(), or isset()).
Can you think of anything in QTX that wouldn’t work correctly when $host is an empty string?
I do not know, I did not investigate either. I added “!empty” check with ” string for now, we can wait until somebody complains about something. Does it work for you in this way? Does it set language correctly in wp-cron.php?lang=xx? Would you be interested to investigate?
Hi John, thanks. If I understood correctly, you’re speaking about the above patch I submitted? Sure, we’ll be testing it. The reason we started working with wp-cron is to run certain tasks where multilingual posts are saved. We’re forming the QTX-compatible multilingual strings directly like '<!--:' . $language . '-->' . $content . '<!--:-->', so but if the scripts run into any issues, I’ll report.
Do you have any preference on how we should test whether the language gets set correctly through wp-cron.php?lang=xx?
No, I do not have preferences. Are you aware that qtx currently uses formatting '[:' . $language . ']' . $content . '[:]' by default, and formatting with ‘{‘ is also available and sometimes works better? Your way is also available as legacy.
Ok. It may take a moment until a good moment for testing. Will report back in case of any issues.
Thanks, we know of that formatting. We tried switching to it, but there were some issues and we had to revert to the legacy format. Had the same back with the original qTranslate, which used the same shorthand format as QTX apart from not allowing you to specify the end of a language-specific string.
Thanks! Yes, this is why different encodings were introduced, because each of them has issues one way or other. In json configuration file, one may specify the encoding differently for each specific field: https://qtranslatexteam.wordpress.com/json-configuration-syntax/
Hi John, this issue still seems to concern the latest QTX. When I had PHP notices enabled during plugin development and cron triggered, I got the following in my email as a result:
PHP Notice: Undefined index: HTTP_HOST in /PATH/wp-content/plugins/qtranslate-x/qtranslate_core.php on line 35
Notice: Undefined index: HTTP_HOST in /PATH/wp-content/plugins/qtranslate-x/qtranslate_core.php on line 35
PHP Warning: Cannot modify header information - headers already sent by (output started at /PATH/wp-content/plugins/qtranslate-x/qtranslate_core.php:35) in /PATH/wp-content/plugins/qtranslate-x/qtranslate_core.php on line 384
Warning: Cannot modify header information - headers already sent by (output started at /PATH/wp-content/plugins/qtranslate-x/qtranslate_core.php:35) in /PATH/wp-content/plugins/qtranslate-x/qtranslate_core.php on line 384
Steps to reproduce:
1. Enable PHP notices in a plugin:
error_reporting( E_ALL );
ini_set( 'display_errors', 1 );
2. Trigger WP-Cron in shell (via Linux cron): php -f /PATH/wp-cron.php
I checked the source code for both the latest stable QTX 3.4.6.4 (which we’re running) and the development snapshot, and in both qtranslate_core.php line 35 still refers directly to $_SERVER[‘HTTP_HOST’]. It’d be better to first check it with either isset() or empty() to avoid invalid reference notices and other unexpected behavior.
The very latest stable is 3.4.6.8 has it https://github.com/qTranslate-Team/qtranslate-x/blob/stable/qtranslate_core.php#L35
Sorry, we had to branch the code, since master branch is far from stable, but we needed to update people with fixes for 4.5. Now we are catching up with good stable changes from master branch. So next release will surely have it, or you may use the latest from GitHub: https://github.com/qTranslate-Team/qtranslate-x/archive/stable.zip now.
Great to hear. Thanks for your work!
