dlouwe

It looks like this issue was being caused by my WP_SITEURL and WP_HOME being set as https:// in my wp-config. I can see that the plugin tries to account for this, but unfortunately I don’t have a lot of time right now to try to debug why it didn’t/isn’t working in my particular case. However I can at least tell you that the plugins_url() function will correctly determine the URL as https regardless of how WP_SITEURL and WP_HOME are set.

For now I’ll manually change my wp-config to use https as that does fix the issue, and really I should have done that in the first place.

Thanks for your help!

Perfect, relevanssi_hits_filter was exactly what I was looking for; I’m all sorted.

Thanks again!

Yes, it does appear that sorting by a meta key is causing the issue; removing the orderby parameter fixes it. Do you know of any way to work around this issue that still lets me sort the results by a meta key? Here’s a sample of my arguments array for reference:

array(10) {
  ["post_type"]=>
  string(13) "presentations"
  ["order"]=>
  string(4) "DESC"
  ["orderby"]=>
  string(14) "meta_value_num"
  ["posts_per_page"]=>
  int(10)
  ["paged"]=>
  int(1)
  ["tax_query"]=>
  array(0) {
  }
  ["s"]=>
  string(4) "robo"
  ["wpcf-author"]=>
  bool(false)
  ["meta_key"]=>
  string(22) "wpcf-presentation-date"
  ["meta_query"]=>
  array(0) {
  }
}

Thanks a lot for your help!

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.

The issue stems from incorrect Heredoc syntac, as outlined here: https://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.

Thanks for your quick response!

As far as I can tell 1.6.2 resolves the issue, though I also don’t really understand how it was possible in the first place.

In any case, cheers!