kicken

You'd just have to configure your apache install to basically respond to any request with the same website. Have your application examine the host name to determine which site it should be displaying. As far as the apache configuration goes, the easiest thing to do would be to just disable virtual hosting so that it serves only a single site. You could also leave virtual hosting, but just have a single vhost.

You can't do exactly what you want if JS is disabled. With JS disabled, the page has to reload in order for the validation to happen, and if there is an error you have to re-generate the form along with the error messages. With JS enabled, you can submit the form data via AJAX for validation and then check the response to see if there was an error or if everything was successful. If successful, go ahead and submit the from normally. Generally speaking if you want the page to work both ways the easiest thing to do is to handle what validation you can within JS without involving ajax at all, then if that passes let the form submit and do the validations also on the server-side. Considering your validations are fairly simple (field not empty, email is valid format) this would be the ideal way to go. You only really need ajax validation in order to handle things which cannot be checked with JS alone (such as for username availability, or duplicate emails, etc). $('#contactus').submit(function (e){ var errors=[]; if ($('#name').val() == ''){ errors.push('Please enter your name'); } if ($('#message').val() == ''){ errors.push('Please enter your message'); } if (!is_valid_email($('#email').val())){ //Google for a JS email validation function and use it here errors.push('Please enter a valid email addres'); } if (errors.length){ alert(errors); //Implement some better method of showing the errors e.preventDefault(); } });

Best guess would be that something in that HTML is requesting a file (an <img> tag perhaps) which does not exist. That causes apache to run your 404.php page which you have setup to destroy the session. A simple 404 error should not be destroying the session, just print a not found message and leave the session alone.

You need to have some kind of mail service configured, be that either SMTP or sendmail. Are you using PHP's mail() function, or are you using a library to handle the email? Also make sure you check your spam/junk folders.

