CMI Web Studio

Open Zend Server page, http://localhost:10081/

Disable “Zend Debugger”

Download xdebug.so binary which I suggest to download at -> http://aspn.activestate.com/ASPN/Downloads/Komodo/RemoteDebugging

Extract the archive and browse into ’5.3′ folder then copy ‘xdebug.so’ to ‘/usr/local/zend/lib/php_extensions’

Open ‘/usr/local/zend/etc/php.ini’ and add the following lines above [zend] section:

zend_extension=/usr/local/zend/lib/php_extensions/xdebug.so
[xdebug]
xdebug.remote_enable=1
xdebug.remote_host=”localhost”
xdebug.remote_port=9000
xdebug.show_local_vars=On
xdebug.var_display_max_data=10000
xdebug.var_display_max_depth=20

Now restart your Zend Server by ‘sudo /usr/local/zend/bin/zendctl.sh stop’ and ‘sudo /usr/local/zend/bin/zendctl.sh start’

In programming, regular expressions are a very useful tool designed to validate, search, and match text patterns. In this article, I have compiled more than 10 incredibly useful regular expressions, for any language, that will probably be very beneficial to you.

Validate an URL
Is a particular url valid? The following regexp will let you know.

/^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \?=.-]*)*\/?$/
Source: http://snipplr.com/view/19502/validate-a-url/

Validate US phone number
This regexp will verify that a US phone number is valid.

/^(\+\d)*\s*(\(\d{3}\)\s*)*\d{3}(-{0,1}|\s{0,1})\d{2}(-{0,1}|\s{0,1})\d{2}$/
Source: http://snippets.dzone.com/posts/show/597

Test if a password is strong
Weak passwords are one of the quickest ways to get hacked. The following regexp will make sure that:

Passwords will contain at least (1) upper case letter
Passwords will contain at least (1) lower case letter
Passwords will contain at least (1) number or special character
Passwords will contain at least (8) characters in length
Password maximum length should not be arbitrarily limited

