Installing PHP5 and Apache on Ubuntu

sudo apt-get install apache2
sudo apt-get install php5
sudo apt-get install libapache2-mod-php5
sudo /etc/init.d/apache2 restart

how to install phpMyAdmin [ubantu]

Install phpMyAdmin from the Universe repository see InstallingSoftware for detailed instructions on using repositories and package managers. (Note, however, that installation from a package manager often does not work).

From console:

sudo apt-get install phpmyadmin

• If you're using Ubuntu 7.10 (Gutsy) or later select Apache2 from the "Configuring phpmyadmin" dialog box.

To set up under Apache all you need to do is include the following line in /etc/apache2/apache2.conf.

Include /etc/phpmyadmin/apache.conf

• If you are using Ubuntu 9.04 (Jaunty), there is no need to modify /etc/apache2/apache2.conf as the package installer already copied the file phpmyadmin.conf into /etc/apache2/conf.d directory. You can also skip the set up step and go directly to http://<hostname>/phpmyadmin and login with the user and password you set up during install.

Once phpMyAdmin is installed point your browser to http://localhost/phpmyadmin to start using it. You should be able to login using any users you've setup in MySQL. If no users have been setup, use admin with no password to login.

Should you get a 404 "Not Found" error when you point your browser to the location of phpMyAdmin (such as: http://localhost/phpmyadmin) this is likely caused by not checking the 'Apache 2' selection during installation. To redo the installation run the following:

 sudo dpkg-reconfigure -plow phpmyadmin

Then select Apache 2 for the webserver you wish to configure.

If this does not work, then you can do the following to include the phpMyadmin-shipped Apache configuration into Apache:

sudo ln -s /etc/phpmyadmin/apache.conf /etc/apache2/conf.d/phpmyadmin.conf
sudo /etc/init.d/apache2 reload

Installing from source

You may install phpmyadmin from source. This method circumvents the package manager and you will need to install updates yourself. This is not recommended for a production web server. Also, you'll need to have Subversion installed to download the source.

To install it from source open the console and cd to the www directory using:

cd /var/www/

then download it using svn by writing:

sudo svn checkout https://phpmyadmin.svn.sourceforge.net/svnroot/phpmyadmin/tags/STABLE/phpMyAdmin phpMyAdmin

then cd to phpMyAdmin

cd phpMyAdmin

and create the folder config

sudo mkdir config

after that chmod it

sudo chmod o+rw config

then open http://localhost/phpmyadmin/scripts/setup.php and follow the instructions.

How can I reset my MySQL password?[ubantu]

To reset your mysqld password just follow these instructions :

• Stop the mysql demon process using this command :

  •    sudo /etc/init.d/mysql stop

• Start the mysqld demon process using the --skip-grant-tables option with this command

  •    sudo /usr/sbin/mysqld --skip-grant-tables --skip-networking &

Because you are not checking user privs at this point, it's safest to disable networking. In Dapper, /usr/bin/mysgld... did not work. However, mysqld --skip-grant-tables did.

• start the mysql client process using this command

  •    mysql -u root

• from the mysql prompt execute this command to be able to change any password

  •    FLUSH PRIVILEGES;

• Then reset/update your password

  •    SET PASSWORD FOR root@'localhost' = PASSWORD('password');

• If you have a mysql root account that can connect from everywhere, you should also do:

  •    UPDATE mysql.user SET Password=PASSWORD('newpwd') WHERE User='root';

• Alternate Method:

  •    USE mysql
       UPDATE user SET Password = PASSWORD('newpwd')
       WHERE Host = 'localhost' AND User = 'root';

• And if you have a root account that can access from everywhere:

  •    USE mysql
       UPDATE user SET Password = PASSWORD('newpwd')
       WHERE Host = '%' AND User = 'root';

For either method, once have received a message indicating a successful query (one or more rows affected), flush privileges:

FLUSH PRIVILEGES;

Then stop the mysqld process and relaunch it with the classical way:

sudo /etc/init.d/mysql stop
sudo /etc/init.d/mysql start

When you have completed all this steps ,you can easily access to your mysql server with the password you have set in the step before. An easy way to have a full control of your mysql server is phpmyadmin (www.phpmyadmin.net), software made in php that can give you a web interface that can be very usefull to people that havent got a lot of confidence with bash .To install phpmyadmin on you server you will need to have 4 things:

• web server apache
• php
• mysql server/mysql client installed
• php_mysql support for apache

All packages can be found browsing synaptic.




Another Way:

USE THIS AS A LAST RESORT METHOD, YOU WILL LOSE ALL YOUR MYSQL DATA

sudo apt-get --purge remove mysql-server mysql-common mysql-client

sudo apt-get install mysql-server mysql-common mysql-client

In the next step be sure to chance the your-new-password with the password you want!

mysqladmin -u root password your-new-password
sudo /etc/init.d/mysql restart

mysql -u root -p

You should now be logged in as root. Make sure to notedown your password

Create an Admin panel with CodeIgniter

As I see it there are three methods to creating an admin system using the MVC framework CodeIgniter. In this article I will show examples of the structures for each and mention the pro's and con's of using each.
This article will only outline the theory and suggest the structures to you. I do not plan on writing yet another "How to make a user login system and add admins to it" type article.

1.) Two applications

