This is not PHP.net, this is http://takien.com/

takien.com is NOT php.net

This is not Takien.com, this is PHP.net

This is not taiken.com, this is php.net

• Windows: 42%
• Linux: 38.5%
• Mac OS X: 19.1%
• Everybody else: 0.4%

The Register is only telling half the story. 38.5% on Linux is a fantastic percentage. I for one am a happy Ubuntu & Gnome desktop user and I haven’t depended on Windows desktop for at least 6 years. Its a shame though that so many employers and technical people still use Windows desktop when Linux Desktop has everything you need, its free, and its not crap either. Funny that the circling vultures at The Register would focus so much on how PHP coders are still on Windows, and fail to point out that as a group they are agressive adopters of Linux Desktop. Visitor stats for websites indicate that Linux desktop is a lot less than 38.5%.  PHP developers are helping lead the way for Linux as a choice for the desktop that is fast encroaching on Windows turf. That turf will soon be taken away from Windows by Linux. Somebody should have pointed that out. Guess that is what I am doing.

Linux dominates the web server world, and it makes darn good sense to see run the same system on the desktop as for the server for reasons of uniformity and behaviour. Its an obvious right choice to make. Learn to work well in the Linux shell on the desktop and you can use all those skills on the server.

Oddly, The Register reported all this but did not supply a reference to the source report on Zend.com

Source: http://www.theregister.co.uk/2010/02/17/php_windows_linux/

Relative Cost Of A Software Bug Fix

Slide credit: Barry Boehm, “Equity Keynote Address” March 19, 2007.

This chart is intended for developers, to decide how best to spend ones time. Ever wonder why, as a developer, fixing bugs is such a pain and a kludge? There is something not simply tough about fixing bugs, there is something fundamentally wrong about putting any effort at all into repairing them. But the chart is also a message to the paying client, the person whose dime it is on. A client may be only thinking in the short term to make the software work, but it is the most expensive and unproductive path to the realization of goals.

The effort to fix bugs is great and the rewards are minimal. Frustrations are high, satisfactions are low. The website suffers from some sort of performance penalty, users are inconvenienced. Bugs must be dealt with with some amount of procedural overhead no matter what, and when the bug is fixed and submitted, very little was ever really accomplished. It is really far better to think of a better solution to all your problems together rather than to continue fixing things one at at time. It will cost the customer less and they will get more. So when bugs become a staple of the work load, its time to persuade the client to accept a rewrite.

…with the software in production, fixing bugs is akin to repairing a car while it is driving down the road, long after it has left the drawing board, the assembly line, and the dealer lot. Its as expensive to do as it can possibly be.

Developers still have a great deal in common with the clients they perform work for. They charge money for their work so they think in terms of the cost in terms of labor time (actually, developers also think this way when they work on their own software). The question every developer asks is, “What is the simplest, easiest, and fastest way to get something done?” The answer could be open to interpretation, but that is because the long view must be taken into consideration, and that is why software makes use of functions, templates, classes, objects, and design patterns. The work is needed now, but how will it be possible to understand the software in a few months time when noone is mentally fresh? How do I share my ideas with other people? How do I take the long view into account?

Despite the love a client may have for their own project, nobody is interested in working on the same software forever. After all, software developers are creative people who really want to expand their skills and take all that they have learned and apply it to the next project, instead of keeping something half dead on life support.

I enjoy attending talks from the best people in the world in my business, because they are very good at exposing the importance of planning and organizing the overall picture, and are very knowledgeable in all the concepts that make projects produce a top quality result in an efficient manner. They also point out the simple mistakes people make that cost them so much. When we are at the far right of the graph, with the software in production, fixing bugs is akin to repairing a car while it is driving down the road, long after it has left the drawing board, the assembly line, and the dealer lot. Its as expensive to do as it can possibly be.

Developers should try to understand the message of this graphic before going further fixing bugs. If you are put in a position fixing bugs, it is time to change the way you work, because you are the one bearing the cost in terms of your own time performing the least valuable, most expensive, and least meaningful work.

