<?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 16:27:47 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Aaron Jorbin's Blog: Commit: The Story of Writing a WordPress Patch]]></title>
      <guid>http://www.phpdeveloper.org/news/14927</guid>
      <link>http://www.phpdeveloper.org/news/14927</link>
      <description><![CDATA[<p>
For those that have considered contribute back to the <a href="http://wordpress.org">WordPress</a> project but weren't sure what the experience might be like, you should check out <a href="http://aaron.jorb.in/blog/2010/03/commit-the-story-of-writing-a-wordpress-patch/">this helpful post</a> from <i>Aaron Jorbin<i/> with his story.
</p>
<blockquote>
Hanging out in the <a href="http://codex.wordpress.org/WordPress_IRC_Live_Help">#WordPress irc channel</a> or on the <a href="http://codex.wordpress.org/Mailing_Lists#Hackers">wp-hackers</a> mailing list, a question that comes up from time to time is 'How do I get a bug patched'. I recently had a patch committed, so I thought I would detail the process from start to finish to help others get an idea of the process. 
</blockquote>
<p>
He shares three lessons he learned during the experience - make it easy for non-coders to see the change, getting suggestions from other developers on the patch and realizing that sometimes, a small change in one place can break other things too.
</p>]]></description>
      <pubDate>Mon, 09 Aug 2010 12:57:17 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Smashing Magazine: Lessons Learned from Maintaining a WordPress Plugin]]></title>
      <guid>http://www.phpdeveloper.org/news/14887</guid>
      <link>http://www.phpdeveloper.org/news/14887</link>
      <description><![CDATA[<p>
On Smashing Magazine today there's <a href="http://www.smashingmagazine.com/2010/07/30/lessons-learned-from-maintaining-a-wordpress-plug-in/">a new article</a> from <i>Joost de Valk</i> about some of the things he learned from maintaining a WordPress plugin - one to help easily track your site via Google Analytics.
</p>
<blockquote>
Recently I released a WordPress plugin for Google Analytics that adds a tracking code and dozens of various pieces of meta data to blogs. Since the release of version 4, I've updated it 6 times, to the point where it's now at version 4.0.6. In this article I would like to share with you my experiences in maintaining this and other WordPress plug-ins and common good practices that I've distilled from that work.
</blockquote>
<p>He breaks it up into a few different categories:</p>
<ul>
<li>Website and Account Configuration
<li>Versioning Option Arrays
<li>Don't Release Too Soon
<li>Know Which Version People Are On
<li>URLs in WordPress
<li>Writing to the Root Directory
<li>Rethink Your Filters
<li>Never Assume
</ul>]]></description>
      <pubDate>Mon, 02 Aug 2010 11:08:05 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Matrin Rusev's Blog: Building a PHP Framework - Lessons Learned]]></title>
      <guid>http://www.phpdeveloper.org/news/12030</guid>
      <link>http://www.phpdeveloper.org/news/12030</link>
      <description><![CDATA[<p>
If you're thinking of trying your hand at creating your own PHP framework, you might want to <a href="http://www.martinrusev.net/blog/2009/02/building-php-framework-lessons-learned/">check out this post</a> from <i>Matrin Rusev</i> about some of the lessons he learned (the hard way) about framework construction.
</p>
<blockquote>
After using Codeigniter, CakePHP and Zend Framework for a while I decided to build my own framework. I wanted to include some features that I couldn't find the way I like them in none of the projects I tested. These are some lessons I learned the hard way. I hope you'd find some useful tips for your software projects.
</blockquote>
<p>
The post looks a a few different topics - doing good planning before development starts, using third-party libraries, planning out the syntax the components inside of your framework will use, how to handle debugging and two tools you can use to benchmark the end result.
</p>]]></description>
      <pubDate>Thu, 26 Feb 2009 12:02:32 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Deasil.com: Lessons to be learned from PHP]]></title>
      <guid>http://www.phpdeveloper.org/news/9411</guid>
      <link>http://www.phpdeveloper.org/news/9411</link>
      <description><![CDATA[<p>
In a <a href="http://comments.deasil.com/2008/01/11/lessons-to-be-learned-from-php/">new post</a> to the blog at deasil.com, they talk about some of the lessons they see that can be learned from PHP and how it works/is packaged up.
</p>
<blockquote>
<a href="http://www.php.net">PHP</a>, though, came along with a breakthrough idea - mod_php was an everything in one install. Unlike mod_perl, mod_php gave you a programming language, templating language and extension all in one.
</blockquote>
<p>
He advocates the PHP language developer's decisions to include everything into the core of the language which (while maybe not the best of decisions) has made PHP into one of the most practical development languages and has helped to make it one of the most popular and widely used languages on the web.
</p>]]></description>
      <pubDate>Sat, 12 Jan 2008 20:04:00 -0600</pubDate>
    </item>
  </channel>
</rss>