In CodeIgniter you can easily set up multiple applications to run off the same CodeIgniter install, simply by creating a copy of index.php and renaming it to something else.

/
  applications/
    frontend/
        controllers/
         home.php
            blog.php
            comments.php
     models/
         blog_model.php
         comment_model.php
     views/
         blogs/
             index.php
             view.php
         comment/
             view.php
         index.php

    backend/
     config/
     controllers/
         dashboard.php
            blog.php
            comments.php
     models/
         blog_model.php
         comment_model.php
     views/
         blogs/
             index.php
             form.php
         comment/
             index.php
         dashboard.php
         login.php

  system/

  index.php
  admin/
    index.php

Here you can see I have put index.php into an admin/ folder of its own. Both index.php files will point to a single folder within /applications and this can be done by setting:
index.php
$application_folder = "applications/frontend";
admin/index.php
$application_folder = "applications/backend";
This method does work, but is only really any good for big sites that have very different content for their front and back ends. You cannot use the same libraries, helpers, models, etc which will mean its very easy to end up with duplicated code. I'm not a big fan of such frontend/backend separation as for most sites, an admin panel will use the same models and code but this varies entirely on the spec of the site you are building.

2.) Sub-directories

This method follows a more usual CodeIgniter set-up and is the way that most new CodeIgniter users will try things at first.

/
    application/
        config/
        controllers/
            admin/
                 blog.php
                 dashboard.php
                 comments.php
            blog.php
            comments.php
        models/
            blog_model.php
            comments_model.php
        views/
            admin/
                blog/
                    index.php
                    form.php
                comments/
                    index.php
                    form.php
                dashboard.php
                login.php
            blog/
                index.php
                view.php
            comments/
                view.php
  system/
  index.php

Here we are keeping the default MVC structure of CodeIgniter and using sub-directories for our controllers to give us the http://example.com/admin/blog URL structure. You'll need to set a $route['admin'] = 'admin/dashboard'; to get example.com/admin worksing but thats easy enough.
This method has the advantage of being able to share models, libraries and helpers across both the front and backend. If you really need to separate models for front and back ends, why not just have a models/admin/ folder and put them in there?
The down side is that when your site expands and more controllers are required, it can be a real pain to have your content so loosely linked across the entire application directory. You can see in the example above that we have several folders for blog and comment content, where really we should only have one. This one folder is called a module...

3.) Modules

To keep all the content under one single folder we can adopt the HMVC approach. This stands for Hierarchal MVC which essentially is just modular CodeIgniter. Two systems have been developed for this: HMVC and Matchbox. I personally prefer use the latter but have never tried HMVC so i'll leave that one up to you.
A strange thing that many CodeIgniter users seem to do is create a blog module, comment module and admin module. This strikes me as a very strange separation of content that goes against the point of using modules in the first place! I have a single admin.php controller in the main controllers folder to act as the default admin page which will handle login, logout and the main dashboard. Then I add another admin.php controller in each module and use URI Routing to get my URL structure as http://example.com/admin/.