Web developers as they learn start by downloading packages in zip and tar.gz archives which is fine. A pro technique is to pull in the resource via SubVersion (svn). Svn provides additional features such as svn externals and svn hooks. Svn externals allows for the pulling in of external resources into a defined project in a svn repository. Svn hooks is for additional labor saving scripting that allows for the automation of repeated tasks such as a script that can pass along data from commit messages into other resources in the project such as the bug tracker. Learning these tricks allows for labor savings at every step in the production cycle. We can take these practices to the next level with capturing the commands in a bash script and then organise all the features of a website in a deployment script, something that is done all the time at software majors.

This script is a big-ass time saver.

I took the time to sort this out recently because I had some web development requests from people who have simple websites that could be converted to WordPress easily enough, but I wasn’t interested in going fishing for plugins and themes twice, and again when the next people come along needing the same thing. The job of a software developer should be to automate processes. I say often that the credo of developers is not to work for a living, but to eliminate work. But this idea is not always employed by developers in all the places it could, and its sometimes even a harder to get a client on board to make full use of methods and procedures that automate tasks and eliminate work.

…the credo of (software) developers is not to work for a living, but to eliminate work.

Lets at least cover the benefits in point form:

• The script takes a couple of minutes and you save hours.
• You dont repeat the labor, but you can repeat the use of the script, deploying anywhere else.
• All your stuff is there at the beginning. Useful for planning, development, and policy across teams.
• You are organised, and you can develop variations. Svn export may be good enough for your needs.

In pseudo code, here is what your script will do:

• Set up your repository.
• Make your directory structure for your project.
• Check out your repository.
• Run procedures for svn externals for core WordPress.
• Run procedures for svn externals for plugins, iterating through data in an external file resource.
• Run procedures for svn externals for themes, iterating through data in an external file resource.
• Grab additional resources in an array, iterate through them using wget command, extract them.
• Cleanup.
• Commit message.
• … anything else you can think to do.

The bash file, save as getallwpsvn.sh:

#!/bin/bash
# run this script with chmod 755 permissions.

workPath=$(pwd)

rm -rf filerepository repository www *.zip # this line cleans dir for testing, comment out when done

svnadmin create repository

mkdir -p filerepository/{branches,tags,trunk/{html,db,cron,scripts,themes,plugins,project,selenium}}
# got anything to import into those directories under trunk?
# import into the directories under trunk now
# before the next step
svn import filerepository file://$workPath/repository -m "initial import using getallwpsvn.sh script"
rm -rf filerepository
svn checkout file://$workPath/repository/trunk www
cd www
svn rm html
svn commit -m "rm html temporarily for clean propset"
svn propset svn:externals 'html http://core.svn.wordpress.org/trunk/' .
svn up
cd html/wp-content/
# get plugins from repository http://svn.wp-plugins.org/
# plugins listed in svn.plugins.externals
svn propset svn:externals -F ../../../svn.plugins.externals plugins/
#svn commit "plugins propset" # no commit if no local repository
svn up
# themes repository: http://svn.wp-themes.org/
# themes repository is a bit of a ghost town, none grabbed here
# browse the site and get the zip
# themes listed in svn.themes.externals file, if there are any
svn propset svn:externals -F svn.themes.externals plugins/
svn up

cd themes
# load up on themes
#more human readable format for array

