roopurt18

When you say descending / ascending order, are you not concerned with the year portion? I think what you will want to do is: create table `myjunktable` ( name varchar( 22 ), hire_date datetime ); INSERT INTO myjunktable( name, hire_date ) VALUES ( 'john', '2005-01-10' ), ( 'jane', '2009-12-10' ), ( 'bill', '2007-11-10' ); select * from myjunktable order by -- We want to order by the number of days between today and the anniv_date -- regardless of sign, so we wrap it all in abs() abs( -- The datediff calculates the number of days between the current time -- and that returned by the concat. -- If anniv_date is 2010-01-05 and today is 2010-01-13, datediff is: 8 -- If anniv_date is 2010-01-14 and today is 2010-01-13, datediff is: -1 datediff( now(), -- The concat takes the hire_date and calculates the anniversary -- for this year. i.e. hire_date, anniv_date -- 2005-01-05 2010-01-05 -- 2007-06-08 2010-06-08 concat( date_format( now(), '%Y' ), -- Returns current year as YYYY, i.e. 2010 date_format( hire_date, '-%m-%d' ) -- Returns month-day portion of hire_date, -- i.e. if hire_date is 2005-01-05, returns -01-05 ) ) );

You have two concepts to organize here: 1) Your framework / library 2) Your application(s) Your framework should be mostly objects and I don't mean just functions wrapped up in the namespace of an object. I would organize the framework like so: # Let / denote the home directory of the framework, such as: # /home/myframework # c:\myframework /bootstrap.php # By including this file, your application will # gain all functionality of the framework. /modules # Directory - modules or plugins go here. /modules/auth # Directory - Contains source code for your # authentication module. /modules/auth/_base.php # Defines abstract class Authentication_Base /modules/auth/active_directory.php # Defines class Active_Directory_Authentication /modules/auth/database.php # Defines class Database_Authentication /classes # Directory - core framework classes (those not # part of a module) go here. /classes/Application.php # File - Defines class Application /classes/Controller.php # File - Defines class Controller /classes/Layout.php # File - Defines class Layout (or Template) /classes/View.php # File - Defines class View /classes/Request.php # File - Defines class Request /third_party # Directory - Third party code (such as # PHPMailer) goes here. /third_party/PHPMailer # Directory - PHPMailer source code /third_party/Spreadsheet # Directory - Spreadsheet related source code /utility # Directory - Any code that is procedural (think # functions or classes with all static # methods) goes here. /utility/string.php # File - Defines StringUtil class /utility/array.php # File - Defines ArrayUtil class /application_skeleton # Directory - Contains skeleton application. # Directory structure mimics that shown below. I like to organize my applications like so: # Let / denote the home directory of the application, such as: # /home/mycoolsite # c:\mycoolsite /index.php # File - All requests filtered here via # .htaccess /.htaccess # Handles request filtering through index.php /private # All non-servable PHP files go here. It's # better to store them outside of the www # directory, but that's not always possible. /private/.htaccess # Forbid all requests inside this directory. /private/classes # Application classes /private/classes/MyApplication.php # File: class MyApplication extends Application { } /private/classes/MyAuth.php # File: class MyAuth extends Database_Authentication { } /private/classes/MyController.php # File: class MyController extends Controller { } /private/controllers/IndexController.php # File: class IndexController extends MyController { } /private/controllers/UserController.php # File: class UserController extends MyController { } /private/layouts/xhtml.php # File: Defines standard template for xhtml requests /private/layouts/xhr.php # File: Defines standard template for ajax / xhr requests /private/views/User # Directory: Views pertaining to User controller /private/views/User/list.php For development and testing, your application code should be separate from the framework code. When it comes time to deploy your code, you should be created a release with version control software and the framework should be deployed inside the application. In order to accomplish this, your application index.php might look like: <?php define( 'APP_DIR_HOME', dirname( __FILE__ ) ); define( 'APP_IS_DEV', strtolower( php_uname( 'n' ) ) === 'mycomputername' ); // Require the framework if( APP_IS_DEV ) require_once( 'c:\\myframework\\bootstrap.php' ); else require_once( APP_DIR_HOME . '/private/myframework/bootstrap.php' ); require_once( APP_DIR_HOME . '/private/classes/MyApplication.php' ); try { $app = MyApplication::getInstance(); $app->Run(); } catch( Exception $ex ) { MyApplication::FatalExceptionHandler( $ex ); } ?> Since your framework is inside version control and it contains an application_skeleton directory, starting a new project is as simple as: 1) Export application_skeleton 2) Rename according to project 3) Check back into version control as a new project As you work on your project you will undoubtedly update framework and application code. When you're ready to make a release: 1) Commit your framework 2) Tag your framework as the next release, such as 1.0.4 3) Commit your application 4) Tag your application as the next release, such as 1.0.2 Now if you're using SVN your repository might look like this: /myframework /tags /myframework-v1.0.0 /myframework-v1.0.1 /myframework-v1.0.2 /myframework-v1.0.3 /myframework-v1.0.4 /trunk /branches /mycoolapp /tags /mycoolapp-v1.0.0 /mycoolapp-v1.0.1 /mycoolapp-v1.0.2 Since mycoolapp-v1.0.2 is dependent on myframework-v1.0.4, we should copy that version of the framework into the project. /myframework /tags /myframework-v1.0.0 /myframework-v1.0.1 /myframework-v1.0.2 /myframework-v1.0.3 /myframework-v1.0.4 [copy this] /trunk /branches /mycoolapp /tags /mycoolapp-v1.0.0 /mycoolapp-v1.0.1 /mycoolapp-v1.0.2 /private /myframework-v1.0.4 [paste it here, because that's where index.php looks for it when deployed] Then we must rename it in the application: /mycoolapp /tags /mycoolapp-v1.0.0 /mycoolapp-v1.0.1 /mycoolapp-v1.0.2 /private /myframework [rename it to whatever index.php expects] Now to deploy your app you just export mycoolapp-v1.0.2 and it will include the correct version of the framework that you built and tested it with. That's all I have time for right now; I hope it helped some.