As mentioned, google about data normalization to get a solid understanding of how databases are designed to work, and what they are optimized for. Think about this one scenario though as a quick way to see how A is more optimal and efficient: So you have a page to display all your products, and filters on the side for users to narrow down the list to things they are interested in. Filters may be for example Type, Price range, Color, Size, etc. Here are two things you may want to do to make things user friendly: 1) Only show filters which would return a result (ie if they filter Shirts and there are no black shirt, don't include black in the color filter) 2) Show a count next to each filter indicating how many match that filter. 3) And of course actually apply the filter if the select it. Now, using method B, here's what you'd have to do for each one 1) SELECT all the products matching the type/size/etc, run through each row, explode the colors of every item, and merge them into an array of colors. 2) Same as above, but for each color also increment a counter for the number of items that color is available. 3) Either similar as above, but as you go through the rows, explode the colors and check them against the selected filter. Each one that matches gets added to the final result, the rest get dropped. With method A, here's how easy things become (each of these queries gives you exactly the results you need, with no additional processing required on the application end): 1) SELECT DISTINCT c.Name FROM products p INNER JOIN product_colors pc ON pc.ProductId=p.ProductId INNER JOIN colors c ON c.ColorId=pc.ColorId WHERE /* The filters, like p.Type='t-shirt', p.Size='L' or whatever */ 2) SELECT c.Name, COUNT(*) as totalProducts FROM products p INNER JOIN product_colors pc ON pc.ProductId=p.ProductId INNER JOIN colors c ON c.ColorId=pc.ColorId WHERE /* The filters */ GROUP BY c.Name 3) SELECT p.ProductId, p.Type, p.Size, GROUP_CONCAT(c.Name) as colorList /*, etc */ FROM products p INNER JOIN product_colors pc ON pc.ProductId=p.ProductId INNER JOIN colors c ON c.ColorId=pc.ColorId WHERE /* The filters, including c.ColorId IN (1,2,3) to limit colors */ GROUP BY p.ProductId Now, of course, with only 2-3 products, either method will appear to run just as well as the other in pratice. It's when you get big that the differences become apparent. So lets fast-forward to the point where you have say, 5,000 products. Let's say the user only wants to see Large t-shirts in colors Blue and Forest-green.Lets assume these are the totals for each of those filters applied individually: # t-shirts: 4700 # in large: 4700 # in blue: 4000 # in forest green: 3500 # in both blue and forest green: 3450 Lets assume for the sake of being able to count rows, every shirt is available in some random selection of 500 colors out of 1000 total colors) Method B Total rows: 4700 (one per product) Method A Total rows: 4700 (products) + 2,350,000 (product_colors) + 1000 (colors) = 2,355,700 So using Method B, in order to filter by the colors you have to first 1) Select 4700 rows (# large shirts) then foreach row, explode the colors, loop over the color list (500 iterations), loop over the selected filters (2 iterations) to find matches, and then push the matching results into an array. Given the numbers above, of the original 4700 rows returned 1200 of them get dropped. How ever long it took to process those rows, is wasted time. 2) Similar to the above 3) Similar to the above If you look at that, there is a lot of looping going on when processing the results from the DB: 4700 iteration (db results) + ((500 * 4700 iterations (colors for each result)) + (500*2 iterations (filter check)) = 2,355,700 iterations Hey, look at that, you're doing just as much work as method A, just in your app rather than in MySQL. Using method A (assuming proper indexing has been done) 1) The database will use the index that exists on product_colors to first find only the products which match blue and forest green. This immediatly narrows down the 2,355,700 rows to only 3450. After that the t-shirt/large filters would apply but they don't change the row count in this situation. On the PHP end, no further processing is require, just read the results 2) Similar to the above. 3) Similar to the above. So, using method A your app only needs to loop 3450 times in order to gather up your results. Using method B, you have to loop 2,355,700 times to achieve the same thing. Being a relation database, mysql has been highly optimized to do such filtering/loop in very efficient manner. As I mentioned above, by using an index mysql can near instantaniously narrow the result set down to the final 3450 rows right off the bat. Your App on the other had likely has not been optimized at all (nor can it be optimized to anywhere the same level as Mysql has been). In addition, if your using something like PHP then you have additional overhead of it being an interpreted language

Whether you need to add/remove colors or not, the optimal solution is to use a separate table for all the color options, then link the available colors with the appropriate products using a third table. Table products - ProductID - Name - Description - Etc. Table colors - ColorID - Name Table product_colors - ProductID - ColorID So in your products table, you'd have the details on each product. The colors table would just be a simple listing of all available colors, one row per color. The product_colors table has one row per product/color combination. So if you had a shirt, and offered it in Red, Yellow, Black, Blue and White, you'd have: products: ProductID | Name | Description ----------------------------------- 1 | Shirt | A basic shirt colors: ColorID | Name ----------------------- 1 | Red 2 | Yellow 3 | Black 4 | Blue 5 | White product_colors: ProductId | ColorID ----------------------- 1 | 1 1 | 2 1 | 3 1 | 4 1 | 5 If you want to run on the assumption that every product will always be available in ever color, you could skip the third table, but having it gives you the option of limiting the color selection for individual products.

A quick google search doesnt seem to indicate anything already pre-written for parsing a PST file. I did find however this PDF on the PST File Format so you could try and write your own.

Whether they should be immutable or not is debatable. The fact is that they are not however, you can change individual characters through array access. <?php $str = 'Blah'; var_dump($str[1]); //string(1) "l" $str[1] = 'a'; var_dump($str[1], $str); //string(1) "a" //string(4) "Baah"

FROM_UNIXTIME DATE_FORMAT

There is an example right there on the page you linked: $('.sigPad').signaturePad({displayOnly:true}).regenerate(sig); Where sig is the JSON data from your database. Have PHP echo out your JSON to a sig variable and then use the line above. var sig = <?php echo json_encode($jsonFromDb); ?>;

For single character access, you can also just treat the string as an array an index into it: $secondChar = $str[1]; //0-based

