Gibbs

Search engines are not instantaneous and can take a while to update their index. AFAIK X-Robots-Tag is Google specific and a HTTP header (not a meta tag). There are many ways to provide directives to crawlers and not all of them are the same. Via a robots.txt file Via meta tags (what you are doing) Via HTTP headers (which is what X-Robots-Tag is) If you want to do this via HTML then use; <meta name="robots" content="noindex" /> Edit: Ignore the above, just realised you are trying to get your XML sitemap unindexed. Use a robots.txt file and have something like: User-agent: * Disallow: sitemap1.xml

Is this a trick question? . The first one with Exception spelt correctly as you are doing unnecessary checks in the second. $day is always set so you don't need isset is_int makes checking is_array, is_bool, is_null and empty redundant The first one is easier to read and maintain

Have you recompiled framework.less? It works for me. A couple of things; The font is 'Varela Round' and not 'Varela-Round'. Not important now but your HTML should be including styles.css

Keep it simple, short and concise. If your website warrants having a lot of categories then by all means go with it but the page itself is vastly more important than its name. This is an old video but probably still relevant.

It is easy to determine if an element is hidden via both CSS and HTML. All this does is reduce spam from bots that aren't particularly good (there's nothing wrong with that). If CAPTCHAs are bad for accessibility then so is proactively ignoring an accessibility feature for convenience?

This is so you can upgrade Bootstrap without overwriting your changes. As a general rule of thumb don't overwrite any vendor code. I assume you are compiling styles.less? The files var-bootstrap.less and var-jasny.less don't actually have any CSS, they only contain LESS variables. That is why it is blank. You might be missing an import or haven't got to that stage in your tutorial yet.

What exactly is the problem you are having?

Guessing your level of expertise I would say no. Magento, like any other platform, will not magically solve your problems. If you have a large catalogue or your requirements get more complex then sure, its developed specifically for that and does it well. You haven't said anything that indicates that is the case. Moving forward it would be a better foundation in the long run but you haven't stated what problems you're having. Are they related to Wordpress or the website itself?

There is still plenty - just take a look at the HTML5 spec implementation scoring for IE12 at http://html5test.com/results/desktop.html Font rendering is an OS related issue - the same would not apply for Chrome/Chromium on Mac or Linux for example.

If possible I would do it in PHP (or similar). Something as simple as <body class="<?php echo $theme; ?>"> or if you have a wrapper use ids. If not then use Javascript as you suggested. It should be pretty straight forward.

IE gets outdated very quickly. We will be hating IE 9/10/whatever in a few years just as much as IE7/8 (both heralded as Microsoft doing a good job catching up, like you mentioned). Also nobody runs a 10 year old Firefox as the vast majority of browsers are on a rolling-release type life cycle.

Are you talking about PHP on Windows/Ubuntu rendering it differently? If that is the case then I don't know but obviously different systems render fonts differently (although not to the scale of what you're saying usually). If you are talking about browsers viewing the images different on Windows/Ubuntu. A caching issue possibly? If the images are being served dynamically try and save them to the filesystem and then access them via a browser.

The idea of moving files outside of the web root is mainly to make files that don't need to be run inaccessible. For example I run the core directories of Drupal and MODX outside as they leave things lying around that nobody needs to run publicly such as install scripts, configuration files and modules. If for some reason PHP stopped running on a mis-configured server you could have a field trip finding files like core/config.php etc. It can also make it harder to determine what is being run and areas to exploit. I can tell eBay is running Wordpress 3.7 as like most people they have left the readme accessible. This isn't inherently secure/insecure either way but could generate less noise (random automated attacks/scans) from script kiddies targeting a specific version of something. Still, there are plenty of other ways that can be achieved but its an example of leaving things lying around that aren't really necessary. In your case your directory structure approach is wrong. Instead of: /public_html/images/yoursiteone.com/ /public_html/images/yoursitetwo.com/ You want something like: /yoursiteone.com/public_html/images/ /yoursitetwo.com/public_html/images/ To keep them truly separate. Otherwise they are sharing the same public directory. In most cases the images will have unique filenames so disabling directory listings should suffice. If the images aren't intended be accessible by the web whatsoever then they should be outside the web root entirely. I.e. /yoursiteone.com/images/ /yoursitetwo.com/images/

Right click > 'Find in Folder'. Is that what you mean? Alternatively CTRL-ALT-F and the "..." button to the right of 'Where:' select 'Open Folders'.

The mail function should be: mail($to, $subject, $message, $headers); In your case: mail($emailTo, $subject, $body, $headers); Rename $headers to $subject Your new $headers should be: $headers = 'From: whatever@whatever'; Edit: For example: if(!isset($hasError)) { $emailTo = 'contact@r-m-t.org.uk'; $body = "Name: $name \n\n Email: $email \n\n Contact No.: $number \n\nPost Code: $postcode \n\n Message:\n $message"; $subject = 'Website Contact Form'; $headers = 'From: whatever@whatever'; mail($emailTo, $subject, $body, $headers); $emailSent = true; } Check out http://php.net/manual/en/function.mail.php#example-3374