SELECT ... FROM `yourtable` WHERE ... ORDER BY `hire_date` DESC That's not descending order...

Excellent book.

Make sure you mark your topics "Solved."

The sequel only needs to be about 15 minutes in length. Characters: Bob: Head of Strategic and Military Operations for "The Company" Bill: High-level executive for "The Company" Bob: We were unprepared for the retaliation of the natives on Pandora and they've driven us off the planet. Bill: ... Bob: Fortunately for us, they're not too advanced and all we care about is what's under the ground. We'll blow the shit outta them from space and go get our unobtanium when the dust settles. Bill: Get it done. 14 minutes and 30 seconds of awesome, mind-boggling explosions. Last 15 seconds of the film. Jake Sully has some how survived the explosions. He holds his GF's dead, limp body in his arms. The camera zooms out as he looks towards the sky. Jake Sully: God damn yoooooooouuuuuuuuuu! Needless to say the third film in the trilogy will be like watching a documentary on Auschwitz.

The technical tools for performing AJAX have been around since the 1990s. AJAX is just a term coined by some guy to describe what he was doing; he didn't do anything other than provide an acronym for stuff that already existed and was already being used. Also, I think many more people favor pushing JSON over XML due to it being more concise. VBScript developers might disagree I guess.

http://docs.jquery.com/Ajax/jQuery.post Doesn't imply one way or another if it's asynch or not. But there is a high probability it uses the XMLHttpRequest object in some fashion which does provide a mechanism to make requests either synch or asynch. http://docs.jquery.com/Ajax/jQuery.ajax#options Tells you how to use the ajax() method and set the request to synchronous. @Mchl AJAX is a misnomer anyways and has nothing to do with the XMLHttpRequest object. The XMLHttpRequest object can perform either type of request.

You're using jquery's post() function which is probably asynchronous. Do you understand the difference between synchronous and asynchronous?

The implication is that only douchebags would take the time to fill those things out in the first place. Funnily enough that's the only one I've ever completed because a gamer buddy of mine linked it to me with "lol" attached to it. I think it's hilarious!