/
    application/
        config/
        controllers/
             admin.php
        modules/
             blog/
                 controllers/
                     admin.php
                     blog.php
                 models/
                     blog_model.php
                 views/
                     admin/
                         index.php
                         form.php
             comments/
                  controllers/
                      admin.php
                      comments.php
                  models/
                      comment_model.php
                  views/
                     admin/
                         index.php
                         form.php
          views/
              admin/
                  dashboard.php
                  login.php
      system/
      index.php

Right now to get at the blog admin you would have to go to http://example.com/blog/admin which may well be fine with you. If not, you can add the following routes to your application/config/routes.php to swap the segments around and emulate a /admin/ folder.
$route['admin/([a-zA-Z_-]+)/(:any)'] = '$1/admin/$2';
$route['admin/login'] = 'admin/login';
$route['admin/logout'] = 'admin/logout';
$route['admin/([a-zA-Z_-]+)'] = '$1/admin/index';
$route['admin'] = 'admin';
This way you have your admin controllers kept with the frontend controllers, you are sharing models, libraries and helpers and you still have some nice URL's.

Summary

If your front and back end applications share nothing in common and never will do, use method #1. If you have a sma

Authentication with CodeIgniter

Here's how I do some basic authentication for a controller in CodeIgniter. It basically consists of creating a new class that extends the default Controller class. You then sub-class this on any controller that requires authentication.
Create your authentication controller in system/application/libraries and call it MY_Controller.php. It's important that you prefix the controller name with MY_, or whatever you have specified $config['subclass_prefix'] as in your configuration.

<?php

class MY_Controller extends Controller
{
    public function __construct()
    {
        parent::__construct();
        $this->load->library('session');
        if (!$this->session->userdata('loggedin'))
        {
            header('Location: /sessions/login');
        }
    }
}

This basically checks if the session data for loggedin is set to true. If not, it'll redirect the user to the /sessions/login URL. This means we have to create a basic controller to handle the sessions.

<?php

class Sessions extends Controller
{
    public function __construct()
    {
        parent::__construct();
        $this->load->library('session');
    }

    public function login()
    {
        $this->load->view('header');
        $this->load->view('sessions/login');
        $this->load->view('footer');
    }

    public function authenticate()
    {
        $this->load->model('user', '', true);
        if ($this->user->authenticate($this->input->post('username'), $this->input->post('password')))
        {
            $this->session->set_userdata('loggedin', true);
            header('Location: /');
        }
        else
        {
            header('Location: /sessions/login');
        }
    }

    public function logout()
    {
        $this->session->unset_userdata('loggedin');
        header('Location: /');
    }
}

The login view is a basic form with fields for username and password that submits to /sessions/authenticate. This controller then loads the user model and checks that a user with the username and password exists. If so, it sets the session data for loggedin to true and redirects the user back to the default controller. If not, it takes the user back to the login page.
Then to implement the authentication in a controller, simply do:

<?php

class SecretPlace extends MY_Controller
{
...

It's a good idea to store your session data in your database and encrypt your cookies with $config['sess_encrypt_cookie'] = TRUE; in config.php. That way people won't be able to snoop around and try to trick your application into thinking they're authenticated.



forther links are:
http://godbit.com/article/codeigniter-session-class
http://mini-app.peccavi.com/

Differences Between jQuery .bind() vs .live() vs .delegate() vs .on()

Before we dive into the ins and outs of these methods, let's start with some common HTML markup that we'll be using as we write sample jQuery code.

<ul id="members" data-role="listview" data-filter="true">

    <!-- ... more list items ... -->

    <li>

        <a href="detail.html?id=10">

            <h3>John Resig</h3>

            <p><strong>jQuery Core Lead</strong></p>

            <p>Boston, United States</p>

        </a>

    </li>

