<?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>Fri, 24 May 2013 01:55:02 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Brandon Savage's Blog: Superglobals In Classes: Revisited]]></title>
      <guid>http://www.phpdeveloper.org/news/12865</guid>
      <link>http://www.phpdeveloper.org/news/12865</link>
      <description><![CDATA[<p>
Revisiting an <a href="http://www.phpdeveloper.org/news/11521">earlier post</a> dealing with superglobals and classes, <i>Brandon Savage</i> <a href="http://www.brandonsavage.net/superglobals-in-classes-revisited/">looks at an example</a> of why its still a bad idea.
</p>
<blockquote>
I asserted at the time that superglobals inside of a class violated some basic rules on what a class was supposed to do. Today, I am revisiting that discussion. The placement of superglobals inside a class creates an impossible situation for code reuse. [...] Ehat happens when we want to move this [code] to another site? Unless we leave our form fields named [the same] we'll have to modify the original code.
</blockquote>
<p>
His alternative - a much better refactoring - lets the verifyCredentials method take in the username and password and has the calling script define where those come from, either from a local or global location.
</p>]]></description>
      <pubDate>Tue, 14 Jul 2009 07:51:11 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Smashing Magazine: 10 Advanced PHP Tips Revisited]]></title>
      <guid>http://www.phpdeveloper.org/news/12199</guid>
      <link>http://www.phpdeveloper.org/news/12199</link>
      <description><![CDATA[<p>
Smashing Magazine has posted <a href="http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/">a new article</a> from <a href="http://shiflett.org/">Chris Shiflett</a> and <a href="http://seancoates.com/">Sean Coates</a> with their rebuttal to the site's previous <a href="http://smashingmagazine.com/2008/11/18/10-advanced-php-tips-to-improve-your-progamming/">10 Advanced Tips</a> article.
</p>
<blockquote>
In November 2008 we published the article <a href="http://smashingmagazine.com/2008/11/18/10-advanced-php-tips-to-improve-your-progamming/">10 Advanced PHP Tips To Improve Your Programming</a>. Apparently, according to negative comments to the post, it contained some errors and some statements that are just wrong. [...] To solve the problem, we asked Chris Shiflett and Sean Coates, two PHP gurus, to take a closer look at the article, explain its errors and make it perfectly clear what is actually right and wrong in the theory and practice. This article is a professional response to our article published a couple of months ago.
</blockquote>
<p>
Here's the <a href="http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/">more accurate descriptions</a> of those tips - what's good and what's bad - as presented by <i>Chris</i> and <i>Sean</i>:
</p>
<ul>
<li>Use an SQL Injection Cheat Sheet
<li>Know the Difference Between Comparison Operators
<li>Shortcut the else
<li>Drop Those Brackets
<li>Favor str_replace() Over ereg_replace() and preg_replace()
<li>Use Ternary Operators
<li>Memcached
<li>Use a Framework
<li>Use the Suppression Operator Correctly
<li>Use isset() Instead of strlen()
</ul>]]></description>
      <pubDate>Tue, 24 Mar 2009 13:01:37 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Christopher Kunz's Blog: PHPShield revisited]]></title>
      <guid>http://www.phpdeveloper.org/news/10242</guid>
      <link>http://www.phpdeveloper.org/news/10242</link>
      <description><![CDATA[<p>
<i>Christopher Kunz</i> has gone back and <a href="http://www.christopher-kunz.de/archives/169-PHPShield-revisited.html">revisited</a> the PHPShield product that he'd looked at <a href="http://www.phpdeveloper.org/news/10025">previously</a> with data obscured to make potential customer think that it had nothing to do with either SourceGuardian or Inovica.
</p>
<p>Checking up on it again, he was happily surprised with some of the results:</p>
<blockquote>
I asked him again today via private mail and his response was swift. The whois entries for phpshield.com now point to his person and we can expect additional information on the web site itself soon. I like it when things can be resolved like that and I actually think this is a chance for his product rather than a possible competition issue.
</blockquote>
<p>
This helps to more clearly define the difference between the PHPShield and SourceGuarian products. You can find out more information about each product from their sites - <a href="http://phpshield.com/">PHPShield</a> and <a href="http://www.sourceguardian.com/">SourceGuarian</a>. Both are encoding packages to help protect and distribute your code.
</p>]]></description>
      <pubDate>Thu, 22 May 2008 08:48:16 -0500</pubDate>
    </item>
  </channel>
</rss>
