This is a placeholder for further information on a javascript problem I know I’m going to have to figure out in the near future.  Internet Explorers 6 and 7 (is there ever another browser that gives me problems?) throw the somewhat cryptic “can’t execute code from a freed script” when loading a page that I’ve recently added some ecma script to.  I’m just getting back into DOM scripting after a while away from messing with it, and am definitely rusty.  Still, my understanding of the error message is that it is roughly speaking a matter of scope of code, and that code loaded for one window or frame will have been freed from memory and will not be available when in other windows or frames.  This doesn’t seem to apply with the scripting I’m doing.  I’m dealing with only one window and no frames so I need to find more out about what the error really means.  If you know, please comment and let me know.  If you want to know, please watch this space for updates.  (If you leave a comment, you can receive notifications when new comments are added)

UPDATE:  FIXED!  About 10 minutes after posting this I found the bizarre (to me, maybe someone can explain it) solution for this problem.  It was as simple as moving any meta tags before the script tags in the head element of the html document.  <script><meta> = heartache <meta><script> = salvation.

This is very simple artical for submit HTML form data without refreshing page with the help of JQuery and Ajax.
jQuery provides a rich set of methods for AJAX web development.
With jQuery AJAX, you can request TXT, HTML, XML or JSON data from a remote server using both HTTP Get and HTTP Post.

$.ajax(options) is the syntax of the low level AJAX function.
$.ajax offers more functionality than higher level functions like load, get, and post.
The option parameter takes name|value pairs defining url data, passwords, data types, filters, character sets, timeout and error functions.

Below is code for HTML form.
<form method="post" name="form">
<li><input id="name" name="name" type="text" /></li>
<li><input id="username" name="username" type="text" /></li>
<li><input id="password" name="password" type="password" /></li>
<li><select id="gender" name="gender">
<option value="">Gender</option>
<option value="1">Male</option>
<option value="2">Female</option>
<div >
<input type="submit" value="Submit" class="submit"/>
<span class="error" style="display:none"> Please Enter Valid Data</span>
<span class="success" style="display:none"> Registration Successfully</span>

Javascript code for jquery ajax form submit

