You can always use the EADB (EasyAuction DB) from everysoft, instead of the auction.pl script I provided. It is a MySQL version of EveryAuction, but I have not tested it myself.

There are other auction scripts for vBulletin, but they are all paid hacks, and are quite expensive. The idea behind this one was to have an easy setup and interface with vBulletin, without the cost, etc.. The perl script I provided is less than 100 kb, but it is powerful, and only displays a few kb at a time, depending on what you are calling up in the script, so it is not very server intensive or bandwidth hungry. Also, all known security holes have been plugged in the script I provided, and I am not sure the same is true for a stock install of EADB (or the commercial auction scripts for vbulletin). I am not implying that any of those are insecure - I just don't have any hands-on experience with them. Security is number one with me, especially when it comes to things like this. I have personally made sure that all known security holes are plugged (such as high bidders being able to see the personal info about sellers at an auction end, even if the reserve was not met, etc.. ), and will continue to develop the script in that direction as needed.

Can mods edit/delete certain auctions by members? and is the personal info easy to obtain if you are a regular member?

The auction is not tied in to vbulletin database in any way, so only the admin of the auction (anyone with the admin password defined in the script) or anyone with access to the cgi-bin directory via ftp account can see any personal info or delete any auctions. You can give the admin password to anyone you trust, I suppose. The auction and registration data are stored as text files, that are not encrypted, and they can easily be read or edited by an auction admin or anyone with access to your server, so make sure that your server is secure. If you move the auction directory outside of the cgi-bin directory then make sure it is in a secure place that requires login, such as your forum directory, and also place a blank index.html file in there so nobody can browse that directory from the outside (this is not necessary in the cgi-bin folder since all servers should block that ability). It is also a good security measure to change the name of the auction reg and data folders, and admin.pl script to another name - just change the reference to them in the config area so the script knows where to go and what to do where :D

I don't want to have any perl scripts on my website.. vB is written in PHP and I don't feel like I want to mix it up with some Perl script :)

Then feel free to buy a commercial script, or develop one of your own, or wait until a free one comes along here. This script is what it is, and I can't make it what it isn't.

But, before you make decisions like that you should ask youself why you feel that way. PHP is great for what it is, and so is plain old HTML, and so is perl. They all can do things well, and they all do things their own way, and they can all work well together.

I don't want this to turn in to a PERL-bashing thread, and I am not biased either way- they both work well at what they do. Both PHP and Perl (as applied to Web applications) are interpreted languages. Interpreted languages are not pre-compiled and executed in a binary format, rather, they are parsed by an interpreter on demand and compiled on-the-fly. Because of this, both Perl and PHP are very portable. Both languages can run on any platform that has an interpreter for the language (with subtle difference here and there).

Perl (Practical Extraction and Report Language) borrows features from C, shell scripting (sh), awk, sed, and many other programming languages, including HTML and javascript. Perl is a general-purpose programming language originally developed for text manipulation and now used for a wide range of tasks including system administration, web development, network programming, GUI development, and more. The language is intended to be practical, and its major features are that it's easy to use, supports both procedural and object-oriented programming, has powerful built-in support for text processing. Perl is not only a Web-scripting language, and looking at is as such only shows a microcosm of its true nature. Perl is, at its most basic level, a text-manipulation language. It provides powerful features that allow the user to easily do some operations that are very complex in C, and also complicates some other things that are easy in C! Perl, in conjunction with CPAN (the Comprehensive Perl Archive Network) offer an enormous amount of "ready-made" modules, that allow code to be reused and shared- database interface modules, CORBA modules, scientific calculation modules, network programming modules, SGML/XML/HTML modules, and so much more. Obviously, because of Perl's powerful and easy text manipulation functions, it was quite natural for web developers to expand their toolbelt to include Perl. Perl can be embedded within HTML documents, run as an SSI (Server-Side Include), or run as its own application (CGI, or Common Gateway Interface). Perl, as applied to CGI and web application design, is designed for the programmer who wants to "output" webpages. A Perl Web application is nothing more or less than a backend program, that interacts with the browser using HTML. Perl's infinite extensibility and modular design make it incredibly popular among web application developers who want a single program (usually with a horde of included modules), or a couple programs, to be their application instead of the several hundred HTML pages (or vbulletin templates) that the same application might require if it was done in PHP.

PHP is an embedded scripting language. A PHP-aware webserver parses HTML documents looking for PHP code, processes it, and sends the results back to the browser. In effect, PHP separates web design from application design. PHP is developed with the web, and web development in mind.

Also- PHP It is not a general purpose language. While it has many facilities specifically catered towards web programming, it is not Perl (or C or C++ or Java). PHP probably cannot beat Perl in terms of convenient and efficient text crunching. Perl is designed with crunching text in mind and has facilities for handling strings and the like that put most other languages to shame. However, PHP does have adequate facilities for most web purposes.

PHP and Perl are both powerful languages that can make web application programming, automation, and dynamic content easy to work with. They are both powerful, wonderful languages, and I enjoy using them interchangeably.
Both Perl and PHP are crucial tools for the Web developer. A lot of the best Web-application developers I know pick one of the languages as their strong language, but keep in mind the other for those times when it just makes sense. I recommend learning them both. Don't get into the zeal wars, understand both languages and you'll see where I'm coming from. Both PHP and Perl are wonderful, extraordinary languages.

I am in my ftp right now but I dont see the cgi_bin in there. How can I get access to it?

look in your public_html folder (or equivalent) If you don't see one then you may not be able to run this script. Contact your server to see if they have cgi access available. If not, then try Perlsp, mentioned at the top of this thread.

I dont have a public_html folder either, all i have in the root is my forums folder so I guess ill have to contact my server.

Ok, I dont have a cgi folder and so I just read on my servers faq pages
"CGI-BIN

Dreamhost does not use a standard CGI-BIN, but rather allows you to place executable scripts anywhere within your account and achieve the same functionality. Simply create a directory somewhere within your account and put your scripts there, then use the 'pwd' command while within that directory to get its pathname. This is what you would use within your script's configuration when asked for a path to the CGI-BIN. "

Would this work?

It sounds as if you could just place the 'auction' directory right inside your forum directory and it should work, according to them. Just change the file path for the iframe in the template to point to the auction.pl file wherever you put it and it will work fine. Give it a shot and let me know :D