I don't usually get stuck with implementation details anymore; what nags me are design decisions. How can I make this portable? What else does it need? How hard would it be to add X feature even though it's not needed now, but would be useful in the future? How can I refactor this to be more maintainable? There are so many occasions when you come to a fork in the road in terms of design. Whenever I reach the fork I try to put off my decision for a day or two if I can. I'll change gears to a different project or a different sub-task of the same project. Often times this little break helps me see the light! I find that my major decisions are made frequently in the same places however: 1) On the shitter 2) While driving 3) While painting 4) Shortly after waking up -- I think every programmer has experience problem solving while sleeping

You might take a look at SugarCRM, although it may be overkill for your needs.

http://www.douchebagnamegenerator.com/ I wish I could take claim for that.

Your site has three basic components you need to worry about when migrating to another host: 1) The web server. Is it Apache, IIS, or another breed? It usually doesn't matter, but as an example my web apps are always driven by Apache and I always use mod_rewrite. I don't know if IIS has an equivalent but if it doesn't, it will be slightly more difficult to make my applications work in IIS. 2) PHP. Which version of PHP is the current site developed in? Which PHP language extensions does it use? Hosting it somewhere else will usually require they be on at least the same version of PHP and have the same extensions enabled, or at least the extensions your application relies upon. 3) The database. I assume it's MySQL, but whatever it is your new host needs to provide a database version that will work with your existing database. Then you have storage, bandwidth, e-mail, FTP, and other considerations to make. If your site is small you're probably Ok in this regard, but it's still a good idea to make sure your new hosting account has enough disk space, provides enough bandwidth, and stuff like that.

Your hosting company is behaving as a consultant. You make requests, they implement them, you pay them. If you want to make a fart and it involves them, then it will cost you money. If you've paid the hosting to develop and host this website for you, then you need to look towards the terms and conditions agreed upon when the work was started. If the hosting company made claims that all code developed was owned by them and that the database was also owned by them and you were just being granted a license to use, then I'm not really sure what you can do. Their obligation to abide by your will really depends on who rightfully owns the virtual property. I think $500 to change a typo is a bit outrageous. I myself work for a company that offers hosting (although not web hosting) as a service. The software we host is archaic, difficult, and can be problematic. It really is in our clients' best interest to let us host and manage their data. In return, we do our best to provide our clients with the data and flexibility they need. When picking up a new client, we unfortunately run into other individuals who have had the same experience you are having now where someone held their data hostage. It really serves no purpose as: 1) It will just drive you (the client) away from this hosting company 2) It makes it more difficult for hosting companies that actually care (i.e. the one I work for) to sell hosting services I can make you a promise though. If you start hosting that software yourself you're bound to run into headaches and troubles that will cost more than $500 to fix. And that is how your hosting company justifies their fee. Once you start maintaining this software yourself, you'll realize how big of a pain in the ass it is and you'll want to find someone to do it for you again. The business mentality is a pendulum swinging between two extremes. It never stops in the middle.

I created a similar system once upon a time. I can't really go into the nitty gritty of it, but here are some things I came up with. 1) Database tables exist to store information and allow us to query that information. When it comes to surveys you need to store surveys, questions, and user responses. You will need to ask questions about the responses, such as "How many people answered with 'Apple' for question #3 of survey #15?" You will probably not need to answer questions about the surveys themselves, such as "How many surveys contain a 1-to-10 rating style question?" 2) Survey and question characteristics are likely to change over time. Today you support short answer, true / false, and "check all that apply" questions. Tomorrow you might support "rating questions." All in all, it will be *difficult* to keep a database structure consistent with how frequently your question "types" may alter over time. 3) Survey responses are one of: boolean / bit, short-text, long-text. Therefore all you really need to store a response is: question_id, user_id, bit_answer, short_answer, long_answer, other_flag 4) I don't recommend having a table that stores the "possible" answers linked via referential key integrity to the actual responses table. If you do this, then it will be difficult to implement responses of type "Other." Since you don't know what "Other" might be, how can you pre-load the "possible_answers" table so the referential keys will work out? You can't. Anyways, taking all of that together I made something along the lines of: survey id, name, description, start_tm, end_tm, survey The `survey` field is the serialized PHP object that represents the survey. It's pretty easy to predict that surveys will have a name, description, start date, and end date. Therefore the table has actual columns for those values. Beyond that, who knows what the client can ask for? Therefore everything else about a survey, which will change drastically with the life of the application, is a serialized PHP object stored in `survey.` question id, survey_id, prompt, order, type, question The `question` field is a serialized PHP object that represents all details of a question not contained within prompt, type and order. The logic behind this design is the same as that with the `survey`.`survey` column. response id, user_id, create_tm, survey_id A general record for a user's submittal of a survey response_item id, response_id, bit_answer, short_answer, long_answer, was_other Store the user's response here. bit_answer contains 0 for false answers, 1 for true answers. short_answer contains any textual response that will fit within varchar(128) or however many characters you deem appropriate. long_answer is a text field for paragraph-like responses. was_other is a flag to indicate if the user clicked a checkbox named "other" on the survey form and typed in their own response. The survey and question tables are flexible enough to allow for easy modification of the code in PHP without having to fuss with the database every time you change a property name in PHP. All of the tables contain enough information to perform simple reporting through an interface that doesn't have access to PHP. Hopefully that helps you some.

IMO you should arrange with your hosting company to create a database / code backup that will be stored daily / weekly at your local office. This will protect you should anything happen to your current hosting company. For example, if your current hosting company tanks, disappears, or whatever, *if* you have the code and a backup of the database you can contract an individual (or company) to get it up and running again on another hosting service. You might experience a few days of down time and pay more than you'd like to for it, but you *would* be up and running again and this is only the worst case scenario. In addition, if you had the code and a backup stored locally, you could then copy that into your own test and development environment to start modifying and managing the software on your own. Once comfortable you could finally move your modifications into production with either your current hosting or a new hosting service if you had to.

It would appear that it *thinks* you're trying to update the `site_id` column. In your UPDATE statement, is `site_id` present? Or, does your update statement look like: UPDATE `tbl_site_photos` SET `site_id`=$old_value, ... WHERE ...

You can not sanitize data all in one go. Use mysql_real_escape_string() when inserting the data or the appropriate escape function for your database. Use an appropriate escaping function such as striptags() or htmlentities() after selecting data from the database and before sending it to the user's browser. Do it any other way and your site will be vulnerable to attacks.

Are you calling eval() on user input? If not, then it doesn't matter if they input PHP code into the comments section on a blog. All you need to do is: 1) When inserting data into the database, use mysql_real_escape_string() (or the appropriate function for your database) 2) When displaying data, call striptags(), htmlentities(), or some other escaping function so that potentially dangerous input from one user is not sent to another user.

Floating point numbers are approximations to their "real" values. 95.01 could be one of those numbers that actually has no representation. I recommend using a math library that supports arbitrary precision if this is a concern for you.

Or if a hacker gets in they will be able to prevent the user from logging in and changing their password. A savvy hacker could even log in as a user and then use wget to send requests to your server on a timer so the session never ends. Then the legitimate user would be locked out permanently.

Well then you can spend months on end developing it yourself. As long as the budget exists for it, who are you to complain?

PHPExcel is good. It's very easy to use and works correctly. I attempted to create a very large spreadsheet with it once and performance suffered though. I recommend it for small to medium files. There is a PEAR Spreadsheet class as well which is good also. I don't understand your boss's design restriction against plug-ins. Unless he is an engineer or developer himself, his only concern should be if you can get it done and if there's a library that already exists that: 1) Will get it done faster 2) He can use commercially Then I don't see what the problem is. Then again my boss has absolutely zero experience designing software and he likes to force arbitrary design decisions on me as well. It's his way of putting his "personal stamp" on the project and rarely does it work out well for either of us.

Yes, you can. You'll also have to find the specification for what the correct Excel file format is and put it in that format. Or you can put it in a CSV file as suggested since Excel understands CSV. Or you can just use one of the many PHP-to-Excel libraries. I don't see what the big deal with installing one is unless your shared host is a turd.