<script type="text/javascript" src=""></script>
<script type="text/javascript" >
$(function() {
$(".submit").click(function() {
var name = $("#name").val();
var username = $("#username").val();
var password = $("#password").val();
var gender = $("#gender").val();
var dataString = 'name='+ name + '&username=' + username + '&password=' + password + '&gender=' + gender;

if(name=='' || username=='' || password=='' || gender=='')
type: "POST",
url: "result.php",
data: dataString,
success: function(){

return false;

My PHP files all display a 500 Internal server error. How can I fix this?
If you are running a PHP-based script on your site and are receiving a 500 and/or 404 errors on your pages, it is likely you have one or more of the following occurring:
1. You are attempting to access PHP files through the temp-URL PHP on our servers requires a fully qualified domain name. You may wait until your domain has been pointed and resolves here or you may email to request a primary domain change to a free subdomain of lunarpages to test your files.
2. The permissions on some of the folders or files are 777 or 666. If this is the case, change them to either 755 or 644 in Cpanel's File Manager (or using your local FTP client).
3. The files and/or folders are not owned by you. Certain applications having been run under php as an apache module may have files owned by the apache user of nobody. An indication that you don't own the files would be if you are unable to change their file permissions. To correct this, please contact support provide your username and the last 4 digits of your credit card on file with us for ownership verification (no charges apply) and provide the location of the folder or files that need to have your ownership.
4. Your .htaccess file has php_values or php_flags in it. This causes a 500 Internal server error when attempting to execute the script.
The php_values and php_flags will need to be removed from your .htaccess file (please make a backup of the .htaccess by copying its contents and saving it on your desktop as htaccess.txt). Take the contents removed from .htaccess and place it into a file you create called php.ini. Remember to remove the php_flag and php_value part before the directives as php.ini files do not require those in front of the values. You can always make the changes and ask us if the changed files are correct.
Because php.ini values are not shared across directories, you would need a separate php.ini file in each folder that has .htaccess or that requires the php_values or php_flags. In order to avoid doing this, you can place a line in the .htaccess file in your public_html folder to have all values in your public_html php.ini to be shared across all folder. This line would be the following:
suPHP_ConfigPath /home/username/public_html
Finally, to explain in depth why suPHP requires these changes to the file permissions, please note that suPHP runs scripts with the permissions of their owners. Regular PHP executes scripts under the permissions of the system user running the web server, which means that your script runs with different permissions than your own user account and makes it very hard to use a PHP script to modify and create files without giving everyone on the server access to your files (this means that on regular PHP you provide write or execute access to group and world even for some files). Since SuPHP makes your PHP scripts run with the same permissions as your regular user account, you do not need group or world write access or execute access for files and suPHP will even prevent files from running that are group or world writable or executable as a security precaution.
666 equals the following:
Mode User Group World
Read 4 4 4 (all checked)
Write 2 2 2 (all checked)
Execute(none checked)
This makes group and world able to write to the file, a security risk
777 equals the following:
Mode User Group World
Read 4 4 4 (all checked)
Write 2 2 2 (all checked)
Execute 1 1 1 (all checked)
This makes group and world able to write and execute the file, a very large security risk.
Basically, suPHP is more secure, and preventing scripts from running as 666 or 777 prevents group or world from maliciously writing to the files and hacking your scripts.

To change the admin side font and any style include the following code in function.php of your theme

<style type="text/css">

body {

font-family: verdana !important;

 font-size: 13px !important;



So you want to add a custom Role to your WordPress site to add more flexibility when assigning users their role, what do you do? Simply add a role, with a few lines of code in your theme’s functions.php file, using WordPress’ add_role() function, as defined below.

add_role( $role_name, $display_name, $capabilities );

The example below adds a role of Video Manager with a custom cabability of ‘manage videos’.

add_role( 'video_manager, 'Video Manager', array( 'manage_videos' ) );

NOTE: Once you add this code to your functions.php file and view any page on your site to make the role addition, you can and should comment it out so that it doesn’t run on every page view.

Now, how do we use this new role with the new capability you ask? Simply use the WordPress current_user_can() function to check the user’s capability.

if ( current_user_can( 'manage_videos' ) ) {
// let them manage those videos!

WordPress Plugin: A WordPress Plugin is a program, or a set of one or more functions, written in the PHP scripting language, that adds a specific set of features or services to the WordPress weblog, which can be seamlessly integrated with the weblog using access points and methods provided by the WordPress Plugin Application Program Interface (API).

Creating a Plugin

This section of the article goes through the steps you need to follow, and things to consider when creating a well-structured WordPress Plugin.
Names, Files, and Locations
Plugin Name

The first task in creating a WordPress Plugin is to think about what the Plugin will do, and make a (hopefully unique) name for your Plugin. Check out Plugins and the other repositories it refers to, to verify that your name is unique; you might also do a Google search on your proposed name. Most Plugin developers choose to use names that somewhat describe what the Plugin does; for instance, a weather-related Plugin would probably have the word "weather" in the name. The name can be multiple words.
Plugin Files

The next step is to create a PHP file with a name derived from your chosen Plugin name. For instance, if your Plugin will be called "Fabulous Functionality", you might call your PHP file fabfunc.php. Again, try to choose a unique name. People who install your Plugin will be putting this PHP file into the WordPress Plugin directory in their installation, wp-content/plugins/, so no two Plugins they are using can have the same PHP file name.

Another option is to split your Plugin into multiple files. Your WordPress Plugin must have at least one PHP file; it could also contain JavaScript files, CSS files, image files, language files, etc. If there are multiple files, pick a unique name for a file directory and for the main PHP file, such as fabfunc and fabfunc.php in this example, put all your Plugin's files into that directory, and tell your Plugin users to install the whole directory under wp-content/plugins/. However, an installation can be configured for wp-content/plugins to be moved, so you must use plugin_dir_path() and plugins_url() for absolute paths and URLs. See: for more details.

In the rest of this article, "the Plugin PHP file" refers to the main Plugin PHP file, whether in wp-content/plugins/ or a sub-directory.
Readme File

If you want to host your Plugin on, you also need to create a readme.txt file in a standard format, and include it with your Plugin. See for a description of the format.

Note that the WordPress plugin repository takes the "Requires" and "Tested up to" versions from the readme.txt in the stable tag.
Home Page

It is also very useful to create a web page to act as the home page for your WordPress Plugin. This page should describe how to install the Plugin, what it does, what versions of WordPress it is compatible with, what has changed from version to version of your Plugin, and how to use the Plugin.
File Headers

Now it's time to put some information into your main Plugin PHP file.
Standard Plugin Information

The top of your Plugin's main PHP file must contain a standard Plugin information header. This header lets WordPress recognize that your Plugin exists, add it to the Plugin management screen so it can be activated, load it, and run its functions; without the header, your Plugin will never be activated and will never run. Here is the header format:

The minimum information WordPress needs to recognize your Plugin is the Plugin Name line. The rest of the information (if present) will be used to create the table of Plugins on the Plugin management screen. The order of the lines is not important.

The License slug should be a short common identifier for the license the plugin is under and is meant to be a simple way of being explicit about the license of the code.

Important: file must be in UTF-8 encoding.

It is customary to follow the standard header with information about licensing for the Plugin. Most Plugins use the GPL2 license used by WordPress or a license compatible with the GPL2. To indicate a GPL2 license, include the following lines in your Plugin:

Programming Your Plugin

Now, it's time to make your Plugin actually do something. This section contains some general ideas about Plugin development, and describes how to accomplish several tasks your Plugin will need to do.
WordPress Plugin Hooks

Many WordPress Plugins accomplish their goals by connecting to one or more WordPress Plugin "hooks". The way Plugin hooks work is that at various times while WordPress is running, WordPress checks to see if any Plugins have registered functions to run at that time, and if so, the functions are run. These functions modify the default behavior of WordPress.

For instance, before WordPress adds the title of a post to browser output, it first checks to see if any Plugin has registered a function for the "filter" hook called "the_title". If so, the title text is passed in turn through each registered function, and the final result is what is printed. So, if your Plugin needs to add some information to the printed title, it can register a "the_title" filter function.

Another example is the "action" hook called "wp_footer". Just before the end of the HTML page WordPress is generating, it checks to see whether any Plugins have registered functions for the "wp_footer" action hook, and runs them in turn.

You can learn more about how to register functions for both filter and action hooks, and what Plugin hooks are available in WordPress, in the Plugin API. If you find a spot in the WordPress code where you'd like to have an action or filter, but WordPress doesn't have one, you can also suggest new hooks (suggestions will generally be taken); see Reporting Bugs to find out how.
Template Tags

Another way for a WordPress Plugin to add functionality to WordPress is by creating custom Template Tags. Someone who wants to use your Plugin can add these "tags" to their theme, in the sidebar, post content section, or wherever it is appropriate. For instance, a Plugin that adds geographical tags to posts might define a template tag function called geotag_list_states() for the sidebar, which lists all the states posts are tagged with, with links to the state-based archive pages the Plugin enables.

To define a custom template tag, simply write a PHP function and document it for Plugin users on your Plugin's home page and/or in the Plugin's main PHP file. It's a good idea when documenting the function to give an example of exactly what needs to be added to the theme file to use the function, including the .
Saving Plugin Data to the Database

Most WordPress Plugins will need to get some input from the site owner or blog users and save it between sessions, for use in its filter functions, action functions, and template functions. This information has to be saved in the WordPress database, in order to be persistent between sessions. There are three methods for saving Plugin data in the database:

Use the WordPress "option" mechanism (described below). This method is appropriate for storing relatively small amounts of relatively static, named pieces of data -- the type of data you'd expect the site owner to enter when first setting up the Plugin, and rarely change thereafter.
Post Meta (a.k.a. Custom Fields). Appropriate for data associated with individual posts, pages, or attachments. See post_meta Function Examples, add_post_meta(), and related functions.
Create a new, custom database table. This method is appropriate for data not associated with individual posts, pages, attachments, or comments -- the type of data that will grow as time goes on, and that doesn't have individual names. See Creating Tables with Plugins for information on how to do this.

WordPress Options Mechanism

See Creating Options Pages for info on how to create a page that will automatically save your options for you.

WordPress has a mechanism for saving, updating, and retrieving individual, named pieces of data ("options") in the WordPress database. Option values can be strings, arrays, or PHP objects (they will be "serialized", or converted to a string, before storage, and unserialized when retrieved). Option names are strings, and they must be unique, so that they do not conflict with either WordPress or other Plugins.

Here are the main functions your Plugin can use to access WordPress options.

add_option($name, $value, $deprecated, $autoload);

Creates a new option; does nothing if option already exists.
Required (string). Name of the option to be added.
Optional (mixed), defaults to empty string. The option value to be stored.
Optional (string), no longer used by WordPress, You may pass an empty string or null to this argument if you wish to use the following $autoload parameter.
Optional, defaults to 'yes' (enum: 'yes' or 'no'). If set to 'yes' the setting is automatically retrieved by the wp_load_alloptions function.


Retrieves an option value from the database.
Required (string). Name of the option whose value you want returned. You can find a list of the default options that are installed with WordPress at the Option Reference.

update_option($option_name, $newvalue);

Updates or creates an option value in the database (note that add_option does not have to be called if you do not want to use the $deprecated or $autoload parameters).
Required (string). Name of the option to update.
Required. (string|array|object) The new value for the option.

Administration Panels

Assuming that your Plugin has some options stored in the WordPress database (see section above), you will probably want it to have an administration panel that will enable your Plugin users to view and edit option values. The methods for doing this are described in Adding Administration Menus.
Internationalizing Your Plugin

Once you have the programming for your Plugin done, another consideration (assuming you are planning on distributing your Plugin) is internationalization. Internationalization is the process of setting up software so that it can be localized; localization is the process of translating text displayed by the software into different languages. WordPress is used all around the world, so it has internationalization and localization built into its structure, including localization of Plugins.

Please note that language files for Plugins ARE NOT automatically loaded. Add this to the Plugin code to make sure the language file(s) are loaded:

load_plugin_textdomain('your-unique-name', false, basename( dirname( __FILE__ ) ) . '/languages' );

To fetch a string simply use __('String name','your-unique-name'); to return the translation or _e('String name','your-unique-name'); to echo the translation. Translations will then go into your plugin's /languages folder.

It is highly recommended that you internationalize your Plugin, so that users from different countries can localize it. There is a comprehensive reference on internationalization, including a section describing how to internationalize your plugin, at I18n for WordPress Developers.
Plugin Development Suggestions

This last section contains some random suggestions regarding Plugin development.

The code of a WordPress Plugin should follow the WordPress Coding Standards. Please consider the Inline Documentation Standards as well.
All the functions in your Plugin need to have unique names that are different from functions in the WordPress core, other Plugins, and themes. For that reason, it is a good idea to use a unique function name prefix on all of your Plugin's functions. A far superior possibility is to define your Plugin functions inside a class (which also needs to have a unique name).
Do not hardcode the WordPress database table prefix (usually "wp_") into your Plugins. Be sure to use the $wpdb->prefix variable instead.
Database reading is cheap, but writing is expensive. Databases are exceptionally good at fetching data and giving it to you, and these operations are (usually) lightning quick. Making changes to the database, though, is a more complex process, and computationally more expensive. As a result, try to minimize the amount of writing you do to the database. Get everything prepared in your code first, so that you can make only those write operations that you need.
SELECT only what you need. Even though databases fetch data blindingly fast, you should still try to reduce the load on the database by only selecting that data which you need to use. If you need to count the number of rows in a table don't SELECT * FROM, because all the data in all the rows will be pulled, wasting memory. Likewise, if you only need the post_id and the post_author in your Plugin, then just SELECT those specific fields, to minimize database load. Remember: hundreds of other processes may be hitting the database at the same time. The database and server each have only so many resources to spread around amongst all those processes. Learning how to minimize your Plugin's hit against the database will ensure that your Plugin isn't the one that is blamed for abuse of resources.
Eliminate PHP errors in your plugin. Add define('WP_DEBUG', true); to your wp-config.php file, try all of your plugin functionality, and check to see if there are any errors or warnings. Fix any that occur, and continue in debug mode until they have all been eliminated.
Try not to echo

<script> and <style> tags directly - instead use the recommended wp_enqueue_style() and wp_enqueue_script() functions. They help eliminate including duplicate scripts and styles as well as introduce dependency support. See posts by the following people for more info: Ozh Richard, Artem Russakovskii, and Vladimir Prelovac.

Reference : <a href=""></a>

Following code will retrieve all file names from a specified folder.

$filePath = "/var/www/public_html/mysite/images";/* Enter path to the folder */




$dir = opendir($filePath);

while ($file = readdir($dir)) {

if (eregi("\.png",$file)) { /* Look for files with .png extension */

$string .= "$file




if ($fileCount > 0) {

echo sprintf("
All Files in %s></h2>

%sTotal Files: %s",$filePath,$string,$fileCount);