I've got a weird problem going on that ended up leading to an app rejection by Apple. It has to do with the custom HTML/Doc plugin. Fortunately, I fixed it so now I can resubmit. Here's what happened, in case it helps anyone else. I created several screens using this plugin so my client could easily change the content. Everything loaded fine in my app. I submitted it to the app store and then changed the app from my admin account to his account on my control panel. When I got the rejection notice today, I was informed that the reviewer was getting "check your internet connection" errors on the screens that used that plugin. After a little investigation, I found what I'm calling strange. If I take the dataURL for one of those plugins and throw it in my browser, I get a 404 error. However, if I navigate to the same folder via FTP and download the file to my computer and open it in my browser, it opens just fine. As it turned out, the issue was not related to switching the app to a different user account. It was related to a security feature. After submitting the app, I begun the process of migrating my entire website over to the server where my self-hosted control panel resides. It's still an ongoing process. But the important thing was that I edited the .htaccess file to allow .html files to be processed as .php files ... site-wide. On my main website, this isn't an issue. I don't allow .html files to be uploaded anyway. But with self-hosted, clients can create .html files using the Custom HTML/Doc plugin. That would be VERY BAD if they could insert php statements into those without my knowledge. Like bad to the point of getting a free account for themselves, or deleting other people's data. Fortunately, built-in security measures put a stop to it. I don't know if this is something Buzztouch looks for or if it's on my server. But outside of my self-hosted folder it works just fine. If it's something @David built in, I have to say, thank you! How did I solve this issue? I created a new .htaccess file for my self-hosted folder, with this command in it: AddHandler text/html .html .htm

Thanks, good solution. Glad to have known you during the formative years ... You're gonna be a tech superstar! :-) -- Niraj

@Niraj. LOL. @Chris1. Nice bit of Sherlock Holmes, I must say. Wot?

This is a good find Chris; Thanks! Sorry for your rejection, but glad you got it sorted out! Cheers! -- Smug

Short answer: I'm glad you ran into this Long answer: Moving stuff around is always tough. Well, that wasn't too long but you get the idea. It sounds like you figured out what most folks get lost on, super fast. 404 and other "messages" are commonly referred to as errors. They aren't errors actually but we humans refere to them as errors because it's lame when they happen! Ha. 404 is a valid "response" from a web server (Apache in this case) telling you that "Hey, I'm Apache and I can't find the file you're looking for" Super useful info for any Sherlock Holmes trying to sleuth out what's happening. Comine Apache with PHP (two entirely different software solutions) and the messages get even more fun to diagnose. But, always remember that Apache is the ONLY thing answering your browser...or device...PHP returns NOTHING to a browser or a phone - this is Apache's job. If Apache can't find a file (404) it doesn't necessarily mean the file doesn't exist, it oftentimes means that Apache can't READ the file. This is almost the same but different. There are tons of ways to setup security in Apache, in terms of who can read what files. 99% of the time .htaccess files are used to control this sorta thing. I'm not advocating or slamming this approach, it's just fact. .htaccess files are easy, flexible, and uber-quick to implement. I run down these steps when I get a mysterious 404: 1) SSH or FTP into server and make sure the file exists. Literally put your eyes on it. 2) Check the file's permissions. Who owns it? Who can read it? Can PHP? Do you know what Linux (yet another piece of the puzzle) user account PHP is running under? 3) Use a regular browser and paste the URL in the address bar - what do you get? Fix whatever you need to get the file delivered to the regular browser. Chrome, Safari, Firefox, Explore, they all make regular HTTP requests for files - exactly like your phone or tablet does. If the browser can't fetch it, neither can your phone. If the browser can, so can your phone.

Thanks David - that sheds a lot of light on this. I admit, Apache is something I don't know much about...mainly because I haven't needed to before. I'll have to do some reading on that before long. ;)

Oops - guess I got logged out before I could post that!

Nice work. BT PHP Injection Attack prevented! I ran BackTrack against a test BT Server and it was pretty hardened. But it's vulnerable just like any box on the public internet if someone really wants to own it. You could also look at mod_rewrite to hide the .php extension and give the impression you're just serving up html. If you want to tinker with Apache more - check out MAMPP and XAMPP. Great local tool to learn on and then you won't be disturbing your production enviroment. I like the GUI on XAMPP a little better. Love Apache server - she is THE workhorse of the internet.

Are you interested in a Webinar on the LAMP Stack? David said he would do it for us.

I would be.