THEMESITES[0]=http://dev.digitalnature.ro/fusion/fusion-wordpress.zip
THEMESITES[1]=http://ericulous.com/?load=googlechrome.zip
THEMESITES[2]=http://ericulous.com/?load=internetcenter.zip
THEMESITES[3]=http://ericulous.com/?load=redbusiness.zip
THEMESITES[4]=http://wordpress.org/extend/themes/download/elegant-box.4.1.1.zip
THEMESITES[5]=http://wordpress.org/extend/themes/download/thirtyseventyeight.4.0.zip
THEMESITES[6]=http://wordpress.org/extend/themes/download/thirtyseventyeight.4.0.zip
THEMESITES[7]=http://wordpress.org/extend/themes/download/constructor.0.6.4.zip
THEMESITES[8]=http://wordpress.org/extend/themes/download/jq.2.4.zip
THEMESITES[9]=http://wordpress.org/extend/themes/download/ahimsa.3.0.zip
THEMESITES[10]=http://wordpress.org/extend/themes/download/retromania.1.3.zip
THEMESITES[11]=http://wordpress.org/extend/themes/download/skinbu.1.0.3.zip
THEMESITES[12]=http://wordpress.org/extend/themes/download/mystique.1.16.zip
THEMESITES[13]=http://wordpress.org/extend/themes/download/lightword.1.9.3.zip
THEMESITES[14]=http://wordpress.org/extend/themes/download/monochrome.2.3.zip
THEMESITES[15]=http://wordpress.org/extend/themes/download/thematic.0.9.5.1.zip
THEMESITES[16]=http://wordpress.org/extend/themes/download/hybrid.0.6.1.zip
THEMESITES[17]=http://wordpress.org/extend/themes/download/new-york.1.0.1.zip
THEMESITES[18]=http://wordpress.org/extend/themes/download/f8-lite.1.3.zip
THEMESITES[19]=http://wordpress.org/extend/themes/download/simplex.1.3.1.zip
THEMESITES[20]=http://wordpress.org/extend/themes/download/cleanr.0.1.2.zip

for s in ${THEMESITES[@]}
do wget "$s"
done

FILES="*.zip"
for f in "$FILES"
do unzip "$f"
done

rm *.zip
rm *.zip.*
cd ../../../
svn commit -m "load in of plugins and themes complete"

cd $workPath
cp $workPath/www/html/wp-config-sample.php  $workPath/www/html/wp-config.php
chmod 777 $workPath/www/html/wp-config.php
chmod 777 $workPath/www/html/wp-content #temporarily, for cache
mkdir $workPath/www/html/wp-content/uploads && chmod 777 $_
touch $workPath/www/html/.htaccess && chmod 777 $_

# do any post processing, other importing now, and commit it if you did.

Set the file permission to chmod 755, and run it from the shell command line as in ./getallwpsvn.sh.

The file you save as svn.plugins.externals:

all-in-one-seo-pack http://svn.wp-plugins.org/all-in-one-seo-pack/trunk
advertising-manager http://svn.wp-plugins.org/advertising-manager/trunk
cforms http://svn.wp-plugins.org/cforms/trunk
google-sitemap-generator http://svn.wp-plugins.org/google-sitemap-generator/trunk
sociable http://svn.wp-plugins.org/sociable/trunk
stats  http://svn.wp-plugins.org/stats/trunk
ultimate-google-analytics http://svn.wp-plugins.org/ultimate-google-analytics/trunk
vipers-video-quicktags http://svn.wp-plugins.org/vipers-video-quicktags/trunk
wordbook http://svn.wp-plugins.org/wordbook/trunk
wp-flickr http://svn.wp-plugins.org/wp-flickr/trunk
wp-super-cache http://svn.wp-plugins.org/wp-super-cache/trunk

The svn.plugins.externals file is a name – resource listing, one per line, when you have more than one resource to define with svn externals.

Please note that you may not need all of this; comment whatever out you want. You dont need to create a local repository, that is only if you are doing team development, or perhaps custom development on themes and plugins. I found though that it was necessary with svn propset directives to create a top-level directory structure wherein is stored all the different directories. The point of this exercise is a pull-in of public resources in a step that you can repeat automatically over and over. It also need not be a very sophisticated script to get the benefits from it.

We had thousands of possible beers to choose from, but we were most attracted to the pumpkin beers from local microbreweries from the taps. We enjoyed a down home meal of mussels, beef, and a crab cake sandwich and fries. A few things to point out in the pics above: Not the skull foam in the beer glass, the chocolate cake, the double chocolate stout, the elephant tap, the cans in the wall, some familiar faces from the php community, and the trappist ale. So never mind the fine dining in DC, go for the soul food and beer.

The conference was great, I learned stuff, I learned what I know, what I dont know, what I need to know, and more. I met a great group of people and traded lots of business cards.

function printR($arr, $label= null) {
if($label){
echo “<h2>$label</h2> \n “;
}
echo “\n\n<pre>\n”;
print_r($arr);
echo “\n</pre>\n\n”;
}

