<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Sun, 26 May 2013 02:19:18 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Sameer Borate's Blog: Raw vs. cooked PHP $_POST variables]]></title>
      <guid>http://www.phpdeveloper.org/news/15155</guid>
      <link>http://www.phpdeveloper.org/news/15155</link>
      <description><![CDATA[<p>
<i>Sameer Borate</i> as a new post to his blog today looking at <a href="http://www.codediesel.com/php/raw-vs-cooked-php-post-variables/">some of the quirks</a> he's found when dealing with the $_POST superglobal in PHP.
</p>
<blockquote>
A little quirk of PHP $_POST var I encountered while fixing a Salesforce web-to-Lead bug. A Wordpress site was using a form to submit user requests to the Salesforce web-service. The form that submitted the data had the following fields along with the others. The problem was with the multi-select field, only the last value selected in the multi-select was getting captured.
</blockquote>
<p>
He investigated and found that his code was echoing out all of the values, but wasn't using the "field_name[]" notation with the square brackets to send back multiple values to PHP. Changing this and trying again, he noticed it still wasn't working as expected (with Salesforce). He figured out they're using "raw" versus "cooked" handling of the POSTed variables. Check out the <a href="http://www.codediesel.com/php/raw-vs-cooked-php-post-variables/">rest of his post</a> to find out what that means.
</p>]]></description>
      <pubDate>Mon, 20 Sep 2010 10:15:16 -0500</pubDate>
    </item>
  </channel>
</rss>
