Celeb CMS II

This is the first of a few sites that will be set up similar. So if I find a good programmer who is reasonably priced, and complete the work. I will keep them on for the mods that must come on other versions. I am looking for a nice CMS script, with API (Verotel) for membership on a celebrity site. You MUST be able to import my SQL DB from my other sister site ([login to view URL]). The way the new site is going to work is off the DB. Every day the script will randomly pick 'X' amount of images from the DB for the daily 'freebies'. So for example, it would pick 12 images from 12 different celebrity galleries that wound be 'unlocked' for 24 hours. The next day it would shuffle, and pick 12 new from 12 different celebs, etc. Only one random image will be unlocked out of a celebrity's gallery page at any given time for the freebies. However, if someone wants to be able to access them all. They can become a member. They can get access to everything by signing up. Depending on security, and cost complication. I may allow for use submitted pictures which would show up on a row under the 'shuffled' deck. The site design must also allow for easy advertising integration where I am not having to do html code. Same for link trades. So some sort of interface would be preferred. The directory structure must follow that of CFO. That means, in when you are checking out the galleries for a celebrity. It has their name in the php/html pages. Not some random number. Example, [login to view URL] Anything I am missing, or suggestions you have for this. Please feel free. It's one piece in a celebrity network of sites I am building. I am a webmaster, and more about sales and maximizing revenue. I am not a programmer. Provide examples of your work. Do not send me your resume. I want to know you can do this, to spec, and in the time limit given. If I feel I find the right programmer for this, and the other sites. I will close out auction early. ## Deliverables 1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done. 2) Deliverables must be in ready-to-run condition, as follows (depending on the nature of the deliverables): a) For web sites or other server-side deliverables intended to only ever exist in one place in the Buyer's environment--Deliverables must be installed by the Seller in ready-to-run condition in the Buyer's environment. b) For all others including desktop software or software the buyer intends to distribute: A software installation package that will install the software in ready-to-run condition on the platform(s) specified in this bid request. 3) All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the buyer on the site per the coder's Seller Legal Agreement). * * *This broadcast message was sent to all bidders on Friday Dec 28, 2007 4:47:14 PM: Here is some additional info... Okay. They need to use Apache features and modules more and raw PHP code less. Apache and her modules are wonderful tools, and most are much faster and less memory/processor intensive than PHP. Don't ship images via PHP. If you want to block sites or users, use a different Apache module to do it. Shove the bad guys into a black hole and don't bother with the rest. Remember that storing a file in MySQL still stores it in the filesystem somewhere. And when you call up that file via PHP then MySQL, you are then suffering at least two more orders of magnitude in the system resources required to serve up that file (as well as the user time required). Serving images from the MySQL database using PHP is similar to using a teaspoon to measure water in to a sieve to supply a river. Left to its own devices, Apache will act as many tributaries served by many springs: a force of nature to be reckoned with. The [login to view URL] into the sieve . . not such a good performance choice. :-) Having a cron job that scans the MySQL database every 10 minutes, writes out uploaded files, scans them for viruses/malware and then stores them to disk is not necessarily a bad solution. There are many other solutions that offer many other price for performance pros and cons. In any case, sending binary files from your MySQL database is a copout, and at this point is to be avoided where feasible. The performance hit is just too large to justify the ease of design and programming. Be careful when authenticating and authorizing users. Do not build slow or repetitive code into your routines, but also be wary when PHP/HTTP sessions can be forged. Request/require proper credentials when and only when needed. There are a bunch of general programming guidelines that any professional seeks to pursue. The main thing is not storing images in the MySQL database for sending out to the clients. It's fine to store the content there and then write out the contents to files, but they need to make good use of the filesystem directly, and serve the images out using basic hypertext links (let the browser and server solve the issues between them and eschew unnecessary PHP). If you need to block proxies or someone else, you can and should explore apache options for doing so. Any time PHP is employed, it creates an artificial bottleneck in webserver performance. Apache is great for sending image files and text to people. In fact, it's written to do just that. PHP is slow and ham-fisted. Therefore, store links to files in the MySQL database, and serve up those links in dynamic pages. The browsers will request the images, and everything will go much much faster. Storing the whole file in MySQL is a poor approach to the problem and will severely degrade the performance of your website. You might suffer marginally less control, but it won't be control you miss. These are my suggestions, but the result will be highly dependent on your choice of environment for your site. You need to have a hosting solution picked out where the admins of the system can easily communicate WELL with your developers. Also you should know that cable providers are starting to supply destructive interference on their clients' connections. Magically, this interference seems to hit adult content sites and other high bandwidth applications more than others. Providers have even begun sending out forged packets that disrupt and hinder TCP/IP communications. The real cost of the interference is then born by the site/server operator and the end user. An otherwise speedy connection to your server becomes inexplicably slower the second you start serving out images and video. Finally, I would advise you that RAM & compute power gets cheaper, but bad designs will never scale. The cost of poor design increases as your sites and requirements grow. An increase in the resource cost of an individual connection to your site will multiply exponentially as you gain more notoriety and subscribers. That's my speech. Take if you need it. Leave it if you don't. * * *This broadcast message was sent to all bidders on Wednesday Mar 12, 2008 10:02:33 AM: For those submitting real bids. I'll consider your offers. ## Platform Must look and work the same on all browsers. I have Linux server. Must not be a windows server application.