Jump to content

Welcome to the forum:

Welcome to the iThemes forum. We've created several tutorial video's to help you get you started with using the forum, please check them out!

Also take note of the forum guidelines.

Support hours:

Our moderators actively respond to forum support requests during normal business hours which are Monday-Friday, 8am - 5pm Central Standard Time, typically within one business day. Although some moderators choose to work during the weekends, we can not guarantee immediate attention to your requests. Thanks for understanding.

What is included with support:

Premium support includes theme/plugin issues such as: bugs encountered under normal operation, how to use basic features, basic WordPress help, and basic help with customization (meaning we point you to resources and will help in more depth as time allows). More information.

Case-sensitivity breaking Serverbuddy's cURL check...

This topic has been archived. This means that you cannot reply to this topic.
No replies to this topic

#1 Guest_Don_*

  • Guests

Posted 19 November 2010 - 02:06 PM

I recently installed Serverbuddy on a test wordpress site to vet my basic site builds, and I kept getting "PHP Curl support" indicating as disabled/Fail. This is on a fairly stock RHEL5 system, and I was able to verify that the standard curl packages are installed and in active use by other packages/plugins.

Last night I tracked the issue back to the check done by Serverbuddy -- apparently it is looking to phpinfo() output for most of these checks (interestingly, using curl to acquire said output...), and is failing to match the cURL information in the output.

The problem apparently lies with Serverbuddy's rule for curl (definitions/general.txt & definitions/information.txt), which targets the text "cURL support", while the phpinfo() output shows a line for "CURL support". Changing the rule in each file from "cURL" to "CURL" allows the plugin to properly identify the system's 'PHP Curl support' status.

Note: a quick google search returned several references to cURL availability checks in other php apps/utils failing due to similar case-sensitivity issues. The common suggestion for resolution was to employ case-insensitive comparisons.