You can of course do fancier things should you wish to dump your results to a directory before overwriting your files.

#!/bin/sh
for files in `find *.php`
do
sed ‘s/..\/..\/adminincl/includes/g’ $files > ‘temp’.$files && mv ‘temp’.$files $files
done

It would work like this:

• set a number of allowed login attempts.
• set the time limit in seconds for duration of access denial.
• keep track of the number of failed login attempts.
• keep track of when login attempts started with timestamp function.
• test for meeting or exceeding the number of allowed login attempts.
• let them keep trying if they have waited past the time limit.
• set a time limit for when they can come back, and forbid them.
• give them some messages and links to help.
• if the login has been successful, wipe out all the tracking for login attempts.
• You are done.

Here we go, into your login processor after initial validation and constructing a sql query.

$loginAttemptsAllowed = 5;

if( $_SESSION['loginAttempt']['Count'] <= $loginAttemptsAllowed ) {
  $result = $db->queryRow($sql); // only query db if allowed to do so
}

if( !$result ){
  $seconds = 300; // 5 minutes
  // if trying again after lockout time limit ....
  if( $_SESSION['loginAttempt']['Count'] >= $loginAttemptsAllowed ) {
    $difference  = abs($_SESSION['loginAttempt']['LockoutTime'] - $_SESSION['loginAttempt']['Time']);
    $diffSeconds = round($difference);
    if( $diffSeconds > $seconds ) {
      unset($_SESSION['loginAttempt']); // they failed but have a new set of chances
      } else {
      $minutes = $seconds / 60;
      $message = "Sorry, you have had $loginAttemptsAllowed failed login attempts. <br />
      We temporarily forbid access in order to protect your private information. <br />
      Please wait $minutes minutes before logging on again.";
      }
    } else {
    if( !isset($_SESSION['loginAttempt']['Time']) ) {
      $_SESSION['loginAttempt']['Time']  = get_microtime();
      $_SESSION['loginAttempt']['Count'] = 1;
    } else {
      $_SESSION['loginAttempt']['Count']++;
    }
    if( $_SESSION['loginAttempt']['Count'] >= $loginAttemptsAllowed ) {
      $_SESSION['loginAttempt']['LockoutTime'] = get_microtime();
    }
    $message = "login error";
  }
  addMessage($message, "MsgErr");
  redirect($_SESSION["backPage"]);
  exit();
}

….. go on and log them. Dont forget to unset( $_SESSION['loginAttempt'] );
// a couple of the functions in there are custom ones, they are basically just wrappers.
// I forget where I got the following function, but it is used for benchmarking. Maybe php.net?

function get_microtime() {

  $mtime = microtime();

  $mtime = explode(" ",$mtime);

  $mtime = doubleval($mtime[1]) + doubleval($mtime[0]);

  return ($mtime);
}

So there you have it. Forcing users to have highly secure passwords, while a good idea, is not always possible.

Keep your users safe. And curses to wordpress for screwing up my code formatting…

You really do want to keep the mod_rewrite rules simple. Dont try to write a complex regexp in mod_rewrite that handles all kinds of apostropes, special characters, etc. (like I did). You dont have to have question marks, quotations, colons in the rewritten url for it to be useful to search engines. You can turn a title like “O’mally’s dog’s bone” into http://domain.com/Omallys_dogs_bone and there is definitely enough textual sense in that rewritten url for a search engine to deal with it.

Take your table with all your content data in it. Create a field for your content for a safe title. Then you can process your old titles into the new field. In your looping construct, use a bit of php to clean out your old titles for spaces, quotes, slashes, and other silly things.

$punctuations = array('.', '\'', '?','!','*','=','Ó','%','@','&',',','/');

$safeTitle = str_replace($punctuations, "", $title);// get rid of the junk

$safeTitle   = str_replace(" ", "_", $safeTitle);// replace spaces with underscores

Now you have a content resource which you can add to your output queries that will fill in your url link on your page for mod_rewrite goodness.

Make your mod_rewrite rule in your .htaccess file. Note here that the rule has a place for 2 variables, and is looking for all instances of strings with upper and lower case letters, the numbers 0-9, and the underscore character. And of course, it turns it all back into a query string to submit to your content page.