    <!-- ... more list items ... -->

</ul>

 


Using the Bind Method
The .bind() method registers the type of event and an event
 handler directly to the DOM element in question. This method has been 
around the longest and in its day it was a nice abstraction around the 
various cross-browser issues that existed. This method is still very 
handy when wiring-up event handlers, but there are various performance 
concerns as are listed below.





        
          


              


/* The .bind() method attaches the event handler directly to the DOM 

   element in question ( "#members li a" ). The .click() method is 

   just a shorthand way to write the .bind() method. */




$( "#members li a" ).bind( "click", function( e ) {} ); 

$( "#members li a" ).click( function( e ) {} ); 

 

The .bind() method will attach the event handler to all of 
the anchors that are matched! That is not good. Not only is that 
expensive to implicitly iterate over all of those items to attach an 
event handler, but it is also wasteful since it is the same event 
handler over and over again.



Pros


This methods works across various browser implementations.
It is pretty easy and quick to wire-up event handlers.
The shorthand methods (.click(), .hover(), etc...) make it even easier to wire-up event handlers.
For a simple ID selector, using .bind() not only wires-up quickly, but also when the event fires the event handler is invoked almost immediately.

Cons


The method attaches the same event handler to every matched element in the selection.
It doesn't work for elements added dynamically that matches the same selector.
There are performance concerns when dealing with a large selection.
The attachment is done upfront which can have performance issues on page load.


Using the Live Method
The .live() method uses the concept of event delegation to perform its so called "magic". The way you call .live() looks just like how you might call .bind(), which is very convenient. However, under the covers this method works much different. The .live
 method attaches the event handler to the root level document along with
 the associated selector and event information. By registering this 
information on the document it allows one event handler to be used for 
all events that have bubbled (a.k.a. delegated, propagated) up to it. 
Once an event has bubbled up to the document jQuery looks at the 
selector/event metadata to determine which handler it should invoke, if 
any. This extra work has some impact on performance at the point of user
 interaction, but the initial register process is fairly speedy. 





        
          


              


/* The .live() method attaches the event handler to the root level 

   document along with the associated selector and event information 

   ( "#members li a" & "click" ) */ 




$( "#members li a" ).live( "click", function( e ) {} );

 

The good thing about this code as compared to the .bind() 
example above is that it is only attaching the event handler once to the
 document instead of multiple times. This not only is faster, but less 
wasteful, however, there are many problems with using this method and 
they are outlined below.



Pros


There is only one event handler registered instead of the numerous event handlers that could have been registered with the .bind() method.
The upgrade path from .bind() to .live() is very small. All you have to do is replace "bind" to "live".
Elements dynamically added to the DOM that match the selector 
magically work because the real information was registered on the 
document.
You can wire-up event handlers before the document ready event helping you utilize possibly unused time.

Cons


This method is deprecated as of jQuery 1.7 and you should start phasing out its use in your code.
Chaining is not properly supported using this method.
The selection that is made is basically thrown away since it is only used to register the event handler on the document.
Using event.stopPropagation() is no longer helpful because the event has already delegated all the way up to the document.
Since all selector/event information is attached to the document 
once an event does occur jQuery has match through its large metadata 
store using the matchesSelector method to determine which event handler to invoke, if any.
Your events always delegate all the way up to the document. This can affect performance if your DOM is deep.


Using the Delegate Method
The .delegate() method behaves in a similar fashion to the .live()
 method, but instead of attaching the selector/event information to the 
document, you can choose where it is anchored. Just like the .live() method, this technique uses event delegation to work correctly. 




If you skipped over the explanation of the .live() method you might want to go back up and read it as I described some of the internal logic that happen.


              


/* The .delegate() method behaves in a similar fashion to the .live() 

   method, but instead of attaching the event handler to the document, 

   you can choose where it is anchored ( "#members" ). The selector 

   and event information ( "li a" & "click" ) will be attached to the 

   "#members" element. */




$( "#members" ).delegate( "li a", "click", function( e ) {} );


The .delegate() method is very powerful. The above code 
will attach the event handler to the unordered list ("#members") along 
with the selector/event information. This is much more efficient than 
the .live() method that always attaches the information to 
the document. In addition a lot of other problematic issues were 
resolved by introducing the .delegate() method. See the following outline for a detailed list.



Pros


You have the option of choosing where to attach the selector/event information.
The selection isn't actually performed up front, but is only used to register onto the root element.
Chaining is supported correctly.
jQuery still needs to iterate over the selector/event data to 
determine a match, but since you can choose where the root is the amount
 of data to sort through can be much smaller.
Since this technique uses event delegation, it can work with dynamically added elements to the DOM where the selectors match.
As long as you delegate against the document you can also wire-up event handlers before the document ready event.

Cons


Changing from a .bind() to a .delegate() method isn't as straight forward.
There is still the concern of jQuery having to figure out, using the matchesSelector
 method, which event handler to invoke based on the selector/event 
information stored at the root element. However, the metadata stored at 
the root element should be considerably smaller compared to using the .live() method.


Using the On Method
Did you know that the jQuery .bind(), .live(), and .delegate() methods are just one line pass throughs to the new jQuery 1.7 .on() method? The same is true of the .unbind(), .die(), and .undelegate() methods. The following code snippet is taken from the jQuery 1.7.1 

 





bind: function( types, data, fn ) {

    return this.on( types, null, data, fn );

},

unbind: function( types, fn ) {

    return this.off( types, null, fn );

},




live: function( types, data, fn ) {

    jQuery( this.context ).on( types, this.selector, data, fn );

    return this;

},

die: function( types, fn ) {

    jQuery( this.context ).off( types, this.selector || "**", fn );

    return this;

},




delegate: function( selector, types, data, fn ) {

    return this.on( types, selector, data, fn );

},

undelegate: function( selector, types, fn ) {

    return arguments.length == 1 ? 

        this.off( selector, "**" ) : 

        this.off( types, selector, fn );

},

With that in mind, the usage of the new .on() method looks something like the following...





        
          


              


/* The jQuery .bind(), .live(), and .delegate() methods are just one 

   line pass throughs to the new jQuery 1.7 .on() method */




// Bind

$( "#members li a" ).on( "click", function( e ) {} ); 

$( "#members li a" ).bind( "click", function( e ) {} ); 




// Live

$( document ).on( "click", "#members li a", function( e ) {} ); 

$( "#members li a" ).live( "click", function( e ) {} );




// Delegate

$( "#members" ).on( "click", "li a", function( e ) {} ); 

$( "#members" ).delegate( "li a", "click", function( e ) {} );


You'll notice that depending how I call the .on() method changes how it performs. You can consider the .on() method as being "overloaded" with different signatures, which in turn changes how the event binding is wired-up. The .on method bring a lot of consistency to the API and hopefully makes things slightly less confusing.



Pros


Brings uniformity to the various event binding methods.
Simplifies the jQuery code base and removes one level of redirection since the .bind(), .live(), and .delegate() call this method under the covers.
Still provides all the goodness of the .delegate() method, while still providing support for the .bind() method if you need it.

Cons


Brings confusion because the behavior changes based on how you call the method.


Conclusion (tl;dr)
If you have been confused about the various different types of event 
binding methods then don't worry, there has been a lot of history and 
evolvement in the API over time. There are many people that view these 
methods as magic, but once you uncover some of how they work it will 
help you understand how to better ode inside of your projects. 



The biggest take aways from this article are that...


Using the .bind() method is very costly as it attaches the same event handler to every item matched in your selector.
You should stop using the .live() method as it is deprecated and has a lot of problems with it.
The .delegate() method gives a lot of "bang for your buck" when dealing with performance and reacting to dynamically added elements.
That the new .on() method is mostly syntax sugar that can mimic .bind(), .live(), or .delegate() depending on how you call it. 


The new direction is to use the new .on method. Get familiar with the syntax and start using it on all your jQuery 1.7+ projects.

Were there any pros or cons that you would have added to the above lists? Have you found yourself using the .delegate method more recently? What are you thoughts on the new .on method? Leave your thoughts in the comments. Thanks!


          


 
 



 



 

Wamp not working on a LAN

Well this is very often in windows environment that wamp server works fine on local machine, but it does not on a LAN when accessed using the IP. Following could be the reasons

1. You are typing a wrong IP address, just check the IP of the machine on which wamp is installed by firing ipconfig command on command line

2. Your wamp server is offline. It should be put online

3. Your windows Firewall is on. In this case just go to Control Panel-->Windows firewall and put it off.

t

Creating a Strong password having character,letter,speical symbol 1 each

$pwd = "Vijay((#@!99321";

if( strlen($pwd) < 8 ) {
 $error .= "Password too short! <br />";
}

if( strlen($pwd) > 20 ) {
 $error .= "Password too long! <br />";
}

if( strlen($pwd) < 8 ) {
 $error .= "Password too short! <br />";
}

if( !preg_match("#[0-9]+#", $pwd) ) {
 $error .= "Password must include at least one number! <br />";
}


if( !preg_match("#[a-z]+#", $pwd) ) {
 $error .= "Password must include at least one letter! <br />";
}


if( !preg_match("#[A-Z]+#", $pwd) ) {
 $error .= "Password must include at least one CAPS! <br />";
}



if( !preg_match("#\W+#", $pwd) ) {
 $error .= "Password must include at least one symbol! <br />";
}


if($error){
 echo "Password validation failure(your choise is weak): $error";
} else {
 echo "Your password is strong.";
}

Putting all together:

$pwd = "Vijay((#@!99321";

if (preg_match("#.*^(?=.{8,20})(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*\W).*$#", $pwd)){
    echo "Your password is strong.";
} else {
    echo "Your password is not safe.";
} 

Password with number,letter,caps:

$pwd = "Vijay99321";