Get code within
(?=^.{8,}$)((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*$
Source: http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=297

Get code within
If for some reason you need to grab all the code contained within the tags, this regexp will do the job:

<\?[php]*([^\?>]*)\?>
Source: http://snipplr.com/view/12845/get-all-the-php-code-between/

Match tel: urls
In a recent post, I showed you how you can use iPhone special link prfixes to automatically call someone.
This regular expression will match those tel: urls.

^tel:((?:\+[\d().-]*\d[\d().-]*|[0-9A-F*#().-]*[0-9A-F*#][0-9A-F*#().-]*(?:;[a-z\d-]+(?:=(?:[a-z\d\[\]\/:&+$_!~*’().-]|%[\dA-F]{2})+)?)*;phone-context=(?:\+[\d().-]*\d[\d().-]*|(?:[a-z0-9]\.|[a-z0-9][a-z0-9-]*[a-z0-9]\.)*(?:[a-z]|[a-z][a-z0-9-]*[a-z0-9])))(?:;[a-z\d-]+(?:=(?:[a-z\d\[\]\/:&+$_!~*’().-]|%[\dA-F]{2})+)?)*(?:,(?:\+[\d().-]*\d[\d().-]*|[0-9A-F*#().-]*[0-9A-F*#][0-9A-F*#().-]*(?:;[a-z\d-]+(?:=(?:[a-z\d\[\]\/:&+$_!~*’().-]|%[\dA-F]{2})+)?)*;phone-context=\+[\d().-]*\d[\d().-]*)(?:;[a-z\d-]+(?:=(?:[a-z\d\[\]\/:&+$_!~*’().-]|%[\dA-F]{2})+)?)*)*)$
Source: http://tools.ietf.org/html/rfc3966#section-3

Validate US zip code
When building a registration form, it is common to ask the user’s zip code. As forms are often boring, there’s a strong chance that the user will try to register false data. This regular expression will make sure he entered a valid American zip code.

^[0-9]{5}(-[0-9]{4})?$
Source: http://reusablecode.blogspot.com/2008/08/isvalidzipcode.html

Validate Canadian postal code
This regexp is very similar to the previous one, but it will match Canadian postal codes instead.

^[ABCEGHJ-NPRSTVXY]{1}[0-9]{1}[ABCEGHJ-NPRSTV-Z]{1}[ ]?[0-9]{1}[ABCEGHJ-NPRSTV-Z]{1}[0-9]{1}$
Source: http://reusablecode.blogspot.com/2008/08/isvalidpostalcode.html

Grab unclosed img tags
As you probably know, the xhtml standard requires all tags to be properly closed. This regular expression will search for unclosed img tags. It could be easily modified to grab any other unclosed html tags.

]+)(\s*[^\/])>
Source: http://snipplr.com/view/6632/grab-any-unclosed-xhtml-img-tags/

Find all CSS attributes
This regexp will find CSS attributes, such as background:red; or padding-left:25px;.

\s(?[a-zA-Z-]+)\s[:]{1}\s*(?[a-zA-Z0-9\s.#]+)[;]{1}
Source: http://snipplr.com/view/17903/find-css-attributes/

Validate an IBAN
I have recently worked on a banking application and this one was definitely a life-saver. It will verify that the given IBAN is valid.

[a-zA-Z]{2}[0-9]{2}[a-zA-Z0-9]{4}[0-9]{7}([a-zA-Z0-9]?){0,16}
Source: http://snipplr.com/view/15322/iban-regex-all-ibans/

Validate a BIC code
Another one very useful for any banking application or website: This regexp will validate a BIC code.

([a-zA-Z]{4}[a-zA-Z]{2}[a-zA-Z0-9]{2}([a-zA-Z0-9]{3})?)
Source: http://snipplr.com/view/15320/bic-bank-identifier-code-regex/

If you’re interested in regular expressions, make sure you have read our “15 PHP regular expression for developers” post.

OK, Dreamweaver has reused the recordset code for too long, but let’s look at the big picture for Dreamweaver CS5. The easiest front end development tool that exists… period. No one can take that away. In CS5, Adobe has finally stepped up their development game a notch.

As a PHP developer, it’s the changes in Code view that really excite me. When you start typing a PHP script in Dreamweaver CS5, you’ll immediately notice a red marker in the line numbers column and an alert about a syntax error. Complete the line without errors, and the marker and warning disappear. Dreamweaver constantly checks your syntax on the fly. It doesn’t tell you what the errors are, but it highlights all lines with errors, making the debugging process much quicker. PHP code hints have also been improved dramatically. There’s full support for all core functions, constants, and classes (as of PHP 5.2).

Code hinting is also much smarter. Instead of needing to search through code hints alphabetically, Dreamweaver CS5 searches for substrings. This is helpful when you can’t remember the exact name of function or class—just type the part of the name that you remember, and Dreamweaver includes it in the list. You can also work out your own shortcuts. For example, if you press Ctrl+spacebar and type gesi, the code hints take you straight to getimagesize() by recognizing the ge of “image” and the si of “size”. And in case you don’t know how a function or class works, the official manual page—complete with code examples—appears as a tooltip at the bottom of the selected code hint.

For serious PHP developers, it gets even better. Dreamweaver CS5 is capable of code introspection, so it builds code hints on the fly for your own functions and classes, as well as for third-party libraries, such as the Zend Framework. The definition files don’t even need to be directly attached to the page you’re working in. With Site-Specific Code Hints, you tell Dreamweaver where your library files are located, and it scans them for you automatically.

So should you upgrade? Seriously, you’re asking that? YES… it’s the best version of Dreamweaver that’s existed.

You don’t need to use $_GET or$_POST anymore. In fact, you probably shouldn’t use $_GET and$_POST anymore. Since PHP 5.2, there is a new and better way to safely retrieve user-submitted data.

How many times have we heard about security issues in PHP applications stemming from unescaped GET and POST parameters? Proper escaping of input is a perennial problem with web development in general, and for whatever reason PHP seems to have had more than its fair share of bad publicity on this front.

On the database side, many worries over SQL injection have been squelched. The clever developers of PDO, for example, have constructed a library that analyzes data and escapes it appropriately. But the problem of validating and sanitizing input is still a substantial issue. To my surprise, many seasoned PHP developers still spend precious development cycles building custom code to filter input.

Why is this surprising? Because PHP (from 5.2 onward) has a built-in filtering system that makes the tasks of validating and sanitizing data trivially easy. Rather than accessing the$_GET and $_POST superglobals directly, you can make use of PHP functions likefilter_input() and filter_input_array(). Let’s take a quick look at an example:

<?php
$my_string = filter_input(INPUT_GET, ‘my_string’, FILTER_SANITIZE_STRING);
?>

The code above is roughly the equivalent of retrieving $_GET[‘my_string’] and then running it through some sort of filter that strips HTML and other undesirable characters. This represents data sanitization, one of the two things that the filtering system can do. These are the two tasks of the filtering system:

• Validation: Making sure the supplied data complies with specific expectations. In this mode, the filtering system will indicate (as a boolean) whether or not the data matches some criterion.
• Sanitizing: Removing unwanted data from the input and performing any necessary type coercion. In this mode the filtering system returns the sanitized data.

By default, the filter system provides a menagerie of filters ranging from validation and sanitization of basic types (booleans, integers, floats, etc.) to more advanced filters which allow regular expressions or even custom callbacks.

The utility of this library should be obvious. Gone are the days of rolling our own input checking tools. We can use a standard (and better performing) built-in system.

Filters won’t solve every security-related problem, but they are a tremendous step in the right direction when it comes to writing safe (and performant) code. It’s also simpler. Sure, the function call is longer, but it relieves developers of the need to write their own filtering systems. These are darn good reasons to never use $_GET (or $_POST and the others) again.

In particular, a debate between the C#/.NET/IIS stack and the Java/J2EE/Apache/Solaris stack and the PHP/Apache/Linux stack could go on and on for years and years and you’d never find the right answer. That’s because there are so many pros and cons of all these platforms that advocates of each side can debate and debate and never get any closer to the truth, but it sure as heck is a fun debate.

There’s so much evidence that when it comes right down to it, millions of people are building huge business-critical things in C#, Java, PHP, or Python, and while they may have problems, they’re not mission threatening problems.

So how do you decide between C#, Java, PHP, and Python? The only real difference is which one YOU know better. If you have a serious PHP guru on your team who has built several large systems successfully with PHP, you’re going to be a heck of a lot more successful with PHP, not because PHP is a better language than C#, Java, or Python, but because he knows it better