RewriteRule ^/?([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)(/)?$ item.php?safeTopicName=$1&safeTitle=$2

Almost done right? Eh, not quite. Almost though. Dont screw over your existing users, who may have linked to something of yours to the past. You can still account for your old reference style to your web content, and you most definitely should. You can write checks for query string data validation to allow for transparent access to content through either the old query string method or the new one.

if($_GET["safeTopicName"]){

  $sql = sprintf("SELECT topicId
                  FROM contentTopics

                  WHERE safeTopicName

                  LIKE '%s'",

                mysql_real_escape_string($_GET["safeTopicName"]));

  diode($topicId = $db->getOne($sql), $sql); // my db connection wrapper

  $sql = sprintf("SELECT articleid

                  FROM content

                  WHERE safeTitle

                  LIKE '%s'",

                mysql_real_escape_string($_GET["safeTitle"]));

  diode($articleid = $db->getOne($sql), $sql);
} else {

  if($_GET["topicId"]) {

    $topicId =  (int)$_GET["topicId"]);

  }

  if($_GET["articleid"]) {

    $articleid =  (int)$_GET["articleid"];

  }
}
if(!isset($topicId) || !isset($articleid)) {

    addMessage("no item found", "MsgErr");

    redirect();

    exit();

}

A couple notes: Im using PEAR, and a couple of custom functions for efficiency sake. Note the use of (int) and mysql_real_escape_string() for sanitizing and typing.  And yes, there are probably better ways to write this up, but you get the idea. Look for your $_GET vars, and if you dont have one set or the other, no result, otherwise, process it so the rest of the code needs no further reliance on these initial options so a user can get to your site with /Planets/earth as well as with item.php?topicId=2&articleid=249.

To Recap:

• Set up safe versions of your content titles
• process the old titles with a script
• make a simpler rewrite rule as a result
• set up your validation to process both kinds of queries
• marvel about how much simpler it was to do it that way than to try and do it all with Mod_Rewrite alone.

Create a moving target that attackers cannot seize upon repeatedly. build arrays in a looping construct for all the form fields you want to assign in your page. Store them in a PHP Session array. You use built-in php functions such as md5(), uniqid(), microtime(), mt_rand(), and a salt value if you like as well. You output your form fields dynamically, using php to assign the randomized hash to the name value of the form field. Enter some data, submit the form. The script takes your $_POST array and compares the array keys to $_SESSION. You can then do further validation and then assign your values to common sense variable names that are always private.

When you have validated this submission, you know the data has come from your form page. While you can spoof referrers, You cant spoof the form field names because they are only created at runtime.

The honeypot is the inverse approach, And also has lots of fans in its camp. A honeypot is a web form with addtional form elements, usually of a hidden type, that get discovered by a spammers crawler. They then seize upon the field name and use it in an attack. But since the form field isnt visible to users through the browser, it must be some kind of forged submission, and is worthy of filtering out.

The advantage of the moving target over honeypot is that forged submissions can be filtered out earlier in the script. Also, an attacker could easily analyze the form page once and determine what form fields to omit, and just add that information into the submitting script. They visited the page once, made a correction, and are back in business. Even so it is known as a successful defense. It is a successful defense because of the reason spam is spam: people messing with your site without ever even visiting it, not once. And if you are using an off-the-shelf website-in-a-box like WordPress or Drupal or whatever, the attacker can even more easily attack your site, with its cookie cutter template form elements, one same as the other million out there already.

It is very economical to attack as many sites as possible in the same way as possible. It will always be so.

I have had my share of naysayers over the moving target method. Please allow me reply to a few of the comments others have already made.

Why not just use the form name, why all form fields? I guess you could, but really there are a couple answers. First is the concept of defense in depth. Secure the whole thing, not just one element that an attacker could lock on to. Next answer is that it is simple enough to do the work in php to generate all the form field names you wish.