 if (preg_match("#.*^(?=.{8,20})(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9]).*$#", $pwd)){
    echo "Your password is good.";
} else {
    echo "Your password is bad.";
} 

How to Impliment the Htaccess in your site...

At first before start proceedings we must know what is ht-access file and why we should use that one?

Basic Definition:
.htaccess files are configuration files of Apache Server which provide a way to make configuration changes on a per-directory basis. A file containing one or more configuration directives is placed in a particular document directory and the directives apply to that directory and all sub directories thereof.

per-directory basis: this means we have to put a ht-access file each directory of our web.

Example:
suppose we have 2 directories in our website like 

http://oms-vision.blogspot.in/(Parent Directory )
http://oms-vision.blogspot.in/admin(Child Directory)

the first one contains the files for http://oms-vision.blogspot.in/ and the second on contains its admin account files.now if we put a htaccess file in parent directory by having some rules

RewriteEngine On

order allow,deny
allow from all
RewriteRule  ^([a-zA-Z0-9_-]+)/$  index.php?action=$1  [NC]
RewriteRule  ^([a-zA-Z0-9_-]+)$  index.php?action=$1  [NC]
RewriteRule  ^([a-zA-Z0-9_-]+)/([a-zA-Z0-9_-]+)/$  index.php?action=$1&id=$2  [NC]
RewriteRule  ^([a-zA-Z0-9_-]+)/([a-zA-Z0-9_-]+)$  index.php?action=$1&id=$2  [NC]
 

 then the same rules will be applied to its child directories also. 
now if u don't want to have any htaccess rules in child directory then u have to put another .htaccess file in child directory having rule


RewriteEngine Off


 
 

How To Enable mod_rewrite In LAMP- Ubuntu Linux

• give permissions to the /var/www/ directory

           sudo chown -R $USER:$USER /var/www/

•  Install the Apache module mod_rewrite

           a2enmod rewrite

• Chnage the directory and keep the back up of the file “000-default”

          cd /etc/apache2/sites-enabled/
         sudo cp  000-default 000-default1

• Edit the file 000-default

          sudo vi 000-default
          Look for the below given code
          Options Indexes FollowSymLinks MultiViews
          AllowOverride none
          Order allow,deny
          allow from all
          Modify “AllowOverride none” to “AllowOverride All”

• Restart Apache

         sudo /etc/init.d/apache2 restart