<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/stylesheets/rss.css" type="text/css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>mehblog: Category PHP</title>
    <link>http://blog.pauldalton.co.uk/articles/category/php</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>random mumblings</description>
    <item>
      <title>My take on the 7 reasons...</title>
      <description>&lt;p&gt;So the hottest topic in the rails community is seems is &lt;a href="http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html"&gt;Derek Sivers&amp;#8217; blog post&lt;/a&gt; on why he switched from trying to reimplement his site in rails to php.&lt;/p&gt;


	&lt;p&gt;As someone who writes both rails and php for a living I feel that I have
a good perspective on the rails vs php thing.&lt;/p&gt;


	&lt;p&gt;I&amp;#8217;m sure the arguments will continue for some time, but all I know is that I write &lt;strong&gt;much&lt;/strong&gt; better php since working with rails.&lt;/p&gt;


	&lt;p&gt;Right tool for the job and all that.&lt;/p&gt;</description>
      <pubDate>Thu, 27 Sep 2007 09:47:00 +0100</pubDate>
      <guid isPermaLink="false">urn:uuid:69d4958e-c601-4803-8b56-afdcc2e40f74</guid>
      <author>paul</author>
      <link>http://blog.pauldalton.co.uk/articles/2007/09/27/my-take-on-the-7-reasons</link>
      <category>PHP</category>
      <category>Rails</category>
      <category>Mumblings</category>
    </item>
    <item>
      <title>Cannot send session cookie ....</title>
      <description>&lt;p&gt;While working on a site last night I got this error when I uploaded the latest version of my code to the live server: &lt;strong&gt;Warning: &lt;/strong&gt;session_start(): Cannot send session cookie &amp;#8211; headers already sent &amp;#8230;

	&lt;p&gt;Now, my first reaction was &lt;span class="caps"&gt;WTF&lt;/span&gt;! as I wasn&amp;#8217;t seeing this on my development box. I was using the &lt;a href="http://www.apachefriends.org/en/"&gt;Apache Friends &lt;span class="caps"&gt;XAMPP&lt;/span&gt;&lt;/a&gt; product to run a &lt;span class="caps"&gt;WAMP&lt;/span&gt; install on my local windows XP machine so I guess there are some differences in the way apache works on win32 and linux.&lt;/p&gt;


	&lt;p&gt;Anyway, the Cannot send session cookie error is usually caused by outputting something to the client and then trying to send a cookie/write to the headers. So I start looking through my included files, trying to find a stray debug line or something like that. Nothing. &lt;scratch head&gt; Ok, go through it again, grepping for any kind of output. Nothing. Oh crap. I can&amp;#8217;t find the problem and the live site is busted right now.&lt;/p&gt;


	&lt;p&gt;Ok, its late and no one will probably notice, but I have to find the problem.&lt;/p&gt;


	&lt;pre&gt;&lt;code&gt;Bang head on table a few times.&lt;/code&gt;&lt;/pre&gt;


	&lt;pre&gt;&lt;code&gt;Ok, start again.&lt;/code&gt;&lt;/pre&gt;


	&lt;pre&gt;&lt;code&gt;And then I see it. I had tabbed all of the source in one of my include files. Including the opening &lt;code&gt; &amp;lt; ?php &lt;/code&gt; line! So, I was effectively sending a tab to output then processing my php.&lt;/code&gt;&lt;/pre&gt;


	&lt;pre&gt;&lt;code&gt;More head slapping. General relief etc.&lt;/code&gt;&lt;/pre&gt;


	&lt;p&gt;So there you go. If you ever have that problem and can&amp;#8217;t see where its coming from, save yourself some wear and tear on the ole forehead and check for whitespace at the beginning of your source files.&lt;/p&gt;

&lt;/code&gt;&lt;/scratch&gt;&lt;/p&gt;</description>
      <pubDate>Tue, 19 Apr 2005 08:11:36 +0100</pubDate>
      <guid isPermaLink="false">urn:uuid:68c4f6077b91b9180734cdbf509b70cf</guid>
      <author>paul</author>
      <link>http://blog.pauldalton.co.uk/articles/2005/04/19/cannot-send-session-cookie</link>
      <category>PHP</category>
    </item>
    <item>
      <title>Beware register_globals</title>
      <description>&lt;p&gt;We deployed a new site last week. Over the weekend I got a bug report from the site owner. Within the administration section of the site a certain session variable was getting reset causing a certain operation to fail.&lt;/p&gt;


	&lt;pre&gt;&lt;code&gt;Initially I was stumped. It worked fine on the dev server...  So I made sure that we had deployed the code to the live server correctly. Yup, all fine.&lt;/code&gt;&lt;/pre&gt;


	&lt;pre&gt;&lt;code&gt;Versions of php were the same.&lt;/code&gt;&lt;/pre&gt;


	&lt;pre&gt;&lt;code&gt;Well, to cut a long story short, register globals had been turned on in an apache config file for the previous version of the site and hadn't been removed when the new site was deployed.&lt;/code&gt;&lt;/pre&gt;


	&lt;pre&gt;&lt;code&gt;This was causing a variable initialisation in one part of the code to overwrite an object in $_SESSION elsewhere.&lt;/code&gt;&lt;/pre&gt;


	&lt;pre&gt;&lt;code&gt;Weird. Lesson learned...&lt;/code&gt;&lt;/pre&gt;</description>
      <pubDate>Mon, 07 Mar 2005 14:18:35 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:5acc55fcff03ace59138beb8a21b3029</guid>
      <author>paul</author>
      <link>http://blog.pauldalton.co.uk/articles/2005/03/07/beware-register_globals</link>
      <category>PHP</category>
      <trackback:ping>http://blog.pauldalton.co.uk/articles/trackback/22</trackback:ping>
    </item>
  </channel>
</rss>
