Open Source Scripts

Written by Sanjib Ahmad

Commercial web application systems used to be expensive at one time. Withrepparttar advent of open source solutions such applications are not only available for free but in many cases they are superior to commercial systems.

Now anyone can have access to advanced systems and scripts such as content management systems, forums, auction scripts, ecommerce systems, shopping carts, photgallery applications and more. Some example scripts are provided below.

Content Management Systems * Drupal * Mambo Open Source * PHPNuke * PostNuke * XOOPS

E-Commerce Systems * OsCommerce

Image Gallery Scripts * Image Gallery

Message Forums * phpBB2

Blogs * Wordpress

You can installrepparttar 144294 scripts yourself on your webserver. You will need to downloadrepparttar 144295 script fromrepparttar 144296 original source site. Unziprepparttar 144297 source files and followrepparttar 144298 installation steps. The installation steps are usually easy as long asrepparttar 144299 basic requirements are working currectly in your system. Basic requirements can include database (for example: MySQL), web server (for example: Apache) and programming language parser (for example: PHP).

ASP, CGI and PHP Scripts and Record-Locking: What Every Webmaster Needs To Know

Written by Sunil Tanna

Many of us install server-side (ASP, CGI or PHP) scripts on our web sites, and many of this scripts store data onrepparttar server. However, poorly designed scripts can experience performance problems and sometimes even data corruption on busy (and not so busy) web sites.

If you're not a programmer, why should this matter to you?

Answer: Even if you're just installing and using server-side scripts, you'll want to make sure thatrepparttar 143660 scripts that you choose don't randomly break or corrupt your data.

First, some examples ofrepparttar 143661 types of scripts which store data on web servers include:

(Of course, many scripts in each of these (and other) categories are well-designed, and run perfectly well even on very busy web sites).

1. Follow-up autoresponders typically storerepparttar 143662 list of subscribers torepparttar 143663 autoresponder, as well where inrepparttar 143664 sequence of messages, each subscriber is. Examples of autoresponder scripts:

2. Classified ad scripts store (at least) a list of allrepparttar 143665 classified ads placed by visitors. Examples of this type of script:

3. Free for all links scripts store a list of all links posted by visitors. See some example scripts listed at:

4. Top site scripts usually store a list ofrepparttar 143666 members ofrepparttar 143667 top site as well as information aboutrepparttar 143668 number of "votes" that each has received. For examples of this type of script, see

So what kind of scripts have problems? And what sort of problems am I talking about?

Wellrepparttar 143669 principle problems all relate to what happens when bits of data from multiple users needs to be stored on updated atrepparttar 143670 same time. Some scripts handle these situations well, but others don't...


Here's a common data corruption problem that can occur with many scripts:

1. When some bit of data needs to be updated, a copy ofrepparttar 143671 server-side script starts running, and then starts updating it.

2. If another user comes along and does an update beforerepparttar 143672 first copy ofrepparttar 143673 script has finished, a second copy ofrepparttar 143674 script starts running atrepparttar 143675 same time.

3. There are a number of ways things can now go wrong, for example:

(a) What ifrepparttar 143676 first copy ofrepparttar 143677 script reads inrepparttar 143678 data, thenrepparttar 143679 second copy readsrepparttar 143680 same data, thenrepparttar 143681 first copy updatesrepparttar 143682 data, thenrepparttar 143683 second copy updatesrepparttar 143684 data? Answer: any changes made byrepparttar 143685 first copy ofrepparttar 143686 script can get lost.

(b) What ifrepparttar 143687 first and second copy of scripts are both adding multiple bits of new data torepparttar 143688 store atrepparttar 143689 same time? For example, imagine each needs to storerepparttar 143690 headline, description andrepparttar 143691 name ofrepparttar 143692 person posting a classified ad. Well, what can happen (with some scripts) isrepparttar 143693 two classified ads can get intermingled, so you might get (for example) HEADLINE-1, DESCRIPTION-1, HEADLINE-2, PERSON-1, DESCRIPTION-2, PERSON-2. Or worse yet, you might get bits of each part of each classified ad, mixed withrepparttar 143694 bits ofrepparttar 143695 other. This type of thing is usually really bad news, as your data may consequently becoming unusable from that point on.

Does this sound too unlikely a problem to worry about? Don't bank on it... even if it happens only 1 time in 1,000, or 1 in 10,000, eventually it will happen: You need a solution.

Sorepparttar 143696 real question is: is it possible for programmers to create scripts without these kinds of problems? Fortunatelyrepparttar 143697 answer is yes, and there are a number of ways that programmers can address it:

1. They can store each bit of data in a separate file. This isn't necessarily a total solution by itself (in particular, a script which just does this could still have problems if multiple copies of a script updaterepparttar 143698 same file atrepparttar 143699 same time), but it does make data corruption less likely, and if corruption does occur, at least it won't corruptrepparttar 143700 entire data store in one go.

2. They can use file-locking. This means that if one copy of a script is working with a file, another copy ofrepparttar 143701 script is prevented from working on that file, untilrepparttar 143702 first copy has finished. File-locking works if done correctly, but programming it into a script needs to be done very carefully and precisely, for every single possible case... even a tiny bug or omission can allowrepparttar 143703 possibility of data-corruption in throughrepparttar 143704 backdoor!

3. They can use a database (such as MySQL) to storerepparttar 143705 data. Providedrepparttar 143706 data is properly structured inrepparttar 143707 database,repparttar 143708 database handlesrepparttar 143709 locking automatically. And, asrepparttar 143710 programmer doesn't have to write their own special locking routines,repparttar 143711 possibility of bugs and omissions are much reduced.

Cont'd on page 2 ==> © 2005
Terms of Use