CMS Script - CFO (792734)

I need a new or revised CMS script for one of my existing websites. What I have works, but I need some further modifications, and upgrades. First off, let me give you the example site, [login to view URL] This site works like this. I upload pictures via FTP into a temp folder. I then use a web interface to either create a new gallery, or I find the existing and then click on it to open, then once all is uploaded I hit save. It auto thumbs, and arranges newest additions first. They are then available for 24 hours, and then archived where only members can access it. In this version of the site, it did not allow for a good indexing of videos, or vid caps. The original version of this site had a movie section that listed the movie, a description of the scene, and then you could click the link for the movie(s). We never got around to that in this version. The original coders were not very good at deadlines, or strong coders so it's time for a new version. The new site needs to have a better indexing system for movies and vid caps as explained above. It also needs to allow for post dating updates. So I can do updates for day(s) or week(s) in advance. Your version of the site must be able to import from the existing DB. I am not going to upload a million images, and 10,000 celebs all over again. It took the better part of a year to do this the first time. So however you need to accomplish this you will have to do. There are some minor things here and there that need to be changed on the existing site. But for the most part it still works well, and does what I need. But instead of trying to have someone do a patch work on this. I will consider a new design with the modifications I need in the script for the post dating, and movie DB option. DO NOT REPLY TO ME WITH BLANKET GENERIC RESPONSES AND COMPANY INFO. THEY WILL BE IGNORED. Your replies, and bid should include EXAMPLES OF YOUR WORK. I want to see you have experience doing these. ## 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 Wednesday Oct 24, 2007 4:54:48 PM: 2. You do not have to do anything with video capturing. I have the videos, and clips. You have to have a system (similar to my picture updating) where I can type in the movie, and scene where the toes are. Tnen upload the clips, or vidclips. It then will need to index them by movie.. A, B, C, etc. This needs to be searchable. So if someone is looking for say, Sandra Bullock. It will come up in the search results. Hope that clears up the point about the movie indexing. It's little more than a better, or more advanced indexing system for clips I already have. * * *This broadcast message was sent to all bidders on Thursday Oct 25, 2007 12:38:16 PM: "So you want exactly the same as the reference site?" Well yes to a degree. The site would work the same. API is the same. Layout similar. I basically need an expansion added on for the movies, and vidcaps. A searchable DB where all of the movies with foot scenes are listed, along with the celebrity in them. So it would show as another tab, or menu item on main menu. * * *This broadcast message was sent to all bidders on Friday Oct 26, 2007 8:10:05 AM: Correct. It has vidcaps movie section but it's unacceptable. I need a separate section that has these. Like under a different tab. It would show the movie, and the a brief description of what's going on. Then the link to the viddcaps and/or movie clip. Post dating means that I can set up the new day's update to post tomorrow, the next day whatever. So if I am out of the office. The site still updates. No special player is needed. I upload the video which is mpg, dvic, avi, whatever. It plays on media player or whatever the member has on their computer. NO SPECIAL PLAYER IS NEEDED! * * *This broadcast message was sent to all bidders on Friday Oct 26, 2007 1:27:17 PM: Please make sure that you are submitting your bids on the project properly. I am getting a number of people who are mentioning, or bidding in their correspondance, but not submitting an official bid. I can't accept your offers this way. Furthermore, if we need to edit a bid, or something causes a change in it. We can deal with that, at that point in time. Thank you. * * *This broadcast message was sent to all bidders on Monday Nov 5, 2007 5:58:37 AM: Some requested our other reqs [login to view URL] [login to view URL] [login to view URL] [login to view URL] [login to view URL] [login to view URL] * * *This broadcast message was sent to all bidders on Monday Nov 5, 2007 6:02:06 AM: Some requested our other reqs [login to view URL] [login to view URL] [login to view URL] [login to view URL] [login to view URL] [login to view URL] * * *This broadcast message was sent to all bidders on Friday Dec 28, 2007 4:46:31 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. ## Platform Must look and work the same on all browsers. I have Linux server. Must not be a windows server application.