requinix

Either (a) you're not in Africa/Lagos, which would be a silly mistake to make, (b) your timezone database is out of date, but probably not given that Africa/Lagos doesn't do DST, and/or (c) your server's clock is set incorrectly.

You cannot control how the browser gets the video from a capturing <input>. If you need more control of that process then you'll have to get the video another way.

All that code in InitializeData should be inside the constructor instead. There is no need for InitializeData to exist. It forces you to call that method every time you create a new instance of MainframeData, and if you forget then you get problems like the one that started this thread. If you need to set up appVer and appTitle when the object is created then you should be literally setting up appVer and appTitle when the object is created.

If you've found explanations about how to use functions like getimagesize() and imagecreatefrom*() to validate images, then you can do the same thing with your uploads with only a couple adjustments: substitute getimagesizefromstring and imagecreatefromstring to work on your $decode data.

Did you write the code for the MainframeData class? If not, where did it come from?

You already know that the appTitle is set by InitializeData. If you don't call InitializeData then there will be no appTitle. All that InitializeData code should exist in the constructor anyways. Move it and you won't have to call any special methods before you can use appTitle.

What's the code where you call it? Is it part of the code you posted before or is it written somewhere else?

Have you tried calling that get_appTitle() method?

If the filename is title + genre + year then you're going to have to identify each piece. The genre will either have to be a single word (so you know the last "word" in the filename was the genre) or one from a specific list, the year is obviously the numbers at the end, and the title would be everything else.

No. Just because you found code posted somewhere on the internet does not make it open source. You can make whatever changes you want but I expect you're going to have a very hard time making it work without using cameratag.com's systems and APIs.

Are you even sure there was a "Titanic" movie in 1990?

If you search for "app-id" in the code you'll see that UUID gets sent to the new_video() function, which makes API calls to www.cameratag.com. Please, please, please, don't go finding Javascript code snippets out there and just copying them into your site without knowing 110% exactly what they do. That's the kind of mistake that results in lawsuits with terms like "monetary damages".

What about the time to maintain this code? There is more than just writing the code and saving the file. What will you do if you have to come back to this file again in the future? What if you need to do another similar AJAX feature somewhere else? Your time to learn this is not a price to pay but an investment in yourself and your employer. Strider64 gave an example of how to do this. AJAX and mod_rewrite are two completely different things.

What "both ways"? Which one? I'm sure it can work, so there's probably something different about your code. Did you check that the HTML works in a regular webpage? What's the rest of the code?

I know what the answer is. It's to wrap your Array in a Proxy. If you don't like that answer then does that mean you want to shop around until you find one you like better?

If you need to use AJAX but don't know how then this would be a good time to learn. Are you using a Javascript framework? If so then see what it offers for AJAX support. If not then you should look into the Fetch API - not XMLHttpRequest, that's mostly obsolete, but the fetch() function and stuff related to it. What you would do is, when someone clicks the button to "submit" the "form", you create a Request with appropriate information (eg, a URL, the POST method, and FormData body), give that to fetch(), and it will give you a Response that you can read from.

If you don't want the page to do anything then use AJAX instead of a <form>. So yes, AJAX can definitely do what you want.

Worry about "clean" and "minimal" once you have stuff that works, first.

You mentioned AJAX in the title so... how about that?

Take a look at Proxy.

On the screen as people are taking the video? I would be very surprised if that was possible. If you need to tell them something, do so on the page before they activate the control.

Once it's installed, sure. But it's not installed by default.

If you need something simple to test a simple site then you can use PHP's built-in server. If you need something more complicated then you're going to have to spend disk space to get it. If you don't need a database then you can install Apache/nginx on its own - if you don't mind configuring them yourself. No? But it is available to install - at least in Pro, not sure about Home.

Apache and PHP do not want to own files. They want to be able to read files, and just like books from a library, they do not have to own the files to be able to read them. For the shared server, you need to find out whether PHP runs as its own user or as your same user account. You must answer this with a webpage, not from a login shell: a webpage that echo exec("whoami"), or uses phpinfo(), or some other method. If PHP runs as the same user as your own account: - All files and directories should be owned by your user account and group - File permissions should be 0640 or 0644 - Directory permissions should be 0750 or 0755 - If you need to support file uploads, nothing special has to be done. Do not use 0777 permissions. If PHP runs as a different user from your own account, such as "www-data": - All files and directories should be owned by your user account and group - File permissions should be 0644 - Directory permissions should be 0755 - If you need to support file uploads: create a special directory for the files (such as "uploads") and set permissions 0777. For your own server, if you want it to have the same website as the shared server then you should make it use the same Apache + PHP setup (mod_php or php-fpm) and with a different user from your regular account (such as "www-data"). Using the same setup is a good way to know that what works on this server will also work on the shared server.

"Won't post" isn't a particularly helpful description. What have you done to troubleshoot this yourself so far? Checked for error messages? Spam folders? Tried using different email accounts, both for sending as well as receiving?