Project Detail

Description

1. To begin, the relevant forum scripts requires an update so that a constant, configurable number of visible messages is displayed on the main page. Currently, a range of message IDs, including both hidden and live messages, are available to be displayed on the main page, but since the number of visible vs hidden messages is always changing, so too is the number of topics displayed continually changing. This task is not likely to take too much time.

2. We require a working script to auto-resize images that are embedded in posts by users (maintaining same aspect ratio) which exceed a configurable pixel width. I have a javascript which performs this function, but it was written for phpbb, so it would have to be adapted for our use. Otherwise, a new function in Perl could be created for this purpose. Currently, images that exceed the width of the containing div are cut off by overflow:hidden. This task shouldn't take very long to finish.

3. There is a "reportmessage" script for allowing registered users to flag messages for moderator review, which needs to be modified slightly to allow configuration for a variable number of reports, both before an alert message is posted in the moderator forum, and before the reported message is set to hidden status. Currently, these values are hardcoded in the script and should only need to be replaced with new variables. A minor template field for printing a "report abuse" hyperlink is also needed as well as a minor function for printing, within the template, a notification upon successful submission of a reported message, e.g. "Your report has successfully been submitted". Then further extend "reportmessage" so that additional notifications are posted whenever any message is assigned hidden status and awaits moderator review, along with a specific reason given for the assignment of this status in the message body, whether this explanation be in the form of a list of matching entries in the banned words list, or an indication that the poster's handle is in the banned/restricted user's lists. Currently, only admins can view hidden messages, make them live, and unlock locked messages, and minor changes are needed to extend these capabilities to moderators as well. This series of minor tasks shouldn't pose much of a challenge.

4. Message header corruption occurs infrequently when hiding a message. The scripts used to hide messages may need to be debugged and rewritten to prevent this from reoccuring. An example of this corruption is available. It may take a little time to diagnose, but this shouldn't be a terribly difficult issue to correct.

5. A new addition is needed to a "readtemplate" script for reading ad html (in the form of text links) into an array and randomly ordering the list of text links, whether printed in a single column or in multiple rows, on each browser refresh. This text link ad html is already present in relevant templates but should probably be moved off of the templates into external txt files to reduce the file size of the templates. In the case of a vertical list of links broken up by <br /> tags (single column cell of text links), each text link instance could be surrounded with fields such as (texlink)<br />text link(/textlink). In the case of a horizontal list of links (multiple rows of each spanning several cells) the cell of each text link instance could be surrounded (textlink)<td>text link</td>(/textlink). These text links would then be randomly ordered and printed again on each browser refresh. The new function must be able to support multiple, unique "zones" to differentiate between separate groupings of text links in the same template. These zones, could then be nested within additional tags like (zone=#)(/zone=#). Much of this new function can be based on existing code, so it shouldn't take long to complete this task.

6. The toplist/traffic trading facilities need to be upgraded. Firstly, they must be extended to record the date a trade was added and the date last modified. Secondly, there is a toplist feature for setting the lowest position/rank to which a partner site can fall on the toplist, but we need a new feature for configuring the highest rank/position to which a site may rise to be able to truly force the ranking of a site. Next, a new template form is needed to allow webmasters to signup to apply to trade traffic through the toplist. Prior registration and a user account in good standing would be required to successfully submit the form. This new form could be based on the preexisting admin version of the form and allow webmasters to enter site title, url, contact name, email, messenger, icq, etc., select the type of trade (toplist, hardlink exchange, or both) and to modify/update this info later if needed (although any subsequent modifications would require admin approval). New partners would have to be approved manually by an admin and the trade must be activated automatically upon a configurable number of unique visitors sent in (detected by the toplist script). The new option to exchange hardlinks would require some minor additions based on existing code. Also, script security needs to be improved to guard against fake traffic, "hit bots", and other common forms of cheating to prevent our traffic from being stolen. The toplist also needs to be extended to rank referring sites by productivity (number of clicks generated per visitor) in addition to ranking by unique visitors to guard against poor quality traffic. We'll also need to guard against "circle-jerk" sites which blindly redirect traffic by deploying a spider to crawl through our partner site's HTML at regular intervals to ensure our return link is actually located there. Toplist data (referrer traffic (visitors, unique visitors, clicks generated for each trading partner) and exit traffic sent to each partner) needs to be logged and stored indefinitely and be available for display in hourly, daily, weekly, monthly, and yearly graphs. Finally, extend reportmessage.pl to post notifications in the moderator forum when a new trade awaits approval or when a webmaster modifies their site info, which will also require approval. This represents, by far, the most substantial work of the project, and it will take some time to complete, though it is straightforward and shouldn't be extremely difficult to accomplish.

7. The search facility needs to be overhauled to improve speed and performance as the I/O used is too slow when searching through 5 years and over posted 600,000 articles. Also, there is a minor bug when searching by usernames which contain underscores or hyphens. Additional filters are also needed to allow optional searching by message subjects, message body, and by date last modified. Search query matches also need to be highlighted in search results in addition to other minor issues. These tasks shouldn't take much effort to achieve.

8. Our posting facilities need to be overhauled to integrate and adopt the bbcode (markup language with bracket delimited tags) standard. I imagine this is a matter of porting these functions from other bbs software (which are mostly written in PHP, e.g. phpBB) into Perl to be adapted for our use. Currently, we offer the option of using a plain textarea, or a WYSIWYG html editor to post messages and bbcode would be added to these as another posting option. This will probably take some time to complete.

In summary, the most labor intensive tasks involve the overhaul of the toplist/traffic trading facilities and the adoption and integration of the bbcode standard as a posting option. Beyond this, overhauling the search facility and debugging the message header corruption issue will require a moderate degree of effort. The rest of the tasks can be considered relatively minor and trivial.

FYI, the forum software uses a combination of custom written, and unconventional, Shell and Perl scripts that were authored in 2002. Message and user data is stored in flat text files as opposed to an actual relational database. However, an online forum testbed will be made available, and I will actively work alongside the service provider, answer questions, and point out relevant directory locations, scripts and templates at every step of the way. Any project is a collaboration between service buyer and provider in which creative ideas are exchanged, so real-time communication and feedback over YIM is appreciated. The service provider must have broadband internet access.

The server is running FreeBSD and SSH access will be provided, but first your IP address will have to be added to the SSH firewall access list. If you are confident in your Perl/CGI/Shell scripting skills, the tasks outlined in this project should not pose an overwhelming challenge for you. If all goes well, your services may be retained, as an even larger project is planned for the immediate future, and plenty of work can be offered due to the age and state of these old scripts.

Please note, I work best with friendly, team-oriented individuals possessing sound English language/communication skills, good work ethic, laid-back attitude and liberal mindset. Priority consideration will be given to those who can begin work soon and respond promptly to private messages. Should your bid be selected, and you do not accept the offer within the hour, the project will be reopened to bidding again. Thanks in advance for your understanding and cooperation!


Additional information submitted:

11/07/2007 at 13:06 EST:
This project has a maximum budget of $500.