Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've already awarded a 100 point bounty to mario's answer, but might start a second 100 point bounty if I see new good answers coming in. This is why I'm keeping the question open and will not choose a final answer, despite having awarded the bounty to mario.
This might seem like a simple question (study the code and refactor) but I'm hoping those with lots more experience can give me some solid advice.
The library is an open source 20,000 line library that's all in a single file and which I haven't written myself. The code looks badly written and the single file is even a bigger problem, because it freezes eclipse for half a minute at least every time I want to make a change, which is one of the reasons I think it's worth it to refactor this library into smaller classes.
So aside from reading the code and trying to understand it, are there common (or not so common) tips when refactoring a library such as this? What do you advise to make my life a little easier?
Thanks to everyone for your comments.
A few generic principles apply:
Divide and conquer. Split the file into smaller, logical libraries and function groupings. You will learn more about the library this way, and make it easier to understand and test incrementally.
Remove duplication. Look for repeated functions and concepts, and replace them with standard library functions, or centralized functions within the library.
Add consistency. Smooth out parameters and naming.
Add unit tests. This is the most important part of refactoring a library. Use jUnit (or similar), and add tests that you can use to verify that the functions are both correct, and that they have not changed.
Add docs. Document your understanding of the consistent, improved library as you write your tests.
If the code is badly written, it is likely that it has a lot of cloning. Finding and getting rid of the clones would then likely make it a lot more maintainable as well as reducing its size.
You can find a variety of clone detectors, these specifically for PHP:
Bergmann's PHPCPD
SourceForge PMD
Our CloneDR
ranked in least-to-most capability order (IMHO with my strong personal self-interest in CloneDR) in terms of qualitatively different ability to detect interesting clones.
If the code is badly written, a lot of it might be dead. It would be worthwhile to find out which part executes in practice, and which does not. A test coverage tool can give you good insight into the answer for this question, even in the absence of tests (you simply exercise your program by hand). What the test coverage tool says executes, obviously isn't dead. What doesn't execute... might be worth further investigation to see if you can remove it. A test coverage tool is also useful to tell you how much of the code is exercised by your unit tests, as suggested by another answer. Finally, a test coverage tool can help you find where some of the functionality is: exercise the functionality from the outside, and whatever code the test coverage tool says is executed is probably relevant.
Our PHP Test Coverage Tool can collect test coverage data.
If it's an open source library, ask the developers. First it's very likely someone already has (attempted) a restructured version. And very occassionally the big bloated version of something was actually auto-generated from a more modular version.
I actually do that sometimes for one of my applications which is strictly pluginized, and allows a simple cat */*.php > monolithic.php, which eases distribution and handling. So ask if that might be the case there.
If you really want to restructure it, then use the time-proven incremental extension structure. Split up the class library into mutliple files, by segregating the original class. Split every ~ 2000 lines, and name the first part library0.php:
class library0 {
var $var1,$var2,$var3,$var4;
function method1();
function method2();
function method3();
function method4();
function method5();
The next part simple goes from there and holds the next few methods:
class library1 extends library0 {
function method6();
function method7();
function method8();
...
Do so until you have separated them all. Call the last file by its real name library.php, and class library extends library52 { should do it. That's so ridiculously simplistic, a regex script should be able to do it.
Now obviously, there are no memory savings here. And splitting it up like that buys you nothing in terms of structuring. With 20000 lines it's however difficult to get a quick overview and senseful grouping right the first time. So start with an arbitrary restructuring in lieu of an obvious plan. But going from there you could very well sort and put the least useful code into the last file, and use the lighter base classes whenever they suffice. You'll need a dependency chart however to see if this is workable, else errors might blow up at runtime.
(I haven't tried this approach with a huge project like that. But arbitrarily splitting something into three parts, and then reshuffling it for sensibility did work out. That one time.)
I assume you are planning to break the library up into thematically relevant classes. Definitely consider using autoloading. It's the best thing since sliced bread, and makes inter-dependencies easy to handle.
Document the code using phpDoc compatible comments from the start.
Calling Side Approach
If you know the library use is limited to a particular class, module, or project it can be easier to approach the problem from the calling side. You can then do the following to clean the code and refactor it. The point of approaching from the calling side is because there are very few calls into the library. The fewer the calls the (potentially) less code that is actually used in the lib.
Write the Calling Side Tests
Write a test that mimics the calls that are done against the library.
Bury the Dead Code
If there is a lot of dead code this will be a huge win. Trace the the actual calls into the library and remove everything else. Run the test and verify.
Refactor Whats Left
Since you have the tests it should be much easier to refactor (or even replace) the code in the library. You can then apply the standard refactoring rules ie. (de-duplication, simplification, consolidation, etc).
Apart from what was already stated I suggest to have a look at Martin Fowler's Catalog of Refactorings based on his book. The page also contains a large number of additional sources useful in understanding how refactoring should be approached. A more detailed catalog listing can be found at sourcemaking. Note that not all of these techniques and patterns can be applied to PHP code.
There is also a lot useful tools to assist you in the refactorings (and in general) at http://phpqatools.org. Use these to analze your code to find things like dead or duplicated code, high cyclomatic complexity, often executed code and so on. Not only will this give you a better overview of your code, but it will also tell you which portions of your code are critical (and better left untouched in the beginning) and which could be candidates for refactorings.
Whatever you do, do write Unit-Tests. You have to make sure you are not breaking code when refactoring. If the library is not unit-tested yet, add a test before you change any code. If you find you cannot write a test for a portion of code you want to change, check if doing a smaller refactoring in some other place might let you do so more easily. If not, do not attempt the refactoring until you can.
Write tests for the library such
that all the lines of the code is
covered(i.e 100% Coverage).
Use
TDD. Start from the higher
level module and re-factor(Top to
Bottom approach).
Run the tests mentioned in step 1. and verify with the results of step 2.
I understand that 100% coverage(as mentioned in step 1) does not necessarily mean that all the features have been covered at least we are making sure that whatever the o/p of the current system will be same as the o/p of new system.
A good book that answers your question with a lot of examples and details is: Working Effectively with Legacy Code, by Michael Feathers.
First of all, consider using a different IDE - Eclipse is notoriously terrible in terms of performance. Komodo is way faster. So is PhpStorm.
In terms of making the refactoring easier, I'd first try to identify the high-level picture - what functions are there? Are there classes? Can you put those classes into separate files just to start with?
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Refactoring depends from you goals and type of solution. This book will help you to understand basic concepts of right code.
If you problem include the headache of manually placing the functions in different files than may be below strategy can help.
get your library file ina php variable
$code = file_get_contents('path/yo/your/library.php');
eliminate tags
$code = str_replace('<?php' ,'' ,$code);
$code = str_replace('?>' ,'' ,$code);
separate all the functions
$code_array = explode('function',$code);
now body of all the functions and their names are in array
create separate files for each of the functions in folder 'functions'
foreach($code_array as $function)
{
$funcTemp = explode('(',$function); // getting function name
$function_name = trim($funcTemp[0]);
$function_text = '<?php function '.$function;
file_put_contents('functions/'.$function_name.'.php',$function_text)
}
now all the functions of your library are in the separate files in a common folder. files are named with the function names. now you can easily look up you functions in folder view and apply your strategies to manage them.
You can also implemet __call() function to use same formates
function __call($name,$params)
{
include_once('functions/'.$name.'.php');
$name($params); // this may be wrong ...
}
Hope it helps :)
Usually, a general rule of thumb is to remove repeated code. Also make sure to have useful documentation. If you're using Java, Javadoc is very useful, but a suitable equivalent is available for other languages.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm developing a web system using regular PHP. This was my first experience with PHP so the code is not legible nor clean. It mixes some HTML code with PHP.
I'd say I have already done half of the code.
What are the real advantages of the Object-oriented PHP?
The website is about books and book authors, using MySQL and Apache. So it's not a very complicated website.
The real advantage of object-orientation: your code is better organized, easier to maintain, more modular (and thus easier to reuse), and potentially less brittle (because of encapsulation of state and implementation, and hopefully better security). (The cynic in me also says that if you learn object-oriented PHP, you take the first important step to leaving the PHP ghetto. Heh. Worked for me!)
There's already a lot of questions from PHPers moving into OO on Stack Overflow:
PHP Object Oriented or Not?
Is my PHP code object oriented?
Learning PHP Class
Not to mention that there are zillions of PHP object-oriented tutorials out there. My take: basically, yes, if you are writing PHP, you should probably be writing object-oriented PHP for anything beyond the most trivial of applications. There are lots of Rails-like frameworks for PHP that will make your life easier, and may help you become a better programmer.
Object oriented PHP does not differ with the procedural style in the amount of HTML code you mingle with PHP code. So if your only concern is the mix you should look for other ways to get your code cleaned. For example you can create html template files with placeholders for your dynamic content and use file_get_contents and str_replace to inject the dynamic content at run time.
In my mind, we PHPers can thoroughly throw away the concept of Object (class instance), we only need Array and Mode Class:
All arrays in initial mode support any array function as its method:
<?php
$array1->array_flip(this);
?>
Use "->mode()" to validate the minimal data set, and then switch mode class:
<?php
$array1->mode('class1', $success);
?>
Any mode class has no "->construct()" in it, but has "->validate()" to validate the minimal data set.
The array in a mode still could use array function as its method, but after using any of them the array will be switched back into basic array mode,
and we need to use "->mode('class1', $success);" to switch mode back.
The radical thought here is data-centric programming; we need to separate the data (array) and the activity (class method).
We could modify the PHP engine, to get rid of parts of OO (object oriented), and support Mode Class. We could call it MyPHP.
For example:
$array_man1 could be set into two modes: cls_normal_man and cls_crazy_man:
<?php
$array_man1->mode('cls_normal_man')->normal_method1()->mode('cls_crazy_man')->crazy_method1();
?>
if you really want to use oo programming go to Ruby.
OO PHP for me is a fake. And if you already have half of code done in structural php dont change your mind.
just remember to make code clean with lots of comments so you can easily change sth in the future
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I recently found out that PHP 5.3 supports new language construct called GOTO. Everybody knows what it does. However, it's not exactly the traditional GOTO, it's just a jump label. I'm interesting in knowing whether this GOTO is evil and implies bad code?
Unless you are programming in assembler, GOTO should always be treated the same way as the life vest of the airplanes: it is good to have them available, but if you need to use them it means that you are in big trouble.
I can't believe nobody posted this :)
Granted, PHP is not compiled... Maybe the raptor will chase you on every visit to your website?
Bad structuring of code is evil, regardless the control structure you use.
I personally prefer a goto that makes clear the flow of the program to "control variables" and nested "if" that will indirectly just cause the same branch in the code.
So, just write the two versions (with and without GOTO) and see which one it's easier to comprehend. Then the choice is easy.
I think this is the most important part of the PHP manual page and missing here:
This is not a full unrestricted goto. The target label must be within the same file and context, meaning that you cannot jump out of a function or method, nor can you jump into one. You also cannot jump into any sort of loop or switch structure. You may jump out of these, and a common use is to use a goto in place of a multi-level break.
IMHO this makes it very different from the ye olde BASIC style gotos.
I'm in the minority (currently), but I believe the restrictions placed on PHP's goto construct make a very beneficial tool:
http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/
I actually walk through an example of arrow code (deeply nested conditionals) and refactor it using standard practices (guard clauses, grouping conditions, pulling out functions) in one version and a goto-based version in the other version, and I actually prefer the goto-based refactoring.
Are guns evil? Both can be used for good or for evil. I would say it was easier to write good code without goto, than with.
Any language feature that can make code more readable in a given situation is A Good Thing. GOTO is one such language feature, even if those situations are few and far between. If we forbade any syntax that made it possible for poor programmers to write bad, unmaintainable code our jobs would be an awful lot harder.
As a software engineer, i mostly work on "mainframes" and "big corporate servers"...
And our daily language (I mean the one in 95% of our base code) is Cobol, which uses extensively GOTOs.
This usage doesn't mean the code is bad. It just means that this tool (GOTO) was the right one at the moment programs were written.
To answer Kaitsuli's question, I think it can be useful tool when writing PHP scripts.
On the other hand, a lot of scripts were achieved without it for almost a decade by now. Furthermore, it goes against PHP's evolution with more object-oriented features.
IMHO, it's nor good nor a bad thing for the code be produced : good programs will still be good and "horror programs" will be worse... The only question is : "Why adding GOTOs 10 years after proving it was not necessary ?".
GOTO usually is evil because it lets you build unstructured code. With the usual loops you can build good structured code easy to follow because it is structured.
When you have non structured code jumping from here to there, you have just found the evil coming from the GOTO statement. Almost always is better to avoid it. Maybe once every 100.000 lines there is a place where a GOTO sentence simplifies A LOT the code thus is not evil but if you are unsure, then you should avoid the GOTO.
Hope this helps.
EDIT: Well, just to add my own opinion here, there are other instructions that allow you to create unstructured code and that are not considered evil when I think they should be.
For example a return in middle of a function is a GOTO to the end of it so I avoid them and use only one return in each function just at its end.
Other languages like Vb.Net (maybe others too) allow to do Exit For, Exit While, breaks and things like these that also unstructure the code and I think should be avoid.
sometimes (I mean in 0.01% of cases) it is useful, like when you have a long long script and you want to test some blocks. but never keep it in your final script
I used GOTO when I write script for working under cli mode. It save my life.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have this idea for a website that's been floating around my head for quite sometime now and now have finally decided to get to work on it. Due to the nature of the project and my experience I am getting comfortable with the idea of running it as a PHP+MySQL application on an Apache server.
This is my first time doing web programming of any sort(I have a background in sysadmin and mainframe systems coding) and I am pretty unsure of what practices to take into consideration so that I don't find myself undoing/redoing things later in the project. Considering all the flak the language has taken on StackOverflow(which can be seen here and here) it would be nice to have a set of common mistakes to watch out for for a beginner like me. I did find this thread outlining things to avoid in PHP but most of the points made little sense to someone like me who's just setting out in PHP.
Do you have any suggestions, tips or tutorials outlining common gotcha's in the language which might come back later in the project demanding entire rewrites.
For what it's worth I am currently working my way through Programming PHP(O'Reilly) and PHP in Action(Manning).
I was in a very similar position a couple years ago, having come from a NOS background myself.
I actually started with PHP and MySQL for dummies. Once I had absorbed the knowledge contained therein, I hit the Web (I used SitePoint a lot, like Boushley recommended) and I read a couple of O'Reilley's book on the subject.
Once thing I will tell you, is that if you want to streamline your understanding and your efficiency, I have found great success with a number of MVC frameworks(CodeIgnitor, CakePHP, etc). If you have no idea what MVC is, I recommend finding out. Now that I use MVC, my code is easier to understand, modify, troubleshoot, etc.
And honestly, half of the learning in PHP is running into those common mistakes and learning from them. Its hard to appreciate those 'common mistakes' until you make them.
Don't worry about HOW you are going to learn, just START leaning!
If I could give you one piece of advice, it'd be to use a framework - they will make your life so much easier. They take away all the repetitive code from programming websites, handle security concerns and abstract lots of things, as well as make you build your website using a pattern such as Model-View-Controller.
I highly recommend the CodeIgniter framework for it's simplicity, power, great documentation and ease of use, but there are plenty of other good frameworks too. There are lots of questions on SO on this so have a quick search. There is a fantastic introductory screencast on CodeIgniter (soon to be a series) from BinaryCake, so check that out here.
I hope that's helped! If you have any PHP concerns, feel free to message me - it's my area of expertise (along with CodeIgniter) and I love it!
While still developing, have all errors show up:
ini_set('display_errors', '1');
error_reporting(E_ALL | E_STRICT);
Can save a lot of time (in case of say, typos in variable names). Change this when it goes live to not display or only display "real" errors depending on the type of site and security levels involved (you don't want everyone to know paths and variable names and such..).
Find a variable/function naming convention (under_scores vs camelCase vs..) that suits you and stick to it. Also, classes go in the /class directory, includes in /inc etc. Both these make it easier to understand your own code years from now. Oh, and the same goes for coding style, I guess: choose one and stick to it (indentation, bracket style, ..).
Comment your code :-) Personally I also have a little log at the end of longer files that shows when I did what and why. Each addition is timestamped, and the same timestamp is also in the comments behind the change itself, as the line number on which it sits can easily change. Similarly, in an included file containing a bunch of functions, I have the list of function names in a comment at the top of the file, with a one-line description behind them.
Finally on security (though this should really be your first concern ;-) ), treat all user input as suspect. That's POST & GET data, cookies, user-agent string, search strings - anything that is supplied by the browser. It's trivial to change cookie data or change/add form items.
Read up on SQL injection & XSS attacks, and look at PHP's relatively new data filter functions: http://php.net/manual/en/intro.filter.php
Google any of these to get some good reading
Don't use register_globals
Turn off magic_quotes - escape all user entered input in SQL statements
Escape any user entered input printed with htmlspecialchars()
Plus a lot more... These are some common things to watch out for though.
There are a number of great websites out there with lots of tutorials. One that comes to mind is Site Point. They'll try their best to sell you a book or two while your're there, but they do have some decent articles. This article for instance discusses some common security blunders in php.
http://www.sitepoint.com/article/php-security-blunders/
They have lots of them...
http://www.sitepoint.com/search/search.php?ps=10&q=php&submit=Search
Also a nettuts.com has a load of tutorials an things of that nature. They're more all across the board though.
http://nettuts.com/
And I think pretty much everywhere you look you'll see the common ones like watch out for register_globals, magic_quotes...
one good book to look at that is also free to download here covers beginner to advanced PHP techniques and is good way to learn good standards :)
Use a framework and use Object Oriented Programming
Books are great for learning additional languages, but for your first one, a good video tutorial is a great way to go!
Register for a Lynda.com account (google: lynda trial) and sign up for as many one day trials as you need (or be a good honest person and purchase a week). They have a pretty good beginner and advanced PHP series of video tutorials which are (IMHO) a great way to learn your first language.
A tip: If you can start programming Object Orientedly from the get-go, you will save some time in the future and learn good practice from the start, luckily the advanced tutorials cover this!
Here's a link: http://www.lynda.com/home/DisplayCourse.aspx?lpk2=435
I've never taken this particular course (when I learned a few years ago, it was different), but I just recommended this to a friend (who was just starting), and he really liked it!
Hope this helps!
If you're new to programming in general, A database backed web application is likely to be a bumpy ride. You will probably be programming in at least two, real programming languages, PHP and SQL, and if you're going to do anything of modest complexity, JavaScript too. Keeping them strait will be rough, because they are all quite different.
Just to warm up to programming, you might want to start instead using a more focused learning excercies, such as working through the Euler Project problems, or Code Kata.
Either way, Try to pick up good habits wherever you learn about them, including the popular suggestion here of using an MVC framework for the heavy lifting.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 8 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I would like to be a PHP/MySQL programmer
What are the technologies that I must know?
Like:
Frameworks
IDEs
Template Engines
Ajax and CSS Frameworks
Please tell me the minimum requirements that I must know, and tell me your favourite things in the previous list?
Thanks
First off, there is no must know about learning PHP and MySQL... You go into it not knowing anything, and you'll come out of it knowing a bunch. If there was a must know, then nobody would be able to get into PHP and MySQL development. I personally think you are at a slight advantage going into this without knowing everything about it. It'll give you a fresh perspective and a think outside of the box attitude :)
As far as the object oriented stuff in this thread, it's true. But, as others have said, it's completely up to the programmer (you) to decide how to write your code. You can use object oriented practices, make a spaghetti code junction, or just right a bunch of functions, or whatever. Either way, as everyone else has been saying, it's up to you :)
IRC channel:
Don't really need this, but I find it helpful... See you in here :)
irc.freenode.net #php
Manual:
The manual is your friend and probably the only thing you should know before diving in.
http://www.php.net/manual/en/
http://dev.mysql.com/doc/refman/5.0/en/apis-php.html
Frameworks:
Make sure it's an MVC framework :)
http://www.cakephp.org/
http://www.phpmvc.net/
http://www.codeigniter.com/
http://www.symfony.com/
http://www.laravel.com
http://www.yiiframework.com/
IDE:
Whatever suits you best :)
http://www.eclipse.org/
http://www.vim.org/
http://www.zend.com/en/products/studio/
http://php.netbeans.org/
https://www.jetbrains.com/phpstorm/
Template engines:
PHP is a good template engine
Model view controller frameworks help with this
twig.sensiolabs.org
http://www.smarty.net/
Ajax:
http://jquery.com/
http://www.mootools.net/
http://developer.yahoo.com/yui/
http://www.prototypejs.org/
http://www.extjs.com/
http://code.google.com/webtoolkit/
https://angularjs.org/
CSS:
http://www.yaml.de/en/home.html
http://code.google.com/p/blueprintcss/
http://developer.yahoo.com/yui/reset/
Definitely not an exhaustive list, and things change constantly... But, it's a start :)
Have fun!
Chrelad
Security is an important topic every web programmer should study before being allowed to post code that can be accessed publicly on the internet.
Examples of security issues:
Injection flaws
Cross-site scripting flaws
Cross-site request forgery
There are more security issues that you should know and keep in mind as you write PHP applications. The website http://www.owasp.org contains lots of useful information to help.
PHP was my first language, which I learned on the side while working as an office junior in my first job over 10 years ago. Here is some things from my experience:
Download the PHP manual, print it off, and start reading from page one. Keep going till you're at the end. Skim over the bits you probably won't need (like using KADM5 or Hyperwave) but always read the introductions so you know what PHP is capable of (this will save you trying to re-invent the wheel). The PHP documentation blows the docs of pretty-much every other language I've worked with since out of the water.
Next step; set up PHP. Manually. Don't use XAMPP or anything else, do it yourself. It always helps to know how your environment is set up.
Don't bother with an IDE at the beginning. Getting to know a language means getting up-close-and-personal. IDEs obscure things in an attempt to help you GetThingsDone which works great when you know what you're doing and know your target environment, but when you're starting out they just get in the way and hide what's important.
Don't bother with frameworks at the beginning, either. Again, they're there to help you GetThingsDone which only works when you know what you're doing in the first place. Start with the basics, otherwise you'll be learning the framework and not PHP.
PHP is essentially an advanced templating engine. Don't fall into the trap of over-hyped "PHP templating engines". They're just doing what PHP already does, doubling-up on the work and running twice as slow as PHP does. Stick with inline html/php to start with. Again, this'll help you get to understand what PHP is, how it works, and when to use it.
As with AJAX and CSS... they're nothing to do with PHP, but with the output you produce from PHP (and with AJAX getting input in). Don't load your plate with too much to eat at once. Start with plain PHP+HTML, and do your CSS by hand. Then, when you're happy, mix in a little javascript.
The best thing you can do with any language is learn the environment you're going to be working in, because programming is (relatively) similar across all of them. They all have loops, data structures, input/output, etc, but they all work just that little differently.
Don't believe the hype. I'm moving from PHP to Python at the moment and I could've just jumped on the Django band-wagon to GetThingsDone, but I know that if I came across a problem I wouldn't know where to begin to fix it. So I'm taking my own advice and starting from the beginning; reading the manual, setting up an test system, parsing simple files, getting input/output, getting it linked in with a web server... all part of getting to know my new environment.
What should every PHP programmer know ?
You need to know a language that is not PHP. I'm not saying you shouldn't develop your sites in PHP, it's actually really good for that, but you really need to know at least one other language to get some perspective.
Why? PHP is broken and full of bad design and misfeatures. You can write excellent code in PHP, but you're never going to be able to spot the bad design and failures of PHP itself if you don't know any better.
I'd suggest python, ruby, or C#
PS: If you don't think this is a helpful suggestion, then by all means downmod this answer, but if you are downmodding because you feel insulted by my claim that PHP is broken and badly designed, don't shoot the messenger, I'm just telling the truth!
First of all, that PHP itself IS a templating system
Security.
Just like Lucas Oman said - it is up to you in PHP to write the code well; and it does not coddle you. If you don't understand why you need to confirm a logout, or why you can't just validate in javascript, or why register_globals is bad - your app will be vulnerable in some form or another.
You need to learn the following (I would suggest in this order):
Basic Object-Oriented Principles (such as inheritance, polymorphism, and encapsulation)
The PHP language itself. Specifically, PHP 5.
Database Design Principles such as tables, keys, relationships, normalization, etc.
SQL - Structured (or Standard never can remember which) Query Language. Specifically learn the basics of select, insert, update, and delete queries.
Good design principles and coding practices (you can find posts here on StackOverflow for one) such as dividing presentation and business logic.
A Framework, Any Framework - this will help you become introduced to more advanced concepts of object-oriented design patterns and allow you to follow tutorials that will encourage good design and coding practices.
Object-Oriented Design Patterns like MVC, Database Abstraction Models and the like
Advanced SQL and other database stuff like triggers, stored procedures, and other functions.
Ignore the mysql_* functions. Not only do they provide no straightforward method of writing secure code, they actually go out of their way to make it painful and tedious if you try. Use mysqli or PDO instead (and you've got no excuse now - PHP 4 was end-of-life'd months ago).
All good answers, but there is something important missing: If you want to seriously get into PHP, then you should be aware that there are a lot of PHP programmers out there who are lazy, inept, ignorant, misguided and unfortunately get their code released to the public. The history of PHP means that it supports some questionable features (not just things like register_globals but also smaller things like automatic initialization) and people still use them. You don't want to.
I would say the most important thing is to learn how the whole process of building a page with PHP works - in that requests come from a client (web browser), hit the web server, get passed through to PHP, which then generates the response that is sent back. A solid understanding of this will ground you in
why you can't send headers after output has started
how sessions and cookies work
how each page should be built in a stateless manner (i.e. deliver whatever the request asks for, don't remember what happened last time, or guess what the user is doing)
The difference between HTML, PHP, JavaScript and CSS, and more importantly, what each is used for primarily and where the responsibility of each lies.
Once you've got that down, then you should be quite comfortable with writing any app. But unless you've got that down, you'll start mixing things as I've seen many rookies do before now.
That every value everywhere has to be encoded appropriately. echo $some_variable_that_seems_innocent is evil nine times out of ten.
Use htmlspecialchars() in HTML/XML, prepared statements or at least addslashes() when building SQL queries, json_encode() when inserting values into scripts, rawurlencode() when appending URL components, escapeshellargs() when constructing shell commands, etc.
If you insert text in URL that's part of a script in XHTML document, you'll need to encode data three times.
Although this isn't a technology, I think it's very important that you understand that, when using PHP, it is completely on you to write good code. PHP is capable of it, but it does not encourage it. You are completely responsible for writing code that is well designed and, if you choose, follows OO principles. You will have no help from the language.
Use a great IDE (like Eclipse for example) that let you debug and have some code completion. This will save you some time.
PHP have a lot of programmer and is very popular = a lot of thing is already done for you, before writing some code, doing a google search is always a good idea.
You should use some of the Framework if you start from scratch. This will answer all your question about AJax, template engines... because most of them come with these packages.
Here is some post about how to start choosing a framework: SO 1, SO2, Here is a list of PHP Framework.
You can develop PHP on Windows, Linux or Mac.
Getting a web server setup
To run PHP and MySQL locally on your computer you will need to install Apache webserver with php module and MySQL database server. ie. a LAMP webserver (Linux Apache MySQL PHP).
In the past, I would recommend installing Ubuntu. These days, there are a few solutions available that will give you one click installation webserver without using linux.
For Windows:
http://www.wampserver.com
For OSX:
http://www.mamp.info
After having a LAMP webserver use w3schools.com tutorials to start.
I would say a basic one would be HTML. ;)
No Php framework expert.As templating which make the system much complex then as it.
Understand business logic requirement and think the cons/pro.Hoping for SA to think all for you is not good programmer.
No ajax.I dealing with large of data,rendering to one js file about 4000 k data is very bad.
Start from notepad or VI
After learn php about 1 to 2 years,try learn other language like c# or c++ to improve your php application.
Php is addicted language rather then other language.You type it works.Other language,you type It's Compile It's Hang up.
7.For complexity application,php is the best to me rather then other language,because you think,you write it works.
You should know how to use effectively at least one Debugger/IDE. It is amazing what you can learn from your code by stepping through it and watching it run. It both makes it much simpler to track down bugs, and improves the quality of your code. I believe you should never commit code to a project that you haven't seen execute.
The PHP Language
Go to PHP.net and read through all of the documentation. When you are done, you won't know everything you need to know about php, but you will know where to look.
Be careful of code snippets you find on the web. Often they contain sql in html, which is bad practice, as well as security vulnerabilities such as sql injection. I've seen few that use prepared statements, which is good for security.
Personally, I found the book "Build your own database driven website using PHP and MySQL" extremely helpful.
Other than that, the one thing I found hardest to get used to with PHP is how relaxed it is, compared with any other language I've ever used. By that I mean no types, flexibility about syntax and punctuation. Personally I think that's a good thing, but I also know that it probably encourages pretty bad behavior.
Here's one other tip I have: try to use something like the DRY principle -- i.e., you'll find yourself writing the same little (or big) bits of code over and over again -- make them into functions as early as you can in the process of coding, and life will be a lot easier later on.