The site could still be attacked. Yes. Assume that it will be. Funky forms is of course not the only line of defense you must apply to stop your site from being trashed. What I was able to accomplish here is to break the link between the site and the garden variety automated attack, which must assume to know your form name and names of input fields in order to forge the rest of the information. The client must be on your web page in real time to submit data into your form. And in fact that is all the moving target approach does. The attacker still harvests your page, prepares a http remote attack in the guise of a simulated form posting, then goes to work, submitting to all the websites. But nothing gets through to a site with the moving target approach because field names wont match up.

A position based attacker could still hit it. Yes but of course you are not done validating your input because you have this in place. Spam, like anything else, is a matter of economics, in terms of both time and money. Yes someone could get you, but not likely, because like 2 boxers in a ring, both have to be stationary for a moment for a punch to connect. Otherwise its much harder to be effective, and much less powerful. The analogy is a fair one: The time required to hit a site with moving target is greater than the time to perform the usual kind of automated crawling and submitting designed for static form field names. The mere fact that you require your user to be on your page, absolutely, is enough in itself for attackers not to bother changing its tactics for millions of websites, or to lose so much time to making an exception to you that it becomes uneconomical to do so. As it stands, they may never even know that their submission was unsuccessful. You can of course push suspicious submissions to Akismet.

Yeah but sessions are evil and should never be used. Some have said so. Not to long ago, they didn’t work very well. But this isnt the case anymore. Drupal doesn’t use sessions, for example, and other middlewares avoid them as well. Projects with requirements for handling legacy code, particular kinds of services or policies may insist that sessions not be used. But even more evil is to never use sessions because of not understanding how to use them properly and parsimoniously.

First comes your form page, use some php before the form to generate the fields that you need.

<?php
session_start();
if(!$_SESSION["subscriber"]["values"]) {
  $fieldNamesCount = 11;
  $fieldNamesArray = array();
  for ($i = 0; $i < $fieldNamesCount; $i++) {
    // $fieldNamesArray2[] =  md5("killSpam" . uniqid(microtime(), 1)); // random coctail with salt, if you wish
    $fieldNamesArray[] =  uniqid(md5(mt_rand())); // random coctail
  }
  $_SESSION["subscriber"]["fieldNames"] = $fieldNamesArray;
} else {
// do something when its a return pag
}

echo "<pre>";
print_r($fieldNamesArray)
echo "</pre>";

……. and then your form fields look something like this:

Name: <input type="text" name="{$_SESSION["subscriber"]["fieldNames"][0]}" value="<?php  echo  $_SESSION["subscriber"]["values"][0]; ?>" size="20" maxlength="50" />

Phone: <input name="{$_SESSION["subscriber"]["fieldNames"][1]}" type="text" value="<?php echo  $_SESSION["subscriber"]["values"][1]; ?>" size="20" maxlength="20" />

You submit this to your form target script. If you look at your page Info in Firefox, under the forms tab, you will see you have form field names created from random hashes generated at runtime. The values for the names will be unique at every page load. The user must be on the page to submit.

So lets take a look at the script you are posting this data to.

Lets just assume that you are pointing this form submission to a different file, so here is what is required at a minimum:

<?php
session_start();
if (!$_POST) {
  echo "no post reference";
  exit();
}
// compare $_SESSION["subscriber"]["fieldNames"]
// to array_keys($_POST);
if(!$_SESSION["subscriber"]["fieldNames"]) {
  echo "no ref to my session";
  exit();
}

$postedKeys = array_keys($_POST); // I need to access this as an  array.

$_SESSION["subscriber"]["values"] = $_POST;
$realNames = array('Name','Telephone',.... etc);

for($i = 0; $i < count($postedKeys); $i++) {
  if($postedKeys[$i] == $_SESSION["subscriber"]["fieldNames"][$i]) {
    // no cheating! you must you my randomly generated field names to use this page!!!!
    $realValues[$realNames[$i]] = $_SESSION["subscriber"]["values"][$_SESSION["subscriber"]["fieldNames"][$i]];
  } else {
    // its the work of satan
    echo "please dont do that ";
    exit();
  }
}

so if it passes all the tests, its good to go. Otherwise, its like two people talking to each other who dont speak each others language. They will never get what each other is saying, will never understand, and will just move on.