Adam

You need to correct the typo in "images/" I mentioned a couple of posts ago. You're type check if still checking for images/, not image/.

You'll want to remove the print_r() line now, that was just for debugging purposes. Also change "// ..." to a die statement. Though as mentioned, once you get this working, you should replace the die statements with proper error handling.

Ah yeah, ha. It's not "image/", just "image/". Missed that! As I said though, you're better off verifying the file extension is valid instead of the file type. Even if it's not actually an image that the user uploads, but it has an image extension, the server will still treat it like an image. Use this: $extension = strtolower(pathinfo($Image['name'], PATHINFO_EXTENSION)); if (!in_array($extension, array('jpg', 'jpeg', 'gif', 'png'))) { // ... } That parses the file extension from the name, then checks if that extension is not in the array of allowed extensions. As for the unescaped variables, you just need to run them through mysql_real_escape_string before use in the query.

Add: print_r($_FILES); exit; .. To the top of your script and post us the output, within tags (those spoiler tags you're using don't display in a fixed-width font.) Although you should be aware your script has security issues with it. For a start, the file type can be spoofed so it's not reliable to verify the actual file type. Also you're blindly inserting values into the database without escaping them.

Take a look at the manual for strpos - it checks the position of a string within another. In this case if the return value is not 0 (i.e. the string "images/" is not at position 0 within the file type,) run that code. Given we can do that, there's no need for the overhead of a regex just to check if a string starts with something. PCRE stands for Perl-Compatible Regular Expression, and is syntactically different to POSIX regular expressions (used by the ereg functions). You can't just change the function name to convert to PCRE from POSIX.

Okay. First timer: var myVar=setInterval(function(){myTimer()},1000); This creates a timer that calls the provided callback every second, which in turn calls the myTimer() function. function myTimer() { var d=new Date(); var t=d.toLocaleTimeString(); document.getElementById("demo").innerHTML=t; } This creates a new Date object with no arguments, meaning it's set to the current date/time. The return value of toLocaleTimeString() is then stored in the variable t, and then set as the innerHTML of the #demo element. This will happen every second, so you'll get the "dynamic" clock. Second timer: function makeArray() { for (i = 0; i<makeArray.arguments.length; i++) this[i + 1] = makeArray.arguments[i]; } The arguments provided to this function are stored as the properties 1, 2, 3, etc. As mentioned this isn't actually an array, so you can't use the array methods, but numeric property names are valid in JS so while this is wrongly named it isn't necessarily bad. Would be a lot easier to remove it though and just define the array like: var months = ['January', 'February' ...]; Though you would need to account for the index starting at 0. var date = new Date(); var day = date.getDate(); var month = date.getMonth() + 1; var yy = date.getYear(); var year = (yy < 1000) ? yy + 1900 : yy; Again this just creates a new Date object to the current date/time, and then uses the Data object's methods to build up a string, which is eventually written to the document once: document.write(day + " " + months[month] + " " + year); With what I said before about one not being shown, if document.write() is called after the document is ready you will overwrite the whole document and so loose the #demo element, meaning the first timer would fail. If called in-line, within the body, it will be written in-line. See the difference here: http://jsfiddle.net/GWezM/ http://jsfiddle.net/z6Mq5/

Well first of all, your makeArray function does not create an array. It just creates a standard object with the function acting as the constructor. You also seem to have two timers. One of which may never be seen, depending on the location of that script in the document. The other that would be seen, does not update itself. So do you see a timer updating every second or a static timer?

Hmm.. I'm can't spot anything with horizontal scroll, or anything that looks out of place? What browser are you using?

$images/ is not a valid PCRE, however you don't need to use a regex here. Just use: if (strpos($_FILE['Image']['type'], 'images/') !== 0) { // ... }

No, doesn't make a great deal of sense to be honest. Can you provide a link to the website, or some code we can use to reproduce the issue? We can't use what you've provided.

You're missing the closing PHP tag here: </form> <?php if(get_option('contact_captcha') == 1) { if(get_option('third_color')) { $third_color = get_option('third_color');if(get_option('template_style') == 'dark') { $captch_stroke = 'dark'; } else { $captch_stroke = 'light'; } } else { if(get_option('template_style') == 'dark') { $third_color = "aaff00";$captch_stroke = 'dark'; } else { $third_color = "6f6f6f";$captch_stroke = 'light'; } } <script src="<?php echo get_template_directory_uri();?>/scripts/motionCaptcha/motionCaptcha_<?php echo $captch_stroke;?>.js"></script>

Hmm you seem to be talking about "custom change events" like we know what they are?

Google's "cache" is probably just a nice name for the latest version of a web page they have on disk.

Looks amazing http://vanilla-js.com/

Skype is a common one to cause problems, apparently. By default it runs on port 80. I don't know why they thought that would be a good idea though?

Well to be honest, those are the kind of problems you'll face splitting out the logic of what title to display, from the logic that actually determines what title should be displayed. If that makes sense?

Just to add, what you have here: document.body.onload = window.setTimeout("fireMyPopup()", 1500); Despite the fact that document.body.onload doesn't actually exist, you're not binding the timeout to the onload event like you may be expecting. What you're actually doing is immediately invoking the setTimeout() function and storing the returned timer ID to the onload property. That means even if the page took a further 2 seconds to load for whatever reason, fireMyPopup() would be called after 1.5, and possibly before the resources needed to render it are available. You need to store a callback at window.onload, or as Xaotique mentioned, use the preferred window.addEventListener method.

If I were you I would steer clear of SOAP, if you can that is. The previous company I worked for used it extensively for communicating with the ERP and I hated it. Requests and responses are so needlessly bloated, which is a bigger issue when you're dealing with requests sent over an internet connection. Have a read up on the HTTP protocol -- you should be familiar with it for web development anyway. It's very light-weight and semantic, extremely well supported on any platform, and it's easy to build an API on top of (known as "RESTful APIs".) Cookies are part of the HTTP protocol, and are essentially just small bits of data stored on the user's computer the browser includes with each request. Have a read.

As far as I'm aware, you can't create custom builds of the core. Only the UI extension allows you to do that.

Hmm, what? All three of those are jQuery. In-fact, the last two are short-cuts for jQuery.ajax.

You need to look into AJAX.

I'm guessing you have a shared "header.php" type file you include across each page? Just define a default config array within your header file, and allow each page to override it: header.php $defaultConfig = array( 'title' => 'Your Site', 'description' => 'Your site description', 'keywords' => 'your, site, keywords' ); $config = array_merge($defaultConfig, isset($config) ? $config : array()); about.php $config = array( 'title' => 'About page' // Default description and keywords will be used as we omitted them here ); include 'header.php'; Keeps it nice and simple, and avoids a huge switch statement.

Don't know CI much, but ordinarily you would assign it to the view from within the controller. An nope that's not the correct syntax; print_r is a function. Check the manual for some examples.

You've essentially just described how sessions are retained normally. Cookies are sent in the request as a header: Cookie: foo=bar; baz=quz One of the key=value pairs is the session cookie, generally a hash, which refers back to a session file on the server containing a bunch of serialised data. You could simulate this through a different header, or as normal through the Cookie header if you want. I've never actually used "NuSoap", but it just looks like a wrapper for SOAP. Personally I would keep the authentication process within the realm of the API implementation, not the server listening for the API requests. I'm not sure if this actually happens, but it's perfectly possible you might not send SOAP requests over HTTP. Much like a session cookie though, you could have a session/authentication hash passed back and forth between requests.

You could just use PuTTY to access the server's VI(M?) editor (assuming it's Linux). That's real easy to transport, heck it's even available as an iPhone app now!