I've dealt with some people who used Godaddy shared hosting and they did have one level above the webroot if I recall correctly. That said, I personally found godaddy's shared hosting to be fairly crappy and terribly slow so I'd recommend a different provider just based on that. I've not used any shared hosting in a long time so I can't really recommend any particular place, there is a thread on here with lots of options though.

The mssql_* functions are outdated and no longer maintained. If your goal is to create a more modern program, then you're already failing. Switch to PDO using the PDO_SQLSRV driver for talking to the database if possible. ODBC would be your next best option if SQLSRV is not an option. Once you've made the switch, if you still have issues, post back with some more details.

There are other possibilities for a timeout, such as a CGI timeout if you're setup in CGI mode. phpinfo() would tell you what SAPI your using. Also remove the @ from in front of your function calls. That operator hides any error messages that may come up, and should be used very rarely. After the download stops, open the resulting file in a text editor or hex editor and check if there are any error messages printed out (after you've fixed the @ problem).

Should read: ... called before anything else any output is generated. You can do whatever you want prior to calling session_start() so long as a) No output is generated and b) You're not trying to use session data Opening a database connection shouldn't conflict with either of the above so feel free to open the DB first, then call session_start.

Probably your SELECT query is returning duplicates. We can't answer why to that without knowing more about each of the tables and the data contained within them. A quick fix might be to just change it from SELECT to SELECT DISTINCT

It sounds to me like your getting confused between Windows's Powershell and a Unix/Linux shell. The command ls -a is a unix/linux shell command to list all files. Get-Childitems will list all the files in windows powershell, it needs no parameters though.

Have a single request to the server for your updates. Format the output of the request in such a way that you can pass all the relevant information for each tab (and anything else) into a single response and then have your JS update things as necessary. Trying to manage several update requests is going to get messy quickly when you start having a bunch of chat tabs open, you may also hit browser limits causing things to slow down. Browsers generally limit the number of concurrent requests to a given domain to 2, further requests are queued. There may also be a cap on the number of concurrent requests one can make regardless of the destination domain.

No, because there was never a request to the captcha when you downloaded the page. You'd just be emulating how a browser works: 1) Download the HTML source of the page 2) Parse the source to acquire the captcha URL 3) Download the image from the captcha URL. That is what the browser does, then it displays the image it gets on the page where necessary. You'd have your script do the same thing, but rather than display the image save it to a file.

I'd venture to guess that you may have another <Directory> or Options elsewhere that is overruling the one you want applied. Setting the options in httpd.conf within a <Directory> has always worked fine for me, both for the target directory and it's subfolders. Edit: On a side note: So your Options -Indexes FollowSymLinks is invalid and the server shouldn't even be starting up with that line in place.

(float) is what you'd use for a decimal number. If your looking for a fixed-point decimal type, there is no such native type in PHP. You would have to implement such a thing yourself with a class.

You're redirecting your output to result.txt. There's no output for exec() to capture and return as a result of that. $result = file_get_contents('result.txt'); to get your output, or stop redirecting it at all.

return falseNow, as for your whole idea: Anti-right-click scripts are nothing more than an annoyance and won't stop anyone from taking your images/source if they to. The only thing such a script will do is annoy the hell out of your visitors by preventing them from using their context menu for legit purposes such as opening a link in a new tab/window.

A somewhat more generic solution to disabling links after a single click would be: http://jsfiddle.net/Xeghq/ $(document).on('click', '.one-click', function(e){ if ($(this).data('clicked')){ e.preventDefault(); } else { $(this).addClass('clicked').data('clicked', true); } }); That would cause any element with class="one-click" to only allow a single click. Once clicked all further clicks would be disabled, and the element would get class="clicked" added to it which you could use to change the visual style if desired. Note that this would work for things such as form submits also. As has been mentioned however, a JS solution like this will only stop someone who is lazy/unskilled. Server-side validations are required to fully prevent such a thing.