Plugin Contributor
slangji
(@slangji)
I can not reproduce this error in any way.
The plugin works perfectly for me.
1 – First deactivate all other plugins
2 – Empty the cache completely
3 – Wait a few hours it is empty
4 – Then try again
Can you give more details?
I’m having the same issue, I’ve uploaded plugin v2014.1231.0 via FTP, tried to Network activate on WP 3.9.1 multisite and obtained the following error
Plugin could not be activated because it triggered a fatal error.
Parse error: syntax error, unexpected ‘<<‘ (T_SL) in /[WP-directory]/wp-content/plugins/wp-missed-schedule/wp-missed-schedule.php on line 259
More info from debugger
Call Stack
# Time Memory Function Location
1 0.0001 241200 {main}( ) ../plugins.php:0
2 2.2570 62353544 require( ‘/[WP-directory]/wp-admin/plugins.php’ ) ../plugins.php:16
3 2.2628 62525904 plugin_sandbox_scrape( $plugin = ‘wp-missed-schedule/wp-missed-schedule.php’ ) ../plugins.php:153
Hope it can help, thanks.
Plugin Contributor
slangji
(@slangji)
@arrozman
WP 3.9.1 ??? … umh … update 1ST to WP 3.9.3 😉
Plugin Contributor
slangji
(@slangji)
I make known to all users of WordPress Multisite, which i’m working very seriously to the verification of this message, when i can play the same problem.
At that point, i’ll make it known to all, in this thread.
However, i could not reproduce this problem, so i assume that it is found elsewhere, and not in my plugin.
In this regard, for now, there are only these two reports, fprse another couple of thread (that would go up to 4 in total) on a base of 300,000 downloads, and 120,000 installations.
Who knows how to speak, those who write solutions, but who just wants to complain, please wait: this problem, if it really exists, it will never be abandoned, and will always be monitored by me, personally.
Thank you all for your cooperation.
sLa
The issue stems from incorrect Heredoc syntac, as outlined here: http://php.net/manual/en/language.types.string.php#language.types.string.syntax.heredoc
A third way to delimit strings is the heredoc syntax: <<<. After this operator, an identifier is provided, then a newline. The string itself follows, and then the same identifier again to close the quotation.
The closing identifier must begin in the first column of the line. Also, the identifier must follow the same naming rules as any other label in PHP: it must contain only alphanumeric characters and underscores, and must start with a non-digit character or underscore.
I’m not sure why it does work for some (apparently most) installations, but updating the syntax to the correct format certainly won’t hurt anything.
Plugin Contributor
slangji
(@slangji)
@dlouwe
Please: you are able to re-write the piece of code affected by this problem syntax correctly, according to this rule, and post it in this thread, so i can test it?
Would you do me a big favor. (i make credit fory you)
P.S. The code should be compatible with hyperdb https://ww.wp.xz.cn/support/topic/resolving-table_name-from-query-broken-in-select-query
Thanks!
Plugin Contributor
slangji
(@slangji)
OK, problem isolated: this is a fake request with puttets users, only writed for create negative report for this plugin! !!!
THE PROBLEM DO NOT EXIST WITH ORIGINAL FILE WITH CHECKSUM C0E9348848150D08E5938ADF450A4D8738F66462
This problem exist when the original file wp-missed-schedule.php was edited and the <<<SQL querie code is modified or minified! !!!
Is possible that somes minify software modify original code, and return this error, but this possibility is more remote …
Thanks!
Yes, you are mostly right. I just checked and the original file appears correct when I open it locally. But when I upload it to my server with FTP the <<<SQL statement is converted to one line.
It appears that lines 259 and 260 end with the CR character (\r), whereas all other lines end with CRLF (\r\n). The newline character on UNIX systems is LF (\n), which means that when the file is transferred directly to a UNIX system (such as via FTP) it discards the CR and the line is not parsed correctly by PHP.
It would appear that when using the WP Admin’s “Add New Plugin”, all CR characters are converted to CRLF, which is likely why this issue does not happen for the majority of people.
The simple solution would be to open the file in a program that can be configured to show line end characters (such as Notepad++) and make sure that those lines end with CRLF like all the rest.
Plugin Contributor
slangji
(@slangji)
Is not true: i certainly do not explain to you the secrets of my plugin!
Thanks!
Plugin Contributor
slangji
(@slangji)
It would appear that when using the WP Admin’s “Add New Plugin”, all CR characters are converted to CRLF, which is likely why this issue does not happen for the majority of people.
No it is not true, this does not happen at all. This is just to discredit my plugin! !!!
The simple solution would be to open the file in a program that can be configured to show line end characters (such as Notepad++) and make sure that those lines end with CRLF like all the rest.
Instead of thinking as it is written, and make the lesson, think about using it, although it uses, or usane others if they work … but i am not aware